Sphere478, thanks for calling me famous. I didn't see that coming! 😊

Yes, I'm willing to share with this community what I've learned about BIOS patching these past 25 years.
But to properly explain these patches, it will be a pretty big story and I’m thinking of splitting it in episodes. So bear with me while I’m preparing the first part.

I will start writing about HOW to patch these compressed 1996-2000 BIOSes and what tools I use.
Later I will explain WHAT to patch for each bugfix in detail.

Note that Petr Soucek already did a nice write-up on Award BIOS modifications some 20 year ago. His page can now be found at https://web.archive.org/web/20071114220315/ht … n.cz/petr/bios/
Links on this page bring you to a detailed explanation of the patches he did for two different Gigabyte socket 7 BIOSes.
I will try to expand on that with more code samples on the various code variations Award Software used over the years, and the appropriate fix for each.

So quite an undertaking but it is about time I wrote this all down. 😉
Cheers, Jan.

Woohoo!! Thanks Jan!! Look forward to the episodes!

Chkcpu wrote on 2021-11-14, 13:18:

Sphere478, thanks for calling me famous. I didn't see that coming! 😊 […]
Show full quote

Sphere478, thanks for calling me famous. I didn't see that coming! 😊

Yes, I'm willing to share with this community what I've learned about BIOS patching these past 25 years.
But to properly explain these patches, it will be a pretty big story and I’m thinking of splitting it in episodes. So bear with me while I’m preparing the first part.

I will start writing about HOW to patch these compressed 1996-2000 BIOSes and what tools I use.
Later I will explain WHAT to patch for each bugfix in detail.

Note that Petr Soucek already did a nice write-up on Award BIOS modifications some 20 year ago. His page can now be found at https://web.archive.org/web/20071114220315/ht … n.cz/petr/bios/
Links on this page bring you to a detailed explanation of the patches he did for two different Gigabyte socket 7 BIOSes.
I will try to expand on that with more code samples on the various code variations Award Software used over the years, and the appropriate fix for each.

So quite an undertaking but it is about time I wrote this all down. 😉
Cheers, Jan.

OMG, you're still there - not like many whose websites and identities are lost in space and time somewhere, many years ago. Great to have you still here, I really appreciate your work - used it nearly 20 years ago when I didn't know anything about BIOS modding, I think. Take the time you need to write your how-to!

And haha, you're also one of those who has found to VOGONS very late (like me), despite you're visible to the WWW for (over) a couple of decades. 😉

BTW does anyone remember the "The Rebels Haven" (www.rebelshavenforum.com / www.rhcf.com)? There was plenty of information / collected wisdom, but they disappeared suddenly back then around 2013. That's just one example...

kind regards
soggi

soggi wrote on 2021-11-17, 11:28:

BTW does anyone remember the "The Rebels Haven" (www.rebelshavenforum.com / www.rhcf.com)? There was plenty of information / collected wisdom, but they disappeared suddenly back then around 2013. That's just one example...

kind regards
soggi

Hard to forget 😀. I spent there some time between 2007-10. Does anyone know what happened? I think that Polygon had also account on XtremeSystems, but he didn't visit it since 2013-14 or so.

I didn't have an account there, even wasn't there regularly, just noted there was great collected wisdom and set it (some BIOS hacking stuff) onto my endless to-do list...then it suddenly vanished. Don't have the time to back-up aaaalll these things. Unfortunately, you just notice it's not archived on archive.org...afterwards.

kind regards
soggi

Yah sucks about rebelshaven, the way the site was set up made it hard for archive.org to get much, even when you can find index pages of the forum sections barely any posts were saved. However, some of their offsite hosting is still up, like http://www.lejabeach.com/M810/M810.htm and the lejabeach domain has a lot of other board/bios pages, unfortunately without an index to tie them together, have to poke about with google site search.

edit: derp, shoulda posted this page, more pertinent to BIOS modding theme of thread... http://www.lejabeach.com/CBROM.html
edit2: another guide http://www.lejabeach.com/Modbin6.html

soggi, thanks for the friendly welcome at VOGONS. 😀
Alas, I never found my way to the rebelshavenforum in those days.
Okay, time to start my story.

#Part 1 – the beginning

To begin this story of “do-it-yourself” BIOS patching, I like to share how I got into this weird hobby.

Back in 1994 when retro PC’s were still brand-new, my first home-build PC was a 486 PCI machine. But when I later upgraded this PC with a Gravis Ultrasound MAX and an Am5x86-133 CPU, and tried to install Windows 95, I ran into several frustrating incompatibilities that appeared to be BIOS related.

As an electronics engineer I was comfortable with PC hardware and although I’m not a software engineer, I was interested in software that directly handles that hardware. So learning x86 assembler was a logical next step. Now I was ready to attack these annoying BIOS bugs and this is how the BIOS patching hobby started.

DOS was still a mainstream OS in these days, and so were most programming tools. I started with DOS Debug and a shareware disassembler, but these tools are inadequate for disassembling a BIOS. These simple disassemblers only produce a RAW listing when you feed them a BIOS image. No differentiation between code and data, no indications for start and end of subroutines or interrupt handlers, no x-ref for jump locations and subroutines, no explanations or remarks, etc...
This makes reading and understanding such a listing very hard.

So I purchased the DOS based Sourcer disassembler with BIOS Pre-processor. Sourcer uses a definition file to define data areas and structures, external entry points, text-string positions, and how code and data pointers are resolved. It also allows to name all the (sub)routines, labels, and entry points.
However, making that definition file for a particular BIOS is a lot of work, but it produces a good readable listing. It helped me to understand the inner workings of a BIOS, especially in the beginning.
Although there are now other good disassemblers, like IDA Pro, I’m still using Sourcer (and DOS) today.

Then I added a Hexeditor and an (E)EPROM programmer and that was all I needed for creating and testing my first patched BIOS.

This first patched BIOS was an Award v4.50G BIOS for my Soyo 030F2 socket 3 board, and I have been patching Award BIOSes ever since. So in the next episodes I will share how I patch these Award v4.5x BIOSes, both the uncompressed and compressed versions.
But I will tell how to patch an AMI socket 7 BIOS as well, in a later episode.

For all BIOS bugs I known a fix for, I will provide a binary signature to help you find the spot in your BIOS where to apply the patch. This string of bytes will uniquely identify the offending code or data so you don’t have to mess with a disassembler. The search function of your Hexeditor is then all you need.

In part 2 of this story, I will explain how an uncompressed Award BIOS can be patched, before I jump to the compressed Socket 7 BIOS.

Jan

#Part 2 – how to patch an uncompressed Award BIOS

In this part I will address the details you should know when patching the uncompressed Award Modular BIOS v4.50(G).

When I started this BIOS patching, I had heard that some BIOSes were compressed, but luckily these 486 BIOSes were still uncompressed.
First, I will talk about the 64KB 486 ISA or ISA/VLB Award BIOS, and tell you where the checksum bytes are and how they are calculated. Essential information if you start changing some bytes and want to avoid bricking your system in the process.

A 64KB BIOS contains 65,536 bytes, 1 0000 in hex, from offset 0h to offset FFFFh. The ROM BIOS is always placed at the top of the 1MB address-range, so a 64KB BIOS fits exactly in segment F000h.
This makes the address-range of such a BIOS: F000:0000 – F000:FFFF. I will be using this Real mode hexadecimal Segment:Offset address notation throughout this story.

The uncompressed Award BIOS v4.50(G) contains the following 5 checksum bytes:
1) F000:E07B is the Version string checksum of 1Ah bytes at offsets E061-E07A
2) F000:E10F is the Revision string checksum of 4Eh bytes at offsets E0C1-E10E
3) F000:FFEE is the checksum of a block of 1FEEh bytes at offsets E000-FFED
4) F000:FFEF is the checksum of the previous 3 checksum bytes
5) F000:FFFF is the checksum of the whole F-segment, so FFFFh bytes at offsets 0000-FFFE
All these checksums are simple 8-bit additions that should produce zero with the checksum byte included in the addition.

Luckily, Award’s Modbin tool works also on the uncompressed BIOS and these checksum bytes are updated automatically when you save your changes in Modbin. In addition, patching the upper 8KB (from offset E000h) is seldom needed and the Revision string can be updated from Modbin. So normally you don’t have to adjust the first 4 checksum bytes when manually patching a BIOS. But you do need to adjust the F-segment checksum at offset FFFFh in this case.

Now when the PCI bus came along, a lot of added BIOS support was needed and the 64KB BIOS was replaced by an 128KB BIOS. This double sized BIOS now occupied 2 segments, the E-segment and the F-segment or E000:0000 – F000:FFFF in Segment:Offset address notation.
These still uncompressed Award v4.50(G) 128KB BIOSes were used on 486 PCI and early Pentium Socket 5 boards.

Most POST routines were placed in the E-segment so that after POST the complete BIOS runtime with all its Interrupt service routines remained available in the F-segment.
Curiously, the E-segment of these uncompressed 128KB Award BIOSes didn’t have any checksum checking, but the F-segment checksums remained identical to that of the 64KB BIOS. This makes patching bugs in the E-segment a lot easier for us!

Of course, when opening a 128KB BIOS file in your Hexeditor, you now see the F-segment and its checksums at fileoffsets 10000h-1FFFFh instead off 0000h-FFFFh. The F-segment checksum at fileoffset 1FFFFh is now checked by adding fileoffsets 10000h-1FFFFh.
For this, a Hexeditor with checksum function is a very handy tool!

As an example of the kind of patches that are possible, I’ve attached a CHANGES.TXT file below. It documents all the changes I’ve made in my uncompressed 128KB Soyo 030F2 Socket 3 BIOS.
At the time I just discovered Award’s Modbin tool and as you can see I modded the various SETUP menu’s extensively, to try-out how far I could tweak the chipset. 😉
In the next part I will talk about each manual patch in detail!

At the end of this episode, a final remark about the Award v4.50(G) BIOS.
These BIOSes copy themselves from ROM to shadow RAM during POST. This of course is to increase performance, but also to store the Harddisk parameter tables inside the BIOS during POST. And I’ve seen several cases where the BIOS used self-modifying code. Ugly but effective.
So be aware of BIOS dumps made via a BIOS copy tool or Debug script. Those BIOS dumps are always a copy from shadow RAM and probably won’t work when programmed back into an EPROM.

Therefore it is great that the retro computing community has a lot of these original BIOSes on file now, or own an (E)EPROM programmer to make a correct BIOS dump directly from the EPROM.

Jan

Edit: Changed all references to the uncompressed v4.50(P)(G) BIOS into v4.50(G). The Award v4.50PG BIOSes are compressed.

Does this have to do with why you set system bios caching to disabled on your bios versions or is that a different reason? You told me long ago to keep it off.

Sphere478 wrote on 2021-11-22, 10:45:

Does this have to do with why you set system bios caching to disabled on your bios versions or is that a different reason? You told me long ago to keep it off.

No, he just meant that you should disable shadow ram when dumping the BIOS with debug or some tool.
Of course you have shadow ram enabled for normal operating purpose.

The thing with the disk parameters is the question where the BIOS stores the values for a type 47 disk.
If the BIOS is shadowed, the parameters may be put in the BIOS address range directly (because shadow RAM is writable, but BIOS ROM not).
There are 2 common other ways, one is to recduce conventional memory from 640K to 639K and store the parameters there.
The other way is to misuse some entries in the interrupt vector table in the first KB.

Shadowing the BIOS ROM (and option ROMs) to RAM is indeed a different technique from allowing System BIOS code and data be cached by the CPU and motherboard cache memories.

My advise to disabled the System BIOS Cacheable option in the BIOS is because of a timing issue between K6 CPUS with internal L2 cache (K6-III, K6-2+, K6-III+) and several earlier Socket 7 chipsets.
When testing K6plus CPUs on boards with Intel 430TX, 430VX, ALi Aladdin IV(+), and SiS5582 chipsets, I found instabilities and boot problems that would go away when the System BIOS Cacheable option was disabled.

Well, I found an instability at BIOS' default voltage value of 2.2 V. When I changed it to 2.0 V the instabilities were gone 😀
And happily in my MVP3 boards I never faced this problem.

#Part 3 – What to patch in an uncompressed Award BIOS

After two episodes of preliminaries, it is time to start patching! 😀

1) Let’s start with the Year 2094 bug. A well known bug in 1994-1995 Award BIOSes.
Actually this bug and its fix were already addressed here recently by jakethompson1, but I will also show it here for completeness sake.
This bug causes the year to jump forward to 2094 at each boot-up whenever the date was set to 1-1-2000 or later.

At POST 0B, the BIOS checks if the RTC uses valid values by reading the CMOS registers for seconds, minutes, hours, day, month, year, and century. It then uses a short table with maximum and minimum values for each of these 7 registers.
The minimum values table contains the hex numbers: 00, 00, 00, 01, 01, 94, 19, and this is the binary signature you have to look for. If you don’t find this signature, your PC should be free of this bug.

The error is in the routine that walks this table, but the fix is setting the minimum year from 1994 to 2000 by changing the last 2 bytes in this table.
The new table should become: 00, 00, 00, 01, 01, 00, 20 to fix this bug.

Note that this silly bug appeared in mid 1994 when Award tried to make the BIOS millennium compliant. Before that, the BIOS didn’t do any century checking, and when Award fixed this bug by the end of 1995, they simply removed this century check again! 😉

2) The 2nd bugfix is for the 2GB Harddisk size display limit bug.

At the beginning of 1994, the IDE Harddisk support of most BIOSes was still limited to 504MB.
But Award fixed that, and all Award BIOSes dated July 1994 or later correctly support the LBA assisted translation, up to the 8 GB limit of the traditional BIOS Int 13h interface.
There is however a bug in the BIOSes dated before January 1996 that limits the harddisk size display, on the BIOS Setup and boot screens, to 2015 MB.

Whenever a drive is 2016 MB or larger, the display starts to count from zero again. The same happens at 4032 and 6048 MB.
This looks a lot like the an actual 2 GB limit but is only a cosmetic bug in the harddisk size display routine, and it doesn't affect the BIOS support for these larger drives.
For these Award v4.50(P)(G) BIOSes, just use the HDD AUTO DETECTION feature to Setup the drive, select the option with LBA at the end, and disregard the incorrect HD size display.
Or, you could read on and patch this bug yourself! 😉

I have found 2 variations of this buggy code in the Award v4.50(P)(G) BIOS, but both variations use the same calculation method and therefore have the same bug. This piece of code takes the Cylinder, Head, and Sector count of the drive in question, multiplies them and divides the result by 2048 to arrive at the number of MB. In the buggy code a between result gets truncated and as a consequence the end result rolls over to zero every 2016MB.
For this bugfix I rearranged the multiplication order so the truncation doesn’t happen and this new code fitted nicely in the same space, so you only have to overwrite the old code by the new.

This is the first variation, and below you’ll see how the buggy and the fixed code look in my disassembler listing of a 03/10/95-ALI-1439G-1437-2A4KC000-00 BIOS.

So the 21 bytes long hex signatures of this first bug and its patch are as follows:
Buggy1: 8B,86,94,00,32,ED,8A,8E,96,00,F7,E1,8A,8E,9B,00,F7,E1,B9,00,08
Patch1: 8A,86,96,00,8A,8E,9B,00,C0,E1,02,90,F6,E1,F7,A6,94,00,B9,00,20
The checksum of this patch1 is 29h less than the buggy1 code, so if this is the only patch you make, add 29h to the last byte of the BIOS to make the F-segment checksum correct again.

And this is the second variation of this bug, as found in the 11/03/94--2C4X6H01-00 BIOS.

This code is even 3 bytes longer and so is its patch.
The 24 bytes long hex signatures of this second bug and its patch are as follows:
Buggy2: 8B,86,94,00,32,ED,8A,8E,96,00,F7,E1,8A,8E,9B,00,C1,E1,03,F7,E1,B9,09,3D
Patch2: 8A,86,96,00,32,ED,8A,8E,9B,00,C0,E1,02,F6,E1,8B,8E,94,00,F7,E1,B9,00,20
The checksum of this patch2 is 29h less than the buggy2 code, so if this is the only patch you make, add 29h to the last byte of the BIOS to make the F-segment checksum correct again.

In the next part I will talk about what can be changed in the uncompressed Award BIOS, to have better Am5x86-133 support.

Jan

Thank you very much for this precious information !!

I've been able to patch the silly bug of the bios of my Full Yes SiS486G
Before

After

My patched bios

Original bios can be found here : https://www.ultimateretro.net/fr/motherboards/5549 ( 07/28/94-SIS-85C471B/E-2C4I9F30-00 )
There are other bugs that would need to be patched in that one though (such as the "1921" bug that you can see here), but this one was quite a silly one 😁

Patching this using DOS' debug was quite tedious though. What kind of editor do you use ? A simple hex file isn't exactly the most appropriate thing either, I'd like something where I can write and read ASM as well as read HEX, kind of like DOS' debug, but better.

By the way do you know what "P" and "G" means in award bioses like this ?

Is P = PCI and G = Green ?

Hi Deksor,

Okay, you did a succesful 2GB patch on your FY-SiS486G BIOS! 😀

Thanks for the original 07/28/94-SIS-85C471B/E-2C4I9F30-00 BIOS.
I looked into the POST code for the RTC but didn’t find any deviations that could explain a “1921” bug. When the year is set to 2021, and the battery is good, it should stay at 2021 after a power down / up cycle.

I first started patching these BIOSes using the DOS Hexeditor that came with my EPROM programmer, but I’m now using Hex Editor Neo by HHD Software Ltd. The free edition of this editor has already a lot of functions, but for checksum and assembler support you have to pay €. 😉

I believe that the G in Award v4.50PG indeed stands for “Green”, to indicate APM support, but the P probably stands for “Plug&Play”. 486 PCI boards are already indicated by 2A4 in the BIOS-ID. 486 ISA and VLB board BIOSes show as 2C4xxxx.

About 2 weeks ago I got a help request by PM from another SiS486G user, to get his Am5x86-133 running on this board, including L1 cache WB mode. As expected, the problem was the lack of BIOS support for this CPU. As this is a SiS471 chipset board, I first tried an up-to-date 11/28/95-SIS-85C471B/E/G-2C4I9G30-00 V3.06 BIOS from a Gemlight board (4WSPG306.BIN), before I spent a lot of time patching the original.

Transplanting a BIOS from another board is not always successful, but with SiS471 boards this usually works fine, and I used this 11/28/95 BIOS successfully on several SiS471 boards, including my Chicony CH-471B. But I do adapt the default chipset register programming via Modbin to that of the original BIOS for each board, to maximize success.

In QDI V4S471/G locks up with 1024kB of cache [Fixed! Nicer Award BIOS available!] member GigAHerZ reports the same success with this 11/28/95 BIOS on his QDI board.

Anyway, the user I sent the updated SiS486G BIOS to, reported that this 11/28/95 BIOS works fine on his FY-SiS486G board, running an Am5x86 at 4x 33 and L1 cache WB mode.
You can download this Rev J.1 BIOS from my site at:
http://www.steunebrink.info/bios/486G-J1.zip

Note that this BIOS shows the “L1 cache: WB/WT” option in the BIOS Setup only for the P24T and for Cyrix CPUs.
For the P24D (486DX2WB), Am486DX4WB and Am5x86, this 11/28/95 BIOS can detect if these CPUs are in WB mode and programs the chipset registers accordingly. It then hides the “L1 cache: WB/WT” option, because user interaction for this automatic function is not required.
So, you only have to find the correct jumpers for L1 WB mode and the BIOS takes care of the rest. 😉

Jan

Edit: updated the link to my website

Thanks !

The screenshots I made were made using PCem, so this might be why the clock was showing a weird date.
For the WB jumper I think I figured it out, but this BIOS refuses to POST when I set it on a DX4 with write back cache, so I guess this is why.

I remember trying a bios from another board way before I made ur.net and it didn't work well. It was actually one of the first thing that made me think that there should be a place listing bioses with their related chipset ... Now we have it 😁

When is the next episode? 😀

Sphere478 wrote on 2021-12-14, 10:09:

When is the next episode? 😀

I'm still working on it. 😉
This episode will be about adding Am5x86-133 support to the uncompressed Award Socket 3 BIOS.
It is probably the most complex episode of the series so it takes some time to find good examples and to get the story as clear as possible.

Modding these 486 BIOSes has also relevance on how to patch Socket 7 BIOSes for K6(+), so I want to tell this 486 stuff first.

Cheers, Jan

#Part 4 – What to patch in an uncompressed Award BIOS – cont’d

In this episode, I will talk about what you can do to get better Am5x86-133 support in your 486 Award BIOS. However, this will be a rather complex story, because Award Software made a lot of changes to its 486 BIOS during the 1994-1995 period, to support all those different 486 CPUs.
So this will be more like a detective story through the BIOS code, with a few examples to clarify the issue.

There are some distinct differences in CPU detection between 1994 and 1995 Award BIOSes and in this episode I will talk about the 1994 BIOS and show details about the 1995 BIOS in a next episode.

I will begin with the end result of the CPU detection, that is what is shown on the BIOS boot screen, and work backwards from there.

Displaying the CPU model
The BIOS contains a list of ASCII-strings of all supported CPU models, and selects one for display of the detected CPU on the boot and summary screens. As there is always a 486DX string in this list, just search for 486DX in the BIOS image with your Hexeditor to find this list. The result will look like this:

This example shows a November 1994 BIOS from a Soyo 30F2 board (11/24/94-OPTI-802G-822-2A4UKS21-00).
As you can see, this BIOS doesn’t support the Am486DX4 Enhanced or Am5x86-P75. The last CPU in the list is for the non-WB AMD 486DX4. In slightly older BIOS versions, like from July 1994, you will see P24D as last in the list and support for both the Am486DX2 and Am486DX4 is missing.

Each entry in this CPU list starts with a byte that holds the length of the string and each string ends with a null byte. Directly preceding the CPU list is a long array of 16-bit words that serves as an index into the CPU list. Each word in this index holds the offset of an item in the CPU list, and the routine that uses this index to select a particular CPU string can be found right before the index array. Here is a disassembly listing of this piece of the BIOS that makes it more clear.

From this listing, you can see that the BIOS holds a uP_ID byte in variable [BP+3Dh] that indicates the detected CPU model. This uP_ID is zero based and in this BIOS it runs from 00 for the 80386DX to 3Fh for the Am486DX4.
These uP_ID’s are only used by the BIOS internally and may vary between BIOS versions, but for the DX4 the uP_ID is usually 2Bh. This knowledge will be useful later on, when adding Am5x86 support.

CPU detection
We now jump back further into the BIOS where the actual CPU detection is done and where the uP_ID is generated.

Just after Reset, the CPU places a 2-byte ID word in its DX register. Remember that most 486 CPUs don’t support the CPUID instruction, so these 1994 BIOSes had to rely on this Reset_ID for CPU identification.
This Reset_ID is then passed on to a “detect_CPU_type” routine. This routine uses a table with known Reset_ID’s to identify the installed CPU, and this is how this table looks in the same 11/24/94 BIOS:

The table in this BIOS holds 14 items of 6 bytes each. The last 4 bytes of each item form 2 words, that I’ve named Reset_ID_from and Reset_ID_to, and the detection routine checks the CPU’s Reset_ID against these table values. The table is checked from top to bottom and the detection stops when a match is found. So the sequence of the table entries is important.

When a match is found, the two corresponding CMOS_3D_uP_ID and CMOS_3F_data bytes of that table item are stored in CMOS registers 3Dh and 3Fh respectively.
Bits 6-0 in the CMOS_3D_uP_ID byte represents the BIOS_uP_ID and a “1” in bit 7 means that a L1 cache is present.
The bits in the CMOS_3F_data byte represent additional CPU data:

Bit 7 = clock tripling CPU
Bit 6 = clock doubling CPU
Bit 5 = reserved
Bit 4 = Green CPU (in older BIOS versions, this is bit 5)
Bits 3-0 are reserved.

In the above table the first item, with Reset_ID 1480h-148Fh, is for the DX4 ODP, and the second item (0480h-048Fh) is clearly for the regular DX4. Both give a CMOS_3Dh value of ABh and, after stripping bit 7, we get the expected BIOS_uP_ID of 2Bh. The third item (0490h-0490h) is for the Cx486DX, and with the above information you can decode the other table entries.
The table ends with an item that points to an “Unknown” CPU string and catches all remaining Reset_IDs from 0-FFFFh. This entry should never be overwritten.

To find this table in your BIOS, search for the hex bytes 80, 04, 8F, 04. These Reset_ID values of 0480h-048Fh are for the DX4 and should be present in every 1994 Award v4.50G BIOS.
In a hexeditor, this looks like:

Unfortunately these Reset_IDs don’t tell us who the CPU vendor is, and many comparable CPU models from different vendors use the same Reset_ID. So, further on during POST additional checks are made for Cyrix/TI and UMC CPUs, but this is all done with hard coded, and sometimes undocumented, instructions in several subroutines. Even the CPUID instruction is used (only twice in this 1994 BIOS), to identify the Intel 486DX2WB (P24D).

All this additional code is quite complex and has no bearing on adding Am5x86 support, so I will not show it here.
But what I will show is the end result of these additional CPU checks, combined with the Reset_ID table detection and the CPU models list shown above.

For this 11/24/94 BIOS, this document shows for each valid BIOS_uP_ID, the CPU list string, the detection method, additional CPU flags, and the sequence order of the detection during POST.

Studying this CPU support list reveals some curious facts:
1) Several CPUs that can never run on a Socket 3 board, like 386 and Pentium, are (still) present.
2) There is no detection logic for Am486DX and Am486DX2 parts. So support for these CPUs in this BIOS is broken.
3) Detection of the Am486DX4 (Non WB) is done by clever deduction. This CPU has a 043xh Reset_ID and is therefore identified as an 80486DX2. (This is why older BIOSes often show this Am486DX4 as an 80486DX2.) But here a check is made on the CPU speed. As the fastest Am486DX2 is running at 80MHz, and the Am486DX4 does 100MHz, an 80486DX2 running faster than 90MHz must be an Am486DX4.

- more in the next posting -