KBFIX.DOC 18-Apr-1990

A problem involving incorrect keyboard data has been reported by
several LANtastic user's. When using enhanced (101-key) keyboards
with NUM-lock on, a "Left-shift on" state occasionally becomes active
when no shift key is depressed. The state can be cleared by pressing
and releasing the left shift key. Also, on some machines, an enhanced
key (Arrows, Insert, Delete, Home, End, PageUp, PageDown) are
occassionally decoded as their numeric keypad NUMlocked equivalents,
e.g. "2", "4", "6", etc.

The problem seems to stem from the fact that the enhanced keyboards
send a string of scan codes (4 scan codes when NUMlock is on) for
each press or release of the key. An E0 scan code precedes each of
the others, to indicate that the following scan code is to be interpreted
as "enhanced".

These four scan code are sent in rapid succession to the PC motherboard.
As each is received, an IRQ1 is activated, which invokes the ISR for
INT 09H. This ISR is initially set to the BIOS keyboard handler,
although it is later re-hooked by resident drivers such as REDIR.
One of the first things the AT-BIOS handler does is to inhibit the
keyboard from sending further scan codes until processing of the one
causing the interrupt is complete.

Unfortunately, before it does this, AT-BIOS executes an STI intruction,
allowing other interrupts (e.g., timer ticks) to interrupt the keyboard
ISR.

Provided the interrupting timer tick ISR executes quickly, and control
returns to the keyboard handler before the scan code is replaced by
a new one, no harm is done. However, TSRs (such as REDIR) often hook
into the timer (08H) interrupt and may prolong its service time by
a substantial amount. If two scan codes come in quick succession
(as with the enhanced keys, which send E0 followed by the keycode),
then the first one (the E0 in this case) may be overwritten by the
second and be lost. Thus, the next scan code is interpreted as
a non-enhanced keystroke (a shift key or a numeric key).

This problem would never occur if the BIOS would inhibit the keyboard
BEFORE it reenables interrupts. Unfortunately it doesn't, and the
BIOS cannot be changed.

Three solutions to this problem have been written. The first, and the
preferable one, is KBFIX.EXE. It should be run in AUTOEXEC.BAT
before any TSRs which hook INT 9 are loaded. It searches through
the MS-DOS INT 9 handler for DOS's hook into the BIOS keyboard handler.
When it is found, the hook is modified to point just AFTER the
offending STI instruction, thereby eliminating the possibility
of interrupt preemption until after the keyboard is disabled.
Unfortunately, it is necessary for a program of this nature to
take advantage of specific characteristics of DOS and BIOS. It has
been tried successfully on several 386 and 286 AT-BIOS implementations
with no problems. The program is smart enough NOT to make the
modification if a discrepancy is noted. Since the modification
is made within DOS, the program does not need to TSR, and no additional
memory is consumed.

If KBFIX.EXE cannot be used because INT9 is already hooked by a device
driver in CONFIG.SYS or the MSDOS is not compatible, the same effect
can be achieved by including KBDFIX.SYS as a device driver (ahead of
any other device drivers which hook INT 9) in CONFIG.SYS. The patch
will be applied directly to the BIOS INT 9 hook, and the driver
will not remain resident (no memory will be consumed).

For specific BIOS implementations where KBFIX.EXE and KBDFIX.SYS will
not work, the INT9FIX.EXE utility was written. It loads as a TSR (288
resident bytes) and hooks the keyboard (09h) interrupt. Before passing
control to the BIOS keyboard handler, it masks IRQ0 (the timer) so the
keyboard ISR cannot be interrupted. When BIOS returns, it restores the
interrupt mask for IRQ0 to its original state. INT9FIX should normally
be the FIRST TSR loaded which hooks INT9, so that timer interrupts are
masked for as short a time as possible. No ill effects from using this
program have yet been noted, but since timer ticks are disabled,
operation of the Print-Screen key, the INT15 scan-code translation
hook, etc., may be affected in some software configurations.

End KBFIX.DOC