Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!pt!andrew.cmu.edu!ww0n+
From: ww0n+@andrew.cmu.edu (Walter Lloyd Wimer, III)
Newsgroups: comp.sys.m6809
Subject: Re: Bit Banger port still won't input
Message-ID: 
Date: Tue, 30-Jun-87 19:23:49 EDT
Article-I.D.: andrew.wUu4W5y00UoBpDU0Gz
Posted: Tue Jun 30 19:23:49 1987
Date-Received: Sun, 5-Jul-87 20:28:57 EDT
Organization: Carnegie Mellon University
Lines: 62




In message <889@sdcc13.ucsd.EDU> mu106sbn@sdcc13.ucsd.EDU (Stephen
Hartford) writes:

>In art <934@vaxb.calgary.UUCP> ingoldsby@calgary.UUCP (Terry Ingoldsby)
writes:
>>  Has anyone managed to get the CoCo III serial port to read
>>data under OS9 Level II. 
>>Does anyone know if T1 works on input?  Did Tandy use the
>>timer or interrupts in reading the port?  Can Tandy write drivers?
>>
>>                                        Terry Ingoldsby
>>                                    ihnp4!alberta!calgary!ingoldsby
>
>I can't speak for the technical aspects of the CoCo 3 port, but I
>can relate what our experiences have been at Computerware. We were
>trying for a long time to get a driver for the serial port to work
>under Level 2, and eventually were told BY TANDY to not waste our
>atime. The way they see it, the internal port is only for rudimentary
>operations such as printers. Their offical policy is that you need
>an RS-232 program pak to use a modem under Level 2.
>
>
>                      Stephen Hartford, programmer (a.k.a. student)
>


I just purchased Level II and had no problems using the bit banger port.
What I did notice, though, is that the driver seems to eat up an incredible
number of time slices since the shell running on my CoCo 3 console
responded very slowly to my keystrokes.  I left the console shell at a
priority of 128 and setpr'd the shell on /t1 to a priority of 1.  This
helped, but it still didn't match the performance I used to get with Level I.

A bug which exists in both the Level I and Level II bit banger drivers
concerns special control characters such as ^C, ^E, ^W, etc.  Using
"dump /t1" verifies that these characters make it through the port, but
their associated signals never reach the appropriate processes to cause
the expected action.  Does anyone know anything about this?

By the way, I created a shell on /t1 with the command "shell i=/t1 &" since
we don't have a login program with "Personal OS-9."  Just out of curiosity
I tried running the Level I tsmon and login programs.  I once disassembled
login and discovered that it changes the user id number by writing to an
address in low memory using absolute addressing!!!  Needless to say this
totally violates the OS-9 philosophy and creates an incredible security hole.
(Well, who ever said OS-9 was very secure in the first place).  Of course, on
Level II this hack doesn't work since even absolute addresses don't
necessarily reference the same physical memory locations.  I don't know
what it IS changing, but I don't intend to find out the hard way by leaving
myself open to random system crashes.  I'm not sure exactly what tsmon
does and whether it could have adverse effects.


Walt Wimer
Carnegie Mellon University


Internet:  ww0n+@andrew.cmu.edu
Bitnet:    ww0n+%andrew.cmu.edu@cmuccvma