Mail Archives: djgpp/2000/10/05/10:57:12
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> schrieb...
>
> On Thu, 5 Oct 2000, Peter Remmers wrote:
>
> > All keys work just fine, EXCEPT for num-lock, caps-lock,
> > scroll-lock and both of the shift keys! In which case the
> > program locks up.
>
> Are you sure the program indeed locks up?
Yes, I'm sure. The counters on the screen don't count up
anymore, which means the interrupt handler doesn't get called
anymore. Also, the keytest function doesn't print any codes,
and Ctrl-Break, which normally brings me back to rhide, doesn't
work either.
> What happens if you press another key after one of the above keys?
Nothing. I don't even get an interrupt for the break-code of the
shift key. The make-code is the last thing that happens.
In pure DOS I have to reboot, in windows I have to
kill the DOS window, i.e. close it with the mouse and the X button
and say yes to the dialog.
> Perhaps the omitted keytest() function locks you up in a loop,
> because it assumes something about each keypress, and that
> assumption doesn't hold when one of these keys is pressed?
As I commented, the function calls bioskey(0x10), prints the code
and does this in a loop until the lobyte of the code
(the ascii character) equals escape.
> Does the test program work if you comment out the code which hooks
> the keyboard interrupt?
Yes, the keytest function was written long before I tried to
do the filtering stuff. I works.
It looks like this:
void keytest()
{
setmode (0, O_BINARY); // disable ctrl-c
int k = 0;
while ((k&0xFF) != 27);
{
k = bioskey(0x10);
printf("%04x '%c'\n", k, k&0xFF);
}
setmode (0, O_TEXT);
}
> Also, does the same happen with Ctrl and Alt keys (you don't mention
> them)?
I thought "All-Except" would imply that these keys too do work.
Yes, they work, and that makes it even more paradox.
> > I simply don't understand why! What makes those keys so special
> > above all the other keys?!?
>
> One thing that makes these keys special is that they don't by
> themselves produce any code visible to BIOS function 10h. Instead,
> they toggle bits in special variables stored in the BIOS data area.
> You need to press a ``normal'' key together with Shift for BIOS
> function 10h to notice any keyboard input. (Alternatively, you could
> call BIOS function 11h to sense the status of these special keys.)
That was my first suspection, but as I found out that both the left
and right ctrl and alt keys work, I was completely perplex.
> > void irq1handler()
> > {
> > ++count;
> > textput(0,0, "before: %d ", count); // pokes into video memory
> > asm volatile("pushfl");
>
> Isn't "pushf" the correct mnemonic?
Both pushf and pushfl are OK for the assembler (bnu2951).
I wanted to make sure it pushes 32bit flags instead of 16bit flags...
I tried "pushl %eflag", but the assembler says eflag is not a
register, although I've seen code doing this... code that does a
"lcall" after the "pushl %eflag.
I must interlude that I very much don't like AT&T syntax, but that's
another story :-)
If I process every key in my ISR myself, and stuff the raw scancodes
into the BIOS keyboard buffer, my keytest() really gets the raw
codes, and ALL keys, including shift and num-lock etc. DO work.
void irq1handler()
{
textput(0,0, " %d ", ++count);
unsigned char CODE = inportb( 0x60 );
unsigned char p61 = inportb( 0x61 );
outportb( 0x61, p61 | 0x80 );
outportb( 0x61, p61 );
outportb( 0x20, 0x20 );
// stuff the raw scancode into the BIOS keyboard buffer
StuffKey((unsigned short)CODE);
}
Peter
- Raw text -