Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cuae2!ihnp4!alberta!calgary!ingoldsby
From: ingoldsby@calgary.UUCP
Newsgroups: comp.sys.m6809
Subject: OS9 ACIA device driver
Message-ID: <750@vaxb.calgary.UUCP>
Date: Mon, 12-Jan-87 12:56:50 EST
Article-I.D.: vaxb.750
Posted: Mon Jan 12 12:56:50 1987
Date-Received: Thu, 15-Jan-87 21:35:37 EST
Organization: U. of Calgary, Calgary, Ab.
Lines: 54
Keywords: OS9, device driver questions

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!ingoldsby