Re: Apple2 keyboard connector pinout

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

James P. Meyer <jimbob@acpub.duke.edu> wrote:

> On 27 Oct 1996, Artur Jasowicz wrote:
> 
> > I wonder if you (or anyone) know how keyboard knows when to send next
> > keystroke. For my clone I used to have a keyboard with its own CPU (6800)
> > and it seemed to know when Apple was busy, say, reading a floppy. It would
> > then store keystrokes in buffer and send them later. Is this possible or
> > was it too long ago and I just don't remember?
> 
>       My WAG is that the buffer is inside the apple and not the 
> keyboard.  There is a lot going on in there.  Just because it *looks*
> like the computer is busy with the disk drive, it doesn't mean it isn't
> doing *bunches* of other stuff.  Like video display, RAM refresh cycles,
> and keyboard input buffering.  The CPU services each one in turn fast
> enough to make it seem that it's all happening at once.

On which planet?  :-)

In all Apple II models, the CPU is concentrating exclusively on disk I/O
while it is accessing a floppy drive (at least for 5.25" drives, and for
a directly connected 3.5" drive).

Video generation and RAM refresh are done by external hardware, not the
CPU.  In the IIe and IIc, this is the IOU chip (Input/Output Unit); the
][ and ][+ use discrete logic to implement the video circuitry.

Every CPU cycle is divided into two phases. During the first phase, the
next byte of video data is fetched from the appropriate buffer (two
bytes are fetched in parallel from main and auxiliary memory on an Apple
IIe while in double resolution modes).  During the second phase, the CPU
gets to access memory.

Memory refresh occurs as a side effect of the video access cycles.


The Apple IIe and earlier models do not have any "keyboard buffering",
except for the single byte provided by the keyboard scanning chip
(AY-3600-PRO).

In the IIe, the keyboard is handled as follows (somewhat simplified):

The AY-3600-PRO has direct connections to the column and row matrix of
the keyboard.  It continually scans the keyboard, watching for any key
being pressed.  This is used to generate an "any key down" flag, which
is available by reading memory location $C010 and examining bit 7 (this
signal is not available in the Apple ][/][+).  [The modifier keys are
handled independently.]

When a key is pressed, the AY-3600-PRO latches the row/column pair, and
sets a "key strobe" flag.  This can be detected by reading memroy
location $C000 and examining bit 7.  A subsequent keypress will
overwrite the last row/column pair.  Accessing location $C010 clears the
strobe flag.

The row/column pair is used in conjunction with the Control and Shift
keys as inputs to the keyboard decoder ROM.  A value from this ROM is
output via bits 6 through 0 when the computer reads location $C000.  (If
the strobe has been cleared and no further keypress has occurred then
the same ASCII value will be returned, but bit 7 will be clear.)


I'm less familiar with the II+ keyboard design.  The main difference I'm
aware of is that the keyboard scanning chip is on the keyboard's
piggyback board, rather than the motherboard.


In the IIc, there is an optional interrupt-driven keyboard buffering
facility.  It works by interrupting the processor through the DSR input
of one of the 6551 ACIA chips whenever a key is pressed (strobe flag).
The IIc then reads and buffers the keypress, which can subsequently be
returned through the standard firmware entry points.  If keyboard
interrupts are enabled, programs which rely on accessing the hardware
directly don't work.


In the IIgs, keyboard buffering is provided in hardware: the ADB
microcontroller can buffer up to 16 keystrokes (with all modifier keys),
and they are delivered to the IIgs through the standard $C000/$C010
interface (with modifiers passed via $C025).  The IIgs Event Manager
provides additional buffering in the event queue (the keyboard is polled
via a VBL-triggered timed interrupt).  The keys are then provided to
applications via the Event Manager, or though the standard firmware
entry points.

(If the Event Manager is not active, then the simple buffering provided
by the keyboard microcontroller can still be used with programs that
poll the keyboard hardware directly.)

-- 
David Empson
dempson@actrix.gen.nz
Snail Mail: P.O. Box 27-103, Wellington, New Zealand