ayandon wrote on 2025-02-19, 05:50:

Hello friends, […]
Show full quote

Hello friends,

I am facing this issue with the default BIOS Patcher Tool.

This is the config -
AMD K6-2 500 MHz + Zida T530B-S motherboard

See the attached screenshot -
Processor Name and Memory Test Counter is overlapping!

Any way to fix this stupid annoying issue?

Actually, this is exactly what this thread is about. Trying to fix this issue.
I recommend giving these 2 pages a read.

B24Fox wrote on 2025-02-19, 08:33:

ayandon wrote on 2025-02-19, 05:50:

Hello friends, […]
Show full quote

Hello friends,

I am facing this issue with the default BIOS Patcher Tool.

This is the config -
AMD K6-2 500 MHz + Zida T530B-S motherboard

See the attached screenshot -
Processor Name and Memory Test Counter is overlapping!

Any way to fix this stupid annoying issue?

Actually, this is exactly what this thread is about. Trying to fix this issue.
I recommend giving these 2 pages a read.

Hello ayandon,

This thread is indeed a great resource about the inner workings of the BIOS Patcher tool and fixing some of its shortcomings! 😀

But if you don’t mind me asking, why are you using BIOS Patcher on your Zida T530B-S BIOS? The latest BIOS is from August 2000 and by that time all 1997-1999 era socket 7 BIOS bugs had been fixed.
I’ve checked the 08/31/2000 Ver. 102 and 103m BIOS and found full K6-2+/III+ support, 128GiB IDE HDD support, and correct UDMA support for Win98(SE).

So the original BIOS shouldn’t need any patching, and I’m curious what you attempted to fix with the BIOS Patcher tool. 😉

Greetings, Jan

Chkcpu wrote on 2025-02-24, 21:15:

Hello ayandon, […]
Show full quote

Hello ayandon,

This thread is indeed a great resource about the inner workings of the BIOS Patcher tool and fixing some of its shortcomings! 😀

But if you don’t mind me asking, why are you using BIOS Patcher on your Zida T530B-S BIOS? The latest BIOS is from August 2000 and by that time all 1997-1999 era socket 7 BIOS bugs had been fixed.
I’ve checked the 08/31/2000 Ver. 102 and 103m BIOS and found full K6-2+/III+ support, 128GiB IDE HDD support, and correct UDMA support for Win98(SE).

So the original BIOS shouldn’t need any patching, and I’m curious what you attempted to fix with the BIOS Patcher tool. 😉

Greetings, Jan

Friend, even I am not sure.....
Pls have a look at the screenshot.
Only Point 13 looks interesting for me.

2 reasons why I was trying BIOS patcher -
1. with my CF-IDE Adapter with 2 GB, DMA option is Disabled in Windows 98 Device Manager!
2. with AT Power supply, when I shut-down the Windows, the screen with message "it is now safe to turn off the system" never shows for some unknown reason.

ayandon wrote on 2025-02-25, 17:44:

Friend, even I am not sure..... Pls have a look at the screenshot. Only Point 13 looks interesting for me. […]
Show full quote

Chkcpu wrote on 2025-02-24, 21:15:

Hello ayandon, […]
Show full quote

Hello ayandon,

This thread is indeed a great resource about the inner workings of the BIOS Patcher tool and fixing some of its shortcomings! 😀

But if you don’t mind me asking, why are you using BIOS Patcher on your Zida T530B-S BIOS? The latest BIOS is from August 2000 and by that time all 1997-1999 era socket 7 BIOS bugs had been fixed.
I’ve checked the 08/31/2000 Ver. 102 and 103m BIOS and found full K6-2+/III+ support, 128GiB IDE HDD support, and correct UDMA support for Win98(SE).

So the original BIOS shouldn’t need any patching, and I’m curious what you attempted to fix with the BIOS Patcher tool. 😉

Greetings, Jan

Friend, even I am not sure.....
Pls have a look at the screenshot.
Only Point 13 looks interesting for me.

2 reasons why I was trying BIOS patcher -
1. with my CF-IDE Adapter with 2 GB, DMA option is Disabled in Windows 98 Device Manager!
2. with AT Power supply, when I shut-down the Windows, the screen with message "it is now safe to turn off the system" never shows for some unknown reason.

1.
There is the possibility that that particular CF Card does not support DMA mode (only PIO)... or... you do not have the correct IDE drivers installed in Win98.
I suggest trying that CF card (with the adapter) on a more modern PC that has IDE, and checking if that CF actually supports DMA or UDMA modes.

2.
That happens to me too with some video cards (especially intel cards... & some others too), on my VIA KT266 machine.
Probably the video card is instructed to power-off along with the OS.
You could fiddle with video options in BIOS, like enabling/disabling VGA BIOS Caching, etc..
Or you can experiment with a different driver or a video card from another manufacturer.

B24Fox wrote on 2025-02-25, 20:40:

1. There is the possibility that that particular CF Card doen not support DMA mode (only PIO)... or... you do not have the corr […]
Show full quote

ayandon wrote on 2025-02-25, 17:44:

Friend, even I am not sure..... Pls have a look at the screenshot. Only Point 13 looks interesting for me. […]
Show full quote

Chkcpu wrote on 2025-02-24, 21:15:

Hello ayandon, […]
Show full quote

Hello ayandon,

This thread is indeed a great resource about the inner workings of the BIOS Patcher tool and fixing some of its shortcomings! 😀

But if you don’t mind me asking, why are you using BIOS Patcher on your Zida T530B-S BIOS? The latest BIOS is from August 2000 and by that time all 1997-1999 era socket 7 BIOS bugs had been fixed.
I’ve checked the 08/31/2000 Ver. 102 and 103m BIOS and found full K6-2+/III+ support, 128GiB IDE HDD support, and correct UDMA support for Win98(SE).

So the original BIOS shouldn’t need any patching, and I’m curious what you attempted to fix with the BIOS Patcher tool. 😉

Greetings, Jan

Friend, even I am not sure.....
Pls have a look at the screenshot.
Only Point 13 looks interesting for me.

2 reasons why I was trying BIOS patcher -
1. with my CF-IDE Adapter with 2 GB, DMA option is Disabled in Windows 98 Device Manager!
2. with AT Power supply, when I shut-down the Windows, the screen with message "it is now safe to turn off the system" never shows for some unknown reason.

1.
There is the possibility that that particular CF Card doen not support DMA mode (only PIO)... or... you do not have the correct IDE drivers installed in Win98.
I suggest trying that CF card (with the adapter) on a more modern PC that has IDE, and checking if that CF actually supports DMA or UDMA modes.

2.
That happens to me too with some video cards (especially intel cards... & some others too), on my VIA KT266 machine.
Probably the video card is instructed to power-off along with the OS.
You could fiddle with video options in BIOS, like enabling/disabling VGA BIOS Caching, etc..
Or you can experiment with a different driver or a video card from another manufacturer.

Hi ayandon,

I agree with @B24Fox that your 2 reasons are not BIOS related and can not be fixed with the BIOS Patcher tool.

Note that this BP tool can fix know bugs in the compressed Award BIOS for the Socket 5/7, Pentium Pro/II/III/4, and AMD Slot A/Socket A systems. So that is why you see a lot of “fixes” in the output of BP that are not applicable when patching a Socket 7 BIOS.

What BP found and fixed at point 1. and 3. is unclear. The 08/31/2000 BIOS fully supports all Socket 7 CPUs ever made, so there shouldn’t be any CPU or Multiplier support fixes needed.
At point 13. “New Freq in Setup open”, BP found some hidden BIOS options that it made selectable. In this case these are additional chipset Frequency selections of the “CPU Host/SDRAM Clock” option in the CHIPSET FEATURES SETUP menu.
But you don’t need BP to make these selections visible, you can do that directly in Award’s Modbin tool.

Be aware that these Non-selectable items are often made hidden on purpose by the motherboard manufacturer, because they are not supported by the board design.
So if you try them out, they may not work or give unpredictable results. 😉

Happy patching!
Jan

Thanks a lot @B24Fox and @Chkcpu for guiding me to the right direction.

I would like to continue in this thread with another request (a.k.a. pathetic cry for help), regarding the BIOS of the same motherboard model (PCchips M577).

I have 2 original BIOSes saved from 2 identical motherboards (PCchips M577, same revision, same everything).
Their BIOSes are the exact same version, and had the same character string at POST; but the ROMs I saved , do not have the same MD5/checksum!
And I'm asking if someone can PLEASE "open them up" and find out what's different between them.

The reason for this, is that the upgraded bios that worked VERY well on the 1st board; causes some weird performance issues on the 2nd board.
So maybe there are some clues in the difference found between their original BIOSes... since they present themselves as "identical version", but they don't seem to actually be identical.
(full story in this post: Re: Problem with UDMA, need BIOS fix for Taken TX3 (LGS Prime 3C))

Hi B24Fox,

I did the comparison between the 1st and 2nd original M577 BIOS. The result: they are byte for byte identical!
So unfortunately no clues for the performance issue on the 2nd board here. 🙁

The reason you see a different checksum is that off course the ESCD blocks are different. This 4KB block is where the BIOS stores its Plug&Play data, and is located at offsets 1D000h-1DFFFh in this BIOS file.
Only if you would have used the exact same set of expansion cards and peripherals on both boards, the ESCD blocks would have been the same.

The CMOS memory of only 128 bytes, used for the RTC registers and the BIOS Setup menu selections, is much too small to house the PnP resource assignments. So a dedicated 4096 bytes block in the BIOS flashchip is used to store this so called Extended System Configuration Data.

So when doing a (binary) compare of two BIOS files, always disregard differences in the ESCD block.

As a sidenote, the BIOS will check the PnP data during each boot-up and update the ESCD block when a hardware change is detected, even if you just placed the graphics card in the next PCI-slot. You can observe this process via the BIOS message “Updating ESCD…….Success” at the end of POST on the BIOS summary screen.
However, if you suspect that old PnP data is not cleared correctly and can be responsible for resource conflicts, you can manually clear the ESCD and let the BIOS load a fresh set of PnP data, by Enabling the “Reset Configuration Data” BIOS option.

This is a one-time action. On the next boot, “Reset Configuration Data” will be Disabled again.

Cheers, Jan

Jan, you're a real legend, as always!! 🥂
Thank you very much for this!

Using the BIOS I shared here: Re: Problem with UDMA, need BIOS fix for Taken TX3 (LGS Prime 3C) , I managed to do a Win98SE test-install on this 2nd board, with the exact same software, drivers & hardware that I know for sure I tested in my previous M577 adventure.
And in MDK2, it seems that OpenGL performance is pretty much identical with the 1st board.
Even the SDRAM has been automatically set to the same CL2 specs as the other board (even if this BIOS doesn't have the CL switch present in it's menu).
So this brings a tremendous amount of relief!

Only "drawback", is that "bla bla bla .. ROM.BY" text at POST, that BIOS Patcher introduces, that screws with the CPU detection line of text.
But other than that, all seems good.

So for the time being, I think I'm gonna leave things as they are, and slowly proceed with this project, and hope no other unplesentries come up ☺️

Once again, thank you Jan, and thank you to everyone for the help and support! 🥂

B24Fox wrote on 2025-03-16, 19:27:

Only "drawback", is that "bla bla bla .. ROM.BY" text at POST, that BIOS Patcher introduces, that screws with the CPU detection line of text.
But other than that, all seems good.

I always use BIOS Patcher version 6.00 instead of 4.xx with Award 4.51PG BIOSes without any problems, and so far also haven't had any problems by using patched ver. 6.0 (the one with removed annoying "... ROM.BY" line).

Chkcpu wrote on 2025-03-16, 16:02:

The reason you see a different checksum is that off course the ESCD blocks are different. This 4KB block is where the BIOS stores its Plug&Play data, and is located at offsets 1D000h-1DFFFh in this BIOS file.
Only if you would have used the exact same set of expansion cards and peripherals on both boards, the ESCD blocks would have been the same.

Hey, Jan, I was not sure about this, as the sh*ttypedia.org states that:

"The ESCD data is stored using the data serialization format used for EISA. Its data starts with the "ACFG" signature in ASCII. PCI configuration can also be stored in ESCD, using virtual slots. Typical storage usage for ESCD data is 2–4 KB."

Ok, the ESCD block is almost 4 KB in size (from address ox1D000 to ox1DFBF), but there are two leading bytes before "ACFG" string and the very firs byte also differs:

Are these two leading bytes (ox1D000 and ox1D001) really a part from ESCD block or they are for example some checksum for the previous BIOS module?

Is this starting address (ox1D000) a standard for the BIOS ESCD block in all the Award BIOSes with core versions 4.51PG or it depends on something in the BIOS code?

analog_programmer wrote on 2025-03-16, 20:25:

B24Fox wrote on 2025-03-16, 19:27:

Only "drawback", is that "bla bla bla .. ROM.BY" text at POST, that BIOS Patcher introduces, that screws with the CPU detection line of text.
But other than that, all seems good.

I always use BIOS Patcher version 6.00 instead of 4.xx with Award 4.51PG BIOSes without any problems, and so far also haven't had any problems by using patched ver. 6.0 (the one with removed annoying "... ROM.BY" line).

When I first experimented with Bios Patcher for the 1st M577 board, I also tried patching with version "6.00.alpha_15".
But unfortunately, the BIOS it produced, was freezing during POST 😕

B24Fox wrote on 2025-03-16, 20:54:

When I first experimented with Bios Patcher for the 1st M577 board, I also tried patching with version "6.00.alpha_15".
But unfortunately, the BIOS it produced, was freezing during POST 😕

Yeah, unfortunately there's no guarantee that one exact BP version will always produce an working patched BIOS from all those different motherboards BIOSes even if they're with same BIOS core version. That's why I use "/s" switch only after some tests with patched BIOS supporting "backup/virtual dual BIOS" option.

analog_programmer wrote on 2025-03-16, 20:25:

Hey, Jan, I was not sure about this, as the sh*ttypedia.org states that: […]
Show full quote

Chkcpu wrote on 2025-03-16, 16:02:

The reason you see a different checksum is that off course the ESCD blocks are different. This 4KB block is where the BIOS stores its Plug&Play data, and is located at offsets 1D000h-1DFFFh in this BIOS file.
Only if you would have used the exact same set of expansion cards and peripherals on both boards, the ESCD blocks would have been the same.

Hey, Jan, I was not sure about this, as the sh*ttypedia.org states that:

"The ESCD data is stored using the data serialization format used for EISA. Its data starts with the "ACFG" signature in ASCII. PCI configuration can also be stored in ESCD, using virtual slots. Typical storage usage for ESCD data is 2–4 KB."

Ok, the ESCD block is almost 4 KB in size (from address ox1D000 to ox1DFBF), but there are two leading bytes before "ACFG" string and the very firs byte also differs:

Are these two leading bytes (ox1D000 and ox1D001) really a part from ESCD block or they are for example some checksum for the previous BIOS module?

Is this starting address (ox1D000) a standard for the BIOS ESCD block in all the Award BIOSes with core versions 4.51PG or it depends on something in the BIOS code?

Hi analog_programmer,

The first 2 bytes at offsets 0x1D000 and 0x1D001 are indeed part of the ESCD block.
These are the first 2 bytes of the ESCD Configuration Header, and represent the size of the stored ESCD data. So the ESCD data of ORIG1.BIN is 0x026D (621) bytes, while the ORIG2.BIN has slightly less ESCD data of 0x0257 (599) bytes.

At http://www.buildorbuy.org/pdf/escd.pdf jou can view an early 1994 version 1.02A of the ESCD Specification. Look in appendix A for the ESCD data details.

So only a small part of the available 4096 bytes is used here for the ESCD data. The rest of the data you see behind the ESCD data in this 0x1D000-0x1DFFF block is just meaningless junk. 😉
Note that when you download a BIOS from the motherboard manufacturers website, this 0x1D000-0x1DFFF block is empty and filled with 0xFF bytes.

Most 128KB compressed Award BIOSes (v4.5xPG) have the ESCD storage space at this 0x1D000-0x1DFFF block, but this is not fixed and can be elsewhere.
On 256KB Award v4.5xPG BIOSes, the 4096 bytes ESCD block is probably somewhere between offsets 0x38000 and 0x3E000. I have no data on that.

Cheers, Jan

Chkcpu wrote on 2025-03-17, 16:28:

Hi analog_programmer, […]
Show full quote

Hi analog_programmer,

The first 2 bytes at offsets 0x1D000 and 0x1D001 are indeed part of the ESCD block.
These are the first 2 bytes of the ESCD Configuration Header, and represent the size of the stored ESCD data. So the ESCD data of ORIG1.BIN is 0x026D (621) bytes, while the ORIG2.BIN has slightly less ESCD data of 0x0257 (599) bytes.

At http://www.buildorbuy.org/pdf/escd.pdf jou can view an early 1994 version 1.02A of the ESCD Specification. Look in appendix A for the ESCD data details.

So only a small part of the available 4096 bytes is used here for the ESCD data. The rest of the data you see behind the ESCD data in this 0x1D000-0x1DFFF block is just meaningless junk. 😉
Note that when you download a BIOS from the motherboard manufacturers website, this 0x1D000-0x1DFFF block is empty and filled with 0xFF bytes.

Most 128KB compressed Award BIOSes (v4.5xPG) have the ESCD storage space at this 0x1D000-0x1DFFF block, but this is not fixed and can be elsewhere.
On 256KB Award v4.5xPG BIOSes, the 4096 bytes ESCD block is probably somewhere between offsets 0x38000 and 0x3E000. I have no data on that.

Cheers, Jan

Thank you for the .pdf document and all the info! Now everything makes sense 😀

I don't know if these explanations are already included in your thread with BIOS modifications/patching topic, but I think they will be of use to someone who's trying to modify Award BIOS 4.51PG "by hand" as knowing the BIOS structure is very important.