sdyer@bbncca.ARPA (Steve Dyer) (12/21/83)
I have just purchased the R/S ACIA RS232 card for my CoCo, and I would like to write a device driver for it to replace /t1, which now uses the same bit-banger as /p. I can read the Tandy/Microware Technical Information doc, but that takes me only so far. Namely, I can't figure out how to get there to a working, assembly language device driver module. Now, UNIX block and character device drivers have canonical forms, so that if you've seen one, you can easily write a new driver for a new device. Can anyone supply me with a similar boilerplate for OS-9 device drivers? Does anyone know if Microware supplies more detailed documentation than what comes with Tandy OS-9? Thanks. -- /Steve Dyer decvax!bbncca!sdyer sdyer@bbncca
danm@mspiggy (Dan McCabe) (12/22/83)
Writing a new /T1 driver for an ACIA has been my ongoing project for the last few weeks. It turns out that a disk device driver is easier to write reliably (or at least I thought that it was easier). One of the problems that I faced with the CoCo is that I can't write an interrupt driven device driver (or at least not with IRQ) because the IRQ line does not come out of the box. Without an interrupt driven driver, you will lose characters if too much else is going on. Although you can't make the driver run off IRQ (and get OS9's help in data space management), you can run it off of NMI or indirectly off of FIRQ (via port CART line). The former is not recommended because the disk driver uses that line. The latter is indirect because the CART line goes to a PIA, which then generates an interrupt. I tried this approach without too much success (i.e., CoCo hangs on me for who knows what reason). The best success that I have had is with a device driver that forks off a scanning process which monitors the ACIA at regular intervals (i.e. 60 times a second). This subprocess feeds a circlular read queue and consumes a circular write queue. The main device driver then feeds the same circular write queue and consumes the read queue. These queues are shared by the driver and the scanner and reside in the data area of the driver. The forked process knows about this area because the initialization routine of the driver, which forks the scanner, puts the adress of its data area (the U register) in a buffer and then passes it in the parameter space to the scanner. When the scanner starts up, it loads its U register with this passed parameter. Thus, they share the same data space. When you use this approach, you need to use some sort of mutual exclusion mechanism to prevent simultaneous access to the buffers and their pointers. I just lock out interrupts while reading and writing the queues. This approach to the RS232 driver works fine most of the time. I still occasionally drop a byte, but I suspect that that is the fault of my disk driver (note: I only lose bytes when I copy the output of /T1 to a disk file; otherwise, I don't lose anything). I hope this helps you. Happy hacking, Dan McCabe decvax!microsof!danm
sdyer@bbncca.ARPA (Steve Dyer) (12/24/83)
What IS the IRQ signal used for in the CoCo? I swear, with every technical turn I take, I am faced with more and more moronic decisions. I've verified that the R/S Disk Controller uses a WD1793 FDC chip which does not support side-select, and now I find out that IRQ doesn't come out of the cartridge slot. (There's still the open question of whether the "Deluxe RS232 Pak" even attempts to bring the ACIA interrupts out onto the bus--probably not, given the cartridge bus.) I suppose that it should be possible to feed IRQ signals directly to the 6809's IRQ pin IFF there are not conflicting uses for it. What does the 60hz line clock use? If it uses IRQ, it would not seem incompatible with other devices. What does the bit-banger RS232 input line use? Dan, I congratulate you on your ingenuity in the face of terrible design decisions. I take it that your clock-driven /t1 should still work with protocols like KERMIT or UMODEM even in the face of lost input characters, simply because they provide a reliable protocol layer. Right? My request for boilerplate still stands, however. A good, canonical non-proprietary example of an OS-9 driver (not necessarily containing CoCo vagaries) would be of great interest to me, and probably to the other members of this group. Can anyone out there help? -- /Steve Dyer decvax!bbncca!sdyer sdyer@bbncca
danm@mspiggy (Dan McCabe) (12/30/83)
For those of you who want to do any sort of expansion of your Coco, I highly recommend Radio Shack's Color Computer Technical Reference Manual. It should be available from your local friendly RS dealer. It contains theory of operation, schematics, etc. and is well worth the $14 that RS charges for it. Regarding the KERMIT and UMODEM protocol support with my /T1 driver: I cannot say whether it will or will not work with my driver, since I know nothing about either of those protocols. Sorry. Regarding the IRQ line of CoCo: this line is used for 60 Hz interrupts which are generated by SAM. Both IRQ and FIRQ (and NMI) are open-collector lines. This means that they can be driven by multiple (open-collector) drivers to get a wired-or effect (the line will go low when any one of the drivers goes low). Unfortunately, access to IRQ is available only by cutting traces (I have considered making CART go to either IRQ or PIA depending on external switch setting). When you have multiple devices generating IRQ, you need to know which device generated IRQ. OS/9 significantly helps in this task by scanning all possible interrupt generators that it knows of. When one is found, the appropriate routine is executed. You must inform OS/9 about such a device by giving a location, bit mask, and interrupt handler pointer. From what I have been told, Microware used to provide said boiler plate routine in their older documantation. Apparently, they have discontinued this practice. If sufficient interest warrants, I will post a minimal ACIA driver. Happy hacking, Dan McCabe decvax!microsof!danm