Thank you for the advice

I don't really have much knowledge of these programmers and I see a TL866 would go for around 100-120 euros locally and then google spits out some variants for around 60-70 euros + shipping.
That's a bit high, or at least higher than I would like to spend in this particular case.

First I'll try my luck and see if I can borrow an ISA card from someone, that would be ideal, or buy one really cheap (I see some at 10-15 euro, owners saying they work). If these fail, I'll reconsider my choices.

Thanks again for the advice on the programmer, I'll keep it in mind.

Tzzantaru wrote on 2025-01-04, 19:15:

Still no joy, and I think I need to get myself an ISA card to see what happens on screen because I don't really like going in bl […]
Show full quote

Still no joy, and I think I need to get myself an ISA card to see what happens on screen because I don't really like going in blind like this.

This is the most success I had so far, it goes through codes until it stops at 16 and hangs there with the floppy light still on, but not reading anything from it anymore. The clip is cut short but I've left it like this for about 10 minutes with nothing happening. After that I powered it off and then on again and still no post. Good thing is that it goes back to boot block so it didn't duck up anything.
In the clip I used the autoexec you gave me, the only difference is that I changed the .BIN name to match the actual .BIN file.

https://www.youtube.com/watch?v=Fpu0xrGz3Uc

I don't know, maybe I need to try with another version of AWD, although I tried 3 so far but I would feel a lot more comfortable if I would be able to actually see what the board is trying to tell me.

Thanks for the blind flash video.

The POST codes after FF are not from the BIOS Bootblock recovery, but are all generated by the Awdflash program to show its progress.
The flash goes well until it stops at code 1B. This is the programming phase of the flashchip. After this there are only 2 more steps, the verify phase (code 1C), and the flash complete phase (code 1D).

This shows me that booting the floppy, executing Awdflash, and loading the BIOS BIN-file all work as expected, but the actual flashing halts due to an error.
This is a strong indication of a failed flashchip!
But just to be sure, did you set JP20 to the correct voltage of the flashchip??

I hope you can get a cheap ISA videocard to show you which error is detected.
Awdflash will also show the detected flashchip type and its required flash voltage (5V or 12V).

Cheers, Jan

Hello,

Thank you for the insight and the explication of the codes shown by the diagnostic board.
I actually enjoy learning these things.

Acording to the chips datasheet, which is a MX29F001TPC-12, the voltage should be 5v and JP20 is set correctly, according to the manual, on pin 2+3.

I will try to get a hold of an ISA card but wouldn't it be a safe choice to already search for and buy another chip?
Or do you think there might be another reason for the chip not being able to be flashed?

Thanks

Ok, so I managed to get myself a cheap ISA card but this mobo just won't work with me. I still have no video output.

The card works, I tested it on my 5x86 system and it boots just fine but on the P5MVP3, won't move a muscle. I tried it on all 3 ISA slots and nothing.

The rest is as described earlier, no changes.

I'll try to get a hold of someone with a programmer and rewrite the bios off board but somehow I'm not confident that it will change anything.

Hi,

Nice that you could get an ISA videocard, but I’m at a loss why it wouldn’t work with this BIOS Bootblock. Maybe the BIOS is corrupted more extensively and the Bootblock video routines or ISA-bus support are affected too.

I very much like to take a look at the present BIOS content. Could you make another blind run with the bootable floppy, but this time with the following command in AUTOEXEC.BAT?

Awdflash /Pn BACKUP.BIN /Sy /e

This will not flash the BIOS but read the complete 128KB BIOS from the EEPROM and store it in the file BACKUP.BIN on the floppy.
During the BIOS backup you should see the codes 13 12 and when the backup is finished, the codes FF 15 should be displayed on the POST analyzer card.

If this works, please send this BACKUP.BIN-file with your reply.

Cheers. Jan

Hello and thank you for your response

I tried but no luck. Apparently it does not want to save anything. I tried 3 versions of AWDFLASH and 1 of UNIFLASH and none of them save anything.

Here is a clip from the version of AWDFLASH you gave me a couple of post ago with the autoexec line from your last post: https://www.youtube.com/watch?v=u25iQY9NAiU

Friday when the ISA card came and I still had no video output I thought that maybe I could use UNIFLASH to force it to write something and also log everything it does. I got the first short beep that indicates the bios file has been read, I also got the second short beep that means it's starting to flash but like 2 seconds after that, boom, continuous beep that indicates some kind of error. Worst part? Even with the log command in autoexec UNIFLASH did not write any logs.

On a side note, let's assume that the BIOS chip is the only problem this board has, I see that these chips are pretty hard to get. Is there any alternate identical version that could be a replacement and be easier to find?

Thank you

Damn that edit button....I always forget to write something

If it makes it easier, the codes that the board goes through are 41, FF,06, 07, 07, 0A, 0F and back to FF. No sign 13, 12 or 15.

Hi,

Thanks for the code sequence. Looks fine and it ends with FF, so Awdflash does complete its command. Strange that no backup.bin file is written. 🙁

About the MX29F001T replacement, the following 1Mbit flashchips should work as well on this board:
Atmel AT29C010A
SST29EE010A
Winbond W29EE011

There are probably others, but these are the most common.

Cheers, Jan

Thank you for the answer

Unfortunately, none of them are easily obtainable here. I found the winbond and the macronix on ebay but I have an estimated delivery somewhere at the beginning of march....so...yeah.

I will return with updates as soon as I have any.

Thank you again, to all of you, for the implication and the answers.

Ok, so, update.

The replacement BIOS chips have arrived(MX29F001TPC-12) and I tried a hot swap reflash(don't have a chip programmer and I didn't find anyone near with one yet) aaaaaand same thing as before. It starts good, ends bad.
It acts as if I didn't even change the chip, goes to bootload, reads the BIOS, starts to flash and then halts and I still have no video output even on the ISA card (just like the videos posted above). It also doesn't log anything even when I tell the flasher to log everything it does.

I don't have any idea left what could have gone wrong with the board. It wasn't even used from the last time it booted, just stayed in storage.

Hi Tzzantaru,

Well, this P5MVP3 is one stubborn board!
So the new flashchip didn’t solve anything. I assume the hotflash procedure went well and programming the new MX29F001TPC-12 was successful?

While reading back through this thread, I noticed that a lot of seemingly unrelated write actions fail. Writing the flashchip by Awdflash or Uniflash, writing the BIOS backup file to floppy, writing to the video RAM to build a picture; they all fail. Although, sending POST codes to the analyzer card works!

In this respect, did you try the analyzer card in an ISA slot? On your videos I see it only used in a PCI-slot and trying it in an ISA-slot may tell us if the ISA bus is perhaps dead.
But be careful when inserting the card in the ISA bus, the display has to point in the other direction, so towards the PSU connector!

From my end, I’ve started disassembling the BIOS Bootblock code of the MVP3_D.BIN BIOS, to find the point where, and on what conditions, the code decides to switch to Bootblock recovery instead of continuing normally with the boot process.
For this it would be helpful to know the sequence of all POST codes generated by the BIOS, from the first C0 up to the floppy detection at code 41. Remove the floppy from the drive so that the BIOS stops at code 41 again, and use the step-back function of the analyzer card to view all stored codes.

Greetings Jan

Hello Jan,

Thank you for the response.

Yes, it would seem it's trying hard to be stubborn 😀)

The only thing the new chip offered is the fact that the problem might indeed be somewhere else since the board behaves exactly the same as before. The hotflash procedure ended in the exact same spot as the last tries with the old chip. AWDFLASH gets stuck at 1b code and UNIFLASH "long continuous beep (some error occurred)" BUT even after the failed attempt to write the BIOS on the new chip, the board still boots to bootblock(with the new chip) so I'm assuming that it at least wrote the bootblock part? Since I'm not getting any video output I don't know what error it gives or what is happening.

You might be right about the ISA bus being dead. If I remember correctly I tried once using the analyzer on the ISA slot and I don't think I got anything from it but I didn't give it too much thought then. But I will be doing another try when I get a little time and maybe post a video of it if it gives any useful information.
Until then, any ideas of what could have trigger the ISA BUS to die like this with the board just staying in a box in storage (or if it's even something that could be repaired)?

Thanks

Hi Tzzantaru,

To avoid a misunderstanding, do I understand correctly that Hotflashing the new chip wasn’t successful? If so, which motherboard did you use for the Hotflash procedure and what were the indications on the screen?

Obviously, we need a correctly flashed new BIOS chip to test the P5MVP3 with, and to determine if the old BIOS chip is faulty or that the fault is elsewhere.

Jan

Hello,

You understand correctly, the hotflash was not successful.

So, due to the fact that in my area I can't really find anyone with a programmer to write the BIOS I tried the hot reflash on the board itself.

I assumed that if the problem is indeed the bios chip, I could boot up AWDFLASH or UNIFLASH with a manual exec instead of autoexec, swap the chips and then manually execute the flash, all of this in blind because I have no video output. I'm guessing that this wasn't as logical as I thought it would be? 😁
Here's what I did.
I set up everything just as before but I replaced autoexec.bat with manual.bat, started up the board with the disk inserted and let it boot to bootblock.
Once it finished booting to bootblock I swapped the BIOS chip and manually execute manual.bat.
So AWDFLASH reacted just as before, going through codes and then just stalling with the floppy led staying lit but no activity from it.
UNIFLASH beeped that it has started correctly, beeped that it read the BIOS files and beeped that it has started to flash but 5-6 seconds after that I got long continuous beep that some error occurred.

Now, I still have 2 more new chips(I bought 3 just to be safe) in case this one is bust so that's not really a problem. The problem is I can't get a hold of the last person that helped me with a programmer to write the BIOS and there's no one else around me that can help with this.
I do have another working board (a Lucky Star LS486E Rev C2) but honestly I'm not sure I want to try hot swapping the bios chips on that one.

I will have some time these days to try the analyzer card in the ISA slot and post a video of it.

In the meantime I going to keep searching for someone to try and write the BIOS on the new chip with a programmer so I can completely rule that one out.

I appreciate your answer and that you're still trying to help me.

Thank you

Hi Tzzantaru,

Thanks for describing your hotflash procedure in detail.
Using the P5MVP3 itself for the hotflash was a clever idea, which could have worked. But running into the same problem as with the direct blootblock recovery was a real possibility. And I still couldn’t tell you if the issue is a hardware problem on the board, a partially corrupted bootblock, or a defective flashchip.
But blind typing the Manual command worked, so the keyboard interface must be good. 😉

About trying your POST analyzer card in an ISA slot, it may be a good idea to first try it on your LS486E. From the Working ISA diagnostic card thread I learned that some of these card don’t function on ISA, even if they are sold as PCI/ISA cards. So a test on your functional LS486E should show you if your card is good on ISA.

Cheers, Jan

Hello,

So, I managed to try out the analyzer card on the ISA slot and apparently I didn't remember correctly when I said it didn't work, because it works. It's just identical to the PCI slot in terms of how it acts.

I'll start with the code sequence video:
https://www.youtube.com/watch?v=ojEMQdk8_rM

And here is a video with a brand new, empty BIOS chip:
https://www.youtube.com/watch?v=UICfKI3qYVo

Now, something that's very odd to me is the fact that the new chips are empty (dooh, evidently 😁) so that means that my initial swap and flash actually managed to write the bootblock part and then failed somewhere around the actual BIOS files.
Also, the original BIOS chip was written with a programmer, like 2 or 3 years ago and the board still acted like today, going directly to bootblock. Now I know that doesn't mean the original BIOS chip isn't still damaged but I cannot wrap my head around the fact that the board is refusing to write BIOS files on a brand new chip IF everything else is working on the board.

Could PcBytes (from the first responses of this thread) be right about the chipset going bad, somehow?

Could the problem be with some voltage regulators somewhere, or some caps that could be gone but don't look like they're gone? If so, what should I check first or where to look, based on what the board does?

As I mentioned earlier the LS486E, that board had some problems too. Same story, kept in storage for like 20 years and then refused to boot. It started up but no beeps, no codes, no nothing (I didn't have the analyzer card back then). Turns out the voltage regulator for the CPU was dead. Swapped the CPU, a 5x86-P75 3.3v to a DX2 5v and the board booted up like it was 1996 again. In the end I replaced the voltage regulator and everything works again with the 5x86-P75.
Could this board have some kind of similar problem?

Thanks

Hi Tzzantaru,

Nice to hear that the ISA bus is not dead and your analyzer card works on ISA as well. 😀

Thanks for the POST codes sequence video. I see the codes:
CF, C0, 00, C1, 0C, C5, 01, 05, 0C, 0D, and 41.
Now that I’ve completed the bootblock disassembly of the P5MVP3 Rev:D BIOS, I can give you my analysis of this POST code sequence.
I’ve found that the recovery mode starts at code 01. So the 01, 05, 0C, 0D, 41 sequence is part of the bootblock recovery.
This means that the decision to go to recovery mode is made before code 01.

Analysis
When I follow the bootblock code from the start, I see that the first two POST steps CF and C0 in this BIOS do the basic system setup:
CF - Test and clear CMOS register 3Dh; do early CPU detection and store result in CMOS_3Dh.
C0 - Early init chipset registers; Set RTC Defaults if invalid; Set system ports values to Default; Clear all DMA Page registers; Clear Status Shutdown byte in CMOS reg 0Fh if not AAh; Set CMOS 3Fh bit 1 if keyboard controller selftest is successful.
The next code 00 is not a POST step, but just a spurious code emitted during reset of the DMA Page registers.
Sofar, the BIOS doesn’t hang so CMOS, chipset, and keyboard controller access works normally and they all appear to be functional.

Now we come up to POST steps C1 and 0C where more tests are performed.
C1 – This step is all about testing RAM. First a RAM type detection is made, followed by a test of the first 256KB of memory. If this test fails, a beep code is emitted and POST is halted, exactly as you saw when no RAM was installed.
If the memory typing and test is successful, the whole 128KB BIOS is copied to lower RAM at address 1000:0000 and run from there. Then the L1 cache is Enabled and the code continues with POST 0C.
0C – This step is where the decision is made if the BIOS can continue with a normal boot-up or not. At this stage, the BIOS is still not decompressed and first a checksum check on the compressed Main System module (original.tmp) is made. Second, a scan for the location of the decompression engine is done and when found, the checksum of its 4KB memory block is checked.
If either of these tests fail, the next normal mode POST step C3 is skipped and the code continues with POST C5.

(Note that this POST_0C is not the same routine as step 0C in the recovery mode sequence. So there are 2 separate POST step 0C routines in this BIOS, each with its own function. Weird.)

C5 – This step prepares the BIOS for the recovery mode.
The BIOS is copied from lower RAM to shadow RAM at address E000:0 to F000:FFFF and this shadow RAM block is then write protected. The L1 cache is Disabled, and the code jumps to step 01 to start the recovery mode.

Conclusion
Normally, POST step 0C is followed by step C3. POST_C3 is where the bootblock code jumps to the decompression engine to decompress all BIOS modules to their allocated location in memory, to continue the normal POST sequence.
Because we don’t see code C3, but C5 instead, we know that one of the checks in POST_0C failed. This again is a strong indication of a corrupt BIOS, or a failed flashchip.
Although it still can be a memory problem, I consider this unlikely because the BIOS doesn’t hang at POST_C1.

Although this analysis doesn’t explain the no-video problem with the ISA graphics card, I expect the board to function normal again when you are able to correct the BIOS problem.

Cheers, Jan

Hello Jan

Awesome and detailed information there, thank you.

So, as far as I understand, almost everything is doing it's job up until it needs to do a checksum check on the main system module and then a check of the location for the decompression engine.
So this should be the earlier 128kb BIOS copied to lower RAM that need to decompress in order to continue doing it's job. I'm guessing that the scan and checking of the location for the decompression engine is also somewhere in the RAM?

I've also found this topic in which you replied ( Re: Soyo SY-4SAW Motherboard with corrupted BIOS - Need help ) where you say that "Because this whole process is done in RAM, what if there is a problem in the memory system? This could cause a memory corruption that would trip the integrity check with the same outcome of a bootblock recovery" and "Bad caps causing ripples on the supply lines to the memory system?"

Now, the first priority is evidently to find someone to program one of the new chips with a BIOS (or make up the courage to hot flash the chip on the LS486E if the first part fails) but for the sake of learning new stuff, you said it could be caused by some bad caps causing ripples to the memory and then I found this reddit thread ( https://www.reddit.com/r/vintagecomputing/com … apped_replaced/ ) (I hope I'm not breaking any rules with posting that link) where he changed the memory regulator (KV1083) and the caps next to it.
For the life of me I cannot find which one is the KV1083 that he's talking about. Is that the voltage regulator and the 2 caps from the top right corner of the board?
Should I start testing those (until I find someone with a programmer)?

Also for the sake of learning new stuff, could you elaborate on how you disassembled the boot block and how you got the information on what each code does or if that's even something I could learn with my very basic skills? 😁

Thank you and I appreciate the effort you're putting into helping me.

Hello Tzzantaru,

Tzzantaru wrote on 2025-05-06, 17:46:

So, as far as I understand, almost everything is doing it's job up until it needs to do a checksum check on the main system module and then a check of the location for the decompression engine.
So this should be the earlier 128kb BIOS copied to lower RAM that need to decompress in order to continue doing it's job. I'm guessing that the scan and checking of the location for the decompression engine is also somewhere in the RAM?

Yes, at the point where the checksum checks fail, the BIOS is already copied and run from RAM. So the checksum checks are also done in the BIOS copy in RAM.

I've also found this topic in which you replied Re: Soyo SY-4SAW Motherboard with corrupted BIOS - Need help where you say that "Because this whole process is done in RAM, what if there is a problem in the memory system? This could cause a memory corruption that would trip the integrity check with the same outcome of a bootblock recovery" and "Bad caps causing ripples on the supply lines to the memory system?"

This quote was about a BIOS problem on a 486 board with a chipset that can have issues with EDO RAM. The VIA MVP3 chipset on your board doesn’t have these issues.

Now, the first priority is evidently to find someone to program one of the new chips with a BIOS (or make up the courage to hot flash the chip on the LS486E if the first part fails) but for the sake of learning new stuff, you said it could be caused by some bad caps causing ripples to the memory and then I found this reddit thread ( https://www.reddit.com/r/vintagecomputing/com … apped_replaced/ ) (I hope I'm not breaking any rules with posting that link) where he changed the memory regulator (KV1083) and the caps next to it.
For the life of me I cannot find which one is the KV1083 that he's talking about. Is that the voltage regulator and the 2 caps from the top right corner of the board?
Should I start testing those (until I find someone with a programmer)?

Your LuckyTech P5MVP3 is a Baby AT board that can be run from an AT power supply. These PSU’s don’t have a 3.3V line, so your board has a (linear) voltage regulator to make 3.3V out of the PSU’s 5V line.
This 3.3V supply is used by the CPU for Vi/o, by the SDRAM slots, and by the AGP slot.
So this 3.3V regulator can get very hot when using a beefy AGP graphicscard with an AT PSU!
However, this P5MVP3 board also has an ATX PSU connector that will feed the 3.3V line directly from an ATX PSU. You wrote that you tested with an ATX PSU where the regulator and its 2 caps have little influence on the 3.3V line and you still had the boot problem. So I don’t think you have a problem with memory, or its power supply.

Also for the sake of learning new stuff, could you elaborate on how you disassembled the boot block and how you got the information on what each code does or if that's even something I could learn with my very basic skills? 😁

My studies gave me a sound knowledge of electronics and when I started my BIOS patching hobby 30 years ago, I got most of my knowledge about PC architecture and x86 assembly language from books. The internet was still in its infancy then. 😉
A story about how I do BIOS disassembly and patching can be read at Re: Diy modding support for k6+And 120gb hard drives into bios roms
Recently I added a part about the compressed Award BIOS: Re: DIY Bios Modding guide Jan Steunebrink k6-2+/3+ 128gb

The ”Sourcer” disassembler I use is an old DOS based program. It gives a good readable listing, however it is a static disassembler and its use is time consuming.
I have been looking for a modern interactive replacement, but haven’t made the change yet.

Cheers, Jan

PS Did you see my Private Message? Please reply via PM or e-mail when you have the time.

Hello again,

So, good news and bad news.

Good news is that I found someone that was kind enough to help me write the new chips. Bad news is that the motherboard is still giving me the cold shoulder.

So I've written all of the 3 chips with all the BIOSes available. 1 chip with Rev A, 1 chip with Rev C, 1 chip with Rev D. Unfortunately, none of them seem to make the board wanna POST.

Rev C and Rev D follow the same procedure as before, triple beep and straight to bootblock with absolutely no video output.
Rev A follows the same procedure as before, triple beep and straight to bootblock, with no video output BUT unlike the other 2 versions this one give no codes on the diagnostic card, just 2 lines.

I also asked the person to make a backup of the original chip and also the new chip #1 (that I've tried to blindly write the bios on the board itself by hot swap). I attached both backups, maybe they'll give any kind of idea, although I doubt it.

I thought of the super IO but I've replaced it with a new one -> same result.

I thought of bad RAM but then I've also tried with the FPM memory I have on the LS486E, which is fully functional -> same result.

I thought of the power supply, but I've also tried with the AT power supply that's running the 5x86 on the LS486E -> same result.

Why doesn't it give any video output on ISA? What can I check to see where it goes wrong? Anything I can measure on the ISA slots or whatever?

Any transistors I can check? Caps, voltage regulators, memory regulators? Anything? Did I mess some settings with the jumpers on the board (although I double and triple checked).
I attach 2 pictures with the board, maybe someone spots something.

Thank you