Resolved one anomaly and digging into the other, in the Alto disk tool

ALTO DISK TOOL

My first test today was to measure the clock frequency directly. It runs at roughly 45.5 MHz which gives a clock duration of about 22.2 ns. This accounts for the timing discrepancy. Time to figure out a more accurate timing method.

One possible complication is that different FPGA boards might run at other frequencies, so that a correction made to fit the board I am testing here might not work properly on a different board at Marc's house or one used by Al Kossow.

My solution is to use the external oscillator socket on the boards, plugging in some new 50MHz oscillator modules I am buying from Digikey. These are accurate to 30 ppm, which locks the frequency to within 1.5K of the target. I have no idea why my board is off so much but the tool must operate very close to the target in order to drive the disk properly.

I then set up the logic analyzer, which is a tedious effort, in order to watch the checksum calculation to determine what is throwing my written checksum off. The initial setup had some problem seeing a reliable clock pulse, so I reconfigured the fpga to output the clock on a different type of output pin, requiring a 40 minute turnaround of the toolchain.

I watch the checksum flip from its correct value to a wrong one - not sure where things are in the overall flow but emitting helpful signals will be the focus on the next round of changes. It appears that the seed is set properly as 0x0151 but the next word ORed in is 0x8342 which doesn't exist in the sector image.

My first record should stay with the checksum 0x0151 since the two data words are both 0x0000 and that doesn't alter the checksum. The second record would be seeded with 0x0151 and then OR in the eighth word of the label, 0x0079 which would produce a new checksum of 0x0128

Until I can know where we are in the process - which record and what 'word time' - I didn't have enough of a clue to spot the flaw. 40 to 60 minutes later, I was ready to test again. The checksum goes awry right away with the header record, first data word being handled.

The proper data is being written to the disk, but somehow the checksum isn't updated with that data. I will map out the FSM that writes the record to the disk, looking carefully at how the checksum is handled.