Date:	Thu, 5 Oct 2000 07:56:25 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Peter Remmers <Peter DOT Remmers AT t-online DOT de>
cc:	djgpp AT delorie DOT com
Subject:	Re: strange interrupt chaining problem with keyboard interrupt
In-Reply-To:	<8rgcqk$rdi$16$1@news.t-online.com>
Message-ID:	<Pine.SUN.3.91.1001005075606.3958E-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

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?  What happens if you press
another key after one of the above keys?  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?

Does the test program work if you comment out the code which hooks the
keyboard interrupt?

Also, does the same happen with Ctrl and Alt keys (you don't mention
them)?

> 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.)

> void irq1handler()
> {
>    ++count;
>    textput(0,0, "before: %d ", count); // pokes into video memory
>    asm volatile("pushfl");

Isn't "pushf" the correct mnemonic?

- Raw text -