MFM controllers are often without their own ROM, the mainboard BIOS should handle what you need. If this particular machine does not, find a different mobo (usually 286 or 386SX, but also some later 386DX and 386/486 mobos) that has a low level HDD format option. AMI BIOS is what I'm familiar with (both the older split SETUP+UTILS and the new color one) but possibly other ones too. Format the HDD on that mobo, with that controller, and just move the prepared HDD and card back to the IBM. As long as the controller is the same the HDD format will work.

Deunan wrote on 2025-07-01, 11:43:

MFM controllers are often without their own ROM, the mainboard BIOS should handle what you need. If this particular machine does not, find a different mobo (usually 286 or 386SX, but also some later 386DX and 386/486 mobos) that has a low level HDD format option. AMI BIOS is what I'm familiar with (both the older split SETUP+UTILS and the new color one) but possibly other ones too. Format the HDD on that mobo, with that controller, and just move the prepared HDD and card back to the IBM. As long as the controller is the same the HDD format will work.

16-bit MFM controllers are often (usually) without their own ROM indeed, but this would be the first 8-bit one I've seen

Now that you've mentioned it... It would be odd for XT-class HDD controller to be ROM-less. The ROM that's on there is most likely just the firmware for the Z8. Well then, perhaps OP is right and this card was meant for some specific machine that had the support built-in already.

Hi, I think some 8-Bit MFM/RLL controllers have an ROM integrated in the WD controller (or similar).
Since the code takes up 8 KB or less, it could been easily implemented in a mask-ROM of the day.

nevermind...

Hey, thanks everyone for all the ideas!

Hi, I think some 8-Bit MFM/RLL controllers have an ROM integrated in the WD controller (or similar).
Since the code takes up 8 KB or less, it could been easily implemented in a mask-ROM of the day.

Now that you've mentioned it... It would be odd for XT-class HDD controller to be ROM-less. The ROM that's on there is most likely just the firmware for the Z8. Well then, perhaps OP is right and this card was meant for some specific machine that had the support built-in already.

That seems strange for me as well, but so far I'm simply unable to find any BIOS code on the controller. If feels like the controller was originally made with a BIOS (which makes sense since there's an empty spot on PCB).
I assume that the target machine in which the controller was intended to be used had HDD control BIOS located on the PCB that was conflicting with the one on the card by address, so they had to remove it (or order with that IC removed).

Format the HDD on that mobo, with that controller, and just move the prepared HDD and card back to the IBM. As long as the controller is the same the HDD format will work.

That sounds very interesting (!), even though its a bit of a bummer that I'd need to use this controller in a different machine each time I need to low-format an HDD (considering the fact that old MFM drives might not be the most reliable hardware).

This also brings me to a somewhat generic question of how does the boot sequence with an HDD work? For some reason I though that after motherboard BIOS is done it tries to run code from the HDD controller BIOS to read and boot from drive, but I now understand that its not needed, since it instead simply calls an interrupt that would operate a controller (if one exists) at its default 0x320h I/O area? And then the controller would either boot the system if it is able to access the drive, or it would return the handle to the system if the drive is not present on non formatted in the "controller's" way?
If so, I have an ST-225 that I bought together with this controller. I did spin it up, but never tired to run the system with the controller connected, so there is a high chance that this drive was initially formatted using this controller, which means I might be able to use it as it is...
I also though that different system stats software would show some info about the HDD controllers, but as I now understand the controller simply acts as a bridge between system and HDD, so it isn't a self-sustainable device without a drive in pair?

Thanks!

Isopodus wrote on 2025-07-01, 15:48:

This also brings me to a somewhat generic question of how does the boot sequence with an HDD work?

On AT the BIOS on the mobo is already aware of IDE-like interface for HDD controllers that was started with WD chips for MFM. So IDE or MFM, if the register layout is compatible the BIOS will, as part of it's boot procedure, read data from first sector of FDD or HDD, check for signature and run it if one is found.

XT is not something I'm very familiar with but my understanding is there is no such code in the mobo BIOS. The card has to come with ROM that will patch some interrupts when run (BIOS will run all ROM extensions found on discovery) and that patch will cause BIOS to call the ROM again during final boot stage (int 19h). XTIDE works in similar way on both XT and AT.

So without that ROM, if BIOS is not written to handle that card on its own, it won't be able to access the HDD at all. All int 13h will do is work with FDC, which is the same for XT and AT.
Also, this being an XT card, the idea to use AT system to format the disk probably won't work, since a) AT expects the HDD to be 16-bit access and b) on different port than XT. That however gives me an idea, if you can find an image of this missing ROM, flash it to DIP EPROM and put in an 8-bit Ethernet card as boot ROM. This way you can test if it works before soldering anything. In fact it can stay that way if it works.

Isopodus wrote on 2025-07-01, 15:48:

If so, I have an ST-225 that I bought together with this controller. I did spin it up (...)

A reminder that ST-225 is not auto-parking HDD. If you let it spin up, and power it off without parking, it'll leave the heads on cylinder 0. Do not subject unparked HDDs to vibrations or you risk cylinder 0 surface damage, which can make the disk inoperable.

Isopodus wrote on 2025-07-01, 15:48:

as I now understand the controller simply acts as a bridge between system and HDD, so it isn't a self-sustainable device without a drive in pair?

Not sure I understand the question, but MFM drives are like multi-head floppies, with denser track layout. The drive is pretty dumb (*), it can move the heads and will amplify the signal but it doesn't understand any of it without the controller. So if you want to read the original data off it you will need the original controller (or low-level dump, it can be done). The disk can be low level re-formatted though, wiping all the data in the process.

*) Even these newer "dumb" drives have servo tracks though, this is what allows them to not have track 0 sensor, and/or recalibrate any thermal expansions to get higher bit density. But still too dumb to park itself, or understand the bit format. So MFM drive is also RLL if it can deal with higher bitrate without too much noise.