From: eplmst AT lu DOT erisoft DOT se (Martin Stromberg)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: strange interrupt chaining problem with keyboard interrupt
Date: 10 Oct 2000 09:22:37 GMT
Organization: Ericsson Erisoft AB, Sweden
Lines: 31
Message-ID: <8run4t$531$2@antares.lu.erisoft.se>
NNTP-Posting-Host: lws256.lu.erisoft.se
X-Newsreader: TIN [version 1.2 PL2]
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Peter Remmers (Peter DOT Remmers AT t-online DOT de) wrote:
: I disassembled keyb.com and got some very interesting insights.
: Num-lock, scroll-lock and caps-lock are special in that they
: cause keyb to change the LEDs on the keyboard. This means
: keyb has to send commands to the keyboard which make the keyboard
: cause an interrupt to announce that its ACK (0xFA) is ready to be
: picked up.
: Keyb.com's interrupt handler sets up it own stack (512 bytes) and
: points DS to the BIOS data segment on entry.
: It also has a reentrance counter. If the reentrace counter is
: greater than zero it does NOT set up the stack again!
: And that's the problem: it expects an ACK from the keyboard, and
: it expects to be reentered by the ACK interrupt, and that means
: it expects SS and DS to have certain values when the interrupt
: occurs.
: Now, if I hook the keyboard interrupt and set up DJGPP's execution
: environment I (or the wrapper) overwrite keyb's SS and DS
: registers, which is fatal in the case of the keyboard's ACK
: interrupt - or any other case of reentry, for that matter.

: In which way the shift keys are special, I don't know. But KEYB
: for whatever reason treats them special, too, because they also
: cause the keyboard to send an ACK, which ends like explained above.

I think I know. Some keyboards have another LED that lights up when
the shift keys is pressed (e. g. Microsnoft Natural keyboard).


Right,

						MartinS