Mail Archives: djgpp/2000/10/09/16:00:58
I wrote:
> I think I should dump the registers before and after the lcall.
Done it, same registers before and after.
Latest findings:
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.
Solutions:
- Make the *wrapper* call the next ISR after restoring DS and SS.
This is only possible with _go32_dpmi_chain_p_m_i_v(), or by
writing your own wrapper in assembly.
- install a real-mode callback for INT 0x15, which provides
a way to eat scancodes, to change them or leave them alone.
Peter
- Raw text -