Pertec drive fpga controller reading sectors properly, implementing CRC error checking. News from the 1800 restoration

1800 SYSTEM RESTORATION IN FINLAND

The man restoring an 1800 system has set up the machines and cleaned them extremely well. He is debating what steps to take next and we are chatting about options and decisions he wants to make.

The part of the system he intends to restore - 1800 system plus 2311 disk drive

Panel of the IBM 1800

He has some decisions to make about the condition of the 2311 disk drive. The heads are attached to a springy rectangular strip that is microwelded to the arm itself. A couple of the heads show the rectangular strip at an odd angle which might indicate that the welds had broken. Too hard to tell from here.

2311 disk arm assembly with heads barely visible

View of the heads with possible weld failures on the heads

PERTEC D3422 DRIVE RESTORATION

Once I was consistently reading the contents into the FIFO and able to step through the contents with my controller logic, it was time to add in the CRC calculation and error checking. Knowing whether all the data is correct or whether my head position is off enough to be causing bit errors will be guide me in what I need to do as I continue the restoration and build-out of my controller logic.

My tests in the morning were successful, thus it was time to work on the CRC function. The Fairchild chip used with the Altair controller has several CRC polynomials, depending on the value set in three control bits. I looked at the controller schematics to see if those three values were hard wired.

They were all pulled to ground, which implements a CRC-16 polynomial method. The data sheet gave an equivalent circuit, which allowed me to implement this in the fpga easily. I then whipped up the circuitry to steer the relevant data through the circuit and make the error checks.

Using it for reading required a state machine that would pump the three header bytes into the generator, then push through the 16 CRC bits and finally determine if there is an error based on whether the residual in the 16 bit internal register of the generator is zero (data passes check) or not. Following that, it has to reset the generator, pump 256 bytes worth of data field bits through the generator, then push in the two CRC bytes and at the end check to be sure the residual is zero.

Writing rather than reading involves an easy modification of the behavior. After pushing the three bytes for the header into the generator, a control flag is flipped and we shift out the CRC bytes instead of sending in the prerecorded value of a sector that was read. We skip the error check since we just generated the CRC, then do the same for the 256 bytes of the data field, flipping the control flag to clock out the resultant 16 bit CRC. Our write logic will take the shifted-out CRC and write it as the last two bytes of both header and data fields.

I whipped up the logic and tested it in the late afternoon. I have a few nits to deal with, such as that my FIFO display is off by one - I get an extraneous byte of 0x00 first. My +5V Timer Board does something odd when I power on and push the Start/Stop button - it seems to be running the timer but shouldn't. More seriously, the CRC state machine is stalled somewhere - I think it is very early in its logic since I don't see any sign that the CRC generator register is turning on any bits. This will take some debugging work.

Since I have a friend visiting from the UK tonight and had my daughter hear this morning, I have run out of time for work on the system today.