Have matching board sets for Alto, debugging read sector operation on real disk drive

ALTO II RESTORATION

Our working hypothesis for our current problem with the Alto is that our CRAM board is mismatched with our Control board - having a 1K CRAM but a control board that is 2K wired with a 3K engineering change. 

Al Kossow loaned us four 3K CRAM and 3K Control board sets, plus some spare PROMs for the control boards. We are pretty certain to have a properly working and matching pair, which should resolve our current problem.

The Alto fails whenever a program tries to execute microcode that was written into the CRAM, because the mode switch from ROM to RAM fails to take. This is due to a grounding of the control pulse as it travels over a cable between the two cards. We suspect that the 1K CRAM board has the pin grounded that would be used to accept the signal on a 3K board. 

ALTO DISK TOOL

Today I cleaned up some signals, wired up the logic analyzer and began collecting traces to debug the disk tool executing its 'read sector' transaction. When I run the 'read entire cartridge' transaction, it stalls at some random cylinder location, apparently because the seek didn't complete properly in my state machine.

The first look at the data being captured looks plausible, but frankly until I look more closely I won't be certain. Ideally I would have a known data pattern to match. The good news is the repeatability of the data that is captured, but it has to be the actual data.

I completed the wiring of the logic analyzer signals to the fpga board so that I can look more granularly at the behavior of the 'read sector' FSM. I am slogging through the states checking that things are occurring as I expect.

With only 4K entries in the logic analyzer, each snapshot at 50ns intervals, I can only see 200 microseconds of activity. A single sector read occurs over 3,333 microseconds. I need to be extremely clever in triggering conditions to spot the portion of the read that I want.

I worked until the evening, without spotting any obvious problems but I know I have conditions where a 'read sector' will stall and of course the stalls that happen trying to read an entire cartridge in one transaction.

This portion of the testing will focus on glitches, race hazards and other situations that can cause my logic to malfunction. I entered this with logic that worked properly with the built-in pattern generator, but that delivers pulses with a orderliness that doesn't exist on a real disk drive. Erratic timing is what can bring out the latent defects.