• Please review our updated Terms and Rules here

Can’t read/write Seagate MFM drive

jacobtohahn

Experienced Member
Joined
May 1, 2018
Messages
79
Location
North Carolina, USA
I recently found two Seagate MFM hard drives (Seagate ST-251, Seagate ST-225) in a storage unit and I’m trying to get them to work with my IBM PC AT. Both drives make their startup sounds, but give hard disk errors in the BIOS. Because I have a BIOS with the ability to low level format, I tried to use it to wipe the disks. However, the procedure returns “Write Fault on Selected Drive” or other errors like “Sector not found”. Doing a surface scan in the BIOS reports that every sector is bad (except for on the last cylinder, for some reason), and the format operation afterwards returns a write fault error.

I also tried using SpeedStor and Disk Manager to low level format. Disk Manager just doesn’t even want to work. SpeedStor, however, is a little more promising. The controller test passes, and the seek test also passes, so the controller is getting commands through to the drives and they’re not stuck and all that. However, the read test fails almost immediately (and the drive activity light never actually comes on on the ST-251, and stays permanently on on the ST-225), so it looks like read/write operations don’t work.

What could be going on here? I would assume that if the drive can seek and such, it would be able to read and write as well, and I find it odd that two drives would have the exact same problem.

Other notes: I’ve tried 3 different controllers, different cables, and I’ve tried changing the drive select around. I’m using an AMI 286 BIOS in my AT. Most importantly, a CM 6426 that came in the AT works just fine.
 
I would assume that if the drive can seek and such, it would be able to read and write as well ...
That assumes that when the controller is instructed to do a 'seek' operation to a track, that the controller also reads the sectors on the track. In my fully functional IBM AT, with stock IBM hard/floppy controller, if I disconnect the data cable from the MFM hard drive, the seek test of SpeedStor still happily works, stepping the heads. That informs me that in my particular scenario, the controller does not also read the sectors on the target track of a seek operation.

It is not always the case, as I write in the 'POSSIBLY USEFUL INFORMATION' section of [here].

Your CM 6426 is functional. Use it to see how your controller's seek operation behaves with the data cable disconnected.

... and I find it odd that two drives would have the exact same problem.
If the seek behaviour is as I wrote above, then you're left with a minimum requirement to low-level the drives (i.e. to ensure a controller-compatible low-level format is on the drive platters).

However, the read test fails almost immediately (and the drive activity light never actually comes on on the ST-251 ...
Is the ST-251's activity light on during the seek test?

... and stays permanently on on the ST-225)
If the ST-225's activity light is on ALL of the time, verify that the ST-225 does not have its 'radial' pins jumpered.

If instead, the light is initially off, turns on at the first drive operation, and then stays on, that is normal behaviour for the stock IBM hard/floppy controller in the IBM AT, because the controller operates in 'latch' mode. You will observe that the hard drive activity light on the front panel of the IBM AT behaves as expected. (For the IBM AT, IBM must not have intended for users to see any activity light on a hard drive.)
 
Check and double check those data cables. It is easy to get them backwards at one end or the other, or plug them in to the wrong header on the controller.
 
In my fully functional IBM AT, with stock IBM hard/floppy controller,
I believe my system should work similarly to yours, as I’m using a WD1003-WA2, which as far as I know works similarly to the stock controller. I’ll have to test.

If the seek behaviour is as I wrote above, then you're left with a minimum requirement to low-level the drives (i.e. to ensure a controller-compatible low-level format is on the drive platters).
I’m not quite sure what you mean by this. Can you elaborate? What’s the minimum requirement?

Your CM 6426 is functional. Use it to see how your controller's seek operation behaves with the data cable disconnected.
I’ll have to try that. Currently out of town but when I get back next week I should be able to test it out and see what I find.

I’m trying the drives one at a time in a single drive configuration. The terminator is on the drive, as the diagram says to.

I should also say that I know one of the drives (I believe it was the ST-225) worked properly up until a few years ago when the original ST11M controller failed. When put in my AT, the ST11 BIOS comes up but the PC BIOS reports “HDD Controller Failure” shortly after. And, when using the ST11 BIOS low level format, after entering all the drive information, it hangs the PC. That’s why I’m using a different controller.
 
Last edited:
Check and double check those data cables. It is easy to get them backwards at one end or the other, or plug them in to the wrong header on the controller.
I tried a ton of combinations of flipping the control and data cables around on the controller and drive, but the one thing I didn’t try is connecting the data cable to the other header (there are two), just because I don’t think it’s the right one. I’ll definitely try it though when I get back next week.
 
If the seek behaviour is as I wrote above, then you're left with a minimum requirement to low-level the drives (i.e. to ensure a controller-compatible low-level format is on the drive platters).
I’m not quite sure what you mean by this. Can you elaborate? What’s the minimum requirement?
In PC's (and I mean that generically), so that floppies can be interchanged between PC's, all PC floppy controllers put down the same low-level format onto a floppy.

There was no need to make 'MFM' hard drives interchangeable between computers. What one finds is that, with exceptions, different MFM HDD controllers put down different low-level formats. So if I purchase a known-working MFM drive from the internet and simply put it in my IBM AT (adjusting the CMOS SETUP accordingly), there is high probability that the AT's MFM HDD controller is not going recognise/understand the particular low-level format on the drive. Symptoms such as an inability to read from the drive, and inability to high-level format (repeat: high-level) (e.g. a DOS format) the drive. If I observe symptoms like that for the situation I write of, I will say to myself, "Yep, it is as I expected. I will need to low-level format the known-working drive using my IBM AT's MFM HDD controller (followed by partitioning and a high-level format)."

This possible low-level format incompatibility adds a variable to the needs-to-be-good equation:
* Hardware compatibility
* Hardware serviceability
* Cabling
* Drive selection
* Drive termination
* Low-level format compatibility

You now know that the stock HDD/FDD controller in the IBM AT does not read the HDD platter surface during a head stepping operation. So the fact that (in your configuration), head stepping is occurring, does not rule out a low-level format incompatibility.

Your 'unknown status' drives could be in one of the following states:
* Drive is good, but presently, there is low-level format incompatibility between controller and drive.
* Low-level format understood by controller, but drive has a hardware fault relating to sector reads/writes
* low-level format incompatibility between controller and drive, PLUS, drive has a hardware fault relating to sector reads/writes

Because of the possibility of low-level format incompatibility, I see no point in any testing that involves getting the controller to read sectors.

If you are confident in other variables (e.g. cabling, drive selection, ...), then to remove the possibility of low-level format incompatibility, I see the 'minimum' action being to attempt (repeat: attempt) a low-level format.
If the low-level format operation fails, it's back to working out why.
If the low-level format operation appears to work, there is a possibility of a secondary issue.
 
... but the one thing I didn’t try is connecting the data cable to the other header (there are two), just because I don’t think it’s the right one. I’ll definitely try it though when I get back next week.
Lots of IBM AT (IBM 5170) information at minuszerodegrees.net
The cabling diagrams at [here] show which data header/connector to use.
 
Back
Top