Impressive, very nice

This is great ~

Thank you very much for posting this!

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.

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.

*** 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:

1ASCII: 0 1 2 3 4 5 7 6 8 9 A B C D E F
2  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:

18bit operation  - 30+31+...+46      =   A2 H
216bit operation - 30+31+...+46      = 03A2 H
3What 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.

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.

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.

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.

So on archive.org there are some archived manuals from ftp.megatrends.com. There are many references to AMIBCP, and even some screenshots, but no AMIBCP itself. Still, it was helpful to better understand some of these old BIOSes.

Other sources, including UMB_DRVR, suggest that 0000h-7fffh in these BIOSes is used for the BIOS setup program and POST, while 8000h-ffffh is used at runtime. That seems consistent with what I see.

In particular, the BIOS starting at 8000h, for the 08/08/93 BIOS, seems to have a quite structured layout. The other dates are likely similar. Note that this was a BIOS without support for an onboard I/O controller and extra setup menu screen to configure it. Some of the gaps in the memory layout are likely filled in with such settings for a BIOS with onboard I/O settings.

18000h - ROM copyright string
28050h - secondary ROM copyright string
38078h - BIOS string 1
480a0h - BIOS string 2 (shows up with Ins key)
580c8h - BIOS string 3 (shows up with Ins key)
680f0h - Power-on copyright banner
78200h - Standard CMOS defaults as a binary image ready to be copied into registers. Partly redundant with default tables later on.
88240h - I/O addresses to probe for serial ports
98248h - I/O addresses to probe for parallel ports
108250h - unknown POST-related flags
11825eh - scan code for Ctrl-Alt-____ turbo-on hot key
12826eh - scan code for Ctrl-Alt-____ turbo-off hot key
138280h - BIOS options flags (editable using AMIBCP)
14     80h - halt on error during POST
15     40h - initialize CMOS on every boot
16     20h - KBC output pin 23,24 blocked
17     10h - Mouse support in BIOS/KBC
18     08h - Wait for <F1> on POST error
19     04h - Display floppy error during POST
20     02h - DIsplay video error during POST
21     01h - Display keyboard error during POST
228281h - BIOS flags (not editable using AMIBCP)
23     02h - power management supported?
24     40h - 80286 CPU?
25     80h - evaluation copy
268282h - Shown/hidden settings for entire submenus of CMOS Setup program
278284h - Power on delay
288285h - Software i/o delay?
298286h - Refresh value?
308290h - Pointer to setup program settings indexes table
318292h - Pointer to choice, choice callback, setup program settings table
328294h - Pointer to CMOS Defaults table
338296h - Pointer to Chipset Defaults table
348298h - Pointers to unknown defaults table (possibly power management related)
35829ch - Pointers to table of lengths of other tables
3682a0h - Pointers to floppy controller configuration tables for 360k-1.44M floppy disk sizes
3782aah - Pointer to unknown function
3882ach - Pointer to floppy controller configuration table for 2.88M floppy disk size
3982b1h - Pointer to maximum register stored in default tables
4082b3h - Maximum CMOS register number to include in checksum computation
4182b6h - Pointers to unknown functions
4282f0h - begin AMI Green PC power management related settings

Finally it also appears that the two-byte checksum is most likely stored at ff50h.

Emulators are great for debugging and patching BIOSes. No harm done if something breaks. If your board has chipset supported in emulator, you should be able to copy your BIOS in there and it should work.

AlexZ wrote on 2021-08-28, 04:29:

Emulators are great for debugging and patching BIOSes. No harm done if something breaks. If your board has chipset supported in emulator, you should be able to copy your BIOS in there and it should work.

Yes, agreed. The old AMIBIOSes that are 64K and that do not have to decompress themselves into RAM often work even with the "wrong" chipset in PCem. Once you get into the ones that are compressed, which tends to show up around the same time as WinBIOS, PCI, and ISA Plug n Play support, the chipset has to match because they have to set up shadow RAM in order to do the decompression.

Have you compared the list of options you've found with the list of options you could enable through AMISETUP?
Any additional features that could be enabled, that AMISETUP can not do?

GigAHerZ wrote on 2021-08-28, 08:59:

Have you compared the list of options you've found with the list of options you could enable through AMISETUP?
Any additional features that could be enabled, that AMISETUP can not do?

The biggest one so far is that a handful of posters have done a hardware modification to keyboard controllers that are already capable of driving a PS/2 mouse, to add a PS/2 mouse port to boards that don't come with one. The hidden Mouse Support Option setting, that you can change using AMISETUP, is not enough on its own. The mouse support is blocked from taking effect unless the appropriate bit at 8280h is set.

jakethompson1 wrote on 2021-08-28, 20:08:

GigAHerZ wrote on 2021-08-28, 08:59:

Have you compared the list of options you've found with the list of options you could enable through AMISETUP?
Any additional features that could be enabled, that AMISETUP can not do?

The biggest one so far is that a handful of posters have done a hardware modification to keyboard controllers that are already capable of driving a PS/2 mouse, to add a PS/2 mouse port to boards that don't come with one. The hidden Mouse Support Option setting, that you can change using AMISETUP, is not enough on its own. The mouse support is blocked from taking effect unless the appropriate bit at 8280h is set.

Beautiful find! Thanks!

First of all, I'm sorry about resurrecting this thread, but I wanted to thank @jakethompson1, as this has been extremely useful for some BIOS tinkering I've been doing.

Also, I wanted to discuss certain details about what is mentioned in the section "Un-hiding options in SETUP":

jakethompson1 wrote on 2021-07-08, 01:40:

a byte identifying which CMOS register is controlled by the setting

So, currently I'm troubleshooting a 486 BIOS (08/08/1993 core) and I've noticed that it completely ignores a couple of settings related to timings: Cache Burst Read Cycle, which always is set to 2T despite setting 1T in the CMOS setup, and Bus Clock Frequency Select, which also ignores the user setting and is fixed at 7.159... MHz instead of using the Bus clock frequency dividers. I'm using CTCHIP34 to verify that these chipset register values remain unchanged at all times no matter if I change them in the CMOS setup. Other registers for timings and options are set correctly according to the option chosen in setup.

Now, since it's a VLB motherboard having a slightly slower ISA bus speed is not of great concern, but the inability to set 1T on the Cache Burst Read Cycle has an effect so notorious that L2 cache is not detected when setting main memory to the tightest timings, due to the small differences between those speeds.

Returning to the BIOS modding, I've noticed that the CMOS register number where these options are set is not the same as the chipset register number that is affected (for instance, in the BIOS setup the CMOS register for the cache timings is 36h, but the chipset register that handles this in the SiS471 chipset is 51h). So, I assume there has to be a mapping between the CMOS register values that are set on the SETUP utility and the chipset register so the chipset is configured at boot time right? I assume this is where the BIOS issue would be, but I'm not so sure where I could start looking for this. Any help or suggestions are welcome!

By the way, I've noticed that in addition to the first byte being the CMOS register that is controlled by the option (including whether it's hidden or not), the following byte indicates which bits of the register are affected by the setting. Not sure about the 3rd byte, but the 4th indicates the number of options for that setting and after that there is one byte per each option that points to entries in the table mentioned by jakethompson1 that maps all the different options with their labels.

TheMobRules wrote on 2023-02-06, 19:23:

First of all, I'm sorry about resurrecting this thread, but I wanted to thank @jakethompson1, as this has been extremely useful […]
Show full quote

First of all, I'm sorry about resurrecting this thread, but I wanted to thank @jakethompson1, as this has been extremely useful for some BIOS tinkering I've been doing.

Also, I wanted to discuss certain details about what is mentioned in the section "Un-hiding options in SETUP":

jakethompson1 wrote on 2021-07-08, 01:40:

a byte identifying which CMOS register is controlled by the setting

So, currently I'm troubleshooting a 486 BIOS (08/08/1993 core) and I've noticed that it completely ignores a couple of settings related to timings: Cache Burst Read Cycle, which always is set to 2T despite setting 1T in the CMOS setup, and Bus Clock Frequency Select, which also ignores the user setting and is fixed at 7.159... MHz instead of using the Bus clock frequency dividers. I'm using CTCHIP34 to verify that these chipset register values remain unchanged at all times no matter if I change them in the CMOS setup. Other registers for timings and options are set correctly according to the option chosen in setup.

Now, since it's a VLB motherboard having a slightly slower ISA bus speed is not of great concern, but the inability to set 1T on the Cache Burst Read Cycle has an effect so notorious that L2 cache is not detected when setting main memory to the tightest timings, due to the small differences between those speeds.

Returning to the BIOS modding, I've noticed that the CMOS register number where these options are set is not the same as the chipset register number that is affected (for instance, in the BIOS setup the CMOS register for the cache timings is 36h, but the chipset register that handles this in the SiS471 chipset is 51h). So, I assume there has to be a mapping between the CMOS register values that are set on the SETUP utility and the chipset register so the chipset is configured at boot time right? I assume this is where the BIOS issue would be, but I'm not so sure where I could start looking for this. Any help or suggestions are welcome!

By the way, I've noticed that in addition to the first byte being the CMOS register that is controlled by the option (including whether it's hidden or not), the following byte indicates which bits of the register are affected by the setting. Not sure about the 3rd byte, but the 4th indicates the number of options for that setting and after that there is one byte per each option that points to entries in the table mentioned by jakethompson1 that maps all the different options with their labels.

Silly question--there is sometimes an Auto Configuration option that could itself be hidden, that might account for what you're seeing. You might want to try AMISETUP before going straight to modding the BIOS.

You're right that often the chipset register and CMOS register numbers don't match, especially when multiple on/off settings are packed into the bits of a CMOS register value and have to be unpacked in order to program the chipset registers. I don't think there is an easy mapping that you could handle with a table; this was all handled in code on a per chipset basis. Now the question is whether AMI/Award did all the programming on their own or offered a "link kit" where chipset vendors could plug in the needed modules to program their chipsets. Once you go past ISA/VLB the BIOSes get even harder to understand.