🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.msdos.programmer
Article #3761

Re: HELP: Keyboard Interrupt 09H

#3761
From: Jerzy Tarasiuk
Date: Tue, 13 Oct 1992 16:15
42 lines
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!jt
References: <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