Re: [Qemu-devel] [PATCH 0 of 1] Fix for DOS keyboard problems

[Jamie Lokier]

Stefan Ring wrote:
> The particular problem that I noticed and that is 100% reproducible
> and also very understandable when you look at what the DOS programs
> do, is that in Borland's Text-Mode DOS IDEs (most likely BC++ 3.1, 4,
> Turbo Pascal 6 but definitely Turbo Pascal 7) and IIRC also in Turbo
> Vision programs generated by them, every cursor key press is
> interpreted twice. So when you open up the leftmost menu and press the
> down cursor key once, the third entry gets selected instead of the
> second one.
> 
> The reason for this is that said programs install an IRQ 1 handler
> which does little more than read from port 60h and pass control to the
> underlying BIOS (or keyboard driver) handler. The BIOS handler reads
> port 60h again, and should apparently see the same value as the first
> handler. The problem with the cursor keys is that they generate two
> scan codes in succession on port 60h that should be read by two
> separate IRQ handler activations but because QEMU's original behavior
> is to consume one data byte per read from 60h, the data gets used up
> too fast.

Let's see if I understand your explanation.

   1. Cursor key is pressed.  The key press is represented as two scan codes.
   2. IRQ 1 is entered.
   3. Borland's code reads port 60h - gets the first scan code.
   4. BIOS's code reads port 60h - gets the second scan code.
   5. Return from IRQ 1.

   6. Cursor key is released.  The key release is represented as two
      scan codes.
   7. IRQ 1 is entered.
   8. Borland's code reads port 60h - gets the first scan code.
   9. BIOS's code reads port 60h - gets the second scan code.
  10. Return from IRQ 1.

So both Borland's code and the BIOS are *missing* scan codes.

How does that result in Borland seeing *multiple* cursor key
press/release sequences?


Apparently when port 0x60 is read, that de-asserts IRQ1, resets the
IBF flag ("input buffer full"), and another byte could be received
from the keyboard.  However, reading port 0x60 quickly, before another
byte can be received over the keyboard cable, should return the same byte.

So I agree that the emulated port 0x60 should return the same value if
there has not been enough time for the (emulated) keyboard cable to
transmit another scan code.

But detecting the particular sequence used by Borland code and the
BIOS together is a hack.  I'm not surprised that, as you say, other
DOS keyboard drivers remain broken after the patch.

If it goes in, the patch should include a very clear comment that the
"held" value and detecting the disable/read/enable sequence is only a
workaround for what Borland does and also depends on the BIOS
sequence, and is not a correct emulation in general.

-- Jamie