Date: Thu, 5 Oct 2000 07:56:25 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Peter Remmers 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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?