I tried to change the version of DOS, now it works a bit better with DOS 6.22.
I tried other versions that failed before. v5.6 doesn't hang anymore.
But still doesn't flash the BIOS.
It seems to be unable to erase the chip.

Not familiar with this particular board but have dealt with flashing BIOS many times. Does the BIOS have a protection setting in the BIOS? There might exist a BIOS protect or enable jumper on the board, you could check through the manual to see if any of those options exist. I see in the screenshot that next to the Flash Type it mentions 12V which is likely refering to a 12V line that may need to be held at 12V for any actual programing of the memory to take place. A quick search of the datasheet for that particular chip would tell you what pin should have 12V when programming and you could measure to see if that voltage is available when attempting to program the BIOS. If 12 V is required and not supplied by the motherboard (I don't think a motherboard would) then it won't be possible to reprogram the chip on the motherboard and you would need an appropriate external programmer. If any of the above options aren't an issue then try other flash programs that are compatible with your system, I have used uniflash and flashrom many times but those probably wouldn't be functional on such an old system.

Just had a quick read through of a datasheet for a 28F010 (linked below) and if indeed your flash part matches up with the datasheet then you would need around 12V on pin 1 of the IC to be able to erase / program the contents.

https://www.futurlec.com/Memory/28F010a.shtml

The Flash chip is a SST PH29EE010. It is a 5V only EEPROM. It is pin compatible with the 28F010 but doesn't require 12V.
By the way I have scoped the VPP pin and it never gets to 12V, and it shouldn't. On the WE# pin (pin 31) there are some spikes to ground even during boot up so I don't think it's enough to trigger it.
Looks like there is some problem communicating with the Flash chip.
The 32,768 KHz clock has a weird looking on the RTC module. It doesn't look like a good sine wave.
I suspect the RTC module of not behaving correctly. I have ordered a NW12887 module (designed by Necroware). Maybe it will solve this issue...

Patrice29100 wrote on 2025-04-06, 10:24:

The Flash chip is a SST PH29EE010. It is a 5V only EEPROM. It is pin compatible with the 28F010 but doesn't require 12V. By the […]
Show full quote

The Flash chip is a SST PH29EE010. It is a 5V only EEPROM. It is pin compatible with the 28F010 but doesn't require 12V.
By the way I have scoped the VPP pin and it never gets to 12V, and it shouldn't. On the WE# pin (pin 31) there are some spikes to ground even during boot up so I don't think it's enough to trigger it.
Looks like there is some problem communicating with the Flash chip.
The 32,768 KHz clock has a weird looking on the RTC module. It doesn't look like a good sine wave.
I suspect the RTC module of not behaving correctly. I have ordered a NW12887 module (designed by Necroware). Maybe it will solve this issue...

ok, I was just going off the info on the screenshot, maybe the missidentification of the flash part is an issue? The EEPROMS might have different timing requirements. Is the RTC able to keep time correctly? Is this motherboard fully functional other than this issue with flashing the BIOS? Another option you have is 'hotswapping' the flash eeprom in another motherboard that supports it and flashing the BIOS ver you want onto it using whatever flash utility works. I like to use a 32 PIN ZIF socket when hotswapping flash chips, makes the whole process far easier and less of a nail biting experience. I have also seen in the past that some motherboards only work with motherboard specific versions of flash utilities and fail otherwise.

edit: nevermind, I reread your first post and saw you have the BootBlock problem.... so it is not a functioning system. Have your tried different memory sticks / slots? I've seen memory which a motherboard didn't like cause the BootBlock problem when the BIOS is actually fully functional. If swapping memory doesn't help I would try another compatible system, 'hotswap' the EEPROM to program the BIOS.

Also if you have a spare 29EE010 laying around and are able to program it with the correct BIOS this would rule out a faulty EEPROM

I've tried to programm the chip with a TL866II plus, and there was no error reading, erasing or writing. The EEPROM is most likely not faulty.
I have tried different simm modules, it did not change anything.
I have a dammage simm socket, but it is just a bit of plastic that is missing. The module sits firmly in it. I will replace that socket too.

Some updates :

I have replaced the damaged RAM socket.
I also got a necroware NW12887 replacement for the RTC module.
I have checked the cache chips (if in any case it could be it...), and they all seem to be OK.
I have tried an other CPU. I have tested the CPU on a different board, and it is OK.
I have tried different memory configurations to no avail...

... And I'm still with the same error... 🙁

I have looked with an oscilloscope for the #CE, #WE and #OE signals on the EEPROM. There is activity on them, but when I try to reprogram the chip with Award's tool I can't see #WE and #CE going low at the same time. But, it could just be bad luck when capturing the trace...

I have traced the #WE enable pin to the #MEMW pin on the ISA bus, and to pin #3 on the UM8886AF (it is the #MEMW on the UM8886N variant according to the schematics found there : Re: UMC8881/8886 Datasheet )

I really don't know what's preventing that board to correctly boot...
I suppose the system tries to update part of the ROM content at boot up (something to do with the PCI configuration, I guess) and fails to do it.

I will try to reflow the chipset, may be some pins are not making good contact.
I have also ordered some replacement EEPROM chips.

Something to add to the list of issues : the board doesn't allways boot on the floppy. Sometimes it just fails at detecting it.

If anybody has any idea I can try ? Any help would be greatly appreciated ! 😀

Patrice29100 wrote on 2025-05-11, 20:16:

I have tried different memory configurations to no avail...

Memory might still be the key to the issue. Unless a 486 board has the very latest revision of the UMC 8881 or SiS 496 chipset, it does not support EDO RAM. If you started computer stuff around the time the Pentium 133 was common, it is quite likely you only have EDO PS/2 SIMMs, and not the older FPM type. If you install EDO RAM into a board that relies on the RAM behaving like classic FPM does, you get data corruption in main memory. The first thing the BIOS of your board performs in main memory is trying to decompress a compressed image of the runtime BIOS into shadow RAM, and if the decompression runs into a checksum error, you drop into the boot block. Unreliable RAM thus is a likely reason to get this issue.

So I highly recommend you to find out whether you have FPM or EDO RAM, and if you don't have FPM RAM, you need to get some.

I've seen excactly this issue on an Asus PVI-486SP3 with the competing SiS 496 chipset and accidentally putting EDO RAM into it.

Usually it won't even POST if EDO is used.

I've tested EDO and FPM. It doesn't change anything. And most of my tests are done with FPM (which works perfectly on my other 486 system).
I don't think it's a RAM issue.
The parity error message is probably triggered by a total system crash while trying to erase/flash the BIOS.
The main problem is the BootBlock... i.e., what's preventing the BIOS from working properly?

Patrice29100 wrote on 2025-05-11, 22:05:

The main problem is the BootBlock... i.e., what's preventing the BIOS from working properly?

On your system, the boot block is always executed first when you turn on the computer. The boot block is supposed to not be erased when the BIOS is upgraded in-system, and it has one primary purpose: Initiaize the RAM and decompress the main part of the BIOS into shadow RAM, then start to execute the main BIOS from shadow RAM.

The boot block itself is executed from ROM. The computer is perfectly able to execute boot block code even if the RAM is unreliable. On the other hand, decompression of the main BIOS is a RAM-intensive operation, and it might fail if data in the RAM gets corrupted. In cases the decompression of the main BIOS fails, the boot block then switches over to its secondary function (and only this function is visible without a POST card): It activates a micro-BIOS included in the boot block which is just good enough to boot MS-DOS from a floppy and run AWDFLASH.

There are basically two reasons why the boot block will drop into recovery mode: Either the data in the BIOS chip is actually corrupted, so it is impossible to be correctly decompressed, or the computer is operating erratically and decompresses the data wrong, even though the compressed data is stored correctly in the BIOS chip. There are some fine variants, though. For example, the boot block is located in the upper 16K of the BIOS chip (possibly even just the upper 8K), so any addressing problem of the BIOS chip that doesn't show in the top 16K range will not inhibit boot-block execution, but it will make the decompressor see corrupted contents of the BIOS chip, even if the contents of the chip is physically OK.

While the symptom is quite strongly pointing towards RAM problems, as you have confirmed that the BIOS contents is good, this does not necessarily mean that the problem is a broken or incompatible RAM stick (although this is likely to cause this symptom), it can also be due to hardware damage to the mainboard, which could make RAM access unreliable.

Another reason for your issue might be an accidentally overclocked processor, e.g. jumpering a 486DX4-100, which can run at 50*2 or 33*3 to 50*3 (although it likely wouldn't even get to the boot block at 50*3, but it might get there at 40*3).

Another potential but unlikely issue could be bent and touching pins in one of the ram sockets. I had two 486 boards where two neighboring ram socket pins were touching essentially tieing two address lines together. In my case it caused both boards not to post but depending on which address lines it may still work in the bios address region? Again very unlikely to be the case but just wanted to mention it

It is probably not the ram sticks that are the cause of all that. But RAM might play an important role here.

As everything seems to point towards something wrong with the RAM : let's test it 😉

I made a boot floppy of Memtest v1.11, and the system booted with it.
I ran the test with 2 x 16MB FPM sticks first, and then with 1 x 4MB EDO.
And there is something awfully wrong the system reports 59MB of RAM in both cases !!

In the configuration of Memtest there is a probe for memory size. I tried it mith the 4MB stick and i found the 4MB. The test ran without issues.
I ran the same procedure with the 2 x 16MB FPM. And it tested OK.
I ran that version of Memtest on my other system just in case there would be a bug in the memory size detection, and it reports the correct amount of RAM.

There seems to be a problem in the memory size detection mecanism of the board. If it thinks it has 59MB of RAM and tries to write in a non existing address it will surely fail. So if the BIOS is trying to decompress into RAM and is unable to do it, that may explain this behavior.

Now I have to find out how the RAM size is detected... 😁

I will also test if there are any pins touching... I already had this problem with my other system (I replaced the damaged sockets)

Thank you all for the feedback ! It is very much appreciated 😀

Patrice29100 wrote on 2025-05-12, 00:07:

It is probably not the ram sticks that are the cause of all that. But RAM might play an important role here. […]
Show full quote

It is probably not the ram sticks that are the cause of all that. But RAM might play an important role here.

As everything seems to point towards something wrong with the RAM : let's test it 😉

I made a boot floppy of Memtest v1.11, and the system booted with it.
I ran the test with 2 x 16MB FPM sticks first, and then with 1 x 4MB EDO.
And there is something awfully wrong the system reports 59MB of RAM in both cases !!

Remeber how I wrote that the bootblock contiains just enough to BIOS to boot MS-DOS and run AWDFLASH? It's quite likely that the memory size reporting (which might be needed if you would load himem.sys) is just not implemented by the boot block.

Patrice29100 wrote on 2025-05-12, 00:07:

In the configuration of Memtest there is a probe for memory size. I tried it mith the 4MB stick and i found the 4MB. The test ran without issues.

OK, this elimintates the most common source of the "unexpected ROM checksum error". At that point, only the first 1MB of RAM is used, which is proven to be reliable by memtest. As you were able to get a good picture in MS-DOS and memtest, it also seems the addressing on the ISA bus works. Yet the BIOS is unable to decompress itself. So either the contents of the flash chip are indeed damaged (did you write a known-good BIOS using your TL866?), or the addressing of the BIOS chip doesn't work correctly (damaged socket?).