Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!cornell!vax5.cit.cornell.edu!hd7x
From: hd7x@vax5.cit.cornell.edu (Sanjay Aiyagari)
Newsgroups: comp.windows.ms.programmer
Subject: Re: HIMEM/QEMM511/Problems with keyboard, shift state lock, etc
Message-ID: <1991Apr2.182856.3818@vax5.cit.cornell.edu>
Date: 2 Apr 91 22:28:56 GMT
References: <1991Mar27.064315.28498@dhw68k.cts.com>
Distribution: na,comp
Organization: CIT, Cornell University
Lines: 29

In article <1991Mar27.064315.28498@dhw68k.cts.com>,
philbo@dhw68k.cts.com (Phil Lindsay) writes:
> Has anyone experienced keyboard problems with their machines when
> running 386 memory managers or HIMEM?  The problems I am having
> are: 1. The shift state locks, the top QWERTY row of my keyboard won't
> produce numbers and the keys ",./" always input as "<>?" ... 2. When
> the cursor pad is used (not numeric cursor pad) I get single
> character 9's every once in a while when cursoring around. The
> problem seems to persist more when I run programs like PWB, TurboC or
> Brief.  ...Any ideas?  Thanks in advance. -phil

Yes, this exact problem happened on my friend's computer.  What was happening
was that for some reason, bit 0 of the BIOS shift state byte at 0:417 was
somehow getting and STAYING set.  Thus, the computer thinks the right shift is
permanently down.  To fix it, type the following program into DEBUG:

xor ax,ax
mov ds,ax
and byte ptr [417],f0
ret

Call this program whatever you want (say FIXKEY.COM) and put it on the line
following WIN in your AUTOEXEC.

This is quite a weird problem, and it was quite a challenge using DEBUG to do a
d 0:417 to check the shift status byte when I first saw this problem.  (I had
to use Alt+numeric keypad for all the numbers!)

Sanjay Aiyagari (hd7x@vax5.cit.cornell.edu)