You have tried about everything I would have. Bad caps are a possibility even though they are not showing any physical issues. But I think that's unlikely. It may seem odd but have you tried going down to say, a single stick of RAM? Also I'm guessing you would have tried this if you had one, but can you try and use a PCI or ISA IDE controller?

And to confirm, these drives work totally fine in another system (that you formatted them in)? If so, does the garbled model number show up on the other system? Did you try the other IDE cabled in the other working system?

That's a nice KLEEEEN AT mobo. I hope you can get it working.

Try with internal/external caches disabled, see if anything changes.

Double check everything. I once had hard disk misbehavior with CPU VID configured incorrectly.

Try whatide, if it will show same c/h/s numbers as on the sticker.

First of all I should say that the problem seems solved 😀 So read backwards if you just want the solution that seems to have worked for me.

Kiteless wrote:

It may seem odd but have you tried going down to say, a single stick of RAM?

I had run memtest86+ from floppy and the RAM passed the tests but due to your suggestion I tried removing all except 1 RAM stick, but found (I think) that the mimumum sumber of SIMM sticks this board will post with is 2 sticks (same SIMM "Bank"). This seems to be confirmed in the manual, and I'd love to know if this 2-stick minimum is a general rule with all motherboards that use SIMM memory?

Kiteless wrote:

Also I'm guessing you would have tried this if you had one, but can you try and use a PCI or ISA IDE controller?

Actually, maybe it's worth mentioning this system came to me with a PCI SCSI ultrawide controller installed along with a SCSI CDR burner and 2x SCSI HDD's that sound like jet planes, and it was booting from SCSI before I removed the SCSI adapter from the system. In light of the problems I am having with the onboard IDE perhaps the SCSI controller is a clue that the original owner back in ~1996 was also having trouble with the onboard IDE. However, even if that's the case I would like to get as deep as possible into the cause and fix the board to work with the onboard IDE if possible. I plan to repurpose the SCSI controller but I do have a PCI IDE controller on its way in case I can't get the onboard IDE working reliably by the time it arrives. I'm pretty sure that a PCI/ISA IDE controller would bypass the problem - thanks for this suggestion!

Kiteless wrote:

And to confirm, these drives work totally fine in another system (that you formatted them in)? If so, does the garbled model number show up on the other system?

Yes the drives work totally fine in multiple other systems, and without the glitched model number.

quicknick wrote:

Try with internal/external caches disabled, see if anything changes.

Thanks for the suggestion, I'll definately use it in future!

gdjacobs wrote:

Double check everything. I once had hard disk misbehavior with CPU VID configured incorrectly.

This suggestion made me check that the jumpers were all set correctly on the board. As a conequence, I changed a few things that I think were set incorrectly according to http://www.elhvb.com/webhq/models/pcchips/m520.htm

Wolfus wrote:

Try whatide, if it will show same c/h/s numbers as on the sticker.

Looks very useful. I found WHATIDE hard to track down but found it at https://jigo.lu/index.php/ms-dos/dos-download … s-and-programs/

Kiteless wrote:

Did you try the other IDE cabled in the other working system?

Progress was made, thanks to this suggestion. I took the IDE cable from my other computer that is working with the drives in question, and moved the known working cable to the i430VX system and woot! the drive (WD CAVIAR) booted properly on the machine for the first time ever, booting to DOS that had been installed to it using another computer. However... the machine soon locked up refusing to read from the drive, then refused to recognise the drive again on subsequent reboots.. at best showing the garbled model number (if anything) and acting just as it had with the original cables. So it was like physically playing around with the cables would help, which seems to me a pretty strong sign that there's something physically wrong with the IDE part of the connections, perhaps some of the solder connections or PCB traces to the 'southbridge' equivalent...

I breadboarded the motherboard to examine it more closely with a multimeter and a USB microscope to look for any sign of broken traces and found that the board was much more dirty that it appeared. This pic is of the pins of the SB82371SB chip that the IDE sockets are connected to. I'm amazed how filthy the board was considering it looks pretty clean and neat to the naked eye (i.e. first photo in thread).

I didn't find any specific damage except for the dirt so I dusted off the board using a small anti-static brush and blasted it with canned compressed air, which made a massive difference. Here's a pic of the same area after a little cleaning:

And now I'm happy to say that the hard drive model numbers appear nornally during post and boot successfully every time. I never found the specific thing that was causing the drives to glitch but belive the issue was caused this debris on the motherboard, some of which muct have been somewhat conductive. Fingers crossed that the problem won't resurface but I think it's fixed now. Anyway it's a real lesson to me to clean old electronics carefully before considering them broken. A bit of a weird solution but I think it's worked! (And if the problem re-surfaces I will come back and let you know my success was short lived).

Anyway I'm very glad I asked for help as your ideas helped encourage me to try things out just when I had thought to give up. Thanks everyone!

ps: During my search for answers I happened across this "IDE & LPT DB25 port Tester test card" on eBay, and I had considered getting one to test the IDE sockets on the motherboard:

doh! While I have a much cleaner board 😀 it seems my success was short lived. Bet you could have seen that coming 😵

Since my last post I've been trying to get both CDROM and HDD to play nice together on this system, during which I would have rebooted ~100 times with out any sign whatsoever of the glitched HDD model numbers during startup... I was able to boot reliably to CDROM or HDD but only if there was only one attached to the system: trying many many possible combination of jumpers, Primary/Secondary MASTER/SLAVE setups etc with multiple different drives and multiple CD drives and multiple cables, etc. And now.. the glitched names have returned and I can only boot to floppy, so I'm back to square one. 😲

I have noticed that the BIOS is being modified during post (after booting once it's reading back a different image on the tl866 than was written to it), and I'm not sure that's normal? I'll start another topic about that and will post here again if I make any progress with the glitched model number issue, then any further issues with the system.

ESCD is often written into the BIOS chip.

Have you tried to lower the FSB to see if it would make a difference ? Jump from 66 to 60MHz or perhaps 55 can show some improvement and perhaps disabling of cache also. If those have no effect the problem is not related to some timing violation but instead something physical (bad via, connector etc.)

Tiido wrote:

ESCD is often written into the BIOS chip.

Have you tried to lower the FSB to see if it would make a difference ? Jump from 66 to 60MHz or perhaps 55 can show some improvement and perhaps disabling of cache also. If those have no effect the problem is not related to some timing violation but instead something physical (bad via, connector etc.)

knowing whether this is ESCD is a bit over my head. I've attached the original BIOS file along with the version I get after 1 boot. I've also attached a pic of a hexdiff of the main area of difference. If you know what to look for, please tell me if that looks like ESCD data to you?

I will try lowering the FSB and report back if there is any difference. Thanks for your suggestions!

(for future reference, the BIOS I am currenly using is the one from the file 520_Bios_19981207S_UNI [NP].zip downloaded from http://cwcyrix.duckdns.org/techpage/download/ … 525-stuff/bios/)

Goto the BIOS settings for the IDE and disable DMA, disable multiple sectors/block mode, and set to PIO 0. See if it becomes stable then.

Hi again. First thank you for all the suggestions which were very helpful!

I'm glad to report that the problem is fixed for real this time 😁

Yesterday the board was giving very clear indicators that it was suffering from an intermittant physical issue (as if to remind me that it was already obvious):

The CDROM was jumpered and set to pri. Master. The HDD was jumpered to 'single' and set to sec. Master. I went into BIOS and chose "LOAD BIOS DEFAULTS" and then set CDROM to be the first boot device, that's all I changed. The model names enumerated without glitch during POST and I had it sucessfully boot from CDROM with full access to both HDD and CD (HDD which had been formatted in another computer). For the first time, both IDE devices were working!

On the very next boot, and without touching anything except the keyboard (Ctrl-Alt-Del) the HDD enumerated with the glitched version of the name, and the CDROM gave a "Boot from ATAPI CD-ROM : Failure ..." message, which I had been receiving many times over the last few days. Incidentally, the CDROM spun up normally when it attempted to boot from it.

Next boot, with my fingers pressing gently down on the SB82371SB chip, neither drive enumerated at all during POST. And next boot, pressing gently on the secondary IDE connector, both drives enumerated but both had glitched names.

So, I was pretty certain it was something physical with the board. I had ordered one of the IDE testers mentioned above but that was weeks away, so I set about tracing all the IDE connections on the pcb...

I used an IDE pinout diagram (https://pinouts.ru/HD/AtaInternal_pinout.shtml) along with the datasheet for the PCIset SB82371SB chip (http://pdf.datasheetcatalog.com/datasheet_pdf … d_SB82371SB.pdf) to find out which pins the IDE socket was supposed to connect to.

What I found was thhat IDE pin 13 did not have a good connection to the chip and went through a funny looking via.

Sure enough that via was the culprit and after I bypassed it with a jumper the board worked as it should.

I then bypassed it permanently by soldering a bodge wire on the underside of the board that would effect the missing connection. I did try to fix the via but it was too small to fix without damaging the board.

I would guess that this board's IDE had been giving problems since leaving the fabricator and that is why the prior owners had used a SCSI controller for the drives. I had read somewhere that PCCHIPS boards are of "sub-par" quality, and perhaps this defect is further evidence of it!

I am very glad to have this system fixed. The added benefit of sticking with it is that during the process of diagnosing the system for way too long I have become strangely attracted to it -- something like stockholm syndrome 😀

Congrats ~

EleDip wrote:

Hi again. First thank you for all the suggestions which were very helpful! […]
Show full quote

Hi again. First thank you for all the suggestions which were very helpful!

What I found was thhat IDE pin 13 did not have a good connection to the chip and went through a funny looking via.

Selection_172.jpg

Sure enough that via was the culprit and after I bypassed it with a jumper the board worked as it should.

Dude this is an awesome fix! Great work. I'm pretty sure I would not have figured that out. Glad to see this Socket 7 mobo get rescued even if it is a PC-CHIPS. Haha.

Kiteless wrote:

Dude this is an awesome fix! Great work. I'm pretty sure I would not have figured that out. Glad to see this Socket 7 mobo get rescued even if it is a PC-CHIPS. Haha.

haha, and thanks! Unfortunately the fix is more a testament to the unsavoury amount of time I spent trying to debug the issue than anything else 😀 I spent way too much time believing that the board was probably working and that I was just doing something wrong with the BIOS and/or IDE jumpers/cables... as this is the first retro PC I've worked on... but it was a good experience and may help me diagnose similar issues faster in future.

I'll really be interested to see if the IDE tester I ordered would have helped me find the issue sooner, and plan to try disconnecting my fix and report back here about whether the IDE tester shows anything helpful if/when it arrives.

ps @Kiteless: Looking forward to more videos in your c:\90s_tech youtube channel -- great work!

EleDip wrote:

haha, and thanks! Unfortunately the fix is more a testament to the unsavoury amount of time I spent trying to debug the issue than anything else 😀 I spent way too much time believing that the board was probably working and that I was just doing something wrong with the BIOS and/or IDE jumpers/cables... as this is the first retro PC I've worked on... but it was a good experience and may help me diagnose similar issues faster in future.

I'll really be interested to see if the IDE tester I ordered would have helped me find the issue sooner, and plan to try disconnecting my fix and report back here about whether the IDE tester shows anything helpful if/when it arrives.

ps @Kiteless: Looking forward to more videos in your c:\90s_tech youtube channel -- great work!

I'll be keeping an eye out here for your findings should you do that. A lot of time sure but I think it was worth it.

And thanks for the positive vibes on the new YouTube channel. I just uploaded my part 2 of the 486 build. It was a long video with LOTS of cuts to keep pacing fast and still ended up being nearly 40 minutes long. Cheers!

Just a quick follow-up on the IDE slot tester which arrived last week.

I disconnected the wire I had soldered to return the fault to the motherboard and sure enough the tester shows that there is a bad connection on PIN 13.

So it Looks like the tester would have helped to diagnose the issue much faster. Though the tester was in no way required it's reassuring it would have worked!

The Chinese written on the tester was a little difficult to interpret so I recorded the IDE tester's pinout in this pic.

Kiteless wrote:

And thanks for the positive vibes on the new YouTube channel. I just uploaded my part 2 of the 486 build. It was a long video with LOTS of cuts to keep pacing fast and still ended up being nearly 40 minutes long. Cheers!

Really enjoying those videos 😎