Re: Input/Output Hardware Protocol?

[dempson@atlantis.actrix.gen.nz (David Empson)]

Please note that I've cross-posted this to the programmer subgroup and
directed followups there.

In article <4bbub3$e2c@yama.mcc.ac.uk>,
Duncan Entwisle <duncane@jumper.mcc.ac.uk> wrote:
> I'm thinking about trying to implement a mouse driver on the Apple //e, 
> that, within my abilities, mimics the functionality of the original version.

I assume you are referring to the IIe mouse card?  The IIe doesn't
have a mouse "driver", as such.

The mouse card contains hardware to interface to the mouse, firmware
support for the Apple II, and its own microprocessor (a 6805, I think)
which actually polls the mouse.

What sort of mouse are you thinking of using, and how do you intend to
interface to it?

> How does the Apple //e handle cards with respect to basic (in terms of 
> the hardware, as opposed to the software). When BASIC attempts to receive 
> input from slot 3, what signals are generated to the card for that 
> request, likewise what happens when printing to a slot (etc)

Nothing special.  It is all to do with the firmware.

When you do a PR#n, the output hooks ($36 and $37) are set to $Cn00.
When the next character is output, the firmware on the card gets
control.  Its first action is usually to initialize itself, then it
changes the output vector to a different location within the card
(usually $Cn07 for output).  Subsequent characters are output via the
output hooks, which now point to the entry of the output code on the
card.

The card firmware is responsible for dealing with any hardware it
needs to access, bank switching the ROM (to access the $C800-$CFFF
space), etc.

An IN#n is similar: the input hooks ($38 and $39) are set to $Cn00.
The next input request causes the firmware init code to be called.  It
changes the input vector to another location, usually $Cn05, then
returns the first input character.

If you do both PR#n and IN#n, both vectors will usually be adjusted by
the first input or output call.


The above description applies to the BASIC firmware provided by nearly
all I/O cards.  Many cards also support the Pascal 1.1 firmware
interface, which works through an entry point table in the $Cn00 page.
The Pacal firmware is much more flexible than the BASIC firmware,
because it can separate out the INIT operation from an actual read or
write, and a STATUS routine is provided so that the program doesn't
have to block while waiting for I/O.

The mouse card supports the BASIC interface for a simple poll-only
method of reading the mouse.  It doesn't directly support the Pascal
1.1 firmware interface, but it does provide the entry point table.  It
also has a large set of additional calls (also accessed via an entry
point table) for more precise control of the mouse.  Most programs that
use the mouse work through this set of calls, not the BASIC firmware
interface.

Note that the IIc and IIgs mouse firmware is closely compatible with
the IIe mouse card.
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand