Tuesday, August 4, 2015

Head crash cuts short my testing of the Pertec controller


I cleaned up some of the CRC generation design but was still testing as of the end of lunch today. I first have to reconcile what I am seeing - to generate the same CRC value as I am retrieving from the disk - before I am sure that the generation logic is sound.

After quite a bit of struggling, I realized that somehow they injected the sync byte into the CRC generator. If I start with just the header fields (two bytes of cylinder number and one of combined head/sector) the CRC comes out wrong, but if I start with the 0xFF sync byte before the three header bytes, I come up with the same CRC value as was stored on the disk.

The therefore don't really check for a sync byte, the controller treats the first non-zero bit as the start of the sync byte and just stuffs that all into the CRC generator. If it was a spurious one bit inside the preamble, the CRC won't match thus this is not risky, but it makes my synchronizing logic wrong or I would need to go inject a pseudo sync byte into the generator myself.

However, I did come up with a solution that is simple - I can change my CRC generator module so that a master reset sets up the register values equivalent to having processed the sync byte, rather than to all zeroes. That way, my existing logic can feed the three header bytes through and get to the same CRC value. This is what I did. Interestingly, that is a value of 0x4040.

Test setup for disk controller (center) and drive (on left)
While I was testing, I suddenly heard the motor slow down ever so slightly, followed about a minute later by a slight scraping sound which I suspected was a head crash. When I pulled the removable cartridge out, I could see the scraping line where the interference was occurring and can see a bit of the oxide trailing on the head. Oh well. I won't be doing any more testing for a while. Not sure how bad the impact was - might be repairable with a cleaning but likely the pack is toast even if the head is cleaned perfectly.


  1. Oh man... that sucks. Doesn't the disk drive know this is 2015 and head crashes almost never happen any more? Grr....

  2. (The drive probably wears really wide ties too....)

  3. If you initialize a CRC check with all zeros, you don't detect leading zeros, or the lack of leading zeros. Many initialize to all 1's to avoid that, but it looks like yours has a different solution.

  4. The logic starts in a state that is skipping over a continual string of zeroes, until the first 1 bit arrives. The CRC was initialized to zeroes so that the generator ignores all the preamble bits until the first 1 bit hits. That is the sync bit, although to set up byte boundaries, there is a whole byte of 1s recorded. The CRC begins right where the 0xFF arrives and continues for the known number of bytes. This is how it deals with leading zeroes - an initial state that requires some minimum number of zero bits in a row.