With the RAM reading all sorted out, I turned to the next challenge if we are going to capture the entire cartridge contents as a PC file. The current tool requires several mouse clicks and data entry operations to read each sector, of the 4, 872 sectors that comprise a cartridge.
There are two ways I can go at this point, either write some PC side software to drive the transactions or build a high level FSM in the fpga to cycle through the entire cartridge as a single command. Because of the time likely to be wasted on a learning curve as I set up a PC side program, I chose to design the FSM instead.
The state machine will consist of cycling through, incrementing the sector, head and cylinder numbers as it fires off 'read sector' commands. The sector number will cycle from 0 to 11 in the 'inner loop', then head number will alternate between 0 and 1 for the 'middle loop', and the cylinder number will cycle from 0 to 202 in the 'outer loop'.
Assuming the worst case wait for a sector to rotate into position, it will take about a second per cylinder. The seek will take just milliseconds, so we should be done with a cartridge read in less than four minutes.
I will use one of the slide switches to control behavior - if the switch is on, then the process will stop if we encounter a checksum error on any sector. If the switch is off, it will ignore the errors. It is possible that I could record the checksum errors in block RAM on the board and display it on the VGA port.
|Driver role, where the tool is cabled to the disk drive|
Transitions happen, reversals of the signal polarity, with clock transitions occurring once per 600 nanoseconds but transitions only occur in between the clock pulses if the data bit value is '1'. Thus I have to sync up to a train of clock transitions and detect any transitions in the middle to decide if I have a 0 or 1 bit.
|Transitions and separation of data bits|
|Emulator role, where the tool is cabled to the Alto|
The logic will also have to look for sync words, shadow the correct number of data words following, switch off again at the proper point to look for the next record's sync word, and validate against the checksum word written.
I am not in a rush to build the disk emulator role, first wishing to get the driver role fully functional for read, write and update operations. When that is accomplished, I am certain of how the emulator should work.
By late afternoon I had the bulk of the logic in place and could begin running simulations to see if I was manipulating the addresses properly and triggering 'read sector' and 'seek' transactions. I did quite a few debugging runs and made progress.