For the PhoenixBIOS is it encrypted in the eeprom itself? I ordered a PLCC32 for my CH341A was hoping I could get in there and change some strings/boot image just as an easy first task.
I attached my extbios+hwinf results, it looks promising! `Int 13h extensions version 2.1 detected` I am just limited by the limits of my drive geometry that the BIOS allows me to express (drive 2)
I have a DFI 586ITBD motherboard with 2A59ID4T bios. The bios detects a k6-2 fine, however I recently put k6-2+ in it shows empty string and wrong clock speed, still with bios caching is disabled, the CPU starts fine (I hadn't read your post then and found it by try and error). In terms of performance, I am gaining a bit boost over k6-2 but I want to make sure that write-back/through and other settings are set correctly, and of course I like see correct CPU model shown on boot up screen 😀
I look forward for your posts about patching bios ROMs from 1995-2000.
I have modified a bios once; I needed a pnp soundcard be initialized in bios so I can have xt-ide boot from the soundcard ide.
Based on what I read it would take me some time to understand code and inject new cpu code.
I have a DFI 586ITBD motherboard with 2A59ID4T bios. The bios detects a k6-2 fine, however I recently put k6-2+ in it shows empty string and wrong clock speed, still with bios caching is disabled, the CPU starts fine (I hadn't read your post then and found it by try and error). In terms of performance, I am gaining a bit boost over k6-2 but I want to make sure that write-back/through and other settings are set correctly, and of course I like see correct CPU model shown on boot up screen 😀
I look forward for your posts about patching bios ROMs from 1995-2000.
In addition to a bios update, you may also find these links useful.
For the PhoenixBIOS is it encrypted in the eeprom itself? I ordered a PLCC32 for my CH341A was hoping I could get in there and change some strings/boot image just as an easy first task.
I attached my extbios+hwinf results, it looks promising! `Int 13h extensions version 2.1 detected` I am just limited by the limits of my drive geometry that the BIOS allows me to express (drive 2)
Yes, encrypted or compressed BIOSes are stored like that in the EEPROM chip. A small part of such a BIOS is not encrypted or compressed and takes care of the decryption/decompression of the BIOS modules in RAM during each boot.
According the Extbios ouput, this BIOS indeed supports the Int 13h extensions and should handle drives up to the LBA28 limit of 128GiB.
Strangely, Extbios reports that both drives are configured as Slave. This can’t be right!
What if you connect only the 30GB SSD, is it recognized correctly and as master then?
About the detected geometry, how is(are) the drive(s) configured in the BIOS? Is the BIOS on Harddisk Autodetect or did you put the CHS values in manually? The first option is the preferred method when dealing with > 8GB drives.
I have a DFI 586ITBD motherboard with 2A59ID4T bios. The bios detects a k6-2 fine, however I recently put k6-2+ in it shows empty string and wrong clock speed, still with bios caching is disabled, the CPU starts fine (I hadn't read your post then and found it by try and error). In terms of performance, I am gaining a bit boost over k6-2 but I want to make sure that write-back/through and other settings are set correctly, and of course I like see correct CPU model shown on boot up screen 😀
I look forward for your posts about patching bios ROMs from 1995-2000.
Hi terryfi,
I haven’t worked on the DFI 586ITBD BIOS before, so I need to analyse this BIOS to see what changes can be made.
Please send me a copy of your 2A59ID4T BIOS and I will tell you which improvements are possible.
I've checked this mid 1998 BIOS and yes, it can be patched for:
- K6-III/K6-2+/K6-III+ support
- Write-Allocation support for K6-2CXT/-III/-2+/-III+
- CPU speed support above 400MHz up to 500MHz
- 32GB and 64GB bugfixes for 128GiB HDD support
I’ve put it on my “to do” list and I will let you know when its ready. This may take a couple of weeks though, because for one I want to finish the next episode of the DIY patching story first.😀
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'm willing to wager that a 2021 -> 1921 wraparound is due to faulty hardware design in the RTC, beyond the BIOS. Probably built using an "old" design that didn't handle the century change too well. This is one area where having a discrete Dallas chip is far preferable to having an RTC integrated, as hardware-level Y2K bugs can be much more easily fixed by changing the clockchip. (If an upgrade is available, that is.)
I choose to kinda, sorta work around hardware level Y2K bugs by making the system think it's running in 1994 or whenever, where at least the days and months match up to the current day. 😜
Life isn't long enough to re-enable every hidden option in every BIOS on every board... 🙁
Thanks Jan, please take your time; meanwhile we will enjoy your future stories 😀
Hi terryfi,
The patched DFI 586ITBD BIOS is ready and I send you a PM with the BIOS and a test guide.
Please let us know how it works, so I can publish this BIOS on my k6plus page. 😉
Thanks Jan, please take your time; meanwhile we will enjoy your future stories 😀
Hi terryfi,
The patched DFI 586ITBD BIOS is ready and I send you a PM with the BIOS and a test guide.
Please let us know how it works, so I can publish this BIOS on my k6plus page. 😉
Jan
Hi Jan
I did some testing with bios and sent you results in PM.
Before embarking on the next episode of this DIY BIOS Modding guide, I need to correct an omission and explain about endianness or, as Wikipedia defines it, “the order or sequence of bytes of a word of digital data in computer memory”.
A comprehensive article about endianness can be found at https://en.wikipedia.org/wiki/Endianness.
The essence of this long article for us is that all x86 computers use little-endian byte ordering. So the least significant byte of a word of digital data comes first when viewed from a hexadecimal byte listing like in a hexeditor. For example, a 16-bit pointer to a table at memory location F000:7F38h is stored as 38 7F and a data word of 048Fh, like a Reset_ID, is stored as 8F 04.
This may seem backwards if you are not familiar with reading disassembler listings or data from a hexeditor, but obviously this knowledge is essential for a successful BIOS patch. 😉
Thank you very much for comprehensive guide, looking forward next chapters!
I personally currently struggle with RAM limit in my old MoBo, it seems like memory mapping issues, probably some pci rom overlapping ram address space, still investigating.
#Part 5 – What to patch in an uncompressed Award BIOS – cont’d
In this episode, I will focus on the changed CPU detection in the 1995 BIOS and how that influences the patches you can make to get better Am5x86-133 support in these 486 Award BIOSes.
Between December 1994 and February 1995, support for the Enhanced Am486DX2/DX4 appears in the Award v4.50G BIOS. These AMD DX2/DX4 CPUs support L1 cache Write-Back and were sometimes displayed with their old Am486DX2PLUS/DX4PLUS name.
These new AMD models were detected via hardcoded CPUID instructions, the same way the P24D already was. So no changes in the Reset_ID table which means my previously described 1994 Am5x86 patch still works in these early 1995 BIOSes.
Around March 1995 however, a significant change in CPU detection was made.
Now that most new 486 CPUs support the CPUID instruction, Award started to use tables with CPUID values. Because CPUID not only retrieves the Reset_ID on the fly but also indicates the CPU manufacturer, a separate table with CPUID values can now be used for each CPU vendor.
This CPU detection method remained in use for years and can also be found in all Award socket 7 BIOSes.
Displaying the CPU model
Just like in the previous episode about the 1994 BIOS, I start with the CPU model list.
Finding this list of ASCII-strings of all supported CPU models in the 1995 Award BIOS, can also be done by searching for 486DX in the BIOS image with your Hexeditor. The result will look like this:
This example shows a September 1995 BIOS from a PCChips M912 board (09/08/95-UMC-498GP-2C4X6B13-00). This BIOS still doesn’t support the Am5x86-P75, but it does support the Enhanced Am486DX4 and the Cyrix 5x86 in x2 and x3 multiplier mode.
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 the disassembly listing of this piece of the BIOS.
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 06 for the 80486DX to 4Fh for the CxDX4.
The up_IDs 00 to 05, formerly used for 386 models, are not used anymore.
These uP_ID’s are only used by the BIOS internally and may vary between BIOS versions, but for the Enhanced Am486DX4 the uP_ID is usually 44h. This knowledge will be useful later on, when adding Am5x86 support.
We now jump back further into the BIOS where the actual CPU detection is done and where the uP_ID is generated. Unlike the single Reset_ID table detection method in earlier BIOS versions, these March 1995 and later BIOSes now use 3 different methods for CPU detection, with separate tables for each method!
For 486 CPUs without CPUID support a short Reset_ID table is still used, but Cyrix design CPUs now have their own detection method via a separate Cx_DIR0 table. The main CPU detection in these 1995 BIOSes however, is done via CPUID tables.
Method 1 - CPUID
This is how these CPUID tables look like in the same 09/08/95-UMC-498GP-2C4X6B13-00 BIOS:
The “Check_CPUID” routine that walks these tables first checks if the CPUID Vendor string matches one of the three entries in the first part of the table. Note that this example is from a BIOS on a 486 Socket 3 board, so there are only entries for Intel (GenuineIntel), AMD (AuthenticAMD), and UMC (UMC UMC UMC ). Other CPU vendors, like Cyrix, never supported the CPUID instruction on their 486 models.
A separate “Method 2” section about detecting Cyrix 486 models, including the Cx5x86, can be found below.
The CPUID Vendor string is always 12 characters long, and is reported by the CPU in three chunks of 4 characters. So GenuineIntel is seen by software as Genu_ineI_ntel and this allows some funny programming practices because the order in which these 4-letter chunks are checked is irrelevant.
In all Award BIOSes you see the Vendor string stored as GenuntelineI and AuthcAMDenti because the detection routine checks the 3rd 4 characters before the 2nd. Verry funny!😉
So when using your hexeditor to search for a Vendor string, use the first 4 characters only (Genu for Intel and Auth for AMD) and you can’t miss it.
Just before the Vendor string, the offset to the associated CPU signature table is stored. So after a CPU Vendor string match is found, the Check_CPUID routine knows which table to check.
Each item in these CPUID tables consists of 4 bytes. The first 2 bytes form the CPUID Signature word of that item, and the 3rd and 4th byte are the CMOS_3D_uP_ID and CMOS_3F_data bytes, just as in the Reset_ID table.
Note that the CPUID signature tables use only one Sign_ word for each item. After the BIOS retrieves the CPUID signature from the CPU, it sets the lowest nibble (the CPU stepping number) to zero before walking the table to find a match. So for example, the first item of the AMD table with a Signature of 0430h will give a match on any 0430h-043Fh AMD CPUID.
This makes each item in the table unique, without any chance of overlap and the order of each item in a table has no relevance. So no worries about sequence if you patch these CPUID tables. 😉
This is how the AMD CPUID table looks when you search for “Auth” with a hexeditor in the same 2C4X6B13 BIOS:
Another change in the 1995 Award BIOS is the way Cyrix CPUs are detected.
Instead of hard-coded instructions, a table with DIR0 (Device Identification Register 0) values is now used.
Device Identification Register 0 is present on all Cyrix design CPUs, except the Cx486S A-step. Its value can be used to uniquely identify a Cyrix/TI/IBM CPU model. This Cyrix 1-byte ID can be retrieved any time by a specific set of I/O instructions.
Some interesting DIR0 values:
The Cx_DIR0 table can usually be found right in front of the Reset_ID table. The “detect_CPU_type” routine is now modified to walk the Cx_DIR0 table instead of the Reset_ID table, when a Cyrix design CPU is detected.
This is how the Cx_DIR0 table looks in the same 09/08/95 BIOS:
The Cx_DIR0 table in this BIOS holds 7 items of 4 bytes each. The first 2 bytes are the two possible DIR0 values for each Cyrix model. Except for the Cx5x86, these two Cx_DIR0_S and Cx_DIR0_P values are usually the same. The 3rd and 4th byte are the CMOS_3D_uP_ID and CMOS_3F_data bytes, just as in the Reset_ID table.
The table is checked from top to bottom and the detection stops when a match is found. But there is no overlap so the sequence of the table entries is not important.
To find the Cx_DIR0 table in your BIOS, search for the hex bytes 29, 2B, CD, 50 or 2D, 2F, CD, 90. These table items for the Cx5x86 in x2 or x3 mode should be present in your 1995 Award v4.50G BIOS.
In a hexeditor, this looks like:
For completeness sake, here is the now much shorter Reset_ID table of this 09/08/95 BIOS, which is still used to detect non-Cyrix CPUs without CPUID support.
When the BIOS can’t find a match with detection method 1 and 2, this Reset_ID table is checked.
Each item of the CPUID tables, the Cx_DIR0 table, and the Reset_ID table contains two corresponding CMOS_3D_uP_ID and CMOS_3F_data bytes. When a match is found, these bytes are stored in CMOS registers 3Dh and 3Fh respectively, just as in the 1994 BIOS.
Bits 6-0 in the CMOS_3D_uP_ID byte represent the BIOS_uP_ID. A “1” in bit 7 means that a L1 cache is present, while bit 0 indicates if the CPU has a build-in FPU.
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 (used for clock quadrupling CPU in later BIOS versions)
Bit 4 = Green CPU
Bit 3 = CPU in L1 cache Write-Back mode
Bits 2-0 are reserved.
Note that the definition of bit 3 is new and indicates that the CPU is in L1 cache WB mode. On specific chipsets, the BIOS uses this information to program the chipset registers accordingly.
So we have now 3 tables for CPU identification in these 1995 BIOSes, and when we put all this Reset_ID, Cx_DIR0, and CPUID detection together, we get the following CPU support list:
For this 09/08/95 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 notable changes in respect to the 1994 BIOS:
1) Several 386 era CPUs, like Cx486SLC(2)/Cx486DLC(2) are no longer supported.
2) There is still no detection logic for Am486DX and Am486DX2 parts. As these part don’t support CPUID and because AMD licensed the microcode from Intel for these DX/DX2 CPUs, they are indistinguishable from the Intel parts software wise. The BIOS will indicate these AMD CPU just as 80486DX(2), which they essentially are. 😉
3) A lot of Intel, AMD, and UMC models are now detected via CPUID i.s.o. via Reset_ID, and the Cyrix detection is improved as well by the use of DIR0.
4) Among newly supported CPUs are the Intel 486DX4WB, AMD Enhanced 486DX2/DX4, CxDX4, Cyrix 5x86, and UMC 486SX2/DX2. Only Am5x86 support is still missing, but adding that is what this episode is all about!
Okay, now we need to decide what needs to be changed to support the Am5x86 CPU in the 1995 BIOS.
Because the BIOS_uP_ID is used in multiple places during POST to make decisions depending on the CPU model, the most effective way to add Am5x86 support to a 1995 BIOS is to let the BIOS think it is an Enhanced Am486DX4. Because the 1995 BIOS now uses CPUID for CPU detection, changes have to be made in the CPUID tables, and not in the Reset_ID table.
As we saw in the previous episode about the 1994 BIOS, the Am5x86 can have 4 different Reset_IDs:
0484h: x3 mode and Write-Through cache
0494h: x3 mode and Write-Back cache
04E4h: x4 mode and Write-Through cache
04F4h: x4 mode and Write-Back cache
Note that when using the CPUID instruction, we simply get the Reset_ID on the fly and call it the CPUID Processor Signature, but the value is the same.
The x3 mode CPUID Signatures 048xh and 049xh are also used by the Enhanced Am486DX4 and already supported by the 1995 BIOS, so we only have to add both x4 mode Signatures 04Exh and 04Fxh.
As most 1995 BIOSes now have logic to program the chipset for L1 cache WB automatically, we have to distinguish between L1 cache Write-Through and Write-Back Signatures. So for the Am5x86 we need to have 2 new table items, one with Signature 04E0h (WT) and a second with Signature 04F0h (WB).
Often, there is no room to expand the CPUID Signatures tables at their original location, so we have to copy the AMD signature table to an unused part of the BIOS and add the Am5x86 signatures there.
When using your hexeditor to look for a place to put the expanded table, choose a location before offset E000h that has a continuous block of 00h or FFh bytes. Usually you find this at the end of the code section.
But stay away at least 100 bytes from the last non-zero byte, because the BIOS uses this seemingly empty block to store Power Management data.
Here is an example of a relocated and expanded AMD Signature table placed at offset DD00h, sufficiently away from the end of code.
So the new AMD table is put at another location and expanded from 4 to 6 items. The 2 added items for the Am5x86 in x4 mode have the same CMOS_3D-uP_ID byte (C5h) as the Enhanced Am486DX4, and the CMOS_3F_data byte for these items has both bits 7 and 6 set to indicate x4 mode. In addition, bit 3 of the CMOS_3F_data byte for signature 04F0h is set to indicate L1 cache WB mode.
This means the following bytes have to be added behind the copied AMD table at the new location: E0, 04, C5, D0, F0, 04, C5, D8, FF, FF
Then, change the 2 bytes in front of the AuthcAMDenti string to point at the offset of the new table.
In the above example: 1A, 85 -> 00, DD but these values will be different for each BIOS.
Patching for the Cx5x86
To add Cx5x86 x4 mode detection to the 1995 BIOS, we only have to change one 4-byte item in the Cx_DIR0 table. I’ve selected the Cx486S item for that and because this CPU is still detected via the Reset_ID table, we can safely overwrite its item in the Cx_DIR0 table with the required Cx5x86 data.
So this simple patch becomes: 12, 12, 96, 10 -> 2C, 2E, CD, D0
What remains is adding x4 multiplier support to the routine that determines the bus_speed (FSB), so the chipset’s DRAM and L2 cache timing registers are programmed correctly.
This fix is the same as for the 1994 Award BIOS, and works now for both the Am5x86 and Cx5x86.
See Part 4 of this story for the details.
Finally, if you had to make changes in the F-segment, remember to correct the last byte of the BIOS to make the checksum good again. 😉
Edit: Around November 1995, Award added Am5x86-P75 and x4 multiplier support to the v4.50G BIOS. So if your socket 3 BIOS is from late 1995/1996, chances are good you don’t need any of the above patches. 😀
In the next part of this story, I will focus on how the compressed Award BIOS can be patched.
Jan
Last edited by Chkcpu on 2022-06-16, 12:02. Edited 1 time in total.