From: JULIUS@BTVLABVM.VNET.IBM.COM ("Julius C. Chang")
Newsgroups: comp.sys.ibm.pc.hardware
Subject: A20 handler
Date: 19 Aug 92 13:39:57 GMT
Article-I.D.: ucbvax.9208191350.AA07094


    This is from my files and is an excerpt from a README file
written by Bob Smith of Qualitas.  Note that the excerpt explains
the origin of the A20 Gate, but not why there are different A20
handlers for HIMEM.SYS.  Basically, the A20 Gate is implementation
dependent and controlling the A20 line can (and usually does) vary
from manufacturer to manufacturer.

Julius
------------------------------------------------------------------------

Compatibility with 8086/8088 Programs
-------------------------------------

Now for a bit of history on how the IBM AT and later systems maintain
a certain degree of compatibility with the 8086/8088 processors.  When
these early CPUs encountered a segment and offset which together
exceed the limit of its 20-bit address space (such as FFFF:0010 =
00100000), they automatically wrap at one megabyte back down to zero.
Thus FFFF:0010 is identical to 0:0, or more accurately, memory
references to the former location are satisfied from the latter
location.  When the IBM AT was designed to use a 80286 CPU, its
architects faced a problem.  The newer processor was oriented more
toward PM operation.  Consequently, it didn't automatically wrap
addresses at 1MB, as that would defeat the purpose of having a
continuous stream of RAM at 1MB and beyond.  Nonetheless, the AT's
designers decided to emulate this odd behavior because they understood
well the need for compatibility.  That is, there were (and still are)
many programs which rely upon the 1MB wrap as it is called.

Because the 8086/8088 processors have a 20-bit address space, they
need address bits A0 to A19 only.  The maximum address which can be
generated in RM (FFFF:FFFF) has 21 significant bits, that is, of the
bits beyond A19 only A20 is non-zero.  The AT's designers realized
that they could emulate the 1MB wrap by artificially forcing A20 to
zero.  Thus the mechanism used to emulate this behavior and obtain
compatibility is called the A20 gate.  Typically, it is controlled by
a single bit in the output port byte (a kitchen sink catchall) of the
8042 PPI (Programmable Peripheral Interface) chip on the system board.
The two values of this bit correspond to the two states of the A20
gate.  The value zero means that A20 is forced to zero regardless of
what address the CPU generates; a value of one means that A20 is
untouched, that is, controlled by the CPU to have whatever value the
CPU calculates.  In this way, with A20 disabled (forced to zero)
although the CPU may generate an address of 00100000 when presented
with FFFF:0010, the actual address the bus sees is 00000000.

As a side note, the A20 gate has caused fits for several system
designers.  When memory cache controllers were introduced into PC
systems, some designers forgot about the A20 gate.  That is, they
designed their systems such that (from a logical perspective) the
sequence of control was from the CPU to the memory cache to the A20
gate circuitry to the bus.  A problem occurs in the following sequence
with (say) A20 enabled:  read from FFFF:0010 (thus putting the value
at physical address 1MB into the cache), disable the A20 gate, and
read again from FFFF:0010.  The program expects to get the second
value from physical address zero (because A20 is now disabled), but if
the memory cache controller doesn't know that the A20 gate has changed
it will provide the CPU with the (incorrect) value from its memory
cache for physical address 1MB.

Moreover, consider what happens with the 486 CPU which has an onboard
memory cache.  Without really having any choice, Intel decided to
immortalize this behavior in silicon by defining an input pin (A20M#)
on the 486 to allow external circuitry to control the state of the A20
address line which the cache sees so that it would work correctly.

One more digression about the A20 gate:  why is it so important to
emulate the 1MB wrap?  Isn't this a problem that could be solved
simply by more careful programming?  Yes, but it's too late.  Quite
likely, your hard disk is infested with numerous programs which under
certain circumstances will fail if the 1MB wrap weren't emulated.  The
major perpetrator of this feature is the EXEPACK program as well as
the corresponding option to the linker.  In particular, the code which
EXEPACK prefixes onto your packed .EXE files is dependent upon the 1MB
wrap.  In particular, if such a program is loaded with its code
segment at 0FF0 or lower (essentially anywhere within the first 64KB)
and the A20 gate is enabled (thus not emulating the 1MB wrap), the
unpacking code fails with the message "Packed file is corrupt!".



------------------------------- Referenced Note ---------------------------
Subject: A20 handler
From: j_manning@csc32.enet.dec.com (John Manning)
Date: 18 Aug 92 14:34:56 GMT

Can some explain the difference in the various A20 handler numbers?

My machine says "A20 handler number 1 installed" when I load himem.sys.  I
noticed a Packard Bell computer at a store yesterday that said "A20 handler
number 3 installed" when it loads himem.sys.  What is the difference?

Thanks,

John

-------------------------------------------------------------------------------
|    John Manning                       |  Opinions expressed are my own.     |
|    j_manning@csc32.enet.dec.com       |  I do not represent Digital Equip.  |
-------------------------------------------------------------------------------
Newsgroups: comp.sys.ibm.pc.hardware