Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!dibble
From: dibble@rochester.ARPA (Peter C. Dibble)
Newsgroups: comp.sys.m6809
Subject: Re: OS9 ACIA device driver
Message-ID: <23868@rochester.ARPA>
Date: Thu, 15-Jan-87 23:51:50 EST
Article-I.D.: rocheste.23868
Posted: Thu Jan 15 23:51:50 1987
Date-Received: Fri, 16-Jan-87 20:52:53 EST
References: <750@vaxb.calgary.UUCP>
Organization: U of Rochester, CS Dept., Rochester, NY
Lines: 53
Keywords: OS9, device driver questions
Summary: Explanation of SCF driver

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.