Xref: utzoo comp.sys.ibm.pc.hardware:3960 comp.sys.ibm.pc.misc:4890
Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!gvgpsa!gold.gvg.tek.com!grege
From: grege@gold.gvg.tek.com (Greg Ebert)
Newsgroups: comp.sys.ibm.pc.hardware,comp.sys.ibm.pc.misc
Subject: Re: Fast a20 support?
Message-ID: <1815@gold.gvg.tek.com>
Date: 19 Dec 90 19:08:34 GMT
References: <90353.083012TACON019@ysub.ysu.edu>
Followup-To: comp.sys.ibm.pc.hardware
Organization: Grass Valley Group, Grass Valley, CA
Lines: 25


Maybe we should title this: GATE A20 NIGHTMARES STRIKE AGAIN !!!

Fast gate-A20 can be implemented in 2 ways:

	#1. Port 92h. This is on the PS/2, and some AT machines. AST Research
	    is one vendor; I don't know who else.

	#2. Kludge logic. I did this for a previous employer. Basically, you
	    'hide' the commands which control A20 from the keyboard controller.
	    External logic drives GATEA20, but it's fed-back into the
	    keyboard controller so software can query GATEA20 through the
	    controller.

The only nasty case I saw where fast GATEA20 was mandatory was while running
Novell non-dedicated NetWare. On a 486/33, it took 30-60 seconds to get a
response from the keyboard; on a 6Mhz AT, response was instantaeous. I can
post the details if someone is interested.

I'll bet that the buggy software you have blindly assumes the GateA20 command
was processed by the keyboard controller (ie, via a timing loop. Horrors !!)
and jumps into what it thinks is high memory (but is actually low memory),
has a heart attack, and reboots. If you want to do some detective work, put
a logic analyzer on the keyboard controller and watch the command stream.
Again, if someone asks for details, I'll post.