Thank you for your additional proposals.
Both the MFM and IDE/FDC/mio cards are ISA and AT grade. Therefor they're dumb without it's own BIOS. The Unisys 386 Phoenix BIOS only supports one irq channel for HDD controller. At the time, there were no ATA standard. You just define master and slave, eg hd0 and hd1 as c/h/s style HDD with precomp and landing zone.

So in this case (without the use of XT grade MFM controller with it's own BIOS programmable with the ROM program at some debug addresses) I had to use either 3drives/4drives HDD driver as a supplement HDD BIOS, or XT-IDE/XT-CF Universal BIOS either on it's own cards BIOS ROM, or on an eithernetcards ROM or with optROMloader from floppy 💾.

On a Mainboard with onboard ide, there are most likely a BIOS with four configurable HDD. One could easily disable, enable, autodetect (ide HDD only from the right ATA standard up, I guess ATA 3) or manually enter the values in c/h/s or lba. But I think that's only possible until socket 7 boards, because you need an ISA Slot for the MFM controller. It may be also possible with an Adaptec ACB SCSI to MFM card or the like.

And thee is also some retro stuff from the 8bit guy with an MFM emulator card I guess. Eventually similar to kryoflux/greaseweazle solutions for flux data with floppy drive from 8" on.

With the 3drives.hdd driver solution I'm not able to boot from CF Card and either load the driver from floppy or the primary MFM card, because the system will be only aware of the CF card until the driver has loaded from accessible MFM partition or floppy.

I guess that would be possible from floppy with optromloading the XT IDE ROM and with F2 one could easily select the CF card from the menu.

A more modern BIOS of a socket 7 or Slot 1 with ISA bridge and slot, may can select it itself or at least is configurable (MFM CHS values must be configured manually anyway)

Disruptor wrote on 2023-04-11, 10:08:

It would be much easier when you could use another motherboard with integrated IDE controller which is able to deactivate primary IDE and to boot from secondary IDE.

Personally, I would use two PCs and a null-modem connection in such a situation.

Programs can be found here: Re: 386 , what can I do with it?

With programs like UFO or File Maven 3, files can be transmitted between two PCs.

LapLink may also do. Or WinLink, which is a similar product.
Or Little Big Lan, also easy to use.

Making an 1:1 disk image would be most favorable, maybe, though.
There are DOS based programs that can do that, I just don't remember their names.
I can check my books/files, though, if there's an interest.

Otherwise, a DOS port of rawrite can be used to write the sectors of the MFM HDD into a file, which is located on a remote drive (attached via null-modem/driver).

Alternatively, XTIDE Universal BIOS can be used here.
It has a utility that can simulate a HDD on another PC. As a medium, the serial port is used, as well..

Thanks. It's nice to have a bunch of options! I once used mTCP with EtherDFS from Mateusz Viste EtherDFS - a network drive for DOS

I think, also partimage or earlier versions of ghost might be interesting.

I don't have a null modem cable or crossover by hand.

One also can use FreeBSD, Slackware 8 or such older Linux distros with xt.o and hd compiled in the kernel, and imaging with dd conv=noerrors, dd_rescue or gddrescue. But maybe one have to use more RAM or also compile a kernel module for that 386 machine. You may have to crosscompile on a faster more modern computer or it will take ages.

Anyway. It was the first running MFM setup in my life. All of my four MFM drives seem to be dead in the beginning. Maybe a kind drop of oil will bring some of the other MFM drives back to life to.

Iarsin wrote on 2023-04-11, 10:44:

Anyway. It was the first running MFM setup in my life. All of my four MFM drives seem to be dead in the beginning. Maybe a kind drop of oil will bring some of the other MFM drives back to life to.

Heads can stick to the platters. Un-sticking them is sometimes possible, but note that this can also result in some damage to the platters, and heads as well. Just the platters is not a big deal if the HDD has auto-parking or was parked manually.
Rather than explain the way to go about with a page of text watch 10s of this YT video: https://youtu.be/SwEi7dK3rIA?t=1234

As for the MFM+IDE cards combo, I never got it to work. Apparently the problem is with multi-io cards claiming IRQ14 even if the IDE is set to secondary (or even disabled). This is on top of early BIOS possibly not being able to boot from secondary IDE anyway. Either use much newer 486+ (probably Pentium) with built-in IDE, these seem to properly allocate IRQs, but - at least for me - such CPU with MFM is a poor combo. Neither period-correct nor will the MFM drive be big enough to fit the software. Or use SCSI controller instead of IDE - for example AHA-1542CF that I have works well along MFM (although you might have to stick to SCSI being the bootable drive, depending on your particular card), and it has floppy controller as well. Any other ports you can add with pure serial/parallel cards.

Oh and in case you didn't know yet, each MFM controller has sligtly different timings so the previous HDD content can only be accessed via low-level flux dump or the exact card that was used to format it. If you don't care about what's on it, but just want to use again, you need to low-level format the HDD. Older BIOSes had that option but if your does not then usually it's possible to run this via DOS debug command.

Thank you, that's valuable information to me, as the info of the other commenters as well. I just solderd the molex 4-pin power connector to the PTI MFM Drive cutted cables, as in the schematics I posted. It turns on, but it lists gibberish with the dir command, ndd cannot solve the FAT issue and calibrat didn't access it. So I think it's about the timing issue you mentioned. I think all the drives stepper motors can need some oil and so on ...

The gears of the stepper motor need some fresh grease/oil, maybe.

Another "tip", maybe.:
If the HDD powers on, tries to seek (squeaky sounds) and then powers down, it maybe had trouble finding track 0.

In that case, power off in the middle of the seek, wait a 1-2 sec (HDD platter still spins on idle speed), then power on again.
Normally, the HDD should then finish the power on procedure successfully and keep running.
This worked for me, at least. In a PC/XT. A couple of times.

Please keep in mind that this puts quite a bit of stress on the PC power supply (power surge, especially if HDD powers on).
Normally, a rapid on-off-on cycle is a very bad idea. A second of pause is the very minimum, I think, otherwise the PSU might die.

Edit: Another tip: MFM/RLL HDDs often don't have an auto-park feature.
They must be "parked" (set down) in a safe spot before being moved around, otherwise the HDD heads on the HDD arm (actuator) may scratch over the surface. There are many programs that do that parking on DOS (park.com etc).

A good program is part of Central Point PC-Tools 4 Deluxe or PC-Tools 7, if memory serves.

Hi Jo22, thank you for the additional tips.
I'm using park of the Unisys first floppy of the archive.org archive.

Bit on the not functioning MFM drives it fails parking, but not on the original Unisys NEC drive.

I'll investigate later on those drives.

Just an FYI on the park command and most hard drives on which one 'should' use it.

most park commands just place the heads of the hard drive on the last cylinder of the hard drive and then halt further operation,
some park commands just return to the dos prompt and any further use of the computer will negate the park operation
most (probably all) hard drives of that era have no special handling of that cylinder or any other cylinders of the disc.
This is in contrast to some modern hard drives which physically lift the heads off the discs, by moving them beyond the disc boundary.

Isn't landing zone the value for the parking position? I noticed another park program, that seems to not lead to any action of the MFM hard drive. The Unisys park command instead leads to a longer time moving part inside the disk. Then it tells, that the drive is parked and one can safely switch the Computer off. A annoying Sirene signals loud the situation and pushes one to switch it off. No other action is possible.

What I also noticed, is that the "write precompensation" precomp in two drives is 5 digits long like 65535 or the like. But the Phoenix BIOS only allows four digits.

What is the meaning of precomp?

Easier to read about then explain it: https://www.google.com/search?q=hard+drive+precompensation
read the first two entries 😀

"WPC is the cylinder of the hard drive at which write precompensation starts.

If the WPC of a drive is shown as zero, that means that precompensation is required to ALL cylinders.
If the WPC is shown as "none" or "N/A" or "-1" or "65535", that means that no precompensation is required.

Using the wrong WPC will not stop the hard drive from booting/operating." -0°

So I'm fine in those cases with -1

Thanks.

Iarsin wrote on 2023-04-13, 01:38:

Using the wrong WPC will not stop the hard drive from booting/operating." -0°

Objection! As the name suggests, this is _write_ precompensation. Nothing magic. It has exactly zero influence over the read process. So no, wrong WPC will not prevent the drive from booting. Operating - maybe, it's not like WPC on will completly change the encoding, I would expect it to affect only the high-numered cylinders (closer to the center of the platters).

EDIT: Seems I misunderstood the quote, please ignore.