Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!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 Subject: GATEA20, RESTART, and related nightmares (2/3) Message-ID: <1833@gold.gvg.tek.com> Date: 4 Jan 91 21:35:40 GMT Organization: Grass Valley Group, Grass Valley, CA Lines: 63 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 #######