NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/ibm/pc/hardware/20076

Text File | 1992-07-22 | 6.5 KB | 132 lines

Newsgroups: comp.sys.ibm.pc.hardware
Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!news.iastate.edu!rjhoffma
From: [e-mail] (Richard J. Hoffmann)
Subject: Keyboard, BIOS problem: Stuck shift key
Message-ID: <[e-mail]>
Keywords: Keyboard, BIOS, INT 9
Sender: [e-mail] (USENET News System)
Organization: Iowa State University, Ames, IA
Distribution: usa
Date: Wed, 22 Jul 1992 15:32:27 GMT
Lines: 119

I have a 486-33 with a generic clone motherboard (Taiwanese, no
name that I can find) with an AMI BIOS.  The machine has a problem
handling the enhanced keyboard.  Specifically, the keyboard often
spontaneously locks as if all keys are shifted.  Also, the
enhanced keys, including the arrows, Delete, PgUp, etc., sometimes
return their equivalents on the numeric keypad (e.g., the enhanced
arrows return 4, 8, 6, or 2, depending on which is used).  The
latter seems to be cured if I turn off the numbers lock.  The
"stuck" shift key (and once the control key) problem persists.

The problem is apparently not peculiar to my machine.  The dealer
has three customers with a similar complaint.  Initially they
blamed the problem on WordPerfect 5.1, but I have the trouble in a
variety of settings.  It's especially bad when I connect to a DEC
system through the ethernet.  They replaced the keyboard BIOS
without effect.

WordPerfect suggested trying software fixes supplied from their
BBS that fiddle with the handling of INT 9.  These don't fix the
problem for me.

If anyone has heard of this problem, and especially if you know
the solution, I'd be grateful to hear it.  The dealer is baffled,
and I have a unit that is hard to use.  The discussion supplied
with the files from WordPerfect implies that this could be an AT-
BIOS problem, something I guess wouldn't be traceable specifically
to AMI.

In case it helps, I've attached below the discussion of the
problem that was included with the files I got from WordPerfect.

Dick Hoffmann
[e-mail]

   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


--
Richard J. Hoffmann              Internet: [e-mail]
Department of Zoology & Genetics   Bitnet: rjhoffma%iastate.edu@isumvs
Iowa State University               Voice: [phone]
Ames, Iowa 50011