Sunday, December 4, 2016

New driver board seems to be working properly; built logic to write an entire cartridge in one transaction


Today I switched back to testing the new driver role board, since the logic analyzer connections and setup are mostly intact. The goal is to verify that the unit with the new board still seeks, reads and writes correctly.

I verified that the SelectUnit1 signal works, in that the drive won't turn on FileReady or ReadyToSRW unless I am selecting it, nor will it respond to commands. I also stepped it through the binary powers of cylinder address to verify that each Trackxx signal is correctly wired. I watched the heads move to the commanded values 1, 2, 4 . . . 128

Next up, I did a read of Cylinder 0, Head 0, Sector 0 which completed reporting no detected checksum errors. I also did a ReadEntireCartridge transaction and watched it walk through all the sectors, retrying on those that have problematic signals with intermittent or permanent checksum errors.

All the above looked good and I monitored the WriteGate to be sure we weren't turning this on inadvertently. It is time to capture the cartridge image as a test of the recovered data images, comparing it to the bitsavers archive version and to previous recorded images. If that passes muster, the final test is to write a sector from RAM and verify that it is read back properly; the board will be fully tested.

The captured disk image and checksum information was captured and then compared to the archived versions to see whether we seemed to be more or less reading properly. The results were quite good, similar to what I experienced with the original board.

The final test, therefore, will be to load a specific sector's contents into RAM, write it to the disk, and then read it back to verify that this works. I will undertake this tomorrow.

I did want to create a WriteEntireCartridge function, analogous to the ReadEntireCartridge but that writes an archived pack image downloaded into RAM onto a blank or scratch cartridge. We have various images from archives that it would be great to have on a disk, such as the Smalltalk system.

In most cases, we will just use the disk emulator role and not need a physical cartridge, but there is something satisfying about running the Alto from a real disk. This cartridge writing function will be a tool used only a few times, invoked as transaction code 5.  Testing will be difficult, as I need a known blank or sacrificial cartridge.

The logic was completed and synthesized, using the ReadEntireCartridge logic as a template, so that it has decent chances of working correctly on the first try, but can't try it until I have a sacrificial cartridge installed. 


  1. Hi,

    I love following your work even it is way above my head most times. Thank you for doing and sharing it!

    Writing to these valuable disks with new hardware and code is scary. I don't think I'd find the courage :-).

    Could you use another board in the disk emulator role as target for your WriteEntireCartridge tests?


  2. I would need an emulator board and another fpga board, but this is an excellent idea. It would lower the risk.

    The way the WriteEntireCartridge process works is to set the cylinder, head and sector, then fire off the well debugged WriteSector process, looping through this incrementing the address from 0,0,0 to the end of the cartridge.

    The risks when testing this would be writing to the wrong address or stalling partway through, but the logic to write an entire sector correctly is already debugged and workign correclty.