Resurrection of the 8-inch hard disk from the 80s
Storage devices are probably one of the most difficult to recover. Especially if we are talking about very outdated hard drives, such as CDC Finch. This compact 8-inch hard drive has replaced 14-inch models with a more convenient form factor. The Finch disc came out in the 1980s, saw a lot of use before it was “retired”, so it’s no surprise that it turned out on the repair stand at a friend’s [Usagi Electric].
On his YouTube channel, he talked interestingly about the recovery process, and we decided to share this story with you.
Hard drive CDC Model 9410 Introduced in the early 1980s, the Finch differed from its 14-inch predecessors in that it was a sealed, air-filtered unit and thus required no maintenance. In the 14-inch models, they did not bother much about dust protection, so Finch showed itself much better in work. And, of course, such disks are much more fun to repair.
Here we will disassemble two Finch disks with different failures. Both seem to have a problem with the controller board, one is not responding to calls via the interface and the other has a short on the pins. The first drive was brought back to life by replacing the dead SN75 110 line driver chip, and the sudden death of the 7818 voltage regulator, which was putting out a miserable 0.3V.
Spoiler: Unfortunately, after half an hour of trouble-free operation in the data reset process, the drive gave a Not Ready message, indicating that there are additional problems on the controller board that need to be fixed. The good news is that the boards seem pretty reliable, but on older drives they tend to deteriorate over time.
How the repair was carried out
The fact that both discs are broken in different ways is very good for us. This means that they can be used for cross-referencing as, apart from the number of discs, they are virtually identical. The 32 megabyte drive starts up, runs a self-test and then stops at track zero waiting for commands from the controller card and is ready to send data, but the controller card doesn’t actually see the drive. And the second drive does not turn on at all due to a short circuit on the 5-volt bus.
Most likely, the problem is a faulty line driver chip. Oscilloscope snapshots show that the differential signal is not differential at all. That is, pins that should be opposite are actually in phase, so the actual signal that Finch receives from the Centurion is incorrect. He believes that there is no reason.
So, the first step is to replace the SN 75110, and then we will do some additional testing on the Centurion to see if it works. We take a soldering iron and change the chip to a new one.
We have a diagnostic card with auxiliary test menus that ran the detection test but never the read test. So let’s run the discovery test and then the read test. It would be nice if everything worked right away, but it’s never easy with CDC drives. Well, let’s try. After that, you can check that the actuators are working and then start working.
The drive starts and passes a self-test … Everything seems to be fine, so let’s run the track search test. The heads move smoothly. Now press Ctrl+C, this should return us to track zero and the test will pass. So, okay, we’re back to where we were before.
Now you can move on to more complex tests that offer more control. We found a lot of interesting things there. Unlike other discs, the furthest track in Finch is zero. When you do a return to track zero (RTZ), it always goes to the inner track and when you explicitly tell it to go to track zero, it also goes to the inner track. It’s a little strange, but it doesn’t really matter. The main thing is that we have a zero track. However, we don’t get any data from it, so the test always fails.
Interestingly, when the test fails, all signals remain active, so the drive continues to act as if it has been selected and is trying to transmit data. So we can check multiple signals in this state. First, we can check the index signal, which is one of the most important. It can come from the cable and is on pin 20. We have an index signal that runs at 60Hz and that’s good. Next, we want to make sure that the “drive ready” signal is low, and that would be pin 22, which actually has a low signal. Now we can check the servo signal. It’s a differential signal so it’s hard to check with an oscilloscope, but we should see something on pins 15 and 16.
We see a weak signal with an amplitude of about 1 volt, since it is a differential signal, the amplitude becomes 2 volts, this is correct. So the drive is ready to go, we have a good servo signal, but no data. We can test this on pins 18 and 19. Again a differential signal, but if we test it, we won’t have any data at the output. At first it seemed to be a “Finch” problem, but people who understand the topic advised to check another signal – read enable. The FFC (Floppy Formatter Controller) will see the index signal, see the servo clock signal and say “Hey Finch, turn on the read permission so I can start getting data”. If read permission is not enabled, Finch will not output data because it will assume that the data is input-directed.
So, the read enable is the 4th pin on the command cable. And if we look, the signal on this pin is always high, the Beat Enable is never activated, and the read enable state must be low for data to start flowing to the output. So we are faced with an interesting situation, Finch itself is probably fine, and the problem may be with FFC.
The next step will be to unplug this whole farm to pull out the FFC, put it on an extender card, support it in some way, and start exploring. How you don’t want to do it…
And here masaka on discord suggested a brilliant idea: why not just use one of the other Finch ports? The FFC has four ports and supports one floppy drive and up to three Finch drives. If the Finch is perfectly fine and we have a problem with the receiving chip on the FFC, the other port may be perfectly fine. When port number three came into play, both drives worked. Now you can run the read test and see what happens.
Press R for the read test, select disk zero, low track and high track, and then press enter. You can hear how the drive is looking for the right track, and the search test is successfully passed!
There is only one thing left – to enter the OS and see what it thinks about the drive. We enter “H1” in the command line to load the OS, we should see a value of “Max disk” other than 1. Unfortunately, it did not work. Most likely, two more Finch drives need to be added. Let’s go to the system configuration utility (sysgen). The name of our configuration is OSN, the disk number is 1. We enter the settings of disk drives, there are already settings for a disk and one Finch drive, then we will add two Finch drives. Now we have drives 0, 1, 2, 3, 4 and 5 and that should be enough for the OS to see them. Exit the program by pressing ctrl+B and “end program”. OK, now we reboot again, press the load opposite button, enter H1. Now a number other than 1 should appear. Oh, we’re in the OS! CRT 0. Let’s try to enter “DOT sta” and “foreign”. OMG it works!
Well, it turns out that the drive, which was thought to be broken for so many years, had a problem with the FFC controller! There are so many files on it, so much information… We need to save them somehow. First, it was decided to back up the files from the “zoa” folder. Somewhere on page 3, in the middle of the backup, something went wrong. An NR Disk5 error occurred.
The heads are unlikely to be damaged. If we take an oscilloscope, we will see a pure indicator signal and pure clock signals, which are from the data cable. However, this indicator signal never reaches the control cable where the FFC will read it. The point is that the disk ready signal never goes low. Apparently, some IC on the Finch board has failed, and the disk is not ready to work. Looks like our Finch Drive is hacked again.
So we know there’s good data on disk, we know there’s some source code we definitely need to keep, the rest isn’t particularly important, but it would be nice to have a backup.
In any case, we need to get this drive working again.
The author of the video plans to gradually analyze the situation and in the future try to perform reverse engineering to find out why the disk does not work. The plan is to return to full capacity not for 30 minutes, but steadily.
