[Qemu-devel] A20 line control (was Re: [PATCH 0/2] pckbd improvements)

[Jamie Lokier]

Blue Swirl wrote:
> On 5/16/10, Jamie Lokier <address@hidden> wrote:
> > Blue Swirl wrote:
> >  > On 5/16/10, Paolo Bonzini <address@hidden> wrote:
> >  > > On 05/15/2010 11:49 AM, Blue Swirl wrote:
> >  > >
> >  > > > In 2/2, A20 logic changes a bit but I doubt any guest would be broken
> >  > > > if A20 line written through I/O port 92 couldn't be read via i8042.
> >  > > > The reverse (write using i8042 and read port 92) will work.
> >  > > >
> >  > >
> >  > >  Why take the risk?
> >  >
> >  > The alternative is to route a signal from port 92 to i8042. Or maybe
> >  > port 92 should belong to i8042, that could make things simpler but
> >  > then the port would appear on non-PC architectures as well.
> >  >
> >  > But I doubt any OS would depend on such details, because the details
> >  > seem to be murky:
> >  > http://www.win.tue.nl/~aeb/linux/kbd/A20.html
> >
> >
> > It's not hard to imagine some DOS memory driver or 286/386 DOS
> >  extender expecting to read the bit, if that's normal on PCs.
> >
> >  The earlier PCs didn't have port 92h, so presumably older DOS software
> >  uses the keyboard controller exclusively.
> >
> >  The details are murky, but on the other hand, I remember back in day,
> >  A20 line was common knowledge amongst DOS hackers on 286s and 386s,
> >  and the time I remember it from, port 92h was not available, so it
> >  can't have been too murky to use the i8042.
> 
> Right, but with this patch, writing to and reading from i8042 would
> still work, likewise for writing to and reading from port 92. Even
> writing via i8042, but reading via port 92 would work. What would not
> work reliably (even then, 50% probability of being correct) is when
> port 92 is written, but reading happens with i8042.
> 
> >  i8042 emulation isn't the same on PC on a non-PC because of the
> >  PC-specific wiring (outside the chip), such as its ability to reset
> >  the motherboard.  I don't see that it makes sense for qemu to pretend
> >  there are no differences at all.  Or, perhaps it makes sense to imply
> >  different GPIO wiring, separate from the i8042 itself.
> >
> >  On the other hand, something which makes sense to me:
> >
> >  In a PC, are port 92h and i8042's outputs OR'd together or AND'd
> >  together to control A20 proper?  Then they'd be two independent
> >  signals, and shouldn't mirror each other.
> 
> That's exactly what I meant, how could also random OS designer trust
> that the signals are combined the same way on every PC? With logic
> circuits, i8042 would still see its own output only, not the combined
> signal. If instead the signals were wired together, with some
> combination of inputs the output would not match what QEMU generates.
> Currently QEMU does not implement any logic for A20 line, which
> obviously can't match real hardware (or maybe some kind of dual port
> memory).

http://www.openwatcom.org/index.php/A20_Line

According to that page, MS-DOS's HIMEM.SYS tries 17 different methods
to control the A20 line! :-) Meanwhile, DOS/4GW, a DOS extender (there
are lots of those) allows the method to be set manually.

But there are only two common ones that are still implemented in
modern PC hardware: The keyboard commands to read, modify and write
the output port, and port 92h.

The random DOS-extender designers had to try each method, by checking
if the address space was actually wrapped.

With port 92h being known as the "fast A20 gate", I'm pretty sure any
program which includes that method will try that one first.

According to the wiki page (actually, my interpretation of it), the
output signal from port 92h is usually OR'd with the output signal
from the keyboard controller port.  That is, they are independent signals.

-- Jamie