Try another video card, it doesn't seem to like the one you used for some reason. Also try an ISA card if you have one.

computerguy08 wrote on 2021-08-20, 12:23:

Try another video card, it doesn't seem to like the one you used for some reason. Also try an ISA card if you have one.

Thanks, but as I wrote, I tried several different PCI video cards and 2 different ISA cards, in all of the slots- and none of them works now.

I got some new observations of dubious importance.
I noticed that if I connect a floppy drive (well, gotek) - the continuous beep does not happen. Instead, one of the two does:
If there is a "disk" in the drive, the computer seems to access and read it, and the POST code is FF. Although there is still no video signal and the keyboard does not seem to work.
If there is no "disk", the POST code stays 41, and a weird beep is sound. A short high note followed by a short low note. It is the first time I heard such BIOS beep.

Also, the transistor's heatsink near the BIOS chip is extremely hot to the touch. Not sure if this is normal.
The board seems unstable. Sometimes I'm not able to get it to even beep at all, and it is stuck on POST code 6C (cache issues?)

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

anetanel wrote on 2021-08-20, 12:35:

Thanks, but as I wrote, I tried several different PCI video cards and 2 different ISA cards, in all of the slots- and none of them works now.

I failed to notice that in your original post, my bad.

As for why it goes to FF with floppy, that's because it boots normally, but without a video adapter initialized.
I suspect you might have misconfigured something when you installed the new CPU. Just to be safe, here's the original manual.
Have another read and double check your settings. Stason/TH99 is known to have mistakes in their manuals/schemas.

computerguy08 wrote on 2021-08-20, 12:56:

I failed to notice that in your original post, my bad. […]
Show full quote

anetanel wrote on 2021-08-20, 12:35:

Thanks, but as I wrote, I tried several different PCI video cards and 2 different ISA cards, in all of the slots- and none of them works now.

I failed to notice that in your original post, my bad.

As for why it goes to FF with floppy, that's because it boots normally, but without a video adapter initialized.
I suspect you might have misconfigured something when you installed the new CPU. Just to be safe, here's the original manual.
Have another read and double check your settings. Stason/TH99 is known to have mistakes in their manuals/schemas.

5dvx0130.pdf

I triple verified and it is all as it should be.
Pentium 133: JC1:2-3, JC2:1-2, JP8:2-3(open. there is no 3 pin), JP9:1-2, JP6:2-3.
I also took pictures before changing anything, and I verified that that was the original state.
Sadly it is not booting yet.

I read (here: http://www.bioscentral.com/postcodes/awardbios.htm) that error code "0D" is "Initialize video interface; Detect CPU clock, read CMOS location 14h to find the type of video in use, detect and initialize video adapter".
Is it possible that somehow the system fails to detect the cpu speed, and there fore always errors, no matter what video card I'm using?
Could be that the pin, or circuitry that is responsible to this CPU clock detection is bad?
Where can I start looking?
Since the old CPU had corroded pins, I thought maybe some corrosion got to the CPU socket. I removed the sliding, top part of the zif socket and gave the pins underneath a good clean and inspection. but couldn't find anything really..
Started to read articles about the Award source code, to find what CPU pin is used in the step. I think I'm entering a rabbit hole 😀

Yeah you're quite right about it being a rabbit hole.
I can't provide a definitive answer, but I can share an observation about Award BIOS:
In your video, it's quite clear that the POST code jumps from 0x0d straight into 0x41.
In my own (emulation) tests with Award BIOS, there were a whole bunch of other POST codes in between, ending with code 0x40 and then 0x41 immediately after that. The execution continues from there on with codes 0xBF, 0x42...and so on.
So those tests after 0x0d were just skipped outright, just because there's no video? That's strange.

The testing was conducted with UniPCemu and Award BIOS v4.51PG from these boards:
Asus P/I-P54TP4XE (430FX)
Gigabyte GA-686NX (440FX)

Note the chipsets. There's no support for 430VX in UniPCemu, so these are not exactly the same as yours.

Can you reflash BIOS?
And some hq pics?

The attempt to access the floppy drive in this way points to some kind of BIOS recovery mechanism. Try populating the floppy with a barebones DOS setup with autoexec.bat launching the flasher?

The machine starts, beeps 1 long and two short (usually video card issue) and then a constant short beeps.

I got this EXACT behavior when corrupting the BIOS on a PCChips M536. I ended up saving it by hotflashing the chip in another machine.

mr.cat wrote on 2021-09-01, 11:54:

In your video, it's quite clear that the POST code jumps from 0x0d straight into 0x41.

The exact sequence when a floppy is connected is as follows:
C0, 00, C1, C6, 0C, C3, C5, 01, 05, 0C, 0D, 41, FF
Ummm... not sure what to make of it though 😀

Nexxen wrote on 2021-09-02, 11:41:

Can you reflash BIOS?
And some hq pics?

I reflashed it with 5DVX_19U.BIN. But nothing changed I'm afraid.
Pics of what?

Oerg866 wrote on 2021-09-02, 11:52:

The attempt to access the floppy drive in this way points to some kind of BIOS recovery mechanism. Try populating the floppy with a barebones DOS setup with autoexec.bat launching the flasher?

The machine starts, beeps 1 long and two short (usually video card issue) and then a constant short beeps.

I got this EXACT behavior when corrupting the BIOS on a PCChips M536. I ended up saving it by hotflashing the chip in another machine.

I'll try it, but I think that flashing with a flash writer should have already solve any BIOS issues...

Oh i didn't see that. That is very strange then indeed. Sorry.

I created a boot disk with the flash command in the autoexec.bat
It indeed seem to work, as in the disk is read and after a while the computer reboots automatically. But the behavior remains the same...

Is there the typical floppy seek before that? If not, then I guess you are indeed seeing the boot block in action. This is very strange, it implies that there is a checksum error somewhere. Are you sure the flash chip, socket, traces on the board are good? You may have severed a trace somehow while replacing the capacitor(s).

Oerg866 wrote on 2021-09-02, 13:07:

Is there the typical floppy seek before that? If not, then I guess you are indeed seeing the boot block in action. This is very strange, it implies that there is a checksum error somewhere. Are you sure the flash chip, socket, traces on the board are good? You may have severed a trace somehow while replacing the capacitor(s).

I'm now 100% sure that flashing by floppy is successful.
The beep speed is a bit different between v 1.90 and older versions (I noticed it when I first slashed 1.90 with the programmer).
I tried flashing 1.60 ,1.70 and 1.90 with the floppy method. and I can tell that the expected beeps difference is happening when changing versions.

I'm not sure about the traces. I guess I'll have to pull the multimeter again and poke around.
But the cap I replaced (TC12) is closer to the power connector and the floppy connector, than to the Flash. And it did work for a while....

Yes I checked also online that the later BIOS may not work with your board, 5DVX is listed with two different BIOS IDs:

2A59GZ1CC
2A59GZ19C

I'm having a hard time finding out the differences though ... I assume it is a different I/O chip (UMC vs ITE perhaps)

anetanel wrote on 2021-09-02, 12:04:

The exact sequence when a floppy is connected is as follows: C0, 00, C1, C6, 0C, C3, C5, 01, 05, 0C, 0D, 41, FF Ummm... not sure […]
Show full quote

mr.cat wrote on 2021-09-01, 11:54:

In your video, it's quite clear that the POST code jumps from 0x0d straight into 0x41.

The exact sequence when a floppy is connected is as follows:
C0, 00, C1, C6, 0C, C3, C5, 01, 05, 0C, 0D, 41, FF
Ummm... not sure what to make of it though 😀

OK found an explanation for the skipped codes: This is the flash recovery procedure in action, just like Oerg866 said.
Were this Award 6.00PG, you'd even get a short description on screen about it. But in these older versions it just silently tries to boot from floppy (which may work, or not).
EDIT: Actually looks like it doesn't depend on version after all, but the graphics card. You may see the short message with this version too, but only with some cards.
The procedure is triggered by a corrupt BIOS (checksum doesn't match) so I managed to reproduce this behavior in emulation (86Box) too, simply by changing a few bits.
And complete with that weird beep you described 😁
Note that the screen may remain black during this whole operation (depending on the graphics card) even if there is nothing wrong with the video.

Could you perhaps try to dump the BIOS to see if the chip itself has suffered some kind of a heat stroke?
(I don't know whether those things can go partially bad...?)

Yes, as far as I am aware only 100% standard ISA VGA compatible cards show an output on the recovery boot block on AWARD Version 4.5x. It may very well be none of the cards tried fit the bill here.

The question remains though; why does the checksum verification still fail even with a re-flashed BIOS. I still reckon there is a break in a trace somewhere.

Here's an idea -- the recovery floppy disk's AUTOEXEC.BAT file may be altered so that it READS BACK the BIOS from the chip. If you find there's garbled data somewhere, then you can draw more conclusions on that.

I tried to save the existing bios, but so far without success.
I tried both awdflash v5.4 and also v8.99, but although it seems to be able to flash the chip, I was not able to make it save the content of it. I believe I uses all the right flags...
I even tried creating a simple autoexec.bat file that will echo some text to a file, and it was not created as well. Could it be that the floppy in only readable in this "bios recovery" state?

Tried now using a different Flash chip from another working motherboard. After flashing it with the original BIOS I saved I get the same behavior.
So I guess it is no a bad chip.

Another observation.
While poking around the BIOS Flash with a multimeter while the chip was out, I noticed that the VSS pin (16) is kinda shorted with pins VDD (32) and both NC (1, 30). And by kinda, I mean that the multimeter beeps for about a whole second, and then stops.
I tried doing the same on another motherboard that uses the same Flash (SST29EE010) and this phenomena is not occurring there...
I measured the resistance between VSS and VDD on the "Good" board, and it was about 0.8 Kohm, while on the "Bad" board it is only about 0.08 Kohm. I'm not that good with electronics, but could it be that some other capacitors are at fault?
I also noticed that when testing continuity between the two legs of various capacitors on the board I get sometime a similar behavior - a short beep (not as long as with the Flash socket) and then it stops.

Chip datasheet: https://www.mouser.co.il/datasheet/2/176/71061-1102136.pdf