megatog615 wrote on 2025-08-21, 20:15:

Chkcpu... please help me with this stubborn BIOS ROM file!
https://theretroweb.com/motherboard/bios/t936 … 07053564709.zip

All I want to fix is HDD size so it's not stuck at 8GB max. Of course, I would very much be happy if I could get all of biospatcher's fixes working. I know biospatcher is slightly out of scope but I'm not sure if I could reliably hex edit this rom by myself.

Hi megatog615,

I will look into this BIOS issue and report back in your LBA48 PCI Option ROM? thread.

Cheers, Jan

myne wrote on 2025-08-22, 07:48:

second rom?

He has a system with onboard video, in which the system and video BIOS are combined on one ROM chip

jakethompson1 wrote on 2025-08-22, 17:51:

myne wrote on 2025-08-22, 07:48:

second rom?

He has a system with onboard video, in which the system and video BIOS are combined on one ROM chip

Hi Jakethompson1,

You are correct!
Indeed, I found the same and of course this is why CBROM got so confused! 😉

I’ve put up an explanation for the OP in his Re: LBA48 PCI Option ROM? thread.

Greetings, Jan

Chkcpu wrote on 2025-08-22, 18:30:

Hi Jakethompson1, […]
Show full quote

jakethompson1 wrote on 2025-08-22, 17:51:

myne wrote on 2025-08-22, 07:48:

second rom?

He has a system with onboard video, in which the system and video BIOS are combined on one ROM chip

Hi Jakethompson1,

You are correct!
Indeed, I found the same and of course this is why CBROM got so confused! 😉

I’ve put up an explanation for the OP in his Re: LBA48 PCI Option ROM? thread.

Greetings, Jan

As I think we've discussed before, I'm somewhat into these old BIOSes for which no known editing tools publicly exist, including some Phoenix 4.0x Re: Hacking/Replacing Phoenix Bios 4.04 on 486 board and AMI "Color" BIOS AMI Color BIOS (1993 and earlier) modification in hex editor

Are these later ones that use CBROM and BIOS Patcher, and so forth, structured enough that >8.4GB support, additional CPUIDs, etc. can be added with a program, or do you have to do a custom assembly patch, or dig by hand for unused space in the F000 runtime segment (when needed eg if the Int 13h handler needs changed), each time?

Occasionally there is interest in adding LBA (at least up to 8.4GB) to AMI "Color" BIOS without having to go to WinBIOS. LBA in "color" BIOS is somewhat rare, but among the differences between v4.8 and v4.9, here https://theretroweb.com/motherboards/s/efa-4dmu-hl3s#bios is LBA support. But so much shuffles around between those two versions that it isn't easy to isolate what changes AMI made to the 08/08/93 core to add LBA.

Hi Jakethompson1,

I have been following your postings with interest, especially about the AMI BIOS.
As my main interest is the Award BIOS, it is great to learn about details from “the other BIOS”. 😉

Many years ago, I did examine two AMI Color BIOSes in greater detail. These were for the Addtech 4GLX3 (011094) and the MSI MS-4134 (080893) boards.
This was in an attempt to improve CPU support (DX4/Am5x86), but I couldn’t finish these BIOS patches due to lack of AMI checksum knowledge. But now I know!

I didn’t look for AMI’s approach to the LBA-assisted translation support then. Also when I started the BIOS patching hobby back 1994, most BIOSes already had translation support up to 8GB and I only had to take care of the occasional 2GB limit bugs.

When I later shifted my attention from 486 to Socket 7 BIOSes, again the main concern was fixing CPU support and that nasty Award 32GB HDD limit bug. So, adding translation to fix the 504MB limit, or adding the Int13h extensions to break the 8GB barrier was never something I got serious about. In addition, adding the Int 13h extensions is a huge change that is difficult to implement in an already assembled BIOS. But perhaps adding the LBA-assisted translation is doable. When I have some time, I will look into these EFA 4DMU BIOSes the get a feeling about what’s involved.

As apple_rom’s BIOS Patcher tool demonstrates, the later BIOSes from Award and AMI are structured enough to allow adding CPU support and bugfixes by a program.
Most bugs like the 32GB HDD limit and UDMA bugs, can be recognized by a unique bytes pattern. In the episodes of my DIY BIOS Modding guide in this thread, I indicate these offending string of bytes whenever possible. Adding CPU support can be a bit more challenging because of the many BIOS changes made over the years.
However, occasionally a rare or new bug requires to do a custom assembly patch. I once found a rare 300MHz CPU speed limit in only 2 Asus socket 7 BIOSes. And patches for jumperless socket 7 boards are particularly challenging due to the unique solutions used by each motherboard manufacturer.

I have been toying with the idea of writing a patcher tool myself but haven’t yet found a solution of how to handle the compressed BIOS.
In recent episodes I explained how to decompress and re-compress the Award BIOSes manually, but doing that from within a patching tool is a programming challenge I’ve yet to solve.
In apple_rom’s tool, he solved this by using external tools like CBROM and LHA to compress his patches. He also avoids patching the main BIOS component (that’s what I do with my manual patching method) by putting the patch code and data in separate modules and patching the BIOS in RAM during each boot-up.
So he only needed to decompress the modules where bugs may be hiding to scan for them.
I know the old UNAWARD tool uses the decompression engine of the BIOS itself, so this may be an option to solve the decompress hurdle. However it would be more elegant and user friendly to let the patching tool do both decompress and compress on its own.

Finding sufficient space in the E000h or F000h segment for the added code and data is usually not a problem. But after compression, all modules still have to fit in the available space. This is the limiting factor, especially on an 128KB BIOS.

Cheers, Jan

The way I understand rom.by's tool is that it makes and inserts an option rom with any updates and doesn't overwrite the existing code.

How exactly it takes precedence over the stock code, I don't know.

myne wrote on 2025-08-26, 03:44:

The way I understand rom.by's tool is that it makes and inserts an option rom with any updates and doesn't overwrite the existing code.

How exactly it takes precedence over the stock code, I don't know.

This is what I know about Romby’s BP tool v4.23 for the Award BIOS.
The tool indeed adds two compressed modules to the BIOS. One is named “start.tmp” and the other “modul.tmp”.

This BP tool contains a database with known binary signatures of code and data that needs improvement, and the blobs of code and data to patch them. After the scan phase, the selected patches are placed in modul.tmp, together with code to execute these patches in RAM later on. So the original compressed modules inside the BIOS flashchip are not changed in any way.

The start.tmp module is very small and only contains a far jump to the start address of modul.tmp. When the BIOS bootblock code decompresses all modules in RAM, also start.tmp and modul.tmp are placed in RAM. In the header of each module, the location in RAM where it has to be decompressed into, is indicated. The BP tool has selected an unused RAM location to store modul.tmp and has programed this locationin its header and in the far jump in start.tmp.

The store location of start.tmp is a bit tricky because it needs to be executed before the start of POST so it can jump into modul.tmp to let it do its patchwork first.
Because the main system BIOS module “original.tmp” is always decompressed first, followed by the other modules, I believe start.tmp is injected into original.tmp at a location that it is executed before POST.
When modul.tmp has finished its patchwork, a far return instruction is executed to return control to the now patched original.tmp in RAM.

Rom.by also provided a roll-back feature to execute the unpatched BIOS.
The modul.tmp code checks for a depressed “-“ (minus) key on the numeric keypad, or a disconnected keyboard, and skips its patching when detecting either condition.

This approach it quite clever and works well when dealing with known bugs and know BIOS layout and structures. The above also explains why BP v4.23 only works on the compressed BIOS.

Cheers, Jan

Repo Man11 wrote on 2025-08-18, 03:05:

I also once tried the 2004 update CD which has all of the updates up to the year 2004, and that made no difference. […]
Show full quote

myne wrote on 2025-08-18, 01:56:

I'd just head to Windowsupdaterestored.com and scroll through the list looking for potential fixes.

And/or keep updating till there's nothing left

I also once tried the 2004 update CD which has all of the updates up to the year 2004, and that made no difference.

Installing Windows 2000 was smooth sailing, not one issue. But when I shut it down, once again...

Also, APM was not enabled by default, so I tried enabling it manually with the APM tab under Power Options. When I shut it down then, it goes to a blinking cursor in the upper left corner rather than the "It's now safe to shut down your computer" screen, and you still have to press the power button to shut it off.

I bought another pair of 64 meg SIMMs to bump it up to 256 in order to see if WinXP would be any different. And that has made another peculiarity of this board surface - it blue screens during setup with 256 megs of memory installed with both XP and 2000, but it passes Memtest86! After it initially passed Memtest, I thought the memory wasn't the issue, so I tried a different XP CD, a different ISO, different hard drive, different optical drives, then finally tried 2000 again only to see that it also would inevitably bluescreen or fail to copy a file with it as well.

It just occurred to me that I never tried disabling the motherboard's cache, which is worth a try since I'm using a K6-3+.

No, disabling the motherboard's cache made no difference, but dropping it back down to 128 megs of memory seems to have resolved the issue. Maybe the manufacturer didn't anticipate anyone trying to use this much ram without additional L2 cache (COAST) - or maybe it's some other quirk. No big deal, 128 is more than enough for Win98 and running 2000 or XP on this board would be silly - I'm just doing it as an experiment.

I successfully installed XP on it (version 2002 with SP1) and it runs surprisingly well and it handles 3D Mark 2000 better than Windows 2000 with SP4 did. But it is still too much for such an old machine, the performance penalty is about 300 points; about 2,100 with Win98 versus about 1,800 with XP.

I managed to create a tool that can read and write award bioses. It can extract and replace modules and the checksum is calculated based on checksum seed which is determined on load (contrary to awdbedit that has a hardcoded seed)
I tested it on a Mitac Award Bios 6.00PG and I was able to modify the system bios using a hex editor and replace it in the image - and boot the system without any checksum errors. It also loads and saves Award 4.51PG but I haven't yet tested with checksums.

Feel free to download it - or use the code like you like.

If anybody has a reasonable lzh compression algorithm in managed c#, let me heard from you. I used lzh-engine from awdbedit because I couldn't make one in managed code work.

https://github.com/adegn73/Awd/tree/master/Awd

https://github.com/ryandrake08/lzhl

no?