How not to run Hitachi’s Drive Fitness Test on Mac

I’ve had (what I suspect) to be some bad seconds on some Hitachi disks.  The recommended tool to diagnose and repair such disks is Hitachi DFT.  Unfortunately, the Hitachi DFT utility only runs in what appears to be real-mode DOS.

They do provide ISOs and floppy disk images though, which are fairly easy to burn or dd onto a USB stick with Disk Utility.  The machine in which these disks are actually in use, however, is not an x86 machine, and it will not be booting any part of that.

I could, of course, take a production desktop offline, if I didn’t need to use it for the 4+ hours it takes to run a thorough DFT test.  On five disks.  Not an option.

The next trick is VMWare Fusion, a go-to Mac utility for virtualization.  Unfortunately, Fusion doesn’t support attaching a physical disk to a virtual machine, so yet another dead end.

Next up, dusting off my eee pc.  I also have a Nippon Labs USB->Everything adapter to wire up the HD.  The eeepc boots from the floppy image that I’ve dd-ed to a USB stick just fine, but no HD detected (other than the eeepc’s internal flash memory).

Taking a look at the DFT disk image, it appears to contain some strange version of PC-DOS (yes, the IBM one) in the 3.x-4.x range, i.e. from the 80s.  USB, as you recall, was retroactively hacked into Windows 95, i.e. way, way, later.  If trying to bring USB support back to the 80s sounds like the world’s worst idea to you, that’s because it is.

The state of DOS USB support

Cypress Semiconductor, a manufacturer of USB controllers, among other things (e.g. laser-guided navigation systems), has written a driver called DUSE for no real reason that I can determine.  It hangs whenever I try to load it.  The documentation says maybe you can pass a manual RAM address mumble mumble memory-mapped IO.  I declined to investigate further.

Panasonic of Japan appears to have written random USB storage drivers for one or more of their products I assume, I can’t read Japanese.  While most of the drivers hang for me, after downloading various versions I eventually found one to successfully detect my USB devices, although it takes a good 60 seconds to load.  I should mention, too, that particular versions of DOS are significant.  At one point I moved from PC-DOS whatever to MS-DOS 6.22, with which I had much more USB success.

Which brings us to the next problem of USB devices in DOS.  Up until the OS starts making intelligent USB calls, the BIOS just pretends that whatever’s on the USB stick is a floppy disk.  But at that point, the floppy disk emulation turns off.  Which would be fine if the driver mounted the flash disk again.  Unfortunately, it’s really two drivers: usbaspi.sys to talk to the USB bus host, and DI1000DD.SYS to treat the device as mass storage.  Since DOS driver loads are sequential, we can load usbaspi.sys, after which we putter around looking for DI1000DD.SYS on a non-existant floppy drive.  The order is, of course, significant, so no fair loading DI1000DD.SYS first and expecting to turn around and load usbaspi.sys later.

The kind folks at Panasonic have prepared for this eventuality, however, because they’ve written yet another driver called RAMFD.SYS which will helpfully copy your floppy disk to a ram drive, cutting the cord to let you load the USB driver.  However, it appears that this miracle driver doesn’t support USB drives masquerading as floppy drives via BIOS emulation, presumably Panasonic was imagining someone literally using a floppy drive with a USB cable attached, not today’s modern marvels.  RAMFD.SYS helpfully prints out some japanese characters and “Media type not supported.”  Oh well.

Since the problem appears to be the dual use of USB, what the heck, let’s install DOS on the EEE PC’s internal flash HD.  Alas, it was not to be.  After dutifully burning 3 separate 1.5MB disk images to my 2000MB flash drive (“Please insert Disk #3”), poor little MS-DOS entered a reboot loop.  Although MS-DOS’s support lifecycle ran out in 2002, you can be sure that we’ll continue to enforce the copyright until at least 2095.  Maybe.  I can’t read the chart.

I can, however, use the internal drive as just a plain old disk of sorts, even if it’s not bootable.  Comment out the USB drivers, boot from USB, copy some files from USB to the HD, turn on the USB drivers again, reboot, Abort Retry Fail, switch over to the internal storage mid-boot, see how far we get, goto 10.

After a little fiddling with the setup, it boots successfully with USB support!  Hooray!

I go to fire up DFT, and it even detects the drive as a Hitachi with the model number and everything!  Just probe the SCSI port, and.. wait, what?  Yes, my little ATA connector appears to be a SCSI device in DOS-land.  Unfortunately, a device that hangs when probed.

It’s easy enough to fix, just pull out the device and plug it back in, and the hang immediately resolves, and my Hitachi drive is in the drive list.  Of course, these crazy backported drivers don’t have hotplug support.  Once the device is unplugged, it’s unplugged for good.  Fail.

I will spare you the story of the next 3 vendors with their special little USB drivers just to tell you, they didn’t work either.  I will leave you with some representative quotes from the most authoritative page I could find on the subject (although lacking in a lot of detail):

The USBdrivers collection includes 5 different usbaspi.sys and 2 usbcd.sys files, the iomega drivers, the ramfd.sys driver, and the modified Win98 OEM config.sys and autoexec.bat files. You will have to experiment to see which one works for you….

Please keep in mind that DOS USB CDrom/HDD/zip/etc. drivers is a brand new and developing area so there is no one single method that is guaranteed to work on every PC.

Of course, how could I forget?  Screw iOS development, I want to move into the new and exciting field of writing drivers for MS-DOS 6.

Before changing careers, I suddenly remembered something…

Back to virtualization

VMWare isn’t the only kid on the virtualization block.  I grudgingly acknowledge the existence of Parallels for Mac, which does, in fact, have physical disk support!  Hooray!

Well.  It does in fact claim to have physical disk support.  The physical disk support does enable.  And it even supports read and write operations.  Very, very fast read and write operations.  So fast, in fact, that a test that reads every sector on the disk twice, a task that should take a few hours minimum, takes about ten minutes.  In other words, either Hitachi accidentally shipped me a hard-drive shaped concord jet, or no part of this Parallels setup is actually testing my disk.

Time to kill DOS

OK, it’s 2011.  Why do I have to retrofit some hardware from 1994 into some OS from 1989 to read sectors from my drive?  (Or flash my BIOS, or…)  Why can’t these real-mode utilities be using, say, Linux?  Unfortunately, Linux’s real-mode support is downright terrible: the top google search results are mailing lists asking about how bad its support is.  Basically no support.

There is no modern real-mode OS.  Or, rather, the last real-mode OS was DOS.  And hardware diagnostics are sort of the killer app for real mode, so they’ve stayed in DOS-world.  Even as we introduce more and more compatability fail with DOS every year.

Apple is the only one to get this right.  They write all their diagnostics to run on OS X, a very nontrivial feat in low-level software engineering.  And not only have they managed to deprecate the 286 (last processor with true Real Mode support), just a little bit ago they deprecated optical media.  I’m pretty sure someone even still manufactures those.

---

Want me to build your app / consult for your company / speak at your event? Good news! I'm an iOS developer for hire.

Like this post? Contribute to the coffee fund so I can write more like it.