Intimate details of early-stage MS-DOS boot process? (why is my drive inaccessible)

[bear]

Ladies, gentlemen:

I am attempting to track down the cause of a problem accessing an MFM hard disk in an IBM 5170 AT. This disk has some data on it that I would like access to (copies of files from another drive with a failing format, prior to having run spinrite on the failing drive). It doesn't exactly matter, but the drive is a Miniscribe 3650 (40 MB). I left myself a post-it on top of the drive indicating I had formatted it as a type 20 (30 MB), leaving one head and some cylinders unused.

Indeed, the drive passes the seek and read tests in the IBM AT Diagnostics, with it set as type 20. There are a couple of sectors the read test fails which weren't originally flagged as defective during the format, but they are all beyond cylinder 250 and nowhere near track 0. This suggests to me the drive is formatted appropriately for the controller and is basically functioning correctly.

But DOS doesn't recognize it. FDISK says "Error: unable to access drive 2" when I pick option 5 to select that disk, so it's pretty clear DOS is deeply unhappy about something on the disk. If it had a partition >32 GB or some other OS partition on it (which it wouldn't) or even no partition table at all, I'd still expect FDISK to at least be able to select the drive.

This may be relevant: when DOS boots, something very very early in the boot process causes that drive to seek every track in order. Is DOS reading something off the drive that it finds nonsensical (one possible idea: a track or head outside the parameters of what should be available according to the drive type, which might indicate my note is inaccurate or misleading somehow - it's possible I had it on the WD1002 controller, but in some other machine with a different set of parameters for "type 20") and this is what it's unhappy about? How can I prove if this is the case?

Is there a way to dump raw sectors off the drive, so I can get an idea of what might be going wrong?

Any advice welcome.

 

[Stone]

I have a couple of those drives and they have long since succumbed to MFM death. I wouldn't give it a good chance of data recovery. But sometimes you just get lucky and after several attempts and reboots I have seen this type of drive come back to (some sort of) life even if only for a brief period of time.

If the window opens, SEIZE IT!!!

IMO, the FDISK error means FDISK requires a LLF in order to recognise it.

As far as dumping raw sectors, you won't be able to do this with any DOS program (for obvious reasons).

In any case, try SpeedStor.

 

[SomeGuy]

Forget about what DOS thinks and focus on what BIOS thinks.

What I would do is grab a copy of Norton Utilities 4.5 (best for 8088,286, and early 386/486s), and use the disk editor to select absolute sectors - if BIOS recognizes it, it will show up there, regardless of what DOS thinks. (For example you should be able to see all zeros on a freshly low leveled non-fdisked/dos-formated drive)

If you have another drive present, yes you can even use Norton Utilities to save sectors as files.

If the geometry type is mismatched you should still be able to read the MBR from the very first sector and determine what geometry it thinks it should be.

Also, keep in mind that MFM/RLL hard disk controller cards are not compatible between models. If this was used on a different model of card, then it would have to be re-low level formatted for the card to recognize it at all.

 

[Chuck(G)]

I suspect that it's mostly a matter of mis-configuration. You can examine individual sectors using DEBUG and interfacing to the INT 13H BIOS services, if you can get DOS booted from a floppy.

 

[SpidersWeb]

Are you using an MFM/RLL controller that has a ROM fitted?
Just mentioning this because the only time I've had the drive scanning symptom on startup is from a Boot ROM that can't find it's marbles.

 

[bear]

What I would do is grab a copy of Norton Utilities 4.5 (best for 8088,286, and early 386/486s), and use the disk editor to select absolute sectors - if BIOS recognizes it, it will show up there, regardless of what DOS thinks.

Thanks for that, I was indeed able to use Norton Utilities to verify that track 0 head 0 sector 1 was unreadable by the controller (despite having passed the read test in diags) and that my FAT was still intact at track 0 head 1 sector 1. Norton Disk Doctor was able to reformat track 0 head 0, regenerate a correct partition table, and restore access to my data. Magic!

Better than magic. Success.

I guess the track seeking was a red herring. It seems just to be what this drive does normally (it still does it). Probably a recalibration routine.