Re: The Apple IIGS ADB Keyboard Lives!

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

Jay Krell <jay.krell@cornell.edu> wrote:

> Is there something to the suggestion that:
> 
> For some reason, an ADB keyboard driver cannot be as reliable as the built
> in firmware?

Correct.  If you use the standard keyboard support, everything is
handled by the ADB microcontroller, which shoves decoded keys into the
$C000 register along with modifier keys in $C025, and handles buffering
internally.  This is 100% compatible with all existing Apple II software
that polls the keyboard directly.  (Slightly less compatible if
buffering is enabled.)

If you need to do something special, e.g. support a non-standard
keyboard or reinterpret keys, then you need to disable the standard
keyboard support and poll the keyboard directly.  This requires an
interrupt handler, which gets called when a keypress (scan code)
arrives.  The interrupt handler then makes use of the feedback mechanism
provided by the ADB microcontroller to emulate the standard keyboard -
the interrupt handler pokes translated scan codes into a register, and
the ADB micro treats them as if they had come from the original
keyboard, resulting in keys appearing in $C000 and $C025, as normal.

The problem: if a program locks out interrupts, then keys will never
arrive.  The keyboard scan code arrival can't interrupt the main
processor, and therefore the keypress never gets presented.

If a program locks out interrupts and sits in a loop waiting for a
keypress, the computer hangs indefinitely, and you have to reboot.

> Witness the flakines caused by, what are they called, "stick"
> and "mouse" keys? on ROM 1 via a System Software update that works fine
> built in to the ROM 3? Something to do with interrupts? The built in
> firmware works with interrupts disabled, but drivers do not?

There is no built-in firmware driver (as such) for handling the standard
keyboard - it is done in hardware, as far as the 65816 is concerned (it
is actually firmware in the ADB microcontroller).

> Though I think enabling buffering on the ROM 3 also caused compatibilty
> problems..

Enabling buffering on any IIgs model can cause problems, due to programs
making assumptions about how the keyboard interface is supposed to work.

The problem occurs when a program thinks it is OK to ignore an unwanted
keypress without clearing the buffer.  For example, if the program is
waiting for a specific keypress (e.g. Space) , it might use code like
this:

WAITKEY:  LDA $C000           ; Poll the keyboard
          CMP #$A0            ; Is it a space?
          BNE WAITKEY         ; No - go back and try again
          STA $C010           ; Clear the keypress

If you press the wrong key (e.g. Return), then $C000 will contain
another value with bit 7 set (indicating a keypress is waiting).  This
is where the buffering problem kicks in.

The above code works fine on the IIe and earlier machines (and on the
IIgs if buffering is disabled), because pressing another key will
replace the previous contents of the keyboard buffer ($C000).  If you
press Return then Space, the program will initially see $8D in the
register, then it will change to $A0.

On the IIgs with keyboard buffering enabled, the first keypress is not
replaced with the second one until the program clears the keyboard latch
by accessing $C010.  This means that the Space key is held pending until
the Return key is "acknowledged" by the program.

The only way out of this kind of problem is to flush the keyboard buffer
(Apple-Shift-Delete, if I remember right), then press the correct key.

The program can avoid this sort of problem by modifying its code as
follows:

WAITKEY:  LDA $C000           ; Poll the keyboard
          BPL WAITKEY         ; until a key arrives
          STA $C010           ; Clear the keypress
          CMP #$A0            ; Was it a space?
          BNE WAITKEY         ; No - go back and get another key


I believe similar problems can occur with keyboard buffering enabled on
the IIc, but it works using a quite different mechanism and is likely to
have different symptoms.

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