While working on my 32-bit 80386DX ISA Single Board Microcomputer, I have encountered an incompatibility using the VIA VT82C42 keyboard controller with the AMI BIOS 8/8/93 version ROM image. My goal is to try and figure out what the BIOS does behind the scenes and why it is not compatible with the VT82C42 controller.
My initial thought would be to analyze different keyboard controllers and try to figure out what exactly differentiates them in the first place.
So I wrote a simple assembly program that retrieves the keyboard controller version number.
GitHub Repository: https://github.com/agroza/kbdver
Main Program: kbdver.asm
I plan to use this KBDVER.COM with a couple of PC configurations and document the version reported by each type of keyboard controller IC. The table below centralizes all my experiments so far.
|KEYBOARD CONTROLLER VERSION|
|Keyboard Controller||Reported Version||Remarks|
|VIA VT82C42||46h (F)||PLCC-44 package, directly soldered on the PCB assembly of a P233MMX ISA SBC|
|AMI KB-BIOS-VER-F||46h (F)||DIP-40 package, socketed on the PCB assembly of the 80386DX SBMC|
Disassembling the ROM BIOS version 8/8/93 reveals the keyboard controller version checking algorithm is located at offset 46FDh.
We can see the BIOS is doing some checks for some known hard-coded keyboard controller versions. If the version is either F, H, M, or anything between H and M, the routine immediately exits. If it is G or anything less than F then the routine jumps to some other part of the code which I'm not interested in. While it works, this code appears to have been written by an amateur.
In theory the patch should be as simple as flipping one instruction (either JZ, JB, or JBE) to its inverted counterpart. Or modifying one of the CMP instructions to check against the version reported by the VIA VT82C42 controller.
But then there is the AMI BIOS ROM checksum value that also needs to be computed and updated. While OPTION ROM checksums are well documented and the algorithm for calculation and the checksum location is known, these old AMI BIOS ROM checksums are not documented. At least not to my knowledge.
Later edit: I managed to get the 80386DX SBMC up and running with the standard PS/2 interface that I implemented when I designed the schematic. The missing link was an American Megatrends AMI KB-BIOS-VER-F integrated circuit that worked out of the box with the 8/8/93 AMI ROM BIOS. However the PS/2 mouse still does not work. So this essay still stands up in my TODO list as I am curious how to adapt the ROM BIOS to enable the PS/2 mouse interface. A very interesting thing is that somehow I overlooked the BIOS keyboard controller identification routine which also performs a detection of the IC version and displays it at the end of the BIOS string in the POST screen.
But at the moment this essay cannot continue since I'm totally blocked by lack of knowledge on the AMI BIOS checksum issue.
I have an idea that might shed some light on the AMI BIOS ROM checksum value(s). But I do lack the hardware required for this. My plan is to connect the logic analyzer directly to the 80386 CPU buses through a dedicated piece of hardware called a logic analyzer preprocessor or interface module. I do have the HP 10269C General Purpose Probe Interface unit. But without an 80386DX-compatible preprocessor interface which goes by the name of HP 10314B Interface Module, I cannot do anything. The idea is to obtain one of these devices. Or build it myself, if somebody would care enough to reverse engineer the on-board PLA integrated circuit as the rest of the PCB wiring appears to be trivial.
If I had that missing link, I would quickly use an 80386DX inverse assembler program on the logic analyzer immediately upon system power-on. My gut feeling is that one of the first instruction groups would deal with the checksum. Even before any other hardware initialization. At the moment that's a daring plan, but we'll see.
I fear that I would not be able to share any of my knowledge that I would obtain from that process, since AMI is still around, and most certainly the ROM BIOS is still well within the copyright timespan. But for sporadic personal use I'd guess there is no problems on modifying a 30-year old ROM for obsolete hardware.
Hope you found this essay interesting.
Copyright © 2004- Alexandru Groza
All rights reserved.
VER. 1.0 | REV. A