Date: Wed, 4 Nov 1998 11:02:39 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: djgpp AT delorie DOT com Subject: Re: Keyboard access In-Reply-To: <363f15f1.86538969@news.cis.yale.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com On Tue, 3 Nov 1998, Mapson wrote: > My assumption was that there was no such thing- that when a key was > pressed, the keyboard only sent one short message of "key pressed", > not to be turned off again until a message "key released" came. It's much more complicated, actually. In short, when a key is pressed, the keyboard transmits it to the keyboard controller, which reads the key ID and generates an interrupt (Int 09h). When the key is released, another Int 09h is generated, with the same key code, but with a certain bit set, meaning it's a key release event. However, all the ports used by the keyboard controller to communicate with the keyboard can be read and written by you as well, so you get access to every information that flows between the keyboard and the controller. > >There is: you need to read the keyboard controller's port. But that > >means you need to do it while the key is still pressed, since that port > >has no memory. > > This is fine with me- how do I find out where this port is, and can I > treat it like any old port? I will start tracking it down now that I > know there is one. I cannot explain all the details here. I suggest to find some good reference about low-level keyboard operation (e.g., "The Indispensable PC Hardware Book" by Hans-Peter Messmer). In a nutshell, you can read port 64h where bit 0 is set whenever a key was pressed or released, and before the keyboard controller had a chance to read that key. Another useful piece of info is that you can send a command to the controller to disable the keyboard during the time you don't want the user to overflow the keyboard buffer. The command is ADh.