Tuesday, October 18, 2016

Read entire cartridge works, file produced as desired


My address incrementing during the ReadEntireCartridge transaction is working properly and the stall condition is fixed now that the sector matching FSM is always producing results. At worst, we will miss one rotation of the disk rather than stall.

I am now verifying the addresses being used to write extracted words to RAM, to be sure my changes that reverse word order and that use concatenation instead of addition/subtraction are all working properly.

I am setting up the proper addresses to the ReadField transaction, based on what I see from the logic analyzer trace, but now I need to zoom in on the memory addresses going to the RAM access FSM to be sure that the decrementing makes sense and addresses are proper.

I ran tests after lunch, found a few defects and pressed on. Eventually, I noticed three odd things. First, I saw two cycles of the memory request trigger signal in some cases, one cycle in others. Second, the logic analyzer only captured 10 or so memory writes in a sector, then it failed to spot others. Third, the label field in memory seemed to have written the checksum as the first word.

I needed to understand these conditions,requiring a mix of pondering, logic inspection and testing.I decided that it would be better to convert the memory access FSM and the four FSMs that call it to use an interlocked protocol - hold the request high until the memory FSM is done, then drop the request allowing the memory machine to go idle.

I completed those changes, built a bitstream and tested in the evening after dinner. It is behaving better but I still have some issues with the countdown logic. I changed some more logic, burned another half hour and tested.

I spotted another flaw in my logic and corrected it, built a bitstream by 9PM and did my final testing of the day. Good news - it worked well. The files produced are exactly what I expect to see and match to the extent I can check random sectors to the xmsmall.dsk file.

I did see some checksum error lights flickered - perhaps 1-2% of the sectors had an error. I need to build out a transaction to fetch the error bit vector into a file, allowing someone to know which sectors had problems and in what record. Potentially we can reread problem sectors several times until we get a good version of the sector.

I installed all the terminator resistors for the inbound signals from the Diablo to the fpga board, on the new second driver board I am building. I have a ribbon cable with the disk connector on one end, to which I tried to fit an IDC 40 cable connector on the other side. This type of connector should pierce the cable to make a 'vampire' connection to its intended wire.

After I pressed the connector onto the wire, I used the VOM to check the wiring connectivity to the pins of the disk connector, but quickly found that all pins are shorted together end to end. The plastic cable is apparently too tough for the vampire metal to cut down into, forcing it to spread as it bit into the cable and to short all adjacent connections.

I tried a second time, same result. It might be a misalignment problem, but I may have to consider replacing the entire ribbon cable. I disassembled the disk connector side but the cable connects to the PC board with three rows, not two rows, blocking me from installed an IDC40 socket.

Tried another connector to press on, but got the same result of complete shorting. I suspect I am going to have to separate the individual leads in this ribbon cable and a length of more typical cable, graft the ends together and thereby get the IDC connector on the line. 


  1. That's very satisfying, to have the whole chain work for a whole disk pack! There are a bunch more 2310-type disk packs in the collection, probably mostly from DEC systems, fewer IBM ones. (Actually doing a search on "2310" only turns up a couple of them, but I have seen many, stacks of them, at Yosemite.) Anyway, could you repackage this tool to be used by the new Digital Repository I've just been reading about?

  2. Hi David

    I could definitely modify it to generalize, with a different extension board connected for each format of media. IBM 2315 cartridges recorded on a 2310 or 1130 are different format from the Alto. Cartridges used in DEC RK05 have yet another format (actually two, 8 sector and 12 sector packs used on PDP 11 and 8). The HP 7900 is another.

    The good news is that these are all essentially the same mechanism at heart, so the interface lines are very similar, the NRZ encoding is similar, the sync word strategy is identical, thus easy to adapt the tool for all.

    I should say that IBM 5440 cartridge, the top loading single platter that replaced the 2315, is basically the same drive also, extending the applicability to Pertec, Perkin-Elmer, S/3, HP and many other maker's top load single platter drives.

    I had built most of a driver for a Pertec 5440 type drive earlier, which was good experience for building this tool, and had done some of the design work for RK-05 drives.


    1. I am building one of the tools for Al, currently just as an Alto pack system, but would be happy to work with him or others to extend this for other media at the museum