Removed and began to clean the Pertec head, got SAC Interface fpga board back in operation to resume debugging of logic

PERTEC D3422 DRIVE RESTORATION

I pulled the bad head out of the drive to see what it looked like. It was quite ugly but the material on the head looks suspiciously like it was a bit of gooey insulation that lurked somewhere in the machine and finally made its way out into the gap between head and disk.

Disk head after removal from drive, post-crash

The ceramic 'slider' of the head appears bright and shiny after I have the head substantially cleaned, whereas a hard particle like grit would have cut lines into the surface. However, until I have 100% of the contaminant off the head I can't determine if it is free of scratches or projections.

First pass cleaning material off head 

I applied 99% isopropyl alcohol with low-lint swabs and pads, which removed layers of the surface junk - much like the insulation itself for which IPA is not a good solvent. It took many passes with swabs and pads to get it as far as I have; the mini-flood of IPA on each pass loosens a bit more of the top layer of the crud and allows it to be pushed off.

After quite a few additional passes, getting closer to clean

I am comparing it to the existing heads that were not crashed but will also look with a microscope to check for fine scratches especially anything that sticks up and disturbs airflow. The small slit where the read and erase head poles stick up is the likely spot for such damage, although the two round holes which maintain flying height could also get damage on their rim.

In a very interesting coincidence, about four months ago I saw an auction for a used disk head which appeared in good condition and might have been suitable for repair of the Diablo drive I also own. It was actually a head for a Pertec D3000 series drive, something that meant nothing to me at the time.

I know from the marking that it is a 2400RPM version (higher bit rate/frequency) but don't know if it is compatible in the other key metrics - bits per inch along the circumference of the track and tracks per inch radially from the hub. It won't help in this case, as it is a bottom head while I crashed my top head. Still, I thought I would mention the unexpected connection.

Crashed head on left, Pertec head from eBay on right

I found a Memorex head that is extremely similar looking on ebay, but it is for a 100tpi, 100bpi, 2400 rpm drive so it won't work. The most critical is the tracks per inch, which reflects the width of the recorded signal. The Pertec drive writes and reads tracks that are half as wide, requiring a narrower pole, thus this head would stomp on adjacent tracks anytime it wrote.

My testing setup, scoping successful read - prior to head crash

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I sorted out the problems - it required me to make a new version of the firmware to run on the 8051 processor embedded in the Cypress EZ-USB module on the ztex fpga board - one that implemented my two high speed ports for transfer between PC and FPGA, but also supported automatic load of a bitstream file in the fpga on power-up. Works now, so I am back in business debugging my interface.

First test involved loading the standalone disk cartridge initialization program (DCIP) into memory using the file on the PC of the memory image. My code flashed the lights loading up storage but I found during the verify pass that at least one of the words had a bit dropped.  I will look through my fpga code to ensure adequate setup and hold times for the addressing lines to the 1130, but also scan the Python program to be sure I am not inducing the problem here.

I will also figure out some instrumentation that I can watch on LEDs and scope, from the sixteen signals I can output for diagnostic purposes. Since my protocol returns the values that I received back to the Python program, which checks that the fpga got a request to store a specific value in memory and that the value matches what was sent, the issue is almost certain to lie in the fpga side logic.

I thought I found a race condition in the cycle steal fetch and store logic, which I removed by changing the FSM sequencing, although the odds of it happening were too low to account for this error. With that changed, I brought the PCs and new bitstream outside to do another test.

What suddenly occurred to me is that it never set bit 12 of the memory location - the location was always zero. This threw the spotlight of suspicion on the hardware itself - my driver for the Channel Data Out register bit 12 or a defect in the 1130 side receiving cards or a cabling/connector issue. The scope became my means of diagnosis - triggering on the output from the fpga to my driver chips, recording what happened on the output pin of the driver when I triggered its input.

The test showed me that I had an intermittent connection, which I found and repaired. The next test
showed a different garble pattern, which I began researching. Darned fragile connections on the board with the drivers! Now it was bit 6 that was awol but soon the machine was reliably loading whatever I wanted into memory and verifying the contents by using CS fetch to read it all later.

I expected to be able to run the DCIP utility at this point, getting output on the console typewriter, but it just looped. Not sure if I have the procedure wrong, but that is a separate and less important test. I will go on now to testing my virtual 2501 card reader logic, which is the next most important function for this interface box.

In scanning quickly at the operating instructions for DCIP, I noticed a comment that said that the typewriter is used if the printer is not ready, but I didn't have the 1132 cabled so it probably appeared ready. The program was probably looping trying to write on the printer. I gave it a try tonight, a quick test to see if I was right, but it still looped. I could be looking for a 1403 printer rather than the 1132 - I have no idea what this particular memory image does.