Saturday, October 22, 2016

Mod made to Diablo disk, no change in error rate, board wiring completed


I completed the modifications to the Diablo drive, such that its short and long times are now 440 ns and 460 ns, in compensation for the 'overclocking' done by Xerox Alto computers when writing 10% above the Diablo factory spec.

I ran the ReadEntireCartridge function again, both with and without the auto-retry on checksum errors, and got essentially the same results. I had opened the cartridge, inspected both platter surfaces, cleaned the disk and also cleaned the Diablo drive heads.

There remains the possibility that this drive and the one that originally wrote the data are not aligned exactly the same. The practice with drives of this era was to use a special "CE" cartridge and an oscilloscope to adjust the arm positioning of every drive, thereby hoping that two things that are closely aligned to a third thing would be closely aligned to each other.

If each adjustment is off by 1%, the two drives could be 2% different in the worst case. With the track positioning of .01" and a guard band between recorded tracks of .003" it wouldn't take much misalignment to have the head reading near the edge of a track rather than directly over the recorded signal.

This suggests to me that we may not be able to retrieve every sector of every cartridge perfectly, instead settling for > 99%. Another factor to consider is the weak error detection mechanism used, a simple XOR checksum which means any even number of bit errors in a 'column', e.g. modulo 16 in the bitstream, would falsely pass the checksum test.

Since the raw rate - a single read of each sector - hit a bit over 6%, but was dropped to 0.6% by retrying any bad sector up to 31 times, we may have errors in content that are misreported as good sectors.

This weakness in checksum strength was a fact of life with the Alto. Every time a user ran the system, they faced the chance that multiple bit errors would slip under the radar and deliver bad data to the user.

I worked further on the new disk driver board, such that by midafternoon I had only 7 fpga signals left to wire before I do the extensive checkout. At dinnertime, the entire board was wired and I went through a connectivity and shorts test. Everything checked out, so it is time for a function test tomorrow. 

1 comment:

  1. The two saving graces are: 1) The bad sectors may not be in use and 2) there may be another disk with the same data and not the same bad sectors.