ingoldsby@calgary.UUCP (05/29/87)
I already asked this question, but all of the suggestions I got have proved
unsuccessful. Has anyone managed to get the CoCo III serial port to read
data under OS9 Level II. I have thoroughly checked my connections, but
nothing. I've tried terminal programs, COPY /T1 /TERM, etc. and nothing
works. The CoCo echos characters back to the sender, but never seems to
return a value to the reading process. After a (long) while, the buffer
seems to fill and subsequent characters arriving at /T1 cause a BELL to be
echoed. 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
P.S.
I know the hardware works 'cause an ancient, very rudimentary terminal
program I wrote for the original CoCo works fine.mu106sbn@sdcc13.UUCP (06/03/87)
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 time. 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. It would have been so pitfully easy to implement a lost-cost, effective real serial port on the CoCo 3, it's frustrating. It seems to be another one of the self-imposed limits by Tandy (like 512K) to limit the marketing potential of the 3, so as not to interfere with the Tandy 1000, etc. Sad, but true. -- Stephen Hartford, programmer (a.k.a. student) /// -- \\\/// Internet: mu106sbn%sdcc13@sdcsvax.ucsd.edu \/// UUCP: ...!sdcsvax!sdcc13!mu106sbn
ww0n+@andrew.cmu.edu (Walter Lloyd Wimer, III) (07/01/87)
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