ingoldsby@calgary.UUCP (01/12/87)
Some time ago I built an interface which incorporates an MC6850 ACIA into
my CoCo. I subsequently wrote an OS9 device driver which works (apparently)
just fine. Last week I bought Peter Dibble's book on OS9 and found that
the ACIA device driver listed therein does some things which I find a bit
mysterious. My driver works just fine, but I worry that I may have missed
something. Rather than send this directly to Peter Dibble, I post to
the net since I thought that the answers might be of interest to others.
Here goes:
On page 364 of `The Complete Rainbow Guide to OS9' is found the listing
of an ACIA device driver. Two things puzzle me with the ACSLEP routine
found on page 366.
Question 1: The first thing that occurs on either READ or WRITE is
the ACSLEP routine is called. This immediately puts
the process into an indefinite sleep. Consider the
following scenario. Suppose no output is pending so
the `buffer empty' (ACIA needs feeding) interrupt is
shut down and only input is being performed. Suppose
now that a process is busy doing something else (ie.
not executing device driver code) when a character arrives
at the ACIA causing the interrupt service routine to
be invoked. The driver terminates by executing the
WAKEUP section of code which determines that the process
is not asleep so it returns without sending a signal.
A short time later, the process decides to do a read, so
it branches to the READ routine, which in turn branches
to the ACSLEP routine where it goes into an indefinite
sleep. It seems to me that unless another character
arrives at the ACIA (thus invoking the interrupt routine
and this time sending a wake-up signal) that the driver
will continue sleeping and not return with the input
character. Am I missing something?
Question 2: Can someone explain the next section of ACSLEP that checks
the process descriptor to see if a signal is present. I
presume that this is necessary in case a signal happens to
arrive while the driver is being executed. Mine doesn't
have this code. What are the consequences of the omission?
Also, why is it necessary to check if the process is
`condem' (condemned?). How does this differ from `dead'?
Two general questions. When the device driver routines are entered
(eg. READ, WRITE, etc.) are the interrupts disabled? This is implied by
the fact that ACSLEP turns them back on.
Where does one find more lucid explanations about the direct page variables?
The one line (and frequently one word) explanations found in DEFS are
frequently insufficient. I presume that only routines running in
system state (like drivers, managers) can access the direct page variables.
True?
Thanks
Terry Ingoldsby
...!ihnp4!alberta!calgary!ingoldsbydibble@rochester.ARPA (Peter C. Dibble) (01/16/87)
In article <750@vaxb.calgary.UUCP>, ingoldsby@calgary.UUCP writes: > the ACIA device driver listed [in the Complete Rainbow Guide does some > things that seem] mysterious. > Question 1: The first thing that occurs on either READ or WRITE is > the ACSLEP routine is called. It only _looks_ like that's the first thing the read and write entries do. Both routines are loops that are not entered at the top. For instance, the read routine is entered ad READ, not READ00. You branch back to the bsr to ACSLEP if there is no data in the queue (at line 162). > Question 2: Can someone explain the next section of ACSLEP that checks > the process descriptor to see if a signal is present. The ACSLEP routine does a sleep for time 0. That will cause it to sleep until it gets a signal. The signal could be a wake-up signal from the interrupt handler, in which case the sleep routine should simply return to the caller. It could also be some other signal, which does not signal that data is ready and requires a return directly to the file manager with carry set. > Two general questions. When the device driver routines are entered > (eg. READ, WRITE, etc.) are the interrupts disabled? This is implied by > the fact that ACSLEP turns them back on. They are not. Read and write mask interrupts when they mess with the queues to prevent the odd problems which would occur if the interrupt routine should be started while they were working. > Where does one find more lucid explanations about the direct page variables? > I presume that only routines running in > system state (like drivers, managers) can access the direct page variables. > True? You will find some explanations of those variables salted through the Complete Guide. The most useful compilation is the memory maps in the back of the book. Level One programs can access the direct page BUT SHOULD NOT. Under Level Two all system data structures including the direct page are hidden in the system address space. You can get at them but you need to use the memory management system calls. It's best not to mess with them at all, but reading them is sometimes hard to avoid. I think there's a program in the Complete Guide that reads the system direct page. (After a quick look I see a program called getsysmem starting on page 317 that reads the first 4K of the system address space.) Peter Dibble ========== Please forgive me if this note looks like an ad for my book. I can't make the usual claims of commercial disinterest. Take any comments that sound like praise for The Complete Rainbow Guide with the appropriate amount of salt.