Ken Shirriff has put together a Python program to transform the PC files captured from my tool into the disk archive format used on bitsavers and with the Contralto simulator. This saves me from having to do the same thing and lets me focus on other tasks still required to complete the disk tool.
This morning I completed the refinement of the RAM addressing change (using asssembly of fixed strings rather than addition/subtraction) and some diagnostic outputs to allow me to watch the incrementing of cylinder, head and sector values during the ReadEntireCartridge transaction.
I had to rewire the probes to the logic analyzer to suit the major change in status signals needed to watch the address incrementing. With all that done, it was time to fire up the testbed. I did several runs.
The results were inconclusive, I need to monitor other signals first to see what it is doing during the incrementing of the registers. Of course this will cause another 30 minute pass to generate the bitstream, but at least I can eat lunch during the delay.
My addressing changes did appear to have broken the write into RAM, or stored data somewhere different, so that is another aspect to debug. The results of the new testing showed me a flaw in my ReadEntireCartridge transaction where I was not sufficiently interlocked with the lower level ReadSector and Seek FSMs.
I redesigned the high level FSM, keeping in mind that there is a one cycle delay in actions that are taken to change the Regxxxx registers including triggering low level transactions, seeing completion and resetting completion. I am working my way through debugging the new design, which is more interlocked and therefore can stall if I get things wrong.
My new interlocking ran afoul of a change I made a few days ago to allow me to reset transactions that stalled. The way I attempted to handle the reset was triggered by the operation of the ReadEntireCartridge transaction with its new interlocking.
The changes were backed out for the stall reset logic, keeping the new high level FSM design, and I spent a quick 30 minutes preparing for the last test of the evening. What I see is that I am now processing the bump of the address correctly, incrementing by one.
The stall occurs when trying to read after completing a seek. Sometimes it gets through several seeks correctly, other times it fails on the first seek. I believe that I am either failing to trigger the FSM that waits for a target sector to come under the heads, or failing to see the completion signal when the sector is matched.
I will work out an interlocking between the sector match FSM and the transactions that use it, build those into the logic tomorrow and then test. It makes sense that I will change out the diagnostic signals to the logic analyzer, in anticipation of the areas I am checking out tomorrow. I am done with testing for today.
I began constructing the driver role board for Al Kossow's version of the tool, now that I am comfortable that all the analog stuff works well for reading and archiving packs. I will make use of a ribbon cable and connector for the Alto to Diablo link that he provided to me, wiring it to the board and hooking up the fpga board he purchased.
I think I will make use of an IDE style socket, although pin 20 of the cable is used while the classic IDE socket has a blank in that position to ensure the cable is not reversed. Fortunately, I have a pure socket with 2 x 20 female positions which provides the needed pin 20 signal.
Supporting his cable means that I have to deal with the signals as they exist on the cable, which are different from the ones on my disk cable on the prototype. I went through all the documentation and decided that I had to produce 16 output signals and handle 12 input signals when using the Alto-Diablo cable.