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