grege@gold.gvg.tek.com (Greg Ebert) (01/05/91)
I have received a lot of inquiries about the GATEA20 function in AT's, so
I guess there's enough interest for a posting.
What the *&%^&@#$ are GATEA20 and restart ?
-------------------------------------------
Lets go back to the days of the PC. It had an 8088 which could directly
handle up to 1Megabyte of memory. Wherever there is a computer, there is
an idiot who thinks he is a programmer. Microsoft is no exception. A version
of BASIC, EXE2BIN, and possibly other programs, were written which *require*
the 'wrap-around' in the address space. For example, in the 8088, you can
keep incrementing an address counter up towards 1 megabyte, and it WILL
wrap-around to address 0, then 1, 2, 3, etc. Idiot programmers use features
like this (as well as timing loops and self-modifying code).
Along comes the 80286. Well, a "feature" in the 8086 Real mode did *NOT*
do the 'wrap-around' properly, so the above-mentioned programs bombed.
It was determined that only address line 20 (called A20) was the culprit.
My 80286 data book vaguely mentions that "A20 through A23 should be ignored
in 8086 Real mode".
So, instead of fixing (1) the software bugs, and (2), the 80286, an AND
gate was placed on A20. The other leg of the AND gate is controlled by
a signal called GATEA20. It should be intuitively obvious that this signal
should originate from the keyboard controller [sarcasm]. The way it worked
was that unless you 'turn-on' GATEA20, the addresses that the system and memory
actually 'see' will indeed wrap just as they do in a PC or PC/XT. But, if you
turn GATEA20 'on', you can use all that memory up to 16MB.
Oh, but that's not all !! The 80286 has this wonderful mode called 'Protected
Mode' which gives you its virual memory, etc whiz-bang features. A very good
name, I might add, because once you're in, you can't get out !!! So, another
function named RESTART was created. What this did was yank the RESET line to
the CPU for a short time to reset the processor. This is *not*, I repeat,
*NOT* what CTRL+ALT+DELETE does. I will repeat it again !! CTRL+ALT+DELETE
does *NOT* issue a reset to the CPU. A flag-bit in (you guessed
it) the keyboard controller tells BIOS if the reset came from a power-up
or a RESTART. Obviously you wouldn't want to run all of those power-on
self-test (POST) routines each time you did a mode switch.
Well, our poor keyboard controller has a lot to do: It has to talk to the
keyboard, handle GATEA20/RESTART, keep a 'boot flag' to see where reset
came from, and possibly control a mouse. Oy veh ! This keyboard controller
is actually a single-chip computer with it's own software (Intel 8742 to be
exact).
- - - - - - -
Stay tuned for the next episode: What is fast GATEA20/RESTART and when/why
do I need it.
----- Boycott redwood products ---------------------------- Recycle -----
"Thou shalt abide by The GNU Manifesto" #####
{uunet!tektronix!gold!grege} Register to vote, then ## | ##
grege@gold.gvg.tek.com vote responsibly # | #
# /|\ #
Support high oil prices, waste tax $$ on war, evade domestic #/ | \#
problems, and die young on foreign soil- Just say YES to Bush #######grege@gold.gvg.tek.com (Greg Ebert) (01/05/91)
As we saw in the last article, the keyboard controller has to talk to the
keyboard and control GATEA20/RESTART.
All software running above 1MB in RAM *must* enable GATEA20. Some software
(most notably Novell NetWare/ non-dedicated), switches GATEA20 quite
rapidly. Although CPU speeds have skyrocketed over the years, the poor old
keyboard controller still creeps along at 8Mhz (although I know of 1
manufacturer who runs it at 12Mhz). So, software which really beats on GATEA20
can be a real nuisance for the keyboard controller on fast CPU's like
a 486/33.
The keyboard controller usually sits in a polling loop waiting for either
a command, or a keystroke. When it gets a command, it basically tells the
keyboard to "shut-up". While the keyboard controller is digesting a command,
the CPU can send another command/data byte, which is 'queued' in a register
in the keyboard controller. When the keyboard controller has finished it's
current command, it allows the keyboard to "talk", and then goes into it's
polling loop. BUT.... The keyboard takes awhile to figure out it's ok to
talk. By the time the keyboard wants to talk, the keyboard controller has
polled and detected a byte in the command/data register and has told the
keyboard to "shut-up" again.
Herein lies the problem: If the keyboard controller is being barraged by
GATEA20 commands, the keyboard never has a chance to send a keystroke.
You can hit a key and nothing happens for 20-30 seconds until the right
conditions of refresh and RTC interrupts slow down the CPU just enough
to let a keystroke get sent.
A possible software kludge would be to poll the keyboard *only* for a
short period of time, and then poll for commands and keystrokes, but this
would reduce the command throughput of the keyboard controller.
FAST GATEA20 & RESTART
----------------------
The PS/2 has a special I/O port (port 92h, bits 0&1) which also controls
GATEA20 and RESTART. Unfortunately , (1) many programmers are too stupid to
write software which 'looks' for this, and then use it, or (2) the software
was written before the PS/2 came out.
So, Compaq, AST Research, and probably other manufacturers, put some kludgy
logic around the keyboard controller so it never gets the dreaded GATEA20
command in the first place. Instead, the kludge-logic controls GATEA20 and
RESTART directly. Now these operations are done at exactly the same speed
as the CPU. As you might have guessed, since the keyboard controller no
longer 'sees' the GATEA20 commands, it doesn't have to repeatedly enable
and disable the keyboard.
Sometimes it is difficult to determine if a GATEA20 'problem' is the lack of
fast-GATEA20, or a hardware compatibility issue. It's not just a matter of
running the application on a slower machine because hardware implementations
of GATEA20 and RESTART can (but shouldn't) vary. I think the best way is
see if keystroke response is slow.
----- Boycott redwood products ---------------------------- Recycle -----
"Thou shalt abide by The GNU Manifesto" #####
{uunet!tektronix!gold!grege} Register to vote, then ## | ##
grege@gold.gvg.tek.com vote responsibly # | #
# /|\ #
Support high oil prices, waste tax $$ on war, evade domestic #/ | \#
problems, and die young on foreign soil- Just say YES to Bush #######grege@gold.gvg.tek.com (Greg Ebert) (01/05/91)
Fast GATEA20 can be emulated with a PAL sitting next to the keyboard
controller. Here are the essentials.
The GA20 function is performed by a two-byte instruction to the keyboard
controller. The first byte is (I think) a D1h written to port 64h. The
next byte is the value. Currently, there are only 2 bits defined: GA20
and Restart. Writing the Restart bit is ridiculous because if written
low, the CPU is locked into reset until power is removed (or if you
have a hardware reset switch).
What you need to do is 'block' all incoming 'D1' commands to the keyboard
controller, AND emulate them externally. To block the D1 command, you need
to decode data of D1h being written to port 64h, and disable -XIOW to the
8742 controller. You must ALSO block the next -XIOW *only* if it is
to port 60h; a subsequent write to 64h is an 'abort' and MUST be issued.
Secondly, after you detect the D1h@64h, you need to latch data bit 1; this
is the GATEA20 signal. Finally, you need to connect this signal to the 8742
(pin 21 I think) so it can be queried by software.
While you are at it, you might want to implement 'FAST RESTART' by
intercepting 1111xxx0 (binary) being written to port 64h. Whenever you
see this condition, yank the RESTART line for a few microseconds.
That's it !!!!
----- Boycott redwood products ---------------------------- Recycle -----
"Thou shalt abide by The GNU Manifesto" #####
{uunet!tektronix!gold!grege} Register to vote, then ## | ##
grege@gold.gvg.tek.com vote responsibly # | #
# /|\ #
Support high oil prices, waste tax $$ on war, evade domestic #/ | \#
problems, and die young on foreign soil- Just say YES to Bush #######grege@gold.gvg.tek.com (Greg Ebert) (01/05/91)
Well, this time I can flame myself. The PAL kludge for GATEA20/RESTART needs another state which looks for a no-op immediately following the GATEA20 command. This no-op (and ONLY this no-op) must also be blocked from the keyboard controller. I can't post PAL listings in CUPL for the kludge logic because they are considered intellectual property by my former employer; but if I can figure out the equations, you can too.