Reading keyboard port 60h problem

[Gustav]

Hello,

I have an old dos TSR which hooks int 9, reads the keyboard input port 060h (to catch a key combination) and then does a far jump to the previous handler (which is the keyboard driver). It works fine in pure dos, in windows dos boxes and dosemu, but causes problems when running in qemu. The problem then is that extended keys aren't recognized any more.

To analyze this problem a bit deeper I wrote another very simple tsr which hooks int 15h, ah=4Fh (this interrupt is called by the keyboard driver itself, with the make code the keyboard driver has read in register AL) and displays the value in AL.

It displays in pure dos, if one presses an "extended" key: E0 xx, for example E0 38 for the right alt key. This is as expected and good.

In qemu it displays for the same key: 38 38. This is bad.

Now my question is: is this a bug in qemu or in my code? Of course, one could argue if qemu wants to be a good emulator, any code that is "emulated" should behave exactly as in the native environment. But for extended keys, which create 2 or more make codes, how long does it take until the second make code is "ready" at port 60h? Or the question slightly modified: Is there an "undo" command my TSR should do after it has read port 60h?

Gustav

[MichaelW]

I have never used any emulator so I have no specific knowledge here. I think the scan codes you are getting would be correct for a PC-XT, but IIRC the keyboard intercept (4Fh) first appeared on the PC-AT.

Per this page "QEMU uses the PC BIOS from the Bochs project and the Plex86/Bochs LGPL VGA BIOS."

Per this page Bochs supports keyboard types "xt", "at", and "mf", with "mf" the default. But in the QEMU documentation I see no indication of how this might be specified.

The bug reports here might provide some useful information.

There is a listing here of a possibly related bug that was fixed in version 2.2:

"[1159626] bugfix [1156776] keyboard scanmode fault by Rene Kootstra"

Back when I was writing TSRs I avoided reading port 60h directly from an interrupt handler because I recalled seeing in a description of the BIOS keyboard handling that the hardware was designed to detect and respond to the read. But according to this page:

"Port A can be safely IN'd from any number of times before the keyboard is cleared;"

And based on what I recall from some tests I performed a few years ago, this does seem to be correct.

[Gustav]

Thanks for your infos, Michael,

> "[1159626] bugfix [1156776] keyboard scanmode fault by Rene Kootstra"

On Bochs 2.2.1 the error does not occur - and from what I read in the error description I doubt that it was this change which has fixed it. I have no version 2.1 avaliable to test that, though.

> Bochs supports keyboard types "xt", "at", and "mf", with "mf" the default. But in the QEMU documentation I
> see no indication of how this might be specified.

I'm sure it emulates an MF keyboard. Otherwise my keyboard driver would complain at boot time.

> "Port A can be safely IN'd from any number of times ..."

Ok, so it is a qemu bug.