Testing emulator role

ALTO DISK TOOL

I have built three disk driver role PCBs, bench tested them but decided to run them with the tool and disk drive to be sure they all are working up to snuff. Serial numbers 1 and 2 worked fine, but number 3 didn't perform the ReadEntireCartridge transaction when I pushed the button. Back to the bench for more testing.

Next up is testing and completion of the disk emulator role, which uses a different emulator role PCB to interface the signals to the FPGA. The boards themselves provide a hardwired two bit 'type' signal that informs the FPGA which board is plugged in.

My 40 pin IDC connector on the end of the Alto to tool cable came off, because I didn't secure it well enough. In addition to attaching a new connector on that, I am building another Diablo to tool connector with a connector, for use on the copy of everything I built for Al Kossow to use in archiving various media held at the CHM.

The ribbon cables used with the Alto have a ground plane bonded to the back of the cable, consisting of a fine wire mesh the width of the cable and a rubber cover. To attach IDC connectors, I have to first peel the rubber backing away, then remove the mesh wire ground plane, and trim the sides to fit into the connector.

Ribbon cable with mesh sandwiched underneath by rubber layer

I spent the afternoon thinking through how I might test the emulator role, given that I didn't have an actual ALTO computer on hand. Along with injection of test signals in specific sequences, I had to plan for monitoring various internal states on the logic analyzer which means that the signals must be brought out to the connectors on the FPGA board.

Fortunately, testing the read capability of the emulator is pretty simple. The tool operates by simulating the rotation of the disk cartridge at the same rates that exist on the physical drive. This means it emits the SectorMark and SectorNumber signals as they would occur. In addition, it is reading the RAM contents for the sectors on the current cylinder and head, giving a serial bit stream as it would appear on a real drive.

Thus, as long as ReadGate is asserted, I should see the entire track streaming cyclically from the ReadData and ReadClock signals I generate. I just have to capture them and compare them to the downloaded disk cartridge contents and the expected behavior. The logic analyzer can show me if the data bits are arriving when they should in relationship to the simulated rotation.

Thus, simply by holding ReadGate and SelectUnit1 on, I can verify the emitted stream that the Alto disk controller will use to read sectors when it wishes to. Seeking and writing behavior will be more complicated to validate.

For seeks, a drive and its controller have a specified 'dance' to perform, signals offered in prescribed order with tightly defined durations and spacing. This means that my test methods must handle the CylinderNumber, Head, and Strobe lines in the required patterns and watch for the return signals from the emulator that acknowledge receipt and indicate completion of the seek operation.

Writing is an activity where the disk controller in the Alto would assert WriteGate and EraseGate, then emit pulses on WriteData&Clock to properly record magnetic flux changes on the right area of the disk track. My emulator should strip out the data from the clock and write the data into RAM at the proper location for the cylinder, head, sector and record.

I could grossly check this by downloading a known cartridge image into FPGA RAM, doing a 'write' of some alternative content for the sector, then upload the RAM to verify what was changed in RAM. There are three possible ways that the Alto will do writing: entire sector, data record of a sector only, or data and label record of the sector.

The first of the three is easy, as the data coming in to the emulator fully replaces the contents of the RAM for that sector number. The other two must be reading the record(s) that are not replaced from RAM, then switch to write the subsequent record(s) when WriteGate switches on.

The disk controller won't turn on WriteGate until the gap between the unchanged records and the following ones, thus the timing of what I produce to test this must be accurate. It must be at the proper time relative to the stream coming in from ReadData, ReadClock and SectorMark.

Thus, the update style writes will be the hardest to prove out in the absence of a real Alto to drive the tool. If I can validate everything else, I will then work on the complex testing needed for the updates.