VOGONS


First post, by jakethompson1

User metadata
Rank Oldbie
Rank
Oldbie

I saw the AMIBCP search thread was active again. In talking with some of the members about the PS/2 mouse hardware modifications on their boards, there are at least a few modifications you can do with these BIOSes even without having AMIBCP, found by digging around in the hex dump, DOS DEBUG, and in IDA Free edition.

These BIOSes are exactly 64K and are not compressed. You know you have a compressed BIOS if it will not allow you to disable BIOS Shadowing. WinBIOSes, unfortunately, are compressed so this works only on older ones. For this example I am using one of the 08/08/93 BIOSes and I'm running it inside PCem "ami486" machine for testing. You could also do this on real hardware but you will have to keep flashing the BIOS chip to make any changes.

Patching out checksum verification code
The first hurdle is that any modifications to the BIOS will invalidate its checksum. These BIOSes validate their checksum by adding up the BIOS contents, 16 bits at a time discarding overflow, and checking that the result sums to zero. By using the Search command in DOS debug we can find this code and use the Unassemble command to verify it's right:

A:\>debug
-S F000:0 L FFFF 2E AD 03 D8 E2 FA
F000:DC9A
-U F000:DC9A
F000:DC9A 2E CS:
F000:DC9B AD LODSW
F000:DC9C 03D8 ADD BX,AX
F000:DC9E E2FA LOOP DC9A
F000:DCA0 7406 JZ DCA8

The JZ instruction jumps to DCA8 if the checksum passes. If the checksum fails, the BIOS continues straight ahead with code I haven't shown, presumably code to beep the PC speaker and loop.

By changing the byte at location DCA0 from 74 to EB, we change JZ to JMP. This makes it so that the BIOS no longer cares whether the checksum is right. Note that we don't actually know where the checksum is. Because it is only verifying that the BIOS contents add up to zero, it could be anywhere.

You must do this before you can make any other modifications.

Enabling PS/2 mouse support
By default PCem will not let you attach a PS/2 mouse to the ami486 machine. By editing src/model.c, going to "[486] AMI 486 clone" line, and adding |MODEL_PS2 after ...MODEL_HAS_IDE and recompiling, it will let you.

After doing that, and attaching a PS/2 mouse in the settings, you may find that mouse drivers report no PS/2. You can try AMISETUP but it won't help. This is because there seems to be a byte in the AMIBIOS that controls various things like whether there is a PS/2 mouse port on the board. We can find it using debug.

INT 15 with AX=C204h asks the BIOS what type of mouse is connected. Start debug, Assemble, and enter the instructions to trigger this interrupt.

A:\>debug
-A
1C27:0100 MOV AX,C204
1C27:0103 INT 15
1C27:0105
-

Now, we want to trigger this interrupt and keep Tracing through the BIOS code until we see a TEST BYTE PTR [....],10 instruction. It may take 10-20 instructions so be patient. This byte seems to be ORed with 0x10 if a PS/2 mouse port is present, and because it is in ROM and not in CMOS, no amount of tweaking in CMOS Setup can change it.

...
AX=C242 BX=0000 CX=0000 DX=0000 SP=FFE6 BP=0000 SI=0000 DI=0000
DS=1C27 ES=1C27 SS=1C27 CS=F000 IP=9741 NU UP EI PL NZ NA PE NC
F000:9741 3C12 CMP AL,12
-T

AX=C242 BX=0000 CX=0000 DX=0000 SP=FFE6 BP=0000 SI=0000 DI=0000
DS=1C27 ES=1C27 SS=1C27 CS=F000 IP=9743 NU UP EI PL NZ NA PE NC
F000:9743 735C JNB 97A1
-T

AX=C242 BX=0000 CX=0000 DX=0000 SP=FFE6 BP=0000 SI=0000 DI=0000
DS=1C27 ES=1C27 SS=1C27 CS=F000 IP=97A1 NU UP EI PL NZ NA PE NC
F000:97A1 3C40 CMP AL,40
-T

AX=C242 BX=0000 CX=0000 DX=0000 SP=FFE6 BP=0000 SI=0000 DI=0000
DS=1C27 ES=1C27 SS=1C27 CS=F000 IP=97A3 NU UP EI PL NZ NA PO NC
F000:97A3 75B1 JNZ 9756
-T

AX=C242 BX=0000 CX=0000 DX=0000 SP=FFE6 BP=0000 SI=0000 DI=0000
DS=1C27 ES=1C27 SS=1C27 CS=F000 IP=9756 NU UP EI PL NZ NA PO NC
F000:9756 2E CS:
F000:9757 F606808210 TEST BYTE PTR [8280],10 CS:8280=2F

Notice that [8280] holds the value 2F, which when ANDed with 10, will produce zero. This means that the byte in the BIOS at offset 8280 needs to be changed from 0x2F to 0x3F (i.e. OR it with 0x10). The PS/2 mouse port will then be enabled.

After making those two modifications on this particular BIOS, and the hack to PCem, I can use a PS/2 mouse even though the board this BIOS belongs to did not have one. Of course, to do this on real hardware, you would have to do the keyboard controller hack described by feipoa, maxtherabbit et al.

Un-hiding options in SETUP
If you scroll through the BIOS using your hex editor, you will eventually come across a region of bytes with hex values 00, 01, 02, 03, 04, ...

Immediately after that is a table of choice strings. This lets BIOS SETUP map numeric choices (0, 1, 2, ...) to the strings that show in SETUP such as Reserved, Disabled, Enabled, Absent, ...

Immediately after that are the actual settings: Typematic Rate Programming, Typematic Rate Delay, etc.

The format of each setting is:
a string describing the setting followed by a 00 byte.
a byte identifying which CMOS register is controlled by the setting. Because registers go only from 0x00 to 0x7f, bit 7 is used to control whether the setting is shown or not.
other bytes not relevant here.

In this particular BIOS, the AUTO Config Function, Cache Read Option, Cache Write Option, DRAM Type, and DRAM Wait State(s) options are all hidden. To show them, I will have to change the byte at 0xc55b from 0x54 to 0xd4, the byte at 0xc57b from 0x41 to 0xc1, the byte at 0xc59b from 0x41 to 0xc1, the byte at 0xc5bb from 0x41 to 0xc1, and the byte at 0xc5db from 0x41 to 0xc1 (i.e. OR them with 0x80).

0000c530: 61 74 65 20 20 20 00 b5 60 00 04 2d 2c 2b 2a 41 ate ..`..-,+*A
0000c540: 55 54 4f 20 43 6f 6e 66 69 67 20 46 75 6e 63 74 UTO Config Funct
0000c550: 69 6f 6e 20 20 20 20 20 20 20 00 54 40 0f 00 20 ion .T@..
0000c560: 20 20 20 20 20 43 61 63 68 65 20 52 65 61 64 20 Cache Read
0000c570: 4f 70 74 69 6f 6e 20 20 20 20 00 41 c0 10 00 20 Option .A...
0000c580: 20 20 20 20 20 43 61 63 68 65 20 57 72 69 74 65 Cache Write
0000c590: 20 4f 70 74 69 6f 6e 20 20 20 00 41 30 11 00 20 Option .A0..
0000c5a0: 20 20 20 20 20 44 52 41 4d 20 54 79 70 65 20 20 DRAM Type
0000c5b0: 20 20 20 20 20 20 20 20 20 20 00 41 04 13 00 20 .A...
0000c5c0: 20 20 20 20 20 44 52 41 4d 20 57 61 69 74 20 53 DRAM Wait S
0000c5d0: 74 61 74 65 28 73 29 20 20 20 00 41 03 12 00 20 tate(s) .A...

After changing those, the settings are unhidden in the Advanced Chipset Setup.

To do
I believe the Power on Default and CMOS Setup default values are stored nearby.
Has anyone run into entire menus (eg Advanced Chipset Setup) being disabled-I believe I did on someone's BIOS and was able to unhide it.
Figure out WinBIOS-it may be a big undertaking.
Based on this experience, the AMISETUP author either had documentation about these BIOSes, or did the same steps described here (including on later BIOSes like WinBIOS). It might be possible to contact the AMISETUP author if he would be willing to provide any more info.

Reply 3 of 9, by Eep386

User metadata
Rank Member
Rank
Member

Thank you very much for posting this!

Life isn't long enough to re-enable every hidden option in every BIOS on every board... 🙁

Reply 4 of 9, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Nice to see this information retained online now. It is probably too involved for most users of the forum, but that could change in time.

Ultimate 486 Benchmark | Ultimate 686 Benchmark | Cyrix 5x86 Enhancements | 486 Overkill Graphics | Worlds Fastest 486

Reply 5 of 9, by hyoenmadan

User metadata
Rank Member
Rank
Member

Just for the record... Combining this technique with MyBCP from Herbert Oppmann (which can uncompress even MAIN module) would make it work for compressed AMIBIOS6 cores, which don't work or get corrupted by AMI BCP7 tools (BCP, MM and OLG logo encoding tools), as long the changes don't mess with the module relocation table contained in MAIN.

Reply 6 of 9, by SSTV2

User metadata
Rank Oldbie
Rank
Oldbie

*** A small off-topic ***

Interesting, I've never had a need to modify an AMI BIOS before, thus most of what was mentioned here was new to me, especially the checksum calculation. I've read on Vogons before, that the AMI BIOS checksum patching is somewhat difficult or unusual and now I see why is that. The whole process doesn't follow a standard checksum calculation method, where every byte is added sequentially and the end result is compared with a specific checksum byte value, instead it adds all 16 bit words sequentially. You might think at first that it's just a simple 16 bit checksum calculation that many HEX editors can easily perform, but that would be a false assumption, because a 16 bit checksum operation also follows a standard checksum calculation method, except you get an additional high byte on top of an 8 bit checksum value.

I'll give an example, lets say we have these values:

ASCII: 0 1 2 3 4 5 7 6 8 9 A B C D E F
HEX: 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46 (LOW, HIGH, LOW, HIGH... bytes)

These would be the checksums of:

8bit operation  - 30+31+...+46      =   A2 H
16bit operation - 30+31+...+46 = 03A2 H
What AMI used - 3130+3332+...4645 = D6CD H

Now knowing how the checksum calculation is actually performed for the AMI BIOS, it doesn't look too difficult to properly patch it, except for one small detail, which was already mentioned by jakethompson1, it's not clear where the actual checksum correction word is.

*** on-topic ***

I know that C2h function of INT15h is essential for the BIOS's PS/2 mouse support, do you know how to check whether that function is present in the AMI BIOS image using a hex editor/debug? I had one case where an AWARD BIOS lacked that function completely, thus PS/2 mouse didn't work even after enabling PS/2 mouse in the BIOS configuration byte (after driver load a cursor would show up in DOS programs, but it wouldn't react to mouse movements). Motherboard was fully PS/2 capable.

Reply 7 of 9, by jakethompson1

User metadata
Rank Oldbie
Rank
Oldbie
feipoa wrote on 2021-07-11, 05:34:

Nice to see this information retained online now. It is probably too involved for most users of the forum, but that could change in time.

Now you know what it's like for us reading your directions on upgrading the 8433UUD to 1024k cache, modifying the keyboard controller to add a mouse port, etc. "Just add an X ohm resistor here, a capacitor here, run a wire from pin X to Y, etc."..... huh? 😁

This process could be automated. One reason I hesitate to is there are too many heuristics now e.g. "there's a table of option names followed by X" which may not always be true across all versions.

Reply 8 of 9, by feipoa

User metadata
Rank l33t++
Rank
l33t++

I do plan on updating those directions, but I'm not sure when. I've since made it possible via jumpers to switch between 256K, 512K, and 1024K, all double-banked. I've been running the newly mod board without any issues for some time now, currently with 512K double-banked at 66 MHz. The existing Biostar manual v2 should have sufficient photographs and written detail for the 1024K mod, but perhaps nobody else has done the mod yet because everyone wants a video these days.

Ultimate 486 Benchmark | Ultimate 686 Benchmark | Cyrix 5x86 Enhancements | 486 Overkill Graphics | Worlds Fastest 486

Reply 9 of 9, by bakemono

User metadata
Rank Member
Rank
Member
SSTV2 wrote on 2021-07-12, 00:53:

Now knowing how the checksum calculation is actually performed for the AMI BIOS, it doesn't look too difficult to properly patch it, except for one small detail, which was already mentioned by jakethompson1, it's not clear where the actual checksum correction word is.

A sum of 16-bit words is not all that unusual, I know I've seen it before (eg. Sega games). Save files for PC games often use a sum of 32-bit words.

Not knowing where the BIOS originally had it checksum fixed doesn't stop us from fixing it again though. Just choose a location that doesn't appear to be used for anything else, such as inside a big block of zeros or an ASCII string that nobody cares about.

new retro game on itch: https://90soft90.itch.io/glamorous-zombie-flakes