I have a Seagate ST-225 20MB hard drive. It used a ST-412 MFM (Modified Frequency Modulation) controller which unfortunately went to the great bit bucket some time ago.

Is it possible to get this hard drive working with a modern PC? My thoughts are to either find a ST-412 MFM controller for ISA and hope I can find some drivers that work in Windows XP or Linux or to try to get or make some sort of adapter bridge to SATA, PATA/IDE/ATAPI or USB.

I know that there are ESDI->SCSI adapters that could be chained to a SCSI->Something Modern adapter, but AFAIK ST-412 is an older protocol that is very similar to but not quite compatible with it.

I don't have any need to retrieve/salvage data from this drive. I'm more interested in the novelty of getting such a disk working again and astonishing little children with the fixed storage media of their ancestors.

Assume for the sake of this question that the drive itself is working - the scope of the question is how to interface it.

  • 2
    Maybe use some microcontroller with USB and enough GPIO to drive it? The pin assignment is documented, "just" needs proper timing for MFM read/write. Sounds like a major project, though ... ATA is no use, the interface is too different, so you might as well use anything the microcontroller supports out of the box, which would be most likely USB, and then you can implement USB storage on top of it.
    – dirkt
    Commented Mar 4, 2017 at 19:56
  • 3
    Or perhaps something like this MFM board (which allows at least reading real drives, although its main use is emulating MFM drives). A real ST-506 might still be supported on Linux, there appears to still be related code in the kernel. Commented Mar 4, 2017 at 20:43
  • 2
    It's an interesting project, but you are swimming against the tide. Most retro-computing projects seek to attach modern flash storage devices to some ancient disk controller.
    – Brian H
    Commented Mar 5, 2017 at 3:25
  • 9
    With MFM disks, didn't the controller and drive effectively form a pair? I could be wrong, but as I recall things, the drive itself fed (and accepted) analog signals to/from the disk controller, which in turn was responsible for actually encoding/decoding the data. So you might need to find a MFM controller of at least the same model as was used with the drive. The major difference between IDE (now called PATA) and many previous interfaces was how this part of the controller was moved to the drive itself; hence Integrated Drive Electronics.
    – user
    Commented Mar 6, 2017 at 21:16
  • 1
    The ST-412 controller is an updated and backwards compatible version of the ST-506 controller. The ATA command set and interface registers are backwards compatible with the ST-506. In theory at least, any OS should be able to use an ST-412 controller as a very primitive IDE drive. The first IDE drives were basically just drives with a builtin ST-506/412 compatible controller. If nothing else if you can find an ISA MFM or RLL controller and a PC with ISA slots to stick it in it will work MS-DOS (and by extension Windows 95/98/ME since they can fall back to MS-DOS if necessary).
    – user722
    Commented Apr 18, 2017 at 22:06

4 Answers 4


Unless going the SCSI bridge route described in another post, you will very likely need a PC with an ISA slot - such mainboards were only common up to the Pentium 3 era, unless you are using a PC using the PICMG backplane form factor used for industrial control.

ST-506 interface drives (aka MFM/RLL) were very dependent on the controller paired to it. A factory new drive was commonly low level formatted using a tool in the controller ROM (debug g=c800:5 IIRC) and would then only work correctly with this or a similarly designed controller card until low level formatted with another controller's tool. In some cases, defect lists had to be typed in from a label on the drive itself, or from accompanying paper documentation, or built by the firmware tool. These were then stored in some location on the drive itself for use of the controller - an ST-506 drive does not hide damaged sectors at its connector, this is the controller card's job to handle.

There is no drive identification of any kind with this interface, the BIOS and the controller firmware has to be told what kind of drive is connected and what its operating parameters are.

An old school IDE drive was basically offering a reduced ISA bus on its connector, emulating a WD1003 controller card.

It can prove necessary to disable most or any on-mainboard IDE, SATA, Floppy functionality to stop it from conflicting with the ST-506 card.

Be aware that two standards - ST-506 aka MFM/RLL, and ESDI, existed back then that had identical looking connectors and superficially identical looking controller cards. These also are very similar from a what-to-do view, but the electrical interface drive-to-controller is totally different.

Be aware that some drives need terminating resistors on the last drive on the cable enabled or installed, similar to SCSI. Be aware that some of the signalling on the two cables is essentially analog.

If experimenting, mind that accidentally letting the low level format tool from a ST-506 controller loose on an IDE drive (some IDE might have it built into a corner of their own firmware, or the firmware from an actual controller card could mess with registers on an IDE drive installed in the same machine) was a known way of messing up IDE drives back in the day.


As people have mentioned in comments, you're looking at a lot of work. You are better off trying to locate a MFM controller. If you only want what is on the disc then maybe somebody with a controller would read it for you. That is of course assuming the data on the drive hasn't degraded.

While the electrical connections are known and well-documented the format of the data on the drive is also not what was used on later IDE drives. MFM drives use RLL encoding. That's when it gets fun because there were different configurations of RLL encoding. Controllers needed to look at the disk and figure out which was used. I hazilly remember there being a way that you could specify during format, but I only used MFM drives for a very short period of time. It was more my curiosity on how something worked than needing it for a particular task.

About half of the electronics to read the disk, and the optional second drive, are on the card. That card had BIOS which presented the drive(s) to the computer as a storage device and hooked interrupt (INT)13 to make it bootable. SCSI controllers also do this. When a drive is presented as INT13 however you don't really need a driver to talk to it.

A software driver was not used to describe drives until Windows 95, which booted from MSDOS. A actual software driver for harddives didn't exist until 2000. Linux started in 1991 so is not much older than Windows 95. The drive is probably predates that by 10 years.

This is 20 megabytes so you're not really going to be able to use it on a modern operating system. At the time 20 megabytes was a lot compared to the 360 K boot disk of dos 3.3(if it was used in a 8088).

  • 1
    The Linux 1.2.13 kernel has a compile-time option to add support for XT hard drives ('at least the DTC 5150X'). According to the comments this was added in 1992.
    – john_e
    Commented Apr 16, 2017 at 22:45
  • 1
    The dtc5150 looks like a floppy controller and not drive controller. Commented Apr 16, 2017 at 22:59
  • 3
    MFM controllers use Modified Frequency Modulation (MFM) as the encoding. RLL controllers use Run Length Limited (RLL) encoding. The drives used with these controllers weren't intelligent enough to encode anything, so just used the encoding the controller used. You could take a 40MB MFM formatted drive and turning it into a 52MB RLL formatted drive simply by attaching it to an RLL controller and reformatting it.
    – user722
    Commented Apr 18, 2017 at 21:54
  • 1
    The Linux 'xd' driver (for MFM / RLL hard drives on an 8-bit ISA interface) was removed in 2013. It can be compiled into kernels before that, but may not work - in the 2.2 and 2.4 kernels I tested it failed on load with 'xd: Out of memory'. This particular bug was fixed in kernel 2.6.33 (committed on 2009-12-09). See the git history at git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/…
    – john_e
    Commented Jul 12, 2019 at 10:41
  • 1
    40MB MFM to 52MB RLL seems too small, I seem to remember ir was more like 50% more space (and 40MB drives were rare, at least in PCs), but 20MB MFM to 30MB RLL was typical. At that time DEC PDPs also used MFM-RLL drives, so PC users would consult DEC-mini guys (almost always male) for advice when necessary. They make a Drem emulator nowadays, www.drem.info but I think they're about $300 Commented Dec 9, 2021 at 1:07

There were such things as SCSI-to-MFM bridgeboards, such as the Adaptec ACB-4000 or the Xebec 1410.

The only experience I've had with this is trying to use Linux (running on a Pentium II PC) to access an MFM drive with an Xebec 1410-type bridgeboard. I was able to establish partial communication with the drive by disabling parity and applying a patch ('adaptec-40XX-1.02') to the kernel which hardcoded the drive size. However I didn't manage to get as far as reading data before the drive failed.


How i managed to do it on a "modern" 486 board with integrated IDE: first i needed to disable IDE controller in bios IMPORTANT: for whatever reason this drive only works as secondary slave drive, the other drives are selected on the BIOS as "None" and the actual disk is selected as drive type 2

the drive is a tandon 20mb mfm drive

  • 1
    That's not the ST506/ST412 interface the OP is talking about, because that one is not compatible with IDE on a physical level, no matter what you do in the BIOS. This interfaces predates IDE. And if your drive is an IDE drive that happens to use MFM, it still uses IDE and not ST506/ST412.
    – dirkt
    Commented Nov 16, 2020 at 5:29
  • 1
    @dirkt is right. IDE was basically an abstraction layer that removed the requirement to mount an ST-412, ESDI, etc. controller card in your computer that matched your hard drive. The point was that the controller was built-in to your IDE hard drive and communicated with your computer at a higher level protocol that abstracted away things like where exactly things were stored on the physical disk in favor of working at the logical sector and block level. Commented Nov 16, 2020 at 23:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .