Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!newsserver.jvnc.net!gmd.de!mururoa!veit
From: veit@mururoa.gmd.de (Holger Veit)
Subject: Re: Intel Keyboard BUG?
Message-ID: <1993Apr13.105523.14426@gmd.de>
Keywords: keyboard bug intel
Sender: veit@mururoa (Holger Veit)
Nntp-Posting-Host: mururoa.gmd.de
Organization: GMD, Sankt Augustin, Germany
References: <jmonroyC5F175.G8x@netcom.com>
Date: Tue, 13 Apr 1993 10:55:23 GMT
Lines: 75
In article <jmonroyC5F175.G8x@netcom.com>, jmonroy@netcom.com (Jesus Monroy Jr) writes:
|>
|>
|> INTEL BUG ?
|> -----------
|>
|> I found this on comp.periphs. I may be of interest to
|> those working on console programming, if you don't already
|> have this information.
|>
|> ====================================================================
|> From: br.pct@RLG.Stanford.EDU (Peter C. Tam)
|> Subject: P8742AH intel keyboard controller
|> Organization: Research Libraries Group, Inc.
|> Date: Tue, 30 Mar 1993 01:55:42 GMT
|>
|> Strange Story:
|>
|> I was able to re-program the keyboard controller INSIDE Windows
|> 3.1 keyboard device driver to do no scan code conversion ONLY ON A
|> COMPUADD 333. For an IBM PS2, AST 386, COMPUADD 433, COMPUADD 325
|> they just ignore the programming, and remain in scan code translation
|> mode.
|>
|> Is this related to the BIOS of each micro? COMPUADD 333 has
|> Phoenix BIOS 1.10.1, COMPUADD 333 & 433 has Phoenix BIOS 1.10.0.
|>
|> Swapping the keyboard controller (P8742AH Intel Chip) between
|> CompuADD 325 and CompuADD 333 makes no difference.
|>
|> Does the above description indicates it is a ROM BIOS difference?
|> AST 386 has AST386 BIOS, PS2 well must have IBM microchannel....
|>
|> For COMPUADD 433, even worse thing happens, it only goes into
|> no scan code translation only after it exit Windows 3.1!!
|>
|> Can anyone tell me what do I miss here???? & Thanks for any info!!!
The 386bsd "codrv" console driver performs a switch to the
AT scan code mode (i.e. switches off the translation mode). There were
some problems with the reset code, but I found that none of them is related
to the translation mode. So if a kernel with codrv runs on your system,
this may be a sign that the keyboard controller is behaving correctly
(the converse is not true1!).
Perhaps someone with these machines could check what happens to their
keyboards and report it to me.
I suspect that Windows traps I/O accesses to the ports 60 and 64
(via the task segment I/O permission map), and disables critical
operations like toggling the translation bit which could make the
internal keyboard handling in Windows unavailable. There may be
different handling in Windows for particularly this feature depending
on the BIOS found, but this is not very likely. The BIOS is not directly
involved in that it has support routines for switching key mode, but it
may indeed have influence on some timing and polling of keyboard registers.
This is no problem (or a problem on a different level) for 386bsd, because
the BIOS is dead after the boot has been finished. The above story, however,
is a warning that sloppy timing and access of the keyboard controller
might actually cause trouble (as we all know with the pccons driver).
Holger
|> ___________________________________________________________________________
|> Jesus Monroy Jr jmonroy@netcom.com
|> /386BSD/device-drivers /fd /qic /clock /documentation
|> ___________________________________________________________________________
|>
--
Dr. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Three lines Signature space
| |/ Schloss Birlinghoven | available for rent. Nearly
DW-5205 St. Augustin, Germany | unused, good conditions