Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site uokvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!inuxc!pur-ee!uiucdcs!okstate.UUCP!uokvax.UUCP!emjej
From: emjej@uokvax.UUCP
Newsgroups: net.micro.6809
Subject: Re: Request for os9 info
Message-ID: <3500142@uokvax.UUCP>
Date: Wed, 2-Apr-86 12:26:00 EST
Article-I.D.: uokvax.3500142
Posted: Wed Apr  2 12:26:00 1986
Date-Received: Sat, 5-Apr-86 11:35:31 EST
References: <8700004@hpvcla>
Lines: 79
Nf-ID: #R:hpvcla:8700004:uokvax.UUCP:3500142:000:3335
Nf-From: uokvax.UUCP!emjej    Apr  2 11:26:00 1986


The following is posted on behalf of a friend who can't post notes...
----------------------------------------

From: chinet!draco@ihnp4.UUCP

> From: davel@hpvcla.UUCP (Dave Lowe)
> Subject: Request for os9 info

> What happens to os9 if it gets handed a character with the most significant
> bit set?  My input driver carefully strips the bit before passing the 
> character on. The keyboard I have has several special function keys and I
> have thought I could flag these keys with the most significant bit.

The device driver does have the major responsibility for allowing eight bit
input. However, some older versions of SCF strip the eighth bit during the
editing functions of the ReadLn and WritLn calls. This was changed in edition
eight (8) of SCF, but I don't know whether the offending code was present in
ALL of the previous versions. In any event, using Read and Write will avoid
the problem. One other point to consider is setting the ACIA for eight data
bits and NO parity.

> My documentation gives precious little information about the register setup
> on the entry into a driver's interrupt routine. Could someone enlighten me?

Only TWO registers have any meaning on entry to the interrupt handler. The
A register, which contains the status register contents after processing by
the mask and flip bytes. And the U register, which points to the device's
static memory area. The DP is set to zero (00) as always on entry to a
device driver.

> What is the purpose of the BITA #1 instruction that always seems to be at
> the beginning of the routine?

If the driver you are a referring to is for the 6850 ACIA, the BITA #1 is
to determine whether the interrupt is an input (bit 0=RDRF= Receive Data
Register Full) or an output (bit 1=TDRE= Transmit Data Register Empty).

> The documentation of getsta/setsta is somewhat confusing. If I remember
> correctly the section on the getsta/setsta driver entry points claims
> that RBF and SCF handle all current status requests. Implying that the
> driver need not worry. Of course this is not true.  The device ready status
> request is at least one that the driver needs to handle. By looking at
> the system calls for getsta and setsta I have concluded that the most of
> the setup and expected return values are passed directly/returned from the
> driver, at least in the device ready case. Is there some better documentation
> on these entry points? New documentation would likely explain when and how
> the getsta entry should return the number of bytes available to be read.

The following is a list of those getstat/setstat calls which are handled
directly by IOMan or the file managers:

Get Status calls handled by IOMan:
 SS.OPT SS.DEVNM

Set Status calls handled by SCF:
 SS.OPT

Get Status calls handled by RBF:
 SS.EOF SS.READY SS.SIZE SS.POS SS.FD

Set Status calls handled by RBF:
 SS.OPT SS.SIZE SS.FD SS.RSBIT

ALL other get/setstat calls are handled directly by the associated driver.

The SCF device SS.READY Get Status call functions as follows:

Entry Conditions> A=path number B=$01

Exit Conditions> If ready: CC=Carry Clear B=#of bytes available

Exit Conditions> Not ready: CC=Carry Set B=$F6 (E$NOTRDY)

To add this to an existing driver will require adding a character counter
to the input and output routines.

Kent D. Meyers
ihnp4!chinet!draco