Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site mspiggy
Path: utzoo!linus!decvax!microsoft!mspiggy!danm
From: danm@mspiggy (Dan McCabe)
Newsgroups: net.micro.6809
Subject: Re: Wanted: OS-9 Device Driver Boilerplate
Message-ID: <123@mspiggy>
Date: Thu, 22-Dec-83 15:13:50 EST
Article-I.D.: mspiggy>.123
Posted: Thu Dec 22 15:13:50 1983
Date-Received: Sat, 24-Dec-83 04:37:41 EST
References: <410@bbncca.ARPA>
Organization: Microsoft, Bellevue, WA
Lines: 36

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