Date:	Sun, 18 Oct 1992 21:29:59 EDT
From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann 713-493-8756)
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	GO32 Keyboard handler

I also have need for a keyboard handler that can return raw scan codes (so I
can tell the difference between the Enter key on the keypad and the other one,
etc, tell when NumLock has been pressed, ...).  The first step is to read the
file DOCS\INTERNAL.DOC again and again until you understand what is there.
After doing that (and frequent references to my Intel I486 Programmer
reference) I believe the key code (pun intended) is all in the files 
event.c, eventque.h, and evintr.asm. (in DJSRC108.zip).  From my 
interpretation of this code, the 16 bit Interrupt 9 is chained by GO32 so
it can tell when a keypress has occurred.  The int 16 bios call is then used
to move this event as a character (if it is a character, else no action)
into an event data structure.  The shift state is also stored.  The structure
is also used for mouse events, so there is an extra unused word that I was
considering to use for the AX return from Int 16, Func 01.  A new routine
parallelling the code in getkey() or getxkey() would be written to return
the word returned from int 16 plus the shift state (which could be checked 
for changes in NumLock, CapsLock, etc).  I believe this would have minimal
impact on any of the code currently in place. (use of the evt_ypos should
not cause problems for keyboard events?)

I believe (am not sure) that these event data structures are written by
this 16 bit interrupt driven code, and then read by the 32 bit code as
necessary.  To do similar work for tcp/ip events you could write a 16 bit
TSR then access the memory data structures directly after locating them
in the low 1 Meg mapped high in the address space.  While you could do the
same for the keyboard events, I have a long list of reasons noone wants to
hear why its a bad idea to add another int 9 handler to all the machines
this software needs to run on.

So, why don't I just fix it and send DJ a patch?  Well, I am working on it
in my spare time (not much of) and I currently have found one of my buddies
with a TCC compiler (while it may be brain damaged, my company provided me
with MSC 6.0 and isn't excited about more software expense at this point).
Compiling GO32 with MSC/MASM seems to be a hopeless task so finding the
right compiler to borrow for a week or two seems the right path, but not
a quick one at this point.

I would love to hear from anyone who can either verify my guesses on the
way to handle this (a couple of lines in event.c and eventque.h, plus the
new routines to access the info) or tell me how totally screwed up I am.
Anyone else with a non-tsr approach to the keyboard problem I would love
to hear it also.  I have tried reading the low memory typeahead buffer
directly to get the scan codes (which sort of works) but the small typeahead
causes me to miss keystroke info at times and I don't know exactly which
shift states were in effect when the scan codes in the buffer were
entered.

Thanks for any comments or advice.
Charles Sandmann

- Raw text -