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