2

According to this webpage: http://stanislavs.org/helppc/8042.html the keyboard controller maintains it's own internal 16 byte make/break code buffer.

"The keyboard's internal controller buffers up to 16 bytes of make/break code information. This is common among all PC systems and shouldn't be confused with the (32 byte) keyboard buffer maintained by the BIOS."

Being able to access this buffer would be very useful to me in my 8086 assembly language programs (presumably updated faster than the 32 byte buffer maintained by the BIOS).

Is there a way to pull those make/break codes from the internal buffer, aside from polling port 60h?

Zoe
  • 27,060
  • 21
  • 118
  • 148
bad
  • 939
  • 6
  • 18
  • 1
    Well the easiest way is to just read the scan codes normally, you don't have to poll, you can use an interrupt handler to put the codes into your own buffer in RAM just like the BIOS does. There are documented controller commands that let you read the 8042's RAM, which on real 8042 would presumably include the buffered scancodes in there somewhere, but I don't think where exactly is standardized. Modern keyboard controllers might not emulate this. – Ross Ridge Dec 27 '17 at 19:27
  • But what is the use of putting it somewhere else in memory? You mean it would be faster to access the scan codes without loading a different segment? I agree with that. I only really want the last break/make code as input into my program, which is why I use port 60h, but it would be useful to access the buffer since human error often causes issues in my program. Often I will strike a key a split second before letting go of the previous key overwriting the make code my program needs, with the break code I wish to ignore. Accessing the buffer will allow me to determine the lost make code. – bad Dec 29 '17 at 07:07
  • I am already ignoring break codes that don't correspond with the last accepted make code, but I still often encounter an out of order break code that does correspond with the previously encountered make code. Causing an undesired stopping of the movement of the sprite in my game for instance. I should mention that the 32 byte buffer in the BIOS sometimes misses the split second make codes. I imagine a very high frequency interrupt could solve this issue, but I still don't know how to program the two PICs. I've been researching it for the last few days in my spare time. – bad Dec 29 '17 at 07:12
  • You have an XY problem. https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem Your real problem is that keyboard input in your game isn't working properly. Your proposed solutions, reading the 8042's buffer or using high frequency interrupts, aren't the solution to your real problem. This is obvious when you realize hundreds of MS-DOS games had no problem handling keyboard input properly without doing either of these things.Your "human error" problem is due a design fault in your own code and the BIOS doesn't miss split second make codes unless you cause it to do so. – Ross Ridge Dec 29 '17 at 16:33
  • I would ask a question tackling the root of my specific issue, but the question would boil down to "How do I write an interrupt?" I wouldn't ask such a question. My specific issue is that a make code appears at port 60h and is overwrtten before my input detection code is executed again. Obvious solution: fast, high frequency interrupt to do the input detection. You can see the current form of my input procedure in my own solution to this previous question of mine. https://stackoverflow.com/questions/47786199/faster-keyboard-scan-code-detection-in-8086-assembly – bad Dec 29 '17 at 17:10
  • And besides, being able to access the buffer could've possibly been useful to me in the future for other purposes. Yes, I asked a question about a possible solution to my problem instead of asking about the specific problem, but since I already had a pretty good idea of what the real solution would be (writing an interrupt, accessing the 8042 buffer was just a side-thought) I decided to ask this question out of curiosity. – bad Dec 29 '17 at 17:25

1 Answers1

3

Not in any documented way. I don't mean to imply that there is a known but undocumented way to do it; I'm simply not willing to say that there isn't any undocumented method for it.

Devices accessed using the port facility generally maintain their own discrete memory and logic, so you should not expect to see that memory space exposed to you anywhere else in the system. There are exceptions to this; DMA transfers of memory areas, or even memory-mapping them into physical address space. But for a keyboard, no, you can't see that memory.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
David Hoelzer
  • 15,862
  • 4
  • 48
  • 67
  • 1
    Yeah, I knew it wouldn't map into system memory or anything like that, but I was hoping there was a way to request bytes from the buffer by communicating with the controller. – bad Dec 27 '17 at 18:11
  • 2
    @Mylifeisabug.: yeah, doesn't hurt to ask, it would have been possible that there was some kind of remote-debug interface, but looks like the answer is no in this case. – Peter Cordes Dec 27 '17 at 18:11
  • 1
    It's worth seeing if you can find some low level docs for the actual controller, but be aware that what works with one might not work with another at that level. – David Hoelzer Dec 27 '17 at 18:15
  • @MargaretBloom He's trying to do it without polish port 60. 0xac will dump those bytes, but you have to clock them out of port 60. – David Hoelzer Dec 28 '17 at 12:21