Wiring new board, creating checksum status upload function, issue with track 0

Today is the day I spend with the 1401 restoration team at CHM. Everything was working well, so I left early and returned to work on the disk tool.

ALTO DISK TOOL

I built up a wiring plan for the new disk driver role extension board, the one that will go to Al Kossow for use in archiving Alto cartridges. This involved signal assignments to various level shifter components and careful recording of the IDC40 pins for each signal.

I am more and more convinced that I need an easy way to display or extract the checksum error status bits that reflect whether a checksum verifiction error occured in each of the three records in each of the sectors. With 4, 872 sectors and three records apiece, it is far more information that I can readily display with the LEDs and seven-segment displays on the fpga board.

I had hoped to record some of the status on the VGA display, although even here there is no reasonable way to display 14, 616 separate status bits on a single screen, yet be able to see where the errors occured.

With 8 lights per seven-segment display, four digits of those, and eight separate LEDs, I could display only 40 bits of data at a time, needing to cycle through that 366 times to see the entire cartridge results.

I have a switch option to stop on the first error during the ReadEntireCartridge function, allowing me to potentially run with stops for each bad sector. I will test this right away, but I think I need a more permanent record anyhow, to go along with the extracted disk files I produce.

My test showed that the logic will stop when one or more of the checksum errors are detected, and will restart with the next sector when the transaction button is pushed again. While doing this, I discovered that some sectors that had been reading clean were now getting errors.

I found some with errors that would read good sometimes, bad sometimes. Others, including sector 0 which I have been using quite a bit, now read bad on all three records and do so consistently. Worried about the condition of the heads and platter, I shut down and inspected.

The disk platter appears superficially good, but I will disassemble it to look more thoroughly. The bottom head is easy to see and looks okay, while the top head is nearly impossible to image clearly with a camera. I applied a hand mirror and both heads look very clean.

Only three possibilities left to explain why S0 might be bad now - one is that the arm is out of alignment and increasing its deviance, which seems unlikely, the other two are that somehow the write gate is turning on and spewing zeroes over the first track, cyl 0 head 0, for all 12 sectors. The latter two may be due to procedural errors.

If it is the latter, I can rewrite the track using the stored image from bitsavers, also debugging my write sector logic, but first I have to figure out what caused the problem and prevent it from ever happening again.

I suppose it could have been procedural, when I used the Adept utility to dump memory with a method that loads its own bitstream to the fpga, overwriting what is there, and resetting the board to run that new logic. If I left the drive spinning when this happened, it could have turned on the write and erase gates, affecting the current cylinder and head.

I will piggyback on the File I/O capability of the Adept utility, adding another set of memory interface registers 16 to 22 which will read out the sector status bits, one byte per sector. I just have to copy, paste and edit the existing logic to create the new functionality. Reading the disk buffer RAM uses registers 8 to 14, with the utility set to 14, thus reading the status vector needs to set the utility to register 22 which is the corresponding mechanism.

I loaded the new bitstream with the checkbit vector upload functionality and did some testing. While I was at it, I hooked the scope to the ReadData and ReadClock lines to see what is coming in from track 0, which I suspect was erased.

The data is definitely irregular, especially the clock signal, which tells me that the track was definitely erased. I can use my WriteSector logic to restore the contents, although I am not yet ready to test that out.

The checksum bit reading logic did not appear to work on my first test, after having read the entire cartridge and observed a number of checksum error flickers on the LEDs. I fired up for another test, manually working the registers to see if the transaction appears to be working.

After a bit of debugging, I figured out the problem and created a new bitstream, but it was time for bed. Tomorrow morning I will test again and expect this to work.

Working on the new board, I ran all the +5V and +3.3V power wiring, then began on the ground wiring. I have all the input signals routed from the IDC connector to the level shifters. More tomorrow.