Jo22 wrote on 2020-08-04, 14:42:

Glad to hear! ^^ If you like, you can also run CheckIt! , too. […]
Show full quote

386SX wrote on 2020-08-04, 14:00:

Newer Scandisk, still no errors ! 😁

Glad to hear! ^^
If you like, you can also run CheckIt! , too.

PS: You can also use bigger HDDs with a Dynamic Drive Overlay (DDO). Or XTIDE Universal BIOS.
But if it works the way it is, just leave it that way. 😀

Yeah I was already sad to think I'd have needed another 90's disk that nowdays are difficult to find imho in good condition and this was quite ok, low noise, not extremely fast but good thing is that also remains quite cool on the temperature side. I used a 8.4GB one with the overlay driver, it worked ok setting a single 504MB partition in dos, but they really got hot on the surface and the overlay driver is a great idea but for a Win9x installation more than a msdos one imho.
Anyway for now it's a great 386 config.. high end but have to study more into the HIMEM, EMM386 stuff to configure it I lost every memories on those things.
Question: I did all these tests without loading the GUEST app for the Iomega ZIP100 drive I had before when I had those errors. Is it possible ( I suppose not) that being connected to the same I/O controller but on the external parallel port, that drive would create some problems before that resulted in those writing/reading cluster errors? It's a strange idea but it's the only thing I've still not loaded after reinstalling everything.

386SX wrote on 2020-08-03, 21:03:

How is this possible? Why should have worked for any other part of the disk but the middle part before? I've to say I always had 1057 / 16 / 63 in the bios setting thinking the bios should have supported it but I suspect it does not really.
What is your opinion? Should I expect soon to see again the same problem?

I still suspect that the drive was moved from a different machine that used a different (modern?) algorithm to translate the disk geometry into an equivalent one with fewer than 1024 cylinders. The MBR therefore had a totally different geometry in it than what your BIOS wanted. That meant that somewhere in the line between DOS picking an area of the disk to read and the BIOS sending the ATA command out to the drive to read it, possibly it got out of the valid range of that disk and was therefore marked bad. By setting it in your BIOS and wiping the drive you forced it to all be consistent. Hope it continues to work.

jakethompson1 wrote on 2020-08-04, 15:52:

386SX wrote on 2020-08-03, 21:03:

How is this possible? Why should have worked for any other part of the disk but the middle part before? I've to say I always had 1057 / 16 / 63 in the bios setting thinking the bios should have supported it but I suspect it does not really.
What is your opinion? Should I expect soon to see again the same problem?

I still suspect that the drive was moved from a different machine that used a different (modern?) algorithm to translate the disk geometry into an equivalent one with fewer than 1024 cylinders. The MBR therefore had a totally different geometry in it than what your BIOS wanted. That meant that somewhere in the line between DOS picking an area of the disk to read and the BIOS sending the ATA command out to the drive to read it, possibly it got out of the valid range of that disk and was therefore marked bad. By setting it in your BIOS and wiping the drive you forced it to all be consistent. Hope it continues to work.

Thanks. It sure sound more a late 486/Pentium hard disk that might have worked into LBA mode. The i440 mainboard I tried was reading it for LBA as first choice, with lower 528 / 32 / 64 values as said. But I think to remember having formatted it the first time some month ago with the 1057 cylinders setting with the amibios utility before installing the system. Who knows maybe the whole 1024 to 1057 might be a part of the problem here. I've read in the manual of the disk that this model was supported by the half 1990 and later amibios versions so I think it should have worked considering the bios date is 1991. But also in the manual is written some lines about the 1024 problem I probably wasn't thinking about when started.
Anyway day by day, I'll do scandisk like I've nevere really done in any system I had in the past I think.. actually I didn't even think I've used the surface tests evere before lately. 😁

Update: the scandisk begins again to find problems at the middle of the disk in the free space, also checkit notice a cylinder number 499 Head 1 with MAJOR problem in the linear read.
I don't understand why these problems at first are solved and after a while seems to come back and spread to others clusters too.. maybe the disk is really beginning to fail who knows... 🙁

I'd write the drive off and move on personally

maxtherabbit wrote on 2020-08-06, 14:06:

I'd write the drive off and move on personally

I think that too, I will switch to the 8GB one for some time until I'll find a period correct disk again... 🙁
Too bad cause it seems like a good working unit with no strange noise and well built too. Too bad.. I don't like the overlay driver solution but it's the only way to not end up seeing new damaged clusters found every days..