VOGONS


Reply 180 of 223, by PC@LIVE

User metadata
Rank Oldbie
Rank
Oldbie
chacha wrote on 2025-03-21, 09:05:
Hello ! I confirm that my MB-8500TVX (rev 2.1) is PERFECTLY working with a K6-II(400), and a K6-IIIE+(400) with the unofficial B […]
Show full quote

Hello !
I confirm that my MB-8500TVX (rev 2.1) is PERFECTLY working with a K6-II(400), and a K6-IIIE+(400) with the unofficial BIOS, as soon as VRM are delivering enough power 😉
I modded the VRM in order to deliver 1.7v, but also using 3.3V as input instead of 5V .
It lowered the heat from the (linear) regulater A LOT, and also reduced electrical noise on sound-card and Voodoo.
On that board, with slow L2 cache, the K6-III gave a massive performance increase.
A big Win ! Thank you very much.

Now I will try to mod the FSB to reach 500MHz, by changing the PLL board.

But on BIOS side => Its done and perfect !

Your results are very interesting, with the low voltage K6, reading you modified the VRM, lowering the temperatures a lot, if I understand correctly, you reduced the input voltage from 5V to 3.3V, and the output one to 1.7V, maybe if you can share the changes, I would like to understand if it is possible to do something similar, with different motherboards, currently I have a Soyo 5BT5 that I have to finish modifying, to go below the VCORE 2.2V, and get 1.7V is perfect to put a K6-2+400 1.6V, in my case, I just have to find the right resistance values, they should be from about 10-20 KOHm.

AMD 286-16 287-10 4MB HD 45MB VGA 256KB
AMD 386DX-40 Intel 387 8MB HD 81MB VGA 256KB
Cyrix 486DLC-40 IIT387-40 8MB VGA 512KB
AMD 5X86-133 16MB VGA VLB CL5428 2MB and many others
AMD K62+ 550 SOYO 5EMA+ and many others
AST Pentium Pro 200 MHz L2 256KB

Reply 181 of 223, by Chkcpu

User metadata
Rank Oldbie
Rank
Oldbie
dm- wrote on 2025-03-24, 03:10:
Hello Jan! […]
Show full quote

Hello Jan!

I got another nice early ATX board MSI MS-5136 TR8

https://theretroweb.com/motherboards/s/msi-ms … 136-ver-1.0-tr8
The board has an undocumented 2.2v setting so i inserted amd k6-2 cpu -)

it's booting with k6-2 cpu with default bios WI7C but there is some issues
incorrect cpu detecting, like MMX cpu 66mhz -)
memory performance reduced to FPM mode (?) according to SpeedSys.

ide controller on this board is dead so i can not check hdd size. using external pci controller.

Could you please create a k6-2 fix for this board?

Hello dm-,

Okay, you have the MS-5136, a nice i430VX board indeed.

I’ve checked the latest WI7C 06/10/97 Award BIOS and as expected for such an early socket 7 BIOS, it has very limited CPU support. It has only basic K6 support and needs a lot of work to add K6-2(+)/III(+) support.

So I have been looking for a ready BIOS upgrade for this board, and found a 03/16/2000-i430VX-2A59GM49C-00 BIOS from Unicore Software. This BIOS came with the Evergreen Spectra K6-2/400 upgrade CPU package.
This 03/16/2000 BIOS supports all socket 7 CPUs from Intel, AMD, Cyrix, Winchip, and Rise. So also the K6-2+/K6-III+ are supported.
It also supports drives larger than 8GB and has the 32GB and 64GB HDD limit bugs fixed for full 128GiB HDD support. Although that doesn’t help much with dead on-board IDE channels. 😉

The attachment 2A59GM49.zip is no longer available

Just as with the original BIOS, this Unicore BIOS should work on the whole MS-5129/MS-5136/MS-5137/MS-5143/MS-5149 series.

Please let us know how this Unicore BIOS works on your MS-5136.
Cheers, Jan

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 182 of 223, by dm-

User metadata
Rank Member
Rank
Member

funny, Unicore bios working with K6-2 perfectly
but with K6-3+ it's acting like all caches are disabled. weird performance

Reply 183 of 223, by Chkcpu

User metadata
Rank Oldbie
Rank
Oldbie
dm- wrote on 2025-03-26, 15:16:

funny, Unicore bios working with K6-2 perfectly
but with K6-3+ it's acting like all caches are disabled. weird performance

Okay, the Unicore BIOS basically works on the MS-5136.

About the strange K6-III+ performance, is the CPU and its speed correctly identified?
Also check if the BIOS option “System BIOS Cacheable” is Disabled (CHIPSET FEATURES SETUP menu). The K6-2+ and K6-III+ need this setting to work reliable on boards with the Intel 430TX, 430VX, ALi Aladdin IV(+), or SiS5582 chipset.

Selecting LOAD SETUP DEFAULTS in the main BIOS menu is also advised, to eliminate the influence of old CMOS values from the previous BIOS.
Also try if disabling the external cache helps.

If the weird K6-III+ performance remains, please run Cachechk and/or Speedsys and post some screenshots. For testing faster CPUs like K6plus, I usually take Cachechk v7 and run it with the /d switch to get accurate timings with an extra digit.

Cheers, Jan

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 184 of 223, by Chkcpu

User metadata
Rank Oldbie
Rank
Oldbie
486guy wrote on 2025-03-20, 03:16:

I thought the available v2.3 firmware on retroweb is the one you already patched. I'm wrong so i downloaded the patched one and tried it but still the same issue. I still need to press F1 to continue.

The attachment IMG_0136.jpg is no longer available

Hi 486guy,

I have been looking through the Ver 2.3 BIOS code, but haven’t found any clues yet about the absence of a fault message when you do get the Press F1 to continue message.

When POST is halted with the “Press F1 to continue, DEL to enter SETUP” message, the BIOS has detected a non-critical error that may need to be addressed by changing the BIOS Setup.
In the STANDARD CMOS SETUP menu, there is a “Halt On:” option where you can select if POST must be halted for Keyboard or Floppy errors.
To narrow down this issue, please try this Halt On: option setting at “No Errors”. When you still get the Press F1 to continue message now, we know that the Keyboard and Floppy are not responsible for the POST Halt.

Also confirm that the Ver 2.2 BIOS doesn’t have this issue. Then I can also look into the 2.2 BIOS code to see what is different and maybe find the issue that way.

Cheers, Jan

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 185 of 223, by luRaichu

User metadata
Rank Newbie
Rank
Newbie
chacha wrote on 2025-03-21, 09:05:

I confirm that my MB-8500TVX (rev 2.1) is PERFECTLY working with a K6-II(400), and a K6-IIIE+(400) with the unofficial BIOS, as soon as VRM are delivering enough power 😉
Now I will try to mod the FSB to reach 500MHz, by changing the PLL board.

Hey!! Can FSB mod be done on MB-8500TTD? Maximum FSB speed without hardware modification is 83MHz.

Reply 186 of 223, by analog_programmer

User metadata
Rank Oldbie
Rank
Oldbie
luRaichu wrote on 2025-03-26, 22:51:

Hey!! Can FSB mod be done on MB-8500TTD? Maximum FSB speed without hardware modification is 83MHz.

Don't expect FSB of 100 MHz from 430TX chipset. 83 MHz seems to be its upper limit.

The word Idiot refers to a person with many ideas, especially stupid and harmful ideas.
This world goes south since everything's run by financiers and economists.
This isn't voice chat, yet some people overusing online communications talk and hear voices.

Reply 187 of 223, by Chkcpu

User metadata
Rank Oldbie
Rank
Oldbie
Sphere478 wrote on 2025-03-13, 22:56:

When will the next modding episode be? 😀

Hi Sphere478,

You are right to keep asking when I will continue with the DIY BIOS modding guide.
It took me a long time, but now the next episode is here! 😊

Note that Part 7 of this story is a recent addition to my patching repertoire. This part about manually compressing the System BIOS module and adding it to the compressed BIN-file, needed to be included here.

Enjoy!
Jan

#Part 6 – How to patch a compressed Award BIOS

With this part I will start a series of episodes about the compressed Award Modular BIOS v4.5xPG(M).
I will first show how to handle the compressed modules in these BIOSes, followed by a description of what you can patch to get better CPU support and fix bugs.

The compressed BIOS
From about 1996 the 128KB (E)EPROM size was not sufficient anymore to contain all BIOS routines, so BIOS developers started to use compressed BIOSes. The top 20KB or so of these compressed BIOSes is not compressed and contains the initial boot code and the decompression engine. Also the ESCD block where the BIOS stores its PnP data is located here. On a 128KB BIOS, this leaves about 108KB for the compressed modules. Due to a slightly different organization, a 256KB BIOS will usually have 220KB compressed code space available.
These 256KB compressed BIOSes started to appear not long after the 128KB compressed BIOS, and obviously could contain more and larger modules, like for extra option ROMs and full screen logo’s.

While on an uncompressed BIOS all code and data is readily available directly from the ROM (or from Shadow RAM at the same addresses when copied there to improve performance), a compressed BIOS has to perform a lot of extra steps to get its contents ready for use.
Only the Bootblock in the top 8KB of the BIOS is largely the same on both the compressed and uncompressed BIOS. At power-up or reset, the BIOS Bootblock is always the first code to be executed and performs the initial chipset setup and RAM test. The uncompressed BIOS then jumps directly to the POST block to perform the Power-On-Self-Test.

The compressed BIOS however first calls the decompression engine to decompress all compressed BIOS modules into RAM. After an integrity check, the decompressed modules are copied to their allocated place in RAM or Shadow RAM. The 128KB main BIOS module original.tmp is thereby always copied to real mode addresses E000:0000h-F000:FFFFh in Shadow RAM.
Because this address range is the same as for the (E)EPROM containing the compressed BIOS, the (E)EPROM access is disabled when the decompressed main BIOS module in Shadow RAM gets control.

Apart from a few exceptions from the 1995/1996 transition period, the Award BIOSes up to v4.50G are uncompressed while v4.50PG and v4.51PG BIOSes are the compressed versions.
When you open such a compressed BIOS in a Hexeditor and look at the beginning of the BIN file, you see the header of the first compressed module. This header contains an -lh5- string at offsets 02h-06h, indicating an LZH level-1 compressed file. At offset 16h you see the filename of this compressed module.

The attachment Compressed BIOS.png is no longer available

On an 128KB BIOS, the first compressed module is always the main BIOS component and usually has original.tmp as filename. The other compressed modules are placed directly behind this main module, just like the compressed files in a zip archive.
On the 256KB BIOS, the placing of the compressed modules is a bit different. The compressed original.tmp is located at offset 20000h and together with the bootblock, have the whole 128KB second half of the BIOS for themselves. The first half, so from offset 0h to 1FFFFh, is for all additional modules.

Award Tools
For the Award BIOS, there are some nice tools from Award Software to handle the compressed BIOS. I use MODBIN v4.50.82a and CBROM v1.30c for socket 7 BIOSes.

The attachment awdtools.zip is no longer available

With the CBROM tool, you can view and manipulate the compressed components in the BIOS BIN file.
This is what you get when using the /d command-line switch for dumping the contents of the BIOS on screen:

The attachment CBROM S1590 BIOS.png is no longer available

This CBROM ouput is from a Tyan S1590 v1.16c socket 7 BIOS, the first compressed BIOS I patched, back in November 2000. 😊

Extracting and Loading modules from the compressed BIOS
Most patches I do in the socket 7 BIOS, have to be made in the main BIOS module. So how do we get this module in decompressed form from the compressed BIOS BIN-file?
It appears that Award’s MODBIN tool is not only useful for viewing and editing the BIOS Setup menus, but can also be used to easily get the main BIOS image from the compressed BIN file.
If you load the BIN in MODBIN and then exit the program without making any changes, 2 new files are created. One of them, ORIGINAL.TMP, is the decompressed main BIOS image file. The size of this file is always 128KB.
I always rename this ORIGINAL.TMP file to have a working copy and to avoid it to be overwritten the next time I start MODBIN. Any appropriate filename for the BIOS in question will do, but below I will use a generic BIOSNAME.IMG as example.

After analyzing the disassembly listing from the decompressed BIOS image and doing the actual patching with my hexeditor, I run the patched image through the disassembler again to check for errors.
Note that Award made a lot of code changes over time so that I need to check each BIOS carefully to see what needs to be changed.
Just as with the earlier described 486 patches, I will provide a binary signature to help you find the spot in your decompressed BIOS image 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.

After patching there is the trick of placing the patched main BIOS image back in compressed form into the BIN file and getting the checksum bytes right. It appeared that this can be done via a special procedure under Windows, with the help of MODBIN.
This procedure makes use of the multitasking capability of Windows, but because MODBIN is a DOS program we have to use a 32-bit Windows version. Any 32-bit Windows, from Win95 to Windows 10 will do.
Although the below procedure could be modified to be used from 64-bit Windows with the help of a DOS emulator like DOSBox, I find it easier to use it under 32-bit Windows directly.

• In Windows explorer, navigate to the folder that contains the BIOS files to work on. This folder should at least have the patched decompressed main BIOS image file (BIOSNM-J.IMG) and a renamed copy of the original compressed BIOS BIN file, that will become the new BIOS.
• Type CMD in the addressbar in explorer and hit the Enter key. This will open a Command window with the current folder as focus.
• Run MODBIN from the CMD-prompt and load the new BIN in MODBIN.
• Now use the same explorer trick to open a second CMD window with a focus on the same folder.
• Use the Copy command to replace the ORIGINAL.TMP file by the patched BIOS image. In our example this command would look like: COPY BIOSNM-J.IMG ORIGINAL.TMP
You will get a question if you want to overwrite ORIGINAL.TMP and hit the Y key to confirm.
• Close this second window with the EXIT command.
• Go back to MODBIN in the first CMD window and select "Update file" to compress and save the patched BIOS image in the new BIN file. MODBIN will automatically calculate the checksum over all the compressed BIOS components and correct the checksum bytes of the BIN.

Note that you have to use MODBIN v4.50.77 or later to get the correct checksum bytes!

However, this trick only works for changes made in the E000h segment (the first 64KB half of the 128KB ORIGINAL.TMP).
Unlike this E000h segment, the F000h segment, in the second half of ORIGINAL.TMP, cannot be changed directly because MODBIN holds a work copy in memory, overwriting any changes when you update the file. Only the changes you make here via MODBIN's menus are allowed in the F000h segment.
Luckily, most changes needed for patching CPU and HDD support have to be made in the E000h segment.
There is a way to make changes in the F000h segment manually, but I will tell about this complicated procedure in the next episode.

As a final crosscheck I check both the original and the patched BIN file with Award's CBROM tool. With the /D switch you can view all BIOS components in the compressed BIN file. The patched BIN should contain the same components and should still have some compressed code space left.

You can also use CBROM to manipulate other modules, like the BIOS extension helper module AWARDEXT.ROM. With CBROM /? you can view the various options.
For extracting, releasing, or loading the AWARDEXT.ROM module you have to use the commands:
CBROM 2A5xxxxx.bin /other 4100:0 extract
CBROM 2A5xxxxx.bin /other 4100:0 release
CBROM 2A5xxxxx.bin /other 4100:0 awardext.rom

To fix the Award BIOS 64GB HDD limit bug, changes will be needed in this AWARDEXT.ROM module.
I will show the details in a later episode.

- more in the next posting -

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 188 of 223, by Chkcpu

User metadata
Rank Oldbie
Rank
Oldbie

#Part 7 – How to patch a compressed Award BIOS – cont’d

Manual editing of the compressed BIOS modules
As mentioned above, the MODBIN trick to get your changes into the compressed BIN file only works for changes made in the E000h segment of original.tmp. As the E000h segment contains all POST routines, this is usually the place where patches are needed.
The F000h segment contains all code and data for the BIOS Setup screens, and the BIOS runtime in the form of Interrupt service routines. The fix for the second IDE HDD 64GB limit bug has to be made here and yes, there is a way to make changes in the F000h segment of original.tmp manually.

The tools you need for this complicated procedure are:
- a good hexeditor
- a checksum tool, preferably as a function of the hexeditor
- an LZH compress tool, like LHA 2.55
- a hex calculator, like the Windows calculator in programmers mode.

Just as with patches in the E000h segment, changes in the F000h segment of the main BIOS module are done in the same way:

• Get the 128KB uncompressed main BIOS module original.tmp from BIOS .BIN file by opening it in MODBIN.
• Rename original.tmp to BIOSNAME.IMG and search for bugs with the help of a binary signature.
• Copy BIOSNAME.IMG to BIOSNM-J.IMG and apply patches.
• Do a binary file compare of BIOSNAME.IMG and BIOSNM-J.IMG to check the patches. Use the file compare function of the hexeditor or simply execute the DOS command: FC /B BIOSNAME.IMG BIOSNM-J.IMG > DIFF.TXT to have all differences listed in a text-file.

Now an extra step is needed for patches in the F000h segment:

• Correct the checksum byte at offset 1FFFFh. This is the checksum of the whole F-segment, so add 10000h bytes at offsets 10000-1FFFF. Let your hexeditor or checksum tool perform an 8-bit addition and adjust the checksum byte so that the addition produces zero with the checksum byte included.

Because the modules in the BIOS are LZH level-1 compressed, an appropriate program has to be used to compress the patched image file (BIOSNM-J.IMG) manually. I use LHA version 2.55 under DOS. Assuming the LHA program is located in the LHA255 directory, use the following DOS command to compress BIOSNM-J.IMG:
• \LHA255\LHA A BIOSNM-J.LZH BIOSNM-J.IMG
• Now take the compressed BIOSNM-J.LZH file and examine the header at the start of the file. This is what it looks like in my hexeditor:

The attachment LZH header after compression.png is no longer available

And this is what all these bytes in the header mean:

o The first byte at offset 00h is the length of the header, not counting the first 2 bytes, and is 25h if a 8.3 characters filename is used.
o The second byte at offset 01h is the header’s 8-bit checksum, not including the first 2 bytes.
o At offsets 02h-06h is a -lh5- string, indicating an LZH level-1 compressed file.
o Offsets 07h-0Ah hold the compressed file size in little endian dword value, not counting the header size.
o Offsets 0Bh-0Eh hold the uncompressed file size in little endian dword value, not counting the header size.
o After compression, offsets 0Fh-10h hold a date or time code. For use as compressed Award BIOS module, this word value has to be changed. Details follow below.
o After compression, offsets 11h-12h holds a date or time code. For use as compressed Award BIOS module, this word value has to be changed. Details follow below.
o Offset 13h is the file attribute of this LZH Level-1 compressed file. Must 20h.
o Offset 14h indicates the compression level of this LZH file. Is normally 01h.
o Offset 15h holds the length of the original filename of the compressed component. Is 0Ch when a 8.3 characters filename is used.
o At offset 16h starts this filename. Occupies up to offset 21h when a 8.3 characters filename is used.
o Offsets 22h-23h hold the compressed component CRC-16 in little endian word value. This value is calculated by the LHA program and must not be changed.
o Offset 24h holds the Operating System ID. Must be changed for use as Award BIOS module. See below.
o Offsets 25h-26h holds the next header size. In Award BIOS it's always 0000h which means no extension header.
o Offset 27h is not part of the header, but is the start of the compressed module data, when a 8.3 characters filename is used.

Only a few changes to the BIOSNM-J.LZH header have to be made to make it usable as compressed Award BIOS module. These are:

• Offsets 0Fh-10h have to be changed to the decompression offset address in little endian word value.
For use as original.tmp module, this has to be 0000h.
• Offsets 11h-12h have to be changed to the decompression segment address in little endian word value.
For use as original.tmp module, this has to be 5000h.
• Offset 24h holds the Operating System ID. Must be changed to 20h for use as Award BIOS component.
• The header’s 8-bit checksum byte, not including the first 2 bytes, at offset 01h is now invalid.
Must be recalculated and updated after the header changes above are made!

After adapting the BIOSNM-J.LZH header for the above changes, it will look like this:

The attachment LZH header after corrections for BIOS.png is no longer available

The BIOSNM-J.LZH file is now ready to be inserted into the new BIOS BIN file, replacing the compressed original.tmp module. These are the steps for an 128KB BIOS:

• At offset 27h starts the compressed BIOS-core component when a 8.3 characters filename is used. Add the compressed file size dword value at offsets 07h-0Ah to this start offset to find the end of the component. In the above example this is 27h+14686h=146ADh.
This offset 146ADh will be the last byte of the BIOSNM-J.LZH file.
• Do the same calculation on the compressed original.tmp module in the original BIOS.BIN file and subtract this value from the size of the modified BIOSNM-J.LZH file. The difference is the amount of bytes the compressed modules behind the original.tmp module have to be shifted to make room for the modified BIOSNM-J.LZH file.
• In your hexeditor, shift (or copy/paste) all modules behind original.tmp by the calculated amount. Then copy the BIOSNM-J.LZH file content and paste it over the original.tmp module in the new BIOS.BIN.
• Note that there is an extra byte behind the original.tmp module and before the start of the header of the next module. This byte is only present after the original.tmp module and is the 8-bit checksum of the whole original.tmp module including the header.
This extra checksum byte is automatically updated in the next step.
• Open the new BIOS.BIN with MODBIN and edit the BIOS Message to your liking. Update the BIOS file so that all checksums are recalculated and correct. Check the new BIOS.BIN with CBROM to see if all modules are present and their sizes are correct.

On the 256KB BIOS, the compressed original.tmp starts at file offset 20000h and has no modules behind it.
This makes inserting the BIOSNM-J.LZH file a lot simpler. So use these step for a 256KB BIOS:
• In your hexeditor, copy the BIOSNM-J.LZH file content and paste it over the original.tmp module in the new BIOS.BIN at offset 20000h.
• Note that there is an extra byte behind the original.tmp module. This byte is only present after the original.tmp module and is the 8-bit checksum of the whole original.tmp module including the header.
This extra checksum byte is automatically updated in the next step.
• Open the new BIOS.BIN with MODBIN and edit the BIOS Message to your liking. Update the BIOS file so that all checksums are recalculated and correct. Check the new BIOS.BIN with CBROM to see if all modules are present and their sizes are correct.

Now that we know how to handle the compressed Award v4.5xPG(M) BIOS, it is time to tell what you can patch in the Socket 7 BIOS. In the next episode I will start with the patches you can make to add K6-2+/III+ CPU support.

Jan

Last edited by Chkcpu on 2025-03-28, 17:23. Edited 1 time in total.

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 189 of 223, by analog_programmer

User metadata
Rank Oldbie
Rank
Oldbie

Yay, finally we're back on the topic 😀 Thanks for the new BIOS modifications tips!

The word Idiot refers to a person with many ideas, especially stupid and harmful ideas.
This world goes south since everything's run by financiers and economists.
This isn't voice chat, yet some people overusing online communications talk and hear voices.

Reply 190 of 223, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
Chkcpu wrote on 2025-03-28, 16:26:
#Part 7 – How to patch a compressed Award BIOS – cont’d Manual editing of the compressed BIOS modules As mentioned above, the M […]
Show full quote

#Part 7 – How to patch a compressed Award BIOS – cont’d

Manual editing of the compressed BIOS modules
As mentioned above, the MODBIN trick to get your changes into the compressed BIN file only works for changes made in the E000h segment of original.tmp. As the E000h segment contains all POST routines, this is usually the place where patches are needed.
The F000h segment contains all code and data for the BIOS Setup screens, and the BIOS runtime in the form of Interrupt service routines. The fix for the second IDE HDD 64GB limit bug has to be made here and yes, there is a way to make changes in the F000h segment of original.tmp manually.

The tools you need for this complicated procedure are:
- a good hexeditor
- a checksum tool, preferably as a function of the hexeditor
- an LZH compress tool, like LHA 2.55
- a hex calculator, like the Windows calculator in programmers mode.

Just as with patches in the E000h segment, changes in the F000h segment of the main BIOS module are done in the same way:

• Get the 128KB uncompressed main BIOS module original.tmp from BIOS .BIN file by opening it in MODBIN.
• Rename original.tmp to BIOSNAME.IMG and search for bugs with the help of a binary signature.
• Copy BIOSNAME.IMG to BIOSNM-J.IMG and apply patches.
• Do a binary file compare of BIOSNAME.IMG and BIOSNM-J.IMG to check the patches. Use the file compare function of the hexeditor or simply execute the DOS command: FC /B BIOSNAME.IMG BIOSNM-J.IMG > DIFF.TXT to have all differences listed in a text-file.

Now an extra step is needed for patches in the F000h segment:

• Correct the checksum byte at offset 1FFFFh. This is the checksum of the whole F-segment, so add 10000h bytes at offsets 10000-1FFFF. Let your hexeditor or checksum tool perform an 8-bit addition and adjust the checksum byte so that the addition produces zero with the checksum byte included.

Because the modules in the BIOS are LZH level-1 compressed, an appropriate program has to be used to compress the patched image file (BIOSNM-J.IMG) manually. I use LHA version 2.55 under DOS. Assuming the LHA program is located in the LHA255 directory, use the following DOS command to compress BIOSNM-J.IMG:
• \LHA255\LHA A BIOSNM-J.LZH BIOSNM-J.IMG
• Now take the compressed BIOSNM-J.LZH file and examine the header at the start of the file. This is what it looks like in my hexeditor:

The attachment LZH header after compression.png is no longer available

And this is what all these bytes in the header mean:

o The first byte at offset 00h is the length of the header, not counting the first 2 bytes, and is 25h if a 8.3 characters filename is used.
o The second byte at offset 01h is the header’s 8-bit checksum, not including the first 2 bytes.
o At offsets 02h-06h is a -lh5- string, indicating an LZH level-1 compressed file.
o Offsets 07h-0Ah hold the compressed file size in little endian dword value, not counting the header size.
o Offsets 0Bh-0Eh hold the uncompressed file size in little endian dword value, not counting the header size.
o After compression, offsets 0Fh-10h hold a date or time code. For use as compressed Award BIOS module, this word value has to be changed. Details follow below.
o After compression, offsets 11h-12h holds a date or time code. For use as compressed Award BIOS module, this word value has to be changed. Details follow below.
o Offset 13h is the file attribute of this LZH Level-1 compressed file. Must 20h.
o Offset 14h indicates the compression level of this LZH file. Is normally 01h.
o Offset 15h holds the length of the original filename of the compressed component. Is 0Ch when a 8.3 characters filename is used.
o At offset 16h starts this filename. Occupies up to offset 21h when a 8.3 characters filename is used.
o Offsets 22h-23h hold the compressed component CRC-16 in little endian word value. This value is calculated by the LHA program and must not be changed.
o Offset 24h holds the Operating System ID. Must be changed for use as Award BIOS module. See below.
o Offsets 25h-26h holds the next header size. In Award BIOS it's always 0000h which means no extension header.
o Offset 27h is not part of the header, but is the start of the compressed module data, when a 8.3 characters filename is used.

Only a few changes to the BIOSNM-J.LZH header have to be made to make it usable as compressed Award BIOS module. These are:

• Offsets 0Fh-10h have to be changed to the decompression offset address in little endian word value.
For use as original.tmp module, this has to be 0000h.
• Offsets 11h-12h have to be changed to the decompression segment address in little endian word value.
For use as original.tmp module, this has to be 5000h.
• Offset 24h holds the Operating System ID. Must be changed to 20h for use as Award BIOS component.
• The header’s 8-bit checksum byte, not including the first 2 bytes, at offset 01h is now invalid.
Must be recalculated and updated after the header changes above are made!

After adapting the BIOSNM-J.LZH header for the above changes, it will look like this:

The attachment LZH header after corrections for BIOS.png is no longer available

The BIOSNM-J.LZH file is now ready to be inserted into the new BIOS BIN file, replacing the compressed original.tmp module. These are the steps for an 128KB BIOS:

• At offset 27h starts the compressed BIOS-core component when a 8.3 characters filename is used. Add the compressed file size dword value at offsets 07h-0Ah to this start offset to find the end of the component. In the above example this is 27h+14686h=146ADh.
This offset 146ADh will be the last byte of the BIOSNM-J.LZH file.
• Do the same calculation on the compressed original.tmp module in the original BIOS.BIN file and subtract this value from the size of the modified BIOSNM-J.LZH file. The difference is the amount of bytes the compressed modules behind the original.tmp module have to be shifted to make room for the modified BIOSNM-J.LZH file.
• In your hexeditor, shift (or copy/paste) all modules behind original.tmp by the calculated amount. Then copy the BIOSNM-J.LZH file content and paste it over the original.tmp module in the new BIOS.BIN.
• Note that there is an extra byte behind the original.tmp module and before the start of the header of the next module. This byte is only present after the original.tmp module and is the 8-bit checksum of the whole original.tmp module including the header.
This extra checksum byte is automatically updated in the next step.
• Open the new BIOS.BIN with MODBIN and edit the BIOS Message to your liking. Update the BIOS file so that all checksums are recalculated and correct. Check the new BIOS.BIN with CBROM to see if all modules are present and their sizes are correct.

On the 256KB BIOS, the compressed original.tmp starts at file offset 20000h and has no modules behind it.
This makes inserting the BIOSNM-J.LZH file a lot simpler. So use these step for a 256KB BIOS:
• In your hexeditor, copy the BIOSNM-J.LZH file content and paste it over the original.tmp module in the new BIOS.BIN at offset 20000h.
• Note that there is an extra byte behind the original.tmp module. This byte is only present after the original.tmp module and is the 8-bit checksum of the whole original.tmp module including the header.
This extra checksum byte is automatically updated in the next step.
• Open the new BIOS.BIN with MODBIN and edit the BIOS Message to your liking. Update the BIOS file so that all checksums are recalculated and correct. Check the new BIOS.BIN with CBROM to see if all modules are present and their sizes are correct.

Now that we know how to handle the compressed Award v4.5xPG(M) BIOS, it is time to tell what you can patch in the Socket 7 BIOS. In the next episode I will start with the patches you can make to add K6-2+/III+ CPU support.

Jan

This post is gold. I figured out the "replace original.tmp while modbin is running" trick on my own but I never would have figured out how to compress and add the patched binary back manually

Reply 191 of 223, by Chkcpu

User metadata
Rank Oldbie
Rank
Oldbie
maxtherabbit wrote on 2025-03-29, 13:41:

This post is gold. I figured out the "replace original.tmp while modbin is running" trick on my own but I never would have figured out how to compress and add the patched binary back manually

Thanks. Good to hear that this manual compress method is valuable. 😀

It took me some time to figure this out and I corrupted my MVP3 and i430TX test BIOSes many times in the process. So I kept my good old (E)EPROM programmer at hand for the next try. 😉

Cheers, Jan

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 192 of 223, by analog_programmer

User metadata
Rank Oldbie
Rank
Oldbie
Chkcpu wrote on 2025-03-28, 16:26:
#Part 7 – How to patch a compressed Award BIOS – cont’d Manual editing of the compressed BIOS modules As mentioned above, the M […]
Show full quote

#Part 7 – How to patch a compressed Award BIOS – cont’d

Manual editing of the compressed BIOS modules
As mentioned above, the MODBIN trick to get your changes into the compressed BIN file only works for changes made in the E000h segment of original.tmp. As the E000h segment contains all POST routines, this is usually the place where patches are needed.
The F000h segment contains all code and data for the BIOS Setup screens, and the BIOS runtime in the form of Interrupt service routines. The fix for the second IDE HDD 64GB limit bug has to be made here and yes, there is a way to make changes in the F000h segment of original.tmp manually.

The tools you need for this complicated procedure are:
- a good hexeditor
- a checksum tool, preferably as a function of the hexeditor
- an LZH compress tool, like LHA 2.55
- a hex calculator, like the Windows calculator in programmers mode.

Just as with patches in the E000h segment, changes in the F000h segment of the main BIOS module are done in the same way:

• Get the 128KB uncompressed main BIOS module original.tmp from BIOS .BIN file by opening it in MODBIN.
• Rename original.tmp to BIOSNAME.IMG and search for bugs with the help of a binary signature.
• Copy BIOSNAME.IMG to BIOSNM-J.IMG and apply patches.
• Do a binary file compare of BIOSNAME.IMG and BIOSNM-J.IMG to check the patches. Use the file compare function of the hexeditor or simply execute the DOS command: FC /B BIOSNAME.IMG BIOSNM-J.IMG > DIFF.TXT to have all differences listed in a text-file.

Now an extra step is needed for patches in the F000h segment:

• Correct the checksum byte at offset 1FFFFh. This is the checksum of the whole F-segment, so add 10000h bytes at offsets 10000-1FFFF. Let your hexeditor or checksum tool perform an 8-bit addition and adjust the checksum byte so that the addition produces zero with the checksum byte included.

Because the modules in the BIOS are LZH level-1 compressed, an appropriate program has to be used to compress the patched image file (BIOSNM-J.IMG) manually. I use LHA version 2.55 under DOS. Assuming the LHA program is located in the LHA255 directory, use the following DOS command to compress BIOSNM-J.IMG:
• \LHA255\LHA A BIOSNM-J.LZH BIOSNM-J.IMG
• Now take the compressed BIOSNM-J.LZH file and examine the header at the start of the file. This is what it looks like in my hexeditor:

The attachment LZH header after compression.png is no longer available

And this is what all these bytes in the header mean:

o The first byte at offset 00h is the length of the header, not counting the first 2 bytes, and is 25h if a 8.3 characters filename is used.
o The second byte at offset 01h is the header’s 8-bit checksum, not including the first 2 bytes.
o At offsets 02h-06h is a -lh5- string, indicating an LZH level-1 compressed file.
o Offsets 07h-0Ah hold the compressed file size in little endian dword value, not counting the header size.
o Offsets 0Bh-0Eh hold the uncompressed file size in little endian dword value, not counting the header size.
o After compression, offsets 0Fh-10h hold a date or time code. For use as compressed Award BIOS module, this word value has to be changed. Details follow below.
o After compression, offsets 11h-12h holds a date or time code. For use as compressed Award BIOS module, this word value has to be changed. Details follow below.
o Offset 13h is the file attribute of this LZH Level-1 compressed file. Must 20h.
o Offset 14h indicates the compression level of this LZH file. Is normally 01h.
o Offset 15h holds the length of the original filename of the compressed component. Is 0Ch when a 8.3 characters filename is used.
o At offset 16h starts this filename. Occupies up to offset 21h when a 8.3 characters filename is used.
o Offsets 22h-23h hold the compressed component CRC-16 in little endian word value. This value is calculated by the LHA program and must not be changed.
o Offset 24h holds the Operating System ID. Must be changed for use as Award BIOS module. See below.
o Offsets 25h-26h holds the next header size. In Award BIOS it's always 0000h which means no extension header.
o Offset 27h is not part of the header, but is the start of the compressed module data, when a 8.3 characters filename is used.

Only a few changes to the BIOSNM-J.LZH header have to be made to make it usable as compressed Award BIOS module. These are:

• Offsets 0Fh-10h have to be changed to the decompression offset address in little endian word value.
For use as original.tmp module, this has to be 0000h.
• Offsets 11h-12h have to be changed to the decompression segment address in little endian word value.
For use as original.tmp module, this has to be 5000h.
• Offset 24h holds the Operating System ID. Must be changed to 20h for use as Award BIOS component.
• The header’s 8-bit checksum byte, not including the first 2 bytes, at offset 01h is now invalid.
Must be recalculated and updated after the header changes above are made!

After adapting the BIOSNM-J.LZH header for the above changes, it will look like this:

The attachment LZH header after corrections for BIOS.png is no longer available

The BIOSNM-J.LZH file is now ready to be inserted into the new BIOS BIN file, replacing the compressed original.tmp module. These are the steps for an 128KB BIOS:

• At offset 27h starts the compressed BIOS-core component when a 8.3 characters filename is used. Add the compressed file size dword value at offsets 07h-0Ah to this start offset to find the end of the component. In the above example this is 27h+14686h=146ADh.
This offset 146ADh will be the last byte of the BIOSNM-J.LZH file.
• Do the same calculation on the compressed original.tmp module in the original BIOS.BIN file and subtract this value from the size of the modified BIOSNM-J.LZH file. The difference is the amount of bytes the compressed modules behind the original.tmp module have to be shifted to make room for the modified BIOSNM-J.LZH file.
• In your hexeditor, shift (or copy/paste) all modules behind original.tmp by the calculated amount. Then copy the BIOSNM-J.LZH file content and paste it over the original.tmp module in the new BIOS.BIN.
• Note that there is an extra byte behind the original.tmp module and before the start of the header of the next module. This byte is only present after the original.tmp module and is the 8-bit checksum of the whole original.tmp module including the header.
This extra checksum byte is automatically updated in the next step.
• Open the new BIOS.BIN with MODBIN and edit the BIOS Message to your liking. Update the BIOS file so that all checksums are recalculated and correct. Check the new BIOS.BIN with CBROM to see if all modules are present and their sizes are correct.

On the 256KB BIOS, the compressed original.tmp starts at file offset 20000h and has no modules behind it.
This makes inserting the BIOSNM-J.LZH file a lot simpler. So use these step for a 256KB BIOS:
• In your hexeditor, copy the BIOSNM-J.LZH file content and paste it over the original.tmp module in the new BIOS.BIN at offset 20000h.
• Note that there is an extra byte behind the original.tmp module. This byte is only present after the original.tmp module and is the 8-bit checksum of the whole original.tmp module including the header.
This extra checksum byte is automatically updated in the next step.
• Open the new BIOS.BIN with MODBIN and edit the BIOS Message to your liking. Update the BIOS file so that all checksums are recalculated and correct. Check the new BIOS.BIN with CBROM to see if all modules are present and their sizes are correct.

Now that we know how to handle the compressed Award v4.5xPG(M) BIOS, it is time to tell what you can patch in the Socket 7 BIOS. In the next episode I will start with the patches you can make to add K6-2+/III+ CPU support.

Jan

Thanks for this guide, Jan!

Some time ago I found a similar method for editing the compressed ORIGINAL.TMP BIOS module, using MODBIN.EXE, CBROM.EXE, LHA.EXE and a HEX-editor. It was more than a year ago, so I have to try to recreate the whole process again, just to be sure how the things work. I left some notes here: Re: Looking for Award BIOS for Polaris/Ford Lian/RedFox BX-6AP2 or similar mobos with VIA BX/Apollo Pro II VT82C692/VT82

Is there any specific reason to use such an old version (1.30C) of CBROM with BIOS ver. 4.5xxG? For these s.5/(s)s.7 BIOSes I use CBROM version 2.08 as it was recommended for use with BIOS Patcher.

The word Idiot refers to a person with many ideas, especially stupid and harmful ideas.
This world goes south since everything's run by financiers and economists.
This isn't voice chat, yet some people overusing online communications talk and hear voices.

Reply 193 of 223, by Chkcpu

User metadata
Rank Oldbie
Rank
Oldbie
analog_programmer wrote on 2025-03-29, 21:39:
Thanks for this guide, Jan! […]
Show full quote
Chkcpu wrote on 2025-03-28, 16:26:
#Part 7 – How to patch a compressed Award BIOS – cont’d Manual editing of the compressed BIOS modules As mentioned above, the M […]
Show full quote

#Part 7 – How to patch a compressed Award BIOS – cont’d

Manual editing of the compressed BIOS modules
As mentioned above, the MODBIN trick to get your changes into the compressed BIN file only works for changes made in the E000h segment of original.tmp. As the E000h segment contains all POST routines, this is usually the place where patches are needed.
The F000h segment contains all code and data for the BIOS Setup screens, and the BIOS runtime in the form of Interrupt service routines. The fix for the second IDE HDD 64GB limit bug has to be made here and yes, there is a way to make changes in the F000h segment of original.tmp manually.

The tools you need for this complicated procedure are:
- a good hexeditor
- a checksum tool, preferably as a function of the hexeditor
- an LZH compress tool, like LHA 2.55
- a hex calculator, like the Windows calculator in programmers mode.

Just as with patches in the E000h segment, changes in the F000h segment of the main BIOS module are done in the same way:

• Get the 128KB uncompressed main BIOS module original.tmp from BIOS .BIN file by opening it in MODBIN.
• Rename original.tmp to BIOSNAME.IMG and search for bugs with the help of a binary signature.
• Copy BIOSNAME.IMG to BIOSNM-J.IMG and apply patches.
• Do a binary file compare of BIOSNAME.IMG and BIOSNM-J.IMG to check the patches. Use the file compare function of the hexeditor or simply execute the DOS command: FC /B BIOSNAME.IMG BIOSNM-J.IMG > DIFF.TXT to have all differences listed in a text-file.

Now an extra step is needed for patches in the F000h segment:

• Correct the checksum byte at offset 1FFFFh. This is the checksum of the whole F-segment, so add 10000h bytes at offsets 10000-1FFFF. Let your hexeditor or checksum tool perform an 8-bit addition and adjust the checksum byte so that the addition produces zero with the checksum byte included.

Because the modules in the BIOS are LZH level-1 compressed, an appropriate program has to be used to compress the patched image file (BIOSNM-J.IMG) manually. I use LHA version 2.55 under DOS. Assuming the LHA program is located in the LHA255 directory, use the following DOS command to compress BIOSNM-J.IMG:
• \LHA255\LHA A BIOSNM-J.LZH BIOSNM-J.IMG
• Now take the compressed BIOSNM-J.LZH file and examine the header at the start of the file. This is what it looks like in my hexeditor:

The attachment LZH header after compression.png is no longer available

And this is what all these bytes in the header mean:

o The first byte at offset 00h is the length of the header, not counting the first 2 bytes, and is 25h if a 8.3 characters filename is used.
o The second byte at offset 01h is the header’s 8-bit checksum, not including the first 2 bytes.
o At offsets 02h-06h is a -lh5- string, indicating an LZH level-1 compressed file.
o Offsets 07h-0Ah hold the compressed file size in little endian dword value, not counting the header size.
o Offsets 0Bh-0Eh hold the uncompressed file size in little endian dword value, not counting the header size.
o After compression, offsets 0Fh-10h hold a date or time code. For use as compressed Award BIOS module, this word value has to be changed. Details follow below.
o After compression, offsets 11h-12h holds a date or time code. For use as compressed Award BIOS module, this word value has to be changed. Details follow below.
o Offset 13h is the file attribute of this LZH Level-1 compressed file. Must 20h.
o Offset 14h indicates the compression level of this LZH file. Is normally 01h.
o Offset 15h holds the length of the original filename of the compressed component. Is 0Ch when a 8.3 characters filename is used.
o At offset 16h starts this filename. Occupies up to offset 21h when a 8.3 characters filename is used.
o Offsets 22h-23h hold the compressed component CRC-16 in little endian word value. This value is calculated by the LHA program and must not be changed.
o Offset 24h holds the Operating System ID. Must be changed for use as Award BIOS module. See below.
o Offsets 25h-26h holds the next header size. In Award BIOS it's always 0000h which means no extension header.
o Offset 27h is not part of the header, but is the start of the compressed module data, when a 8.3 characters filename is used.

Only a few changes to the BIOSNM-J.LZH header have to be made to make it usable as compressed Award BIOS module. These are:

• Offsets 0Fh-10h have to be changed to the decompression offset address in little endian word value.
For use as original.tmp module, this has to be 0000h.
• Offsets 11h-12h have to be changed to the decompression segment address in little endian word value.
For use as original.tmp module, this has to be 5000h.
• Offset 24h holds the Operating System ID. Must be changed to 20h for use as Award BIOS component.
• The header’s 8-bit checksum byte, not including the first 2 bytes, at offset 01h is now invalid.
Must be recalculated and updated after the header changes above are made!

After adapting the BIOSNM-J.LZH header for the above changes, it will look like this:

The attachment LZH header after corrections for BIOS.png is no longer available

The BIOSNM-J.LZH file is now ready to be inserted into the new BIOS BIN file, replacing the compressed original.tmp module. These are the steps for an 128KB BIOS:

• At offset 27h starts the compressed BIOS-core component when a 8.3 characters filename is used. Add the compressed file size dword value at offsets 07h-0Ah to this start offset to find the end of the component. In the above example this is 27h+14686h=146ADh.
This offset 146ADh will be the last byte of the BIOSNM-J.LZH file.
• Do the same calculation on the compressed original.tmp module in the original BIOS.BIN file and subtract this value from the size of the modified BIOSNM-J.LZH file. The difference is the amount of bytes the compressed modules behind the original.tmp module have to be shifted to make room for the modified BIOSNM-J.LZH file.
• In your hexeditor, shift (or copy/paste) all modules behind original.tmp by the calculated amount. Then copy the BIOSNM-J.LZH file content and paste it over the original.tmp module in the new BIOS.BIN.
• Note that there is an extra byte behind the original.tmp module and before the start of the header of the next module. This byte is only present after the original.tmp module and is the 8-bit checksum of the whole original.tmp module including the header.
This extra checksum byte is automatically updated in the next step.
• Open the new BIOS.BIN with MODBIN and edit the BIOS Message to your liking. Update the BIOS file so that all checksums are recalculated and correct. Check the new BIOS.BIN with CBROM to see if all modules are present and their sizes are correct.

On the 256KB BIOS, the compressed original.tmp starts at file offset 20000h and has no modules behind it.
This makes inserting the BIOSNM-J.LZH file a lot simpler. So use these step for a 256KB BIOS:
• In your hexeditor, copy the BIOSNM-J.LZH file content and paste it over the original.tmp module in the new BIOS.BIN at offset 20000h.
• Note that there is an extra byte behind the original.tmp module. This byte is only present after the original.tmp module and is the 8-bit checksum of the whole original.tmp module including the header.
This extra checksum byte is automatically updated in the next step.
• Open the new BIOS.BIN with MODBIN and edit the BIOS Message to your liking. Update the BIOS file so that all checksums are recalculated and correct. Check the new BIOS.BIN with CBROM to see if all modules are present and their sizes are correct.

Now that we know how to handle the compressed Award v4.5xPG(M) BIOS, it is time to tell what you can patch in the Socket 7 BIOS. In the next episode I will start with the patches you can make to add K6-2+/III+ CPU support.

Jan

Thanks for this guide, Jan!

Some time ago I found a similar method for editing the compressed ORIGINAL.TMP BIOS module, using MODBIN.EXE, CBROM.EXE, LHA.EXE and a HEX-editor. It was more than a year ago, so I have to try to recreate the whole process again, just to be sure how the things work. I left some notes here: Re: Looking for Award BIOS for Polaris/Ford Lian/RedFox BX-6AP2 or similar mobos with VIA BX/Apollo Pro II VT82C692/VT82

Is there any specific reason to use such an old version (1.30C) of CBROM with BIOS ver. 4.5xxG? For these s.5/(s)s.7 BIOSes I use CBROM version 2.08 as it was recommended for use with BIOS Patcher.

Hi analog_programmer,

It appears you beat me to it, with finding a way to compress original.tmp and store it in the BIN manually! 😉

Yes, I remember your BX-6AP2 BIOS thread where you, Horun, and I discussed finding an alternate BIOS for this bricked board. However, I never read the outcome.
At that time it was just a few weeks after my father-in-law’s funeral and my wife and me started to get really busy going through his stuff, deciding where it all should go.

Reading through your manual compress and replace method now, I see that it is quite similar. However you don’t describe adapting the compressed original.tmp header before copying it to the BIN. I’m curious to know if you let Modbin do this for you.

Great that you finally solved the mystery and that the board appeared to be an (incorrectly labeled) BX-6AV2, and you could get it fully functional with an older BIOS version for this board!

About CBROM V1.30C, I selected this 1999 version because it worked best on all 1997/1998/1999 socket 5/7 Award BIOSes. For 2000+ and Slot 1 BIOSes I do use a later CBROM version, usually V2.07.

Jan

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 194 of 223, by analog_programmer

User metadata
Rank Oldbie
Rank
Oldbie
Chkcpu wrote on 2025-03-30, 12:36:
Hi analog_programmer, […]
Show full quote

Hi analog_programmer,

It appears you beat me to it, with finding a way to compress original.tmp and store it in the BIN manually! 😉

Yes, I remember your BX-6AP2 BIOS thread where you, Horun, and I discussed finding an alternate BIOS for this bricked board. However, I never read the outcome.
At that time it was just a few weeks after my father-in-law’s funeral and my wife and me started to get really busy going through his stuff, deciding where it all should go.

Reading through your manual compress and replace method now, I see that it is quite similar. However you don’t describe adapting the compressed original.tmp header before copying it to the BIN. I’m curious to know if you let Modbin do this for you.

Great that you finally solved the mystery and that the board appeared to be an (incorrectly labeled) BX-6AV2, and you could get it fully functional with an older BIOS version for this board!

About CBROM V1.30C, I selected this 1999 version because it worked best on all 1997/1998/1999 socket 5/7 Award BIOSes. For 2000+ and Slot 1 BIOSes I do use a later CBROM version, usually V2.07.

Jan

Hi, Jan!

It was a while ago and I don't remember exactly what I've done to make BIOS checksums valid and unfortunately I didn't left any notes on that. I do remember, that I've found some clues on other BIOS-modding forums about it. Also I know for sure, that I manually replaced the modified and compressed by LHA.EXE "original.tmp" by using HEX-editor, just as it is described in the thread about my mislabeld BX-6AV2 mobo (still works great after all those BIOS experiments).

I have to recreate these steps:

1) Extract uncompressed "original.tmp" by using MODBIN.EXE - easy-peasy;
2) "Strip down" the BIOS dump file to header, bootblock and compressed "original.tmp" module + empty space by using CBROM.EXE while keeping in separate files all of the additional BIOS modules;
3) Edit uncompressed "original.tmp" module from 1) with HEX-editor;
4) You've also revealed here how to calculate and the edit new checksum for uncompressed "original.tmp" module - it's valuable and nowadays hard-to-find information;
5) Compress the new modified "original.tmp" by using LHA.EXE;
6) Replace compressed new "original.tmp" in "stripped" from additional modules BIOS file by using HEX-editor, while keeping an eye on the empty space after the new compressed "original.tmp";
7) Add all the stripped additional BIOS modules by CBROM.EXE;
8.) Test the new BIOS file with MODBIN.EXE.

I think this was what I've done to edit the PCI routing table (and some chipset initialization bytes) while experimenting with alien BIOSes for my then dead BX-6AV2 mobo.

Actually you were the one that made me do all this fiddling with the Award BIOSes 4.51PG back than 😀 Thanks for all the help!

I'm looking forward for the next episode of your BIOS-modifications tips on how to add custom CPU table 😉

The word Idiot refers to a person with many ideas, especially stupid and harmful ideas.
This world goes south since everything's run by financiers and economists.
This isn't voice chat, yet some people overusing online communications talk and hear voices.

Reply 195 of 223, by TheMobRules

User metadata
Rank Oldbie
Rank
Oldbie

Hi Jan/analog_programmer

I've been following this discussion about extracting and re-compressing these Award BIOS with great interest, and a while back I was trying to do the same kind of process with an early AMI WinBIOS (from an Acer VI15G board). The structure of the BIOS consists on a compressed block (which starts at the very beginning of the file with header AMIBIOSC+<date>) and an uncompressed section which contains, among other things the decompression code.

There is a known tool called AMIDECO, but I've also managed to extract the compressed block by using LHA as well (it's basically an LZH file with simplified headers, just compressed and uncompressed sizes IIRC), but I haven't been able to re-compress the block properly with LHA after patching it, and going by the POST codes the BIOS hangs during the extraction routine. I've tried to disassemble the extraction code but I got lost pretty quickly in the process.

I was wondering if this may be similar to what you've been discussing about the Award BIOS, in particular I'm interested if you have any tips about how to determine the compression level used in order to re-pack the BIOS after patching it. Of course, if there's a counterpart for AMIDECO that would allow re-compressing the BIOS it would be ideal, but I'm not aware of the existence of such a tool.

Thanks!

Reply 196 of 223, by analog_programmer

User metadata
Rank Oldbie
Rank
Oldbie

Hi, TheMobRules!

I have almost zero experience with AMI BIOSes modifying beyond using of tools like AMIBCP. Mr. Steunebrink explained in details how the compression level is determined in Award BIOS. As for the Award BIOS modules compressed with format "header level 1" LZH compression I can confirm that there is no problem when LHA.EXE is used with no explicit settings for compression header level in command prompt - it uses the default header level 1 format and this causes no errors with compressed BIOS module.

If you know how to isolate compressed module in AMI BIOS dump file, than you can check if with one of the other header levels of 0, 2 and 3 LHA.EXE will produce identical compressed module from the one uncompressed by AMIDECO.EXE.

For sure Jan knows more about the old AMI compressed BIOSes as I also use one of his patched AMI BIOSes for PCChips M571 ver. 3.2A motherboard. I'm also very interested in AMI BIOS patching/modding, 'cause the info on this topic is also very scarce.

The word Idiot refers to a person with many ideas, especially stupid and harmful ideas.
This world goes south since everything's run by financiers and economists.
This isn't voice chat, yet some people overusing online communications talk and hear voices.

Reply 197 of 223, by TheMobRules

User metadata
Rank Oldbie
Rank
Oldbie
analog_programmer wrote on 2025-03-30, 20:57:
Hi, TheMobRules! […]
Show full quote

Hi, TheMobRules!

I have almost zero experience with AMI BIOSes modifying beyond using of tools like AMIBCP. Mr. Steunebrink explained in details how the compression level is determined in Award BIOS. As for the Award BIOS modules compressed with format "header level 1" LZH compression I can confirm that there is no problem when LHA.EXE is used with no explicit settings for compression header level in command prompt - it uses the default header level 1 format and this causes no errors with compressed BIOS module.

If you know how to isolate compressed module in AMI BIOS dump file, than you can check if with one of the other header levels of 0, 2 and 3 LHA.EXE will produce identical compressed module from the one uncompressed by AMIDECO.EXE.

For sure Jan knows more about the old AMI compressed BIOSes as I also use one of his patched AMI BIOSes for PCChips M571 ver. 3.2A motherboard. I'm also very interested in AMI BIOS patching/modding, 'cause the info on this topic is also very scarce.

Thanks! Yeah, the lack of an AMIBCP for these older AMI BIOSes complicates things when it comes to modding/patching. There are some nice threads on this forum about patching some of the pre-WinBIOS versions, and in fact these early WinBIOSes are similar in structure once you decompress them so the same principles can be applied, but repacking the BIOS is the crucial step that is missing for me.

I think I recall trying different levels of compression with LHA and none of them working properly, but my memory is fuzzy since it's been a while.

I'll try to consolidate all my findings about the WinBIOS structure and compression (maybe on a separate thread) since I did my research some time ago and need to review my notes, but let's wait and see if Mr. Jan has more info about it!

Reply 198 of 223, by Chkcpu

User metadata
Rank Oldbie
Rank
Oldbie
analog_programmer wrote on 2025-03-30, 15:08:
Hi, Jan! […]
Show full quote
Chkcpu wrote on 2025-03-30, 12:36:
Hi analog_programmer, […]
Show full quote

Hi analog_programmer,

It appears you beat me to it, with finding a way to compress original.tmp and store it in the BIN manually! 😉

Yes, I remember your BX-6AP2 BIOS thread where you, Horun, and I discussed finding an alternate BIOS for this bricked board. However, I never read the outcome.
At that time it was just a few weeks after my father-in-law’s funeral and my wife and me started to get really busy going through his stuff, deciding where it all should go.

Reading through your manual compress and replace method now, I see that it is quite similar. However you don’t describe adapting the compressed original.tmp header before copying it to the BIN. I’m curious to know if you let Modbin do this for you.

Great that you finally solved the mystery and that the board appeared to be an (incorrectly labeled) BX-6AV2, and you could get it fully functional with an older BIOS version for this board!

About CBROM V1.30C, I selected this 1999 version because it worked best on all 1997/1998/1999 socket 5/7 Award BIOSes. For 2000+ and Slot 1 BIOSes I do use a later CBROM version, usually V2.07.

Jan

Hi, Jan!

It was a while ago and I don't remember exactly what I've done to make BIOS checksums valid and unfortunately I didn't left any notes on that. I do remember, that I've found some clues on other BIOS-modding forums about it. Also I know for sure, that I manually replaced the modified and compressed by LHA.EXE "original.tmp" by using HEX-editor, just as it is described in the thread about my mislabeld BX-6AV2 mobo (still works great after all those BIOS experiments).

I have to recreate these steps:

1) Extract uncompressed "original.tmp" by using MODBIN.EXE - easy-peasy;
2) "Strip down" the BIOS dump file to header, bootblock and compressed "original.tmp" module + empty space by using CBROM.EXE while keeping in separate files all of the additional BIOS modules;
3) Edit uncompressed "original.tmp" module from 1) with HEX-editor;
4) You've also revealed here how to calculate and the edit new checksum for uncompressed "original.tmp" module - it's valuable and nowadays hard-to-find information;
5) Compress the new modified "original.tmp" by using LHA.EXE;
6) Replace compressed new "original.tmp" in "stripped" from additional modules BIOS file by using HEX-editor, while keeping an eye on the empty space after the new compressed "original.tmp";
7) Add all the stripped additional BIOS modules by CBROM.EXE;
8.) Test the new BIOS file with MODBIN.EXE.

I think this was what I've done to edit the PCI routing table (and some chipset initialization bytes) while experimenting with alien BIOSes for my then dead BX-6AV2 mobo.

Actually you were the one that made me do all this fiddling with the Award BIOSes 4.51PG back than 😀 Thanks for all the help!

I'm looking forward for the next episode of your BIOS-modifications tips on how to add custom CPU table 😉

Hi analog_programmer,

Looking at the steps you used to get the patched “original.tmp” back into the BIOS BIN file, I see how this would have worked as well. Two remarks though about your procedure:

1) Using CBROM to strip down the BIOS BIN-file to contain only the bootblock and the compressed “original.tmp” module including its header, and nothing behind, is a nice alternative method for copying the compressed patched “original.tmp” over the old one in the BIN-file. No worries about shifting the compressed modules behind original.tmp to make room, and calculating how many bytes this shift must be.
Of course, just as you describe in steps 2 and 7, you have to extract and save each module before you release it from the BIN, and put them back one by one afterwards.
A nice side-effect is that each time you use CBROM to store one of the previously released modules back in the BIN-file, the checksum bytes of the BIN are recalculated. So using MODBIN to edit the sign-on message and update the BIN to get the checksums correct, as I do as the last step, isn’t necessary in your procedure.
But checking the BIN with MODBIN as a last step is always a good idea of course!

Note that this “strip down” procedure is only necessary on 128KB compressed BIOSes. Although CBROM lists all modules as being stored behind original.tmp on both 128KB and 256KB BIOS BIN-files, this is actually so on 128KB BIOSes only.
On the 256KB BIOS, original.tmp is located separately at file-offset 20000h with nothing directly behind it. All the other modules are located at offsets 0-1FFFFh and are not in the way when overwriting the compressed original.tmp module by the patched version.

2) You don’t describe editing the header of the patched original.tmp module after compression. It is very well possible that CBROM takes care of that when putting the previously released modules back into the BIN. I never tested this and edit the header of the compressed patched original.tmp before I put it back into the BIN-file, just to be sure. 😉

Happy patching!
Jan

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 199 of 223, by Chkcpu

User metadata
Rank Oldbie
Rank
Oldbie
TheMobRules wrote on 2025-03-30, 19:42:
Hi Jan/analog_programmer […]
Show full quote

Hi Jan/analog_programmer

I've been following this discussion about extracting and re-compressing these Award BIOS with great interest, and a while back I was trying to do the same kind of process with an early AMI WinBIOS (from an Acer VI15G board). The structure of the BIOS consists on a compressed block (which starts at the very beginning of the file with header AMIBIOSC+<date>) and an uncompressed section which contains, among other things the decompression code.

There is a known tool called AMIDECO, but I've also managed to extract the compressed block by using LHA as well (it's basically an LZH file with simplified headers, just compressed and uncompressed sizes IIRC), but I haven't been able to re-compress the block properly with LHA after patching it, and going by the POST codes the BIOS hangs during the extraction routine. I've tried to disassemble the extraction code but I got lost pretty quickly in the process.

I was wondering if this may be similar to what you've been discussing about the Award BIOS, in particular I'm interested if you have any tips about how to determine the compression level used in order to re-pack the BIOS after patching it. Of course, if there's a counterpart for AMIDECO that would allow re-compressing the BIOS it would be ideal, but I'm not aware of the existence of such a tool.

Thanks!

Hi TheMobRules,

It did patch several compressed AMI socket 7 BIOSes for K6plus support, but worked on only two socket 3 BIOSes to see if Am5x86 support could be added. These two AMI BIOSes were the still uncompressed pre-WinBIOS types.

On the AMI socket 7 BIOS I also use AMIDECO and found that its modules are Level-1 LZH compressed, just as in the Award BIOS. But AMI has the -lh5- header completely replaced by a custom header of usually 20 bytes. This AMI header contains information about the type of module, the compressed and original sizes, and the location in (shadow)RAM where it must be placed.
In a next episode about patching the AMI socket 7 BIOS, I will come back on this with all the details. It has been many years since I patched an AMI BIOS though, so I have to re-investigate the steps I used before writing that episode. 😉

I did look at the AMI socket 3 WinBIOS in the past, but couldn’t make heads or tails from it. I suspected they were (partly) compressed but I couldn’t recognize any compression or AMI like header. So I never tried if AMIDECO would work on these.
So thank you for your info on the compressed parts of the VI15G WinBIOS!!!
You say that both AMIDECO and LHA.EXE are able to decompress these modules, so chances are good that LZH Level-1 is used here as well. I will look into this and try to find-out what compression method is used on the WinBIOS.

Cheers, Jan

Edit: I just did a short test on the compressed modules from the VI15G WinBIOS, and they are indeed NOT Level-1 LZH compressed.
So yes, I agree that opening a separate thread about this AMI WinBIOS compression issue is a good idea, and let the Vogons community magic work! 😊

Last edited by Chkcpu on 2025-04-01, 16:37. Edited 1 time in total.

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page