Recently my friend Bogdan gave me an old Seagate ST-225 (20MB, MFM interface) harddisk for my collection. The drive was not in its best shape: it looked like it spent decades being moved from one dusty drawer to another, in addition to missing its power connector. I wasn't expecting it to be working but wanted to give it a try. I soldered a power connector with short lengths of wire to check whether it would start, since actually interfacing it to a computer requires quite an effort. Surprisingly, it does start and it isn't very noisy (that would have been a bad sign). It performs its full-seek upon startup and continues to spin merrily. This is somewhat promising and justifies the effort of taking out an old computer to investigate further.
The MFM interface means that I have to use a computer with MFM controller and without IDE controller. While I do have such a computer, it's placed in a rack and its insides are difficult to access. I do have another functioning 286 (Everex 286/12MHz) but that one has an IDE harddrive. Luckily though, the Everex, instead of using a "Super-IO" (a single board providing RS-232, parallel, floppy and IDE interfaces), has serial and parallel interfaces on the motherboard, while the IDE+Floppy are on a separate ISA board. And I have another MFM+Floppy interface that can be used. I could hardly have wished for a better combination (it's not its first time being used like that).
First step: Put the computer on the table and check that everything is working in its current configuration. I power it up and - due to lack of battery - it complains about CMOS settings. While looking through the Setup screen, the power supply suddenly dies. In fact it almost dies: I could see the keyboard LEDs still lit, in the second it took for my hand to hit the power switch. However, the screen image disappeared, the fan stopped and the IDE drive spun down. While I'm glad at the lack of BANG, this event has me quite worried. Having no other AT power supply at hand, things are beginning to look dificult.
Hoping this power supply will not get worse without load (some older switching power supplies require a minimum load), I disconnect everything, get ready with the multi-meter and throw the switch once more. Fan starts and.. voltages check ok. This is worrying: if the power supply is fine, then chances are the MB is bad. It can still be a problem with the PS under load but I don't think so. Hoping it was maybe a freak occurence (or maybe one of the cards, HDD or floppy drive might be the cuplrit), I connect just the motherboard and try again... Silence (no fan) but power LED lights. In fact, when I turn off the power I see the fan trying to move. This suggests a problem on the 12V rail. However, the empty motherboard shouldn't pull too much current on the 12V rail. This is old technology, almost everything is 5V and there are no DC-DC converters on the MB.
Then it occurs to me: this motherboard only has tantalum capacitors. Their usual failure mode is to short-out. With everything disconnected I measure the resistance between the 12V input pin and ground but it's fine, no short. Open-circuit, no less. However, the negative rail (-12V) is dead short to ground. Found you! I think -12V is only used for RS-232 and the only capacitor that looks to be connected to it is right next to the power connector.
After extracting the suspected capacitor the -12V rail looks good and indeed the cap measures short. I find another one that is similar (if larger in volume): 22µF / 25V. It looks old but unused. I solder it in place, put everything back, power-on.
Everything starts fine, but then I hear some pops between the ticks of memory testing. Quick power-off just as the smoke begins to rise. A look at the MB confirms that the newly replaced capacitor is the source of the smoke. It looks slightly charred now, but I can see that I put it in place properly (correct polarity). Well, I don't have another tantalum so I decide to replace it with an electrolytic and see what happens. Unsolder, clean the holes, insert another (newer) electrolytic, put everything back.
Except this time I insert the multi-meter probes in the connector as well and when throwing the switch I keep an eye on the voltage. -12.07, steady. Capacitor remains cold. I suppose that the other tantalum was as ready to fail as the one on the board. It has every chance of being as old as this MB (long story) so there's that.
Back to that first step. Capacitor troubles now gone, the computer runs fine. It boots from its IDE HDD once I set it in BIOS Setup, however there is a distinct lack of network card inside it. Right, I removed it some time ago to fit it in the R&S PSA5. Side-note: this means that last I powered this computer was more than two years ago. Found another network card (luckily I still have one or two ISA Ethernet cards with twisted-pair capability), its setup program is already present on the HDD, and the card is NE20001 compatible.
Second step: networking. I fire-up my Netware 3.12 Server (still my favorite for DOS networking), configure the card, and, quicker than Windows is populating "Network Neighborhood", I'm connected. The reason for networking requirement is that once I install the MFM controller, I will only have a floppy drive and the HDD that I want to copy. On the other hand, on the Netware server I have everything I need: lots of free space (gigabytes!), Borland C (compiler and IDE) and so on. Not to mention that I want to get the image onto a modern computer. Some time ago I wrote a rather crude C program to make an image of a HDD from under DOS. It's result is similar to running dd if=/dev/... of=file conv=noerror,sync under Linux.
Third step: make a bootable diskette, copy ipx and netx to it (for Netware connectivity) and test that it's working. This goes without a hitch.
First boot (from diskette) with HDD connected goes quite smoothly, I can see that it was using Stacker - not a big surprise, I used it too on a similar drive. The real surprise is the date of Stacker volume: March 23rd, 1997. While we in Romania were a little bit late to the PC Party, by 1997 we were pretty much on par with the rest of the world. Meaning a 20MB HDD still being used (in 1997, when 1GB drives were starting to appear) is rather curious. Trying to look at stacker.log reveals the first of many read errors. An attempt to make an image with my program seems doomed to fail: heads 1 and 2 give read errors on almost every sector. (This drive has 2 platters and 4 heads, numbered 0-3)
Content with not really being able to salvage much - this is merely an experiment, no big deal - I set the program to read as much as possible, just to see what happens. In the meantime I try to adjust the drive position - I just read that these drives don't like to be installed "belly-up" - when suddenly no more errors while the drive is in my hand! When I set it down again the read error messages appear again, but now there is a gap of a few tracks between errors.
That version of my program only displays errors - the idea being that I would redirect STDOUT to a file and have a log of the bad sectors. However "no news is good news" is not really the best approach here: Sometimes no news might mean the HDD interface is struggling to read. I modify the program to write both successes and failures on screen and into a separate log file and give it another try. I also increase the number of retries to 10, for good measure (from the previous 5). Another try and it's looking good: the reads succeed when I gently rock the drive perpendicular to the axis of rotation. Doing that in the unrecommended position (belly-up) seems to go even better. I'm quite convinced this isn't too good on the drive but I'm quite curious what was on it and this approach seems to be working. Should anyone want to try this please take note: I only rocked it gently! My motions were fluid, I did not knock on the drive or hit it; in fact I think that would have been disastrous.
The rocking approach proved effective. On second attempt everything was read. There were some retries but mostly whole tracks were read at once (the program first tries to read entire track; if that fails it tries each sector up to 10 times). This happened just when I was thinking of modifying the program and adding an option to only re-read the sectors that previously failed. Since everything read fine on this attempt, I'll leave that for another time. I transfer the HDD image into an emulator, start it up and...
This leaves WORK and there was a slight personal surprise. It contained the sources for a bitmap editor I developed for Bogdan's company around 1995-1996. The program was integrated with a production management system developed for a knitting company. This editor was used to draw simple sketches to be included in the production documents. The program included the editor and an Epson ESC/P graphic driver2. Aside for that there were some assembly programs writen by Bogdan for monitoring a newspaper printing press. (I remember that project, he used a rather unusual hardware interface: a modified COBRA computer)
First, the ST-225 lives up to its reputation: despite its age and relative improper storage (I suspect it got tossed from one place to another without any packing, based on its looks) it was still readable after over 20 years!
Second, I'm not sure about the reason (I suspect it has to do with slight modifications in head-to-platter distance, partially helped by the gyroscopic effect of the platters) this rocking approach proved effective with this type of drive: I tried another ST-225 with similar symptoms that was read fine with this approach. Alas, that drive was formatted (root directory and FAT are empty, however, data area isn't empty). Image kept for investigation.
Finally, keep in mind that tantalum capacitors can fail short and defects that look scary (no power, smoke etc.) could sometimes have a simple solution.
I also dismantled the power supply to test on the capacitors but almost all electrolytic capacitors inside measured fine (both in capacity and ESR). What is more, the -12V rail is regulated by a 7912 (linear regulator) so it's unlikely to have been the cause of the MB capacitor troubles.
Part two with the DOS program source (for imaging the harddrive), description of the whole procedure and a movie showing the rocking approach
should follow soon is here.
↑1 NE2000: a very common network card from the '90s. Being so common, drivers for it are almost everywhere.
↑2 Epson ESC/P: the whole application run under DOS, so the program had to generate the proper commands for that specific printer protocol and send those directly to the parallel port.