Article View: comp.os.msdos.programmer
Article #3761Re: HELP: Keyboard Interrupt 09H
From: Jerzy Tarasiuk
Date: Tue, 13 Oct 1992 16:15
Date: Tue, 13 Oct 1992 16:15
42 lines
3141 bytes
3141 bytes
>>>>> On 12 Oct 92 21:31:28 GMT, ceharris@csugrad.cs.vt.edu (Carl Harris) said: Carl> In article <1992Oct9.154103.18137@sol.ctr.columbia.edu> Carl> jerry@connection.prospect.com (Jerry Shekhel) writes: >Hello out there. I'm creating a VGA game, and I need precise keyboard >control, so the kbhit()/getch() functions are insufficient. I need to know >when keys are pressed and released. I managed to do this by intercepting the >keyboard hardware interrupt Carl> [lengthy code example deleted] >This works, but the problem is that since I'm not using the BIOS to read the >keystrokes (I'm just reading the key_map[] array), the BIOS buffers them up >and starts clicking the speaker when the buffer overflows. Needless to say, >when I'm holding keys down, this click turns into a "drumroll" and slows down >my game. I tried removing the call to old_handler(), but then everything >stopped working, as if the interrupt itself was no longer being generated. Carl> Before exiting your ISR, you may clear the keyboard's MAKE/BREAK status by Carl> writing 0x80 to the keyboard control port. This will 'remove' the key Carl> press/release from the keyboard in the same manner as the BIOS keyboard ISR. Carl> After doing this, you must *not* pass control to the BIOS ISR. Rather, issue Carl> the EOI to the interrupt controller and return from the interrupt via IRET. Note this is OK for XT only. AT keyboard controller doesn't need writing the 0x80 to the port 0x61 and it can be harmful. Simplest is use BIOS service. Can intercept scan code from keyboard by reading it from port 0x60 before passing control to BIOS routine and remove characters from keyboard buffer. Not also should clear shift status to avoid detection Alt-Ctrl-Del or Ctrl-ScrollLock by BIOS. Note also some AT class computers may have keyboard controller which returns other scan codes than usual keyboard and they have BIOS which uses Int 15h, function 4Fh to pass 'standard' scan code to application (Borlands SuperKey doesn't work on such a computers because it services Int 9 only). If you want service Int 9 without BIOS: on first interrupt read scan code from port 0x60, wait several microsecond and check if IRQ line is still active (by command to 8259). If it is, use code which writes to port 0x61 (set and clear bit 7). If it isn't, need send the EOI to 8258 only. Reading scan code is simplified version of Int 9 service, good program on AT should first send Keyboard Disable command. Otherwise no recovery is possible after transmission parity error.
Technical Details
Message-ID:
<JT.92Oct13171510@fizyk1.fuw.edu.pl>Path:
arc1-ca.pugleaf.net!sparky!uunet!mcsun!sunic!fuw.edu.pl!cocos!jtReferences:
<1992Oct9.154103.18137@sol.ctr.columbia.edu> <Bw12GH.BqK@csugrad.cs.vt.edu>Show Full Headers
Complete Article Headers
Newsgroups: comp.os.msdos.programmer,alt.msdos.programmer Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!sunic!fuw.edu.pl!cocos!jt From: jt@fuw.edu.pl (Jerzy Tarasiuk) Subject: Re: HELP: Keyboard Interrupt 09H In-Reply-To: ceharris@csugrad.cs.vt.edu's message of 12 Oct 92 21:31:28 GMT Message-ID: <JT.92Oct13171510@fizyk1.fuw.edu.pl> Sender: news@fuw.edu.pl Nntp-Posting-Host: fizyk1 Organization: Warsaw University Physics Dept. References: <1992Oct9.154103.18137@sol.ctr.columbia.edu> <Bw12GH.BqK@csugrad.cs.vt.edu> Date: Tue, 13 Oct 1992 16:15:10 GMT Lines: 42