Machined latch handle arrives, ready for tapping, painting and installation; FPGA fun

MISSING LATCH ON REAR DOOR OF THE IBM 1130 FROM SYSTEM SOURCE MUSEUM

The latch on the rear cover door of the IBM 1130 has a handle that is slid up and down in its housing to latch or unlatch the door so that it can swing out, exposing the logic gates and permitting opening of the other cover door at the rear. 

The handle was broken off and missing, with no signs of any mounting bolts either. This made it difficult to open and close the door. 

I HAD DESIGNED AN ALUMINUM REPLACEMENT AND HAD IT FABBED BY XOMETRY.COM

Given the appearance and sizes I measured, I was able to design a handle that could be milled and tapped. I used a CAD program to design this and uploaded the files to a couple of CNC services. The best price and turnaround was with Xometry.com thus I placed the order.

Attachment holes needing to be tapped for 4-40 threads

Rounded edges for comfort

LATCH ARRIVES AND IS BEING FINALIZED BEFORE ATTACHMENT

It arrived, looks great, although in spite of the CAD files that showed 4-40 screw threads, I have only the hole ready to be manually cut with a hand tap. Once the threads are in place and I am sure it attaches properly, it will get a coat of gray paint to fit in with the door color scheme.

Handle in place inside the latch mechanism

BATTLING DDR3, FPGA AND VIVADO

Before I can focus too solidly on the disk drive control side of the FPGA logic I have to implement two important bits that underlie the functionality of the system - the channel with the Arduino that feeds virtual cartridge images to the FPGA and the RAM that holds the image for access and update by the disk drive. 

The mechanics of the link itself, a Serial Peripheral Interface (SPI) link, is easy. The protocol and transactions that run over that link are more complicated and will need to be debugged in concert with the Arduino side once I have enough done in the FPGA. 

The RAM I used with prior FPGA boards was SDRAM, which is treated as if it were ordinary static RAM. Very easy - provide an address, toggle some control lines and at the proper time the word you want pops out or is written. 

The new board instead has DDR3 dynamic RAM, much more complicated. The chip has a whole calibration initialization it completes at startup, it looks for temperature data so that it can adjust operation in compensation, and it requires regular refresh cycles to maintain contents. In the search for speed, the chip does its input-output in bursts of eight words, rather than reading or writing a single word. 

Fortunately, my capacity requirements are so modest compared to the chips size that I can adopt simplifying strategies. I will read or write a burst of eight words but only use one of them, the other seven are wasted space. The transfer rate and access speed of the chip is so fast that I can do this and still easily meet my speed requirements. Each word on the disk is read or written in about 30 microseconds, while the RAM is enormously faster. 

The other complication of using this RAM chip is that it drives the clock for all the logic that controls RAM, independent of the clocks used for the rest of the FPGA design. That requires me to use synchronizing devices to handle the cross clock domain issues, in this case FIFO queues with independent clocks on the two sides. 

Vivado caused quite a few headaches and acted bizarrely, adding hours to the time already wasted in learning curve. For example, the installation of the tool created a folder on Windows called Vivado Projects where my project files get stored. Turns out that some of the code in Vivado can't handle a file path with embedded spaces - such as the very name it defaulted to for the project directory. It fails in obscure ways, such that it was only through some Google searching that I found the issue. The folder is now named VivadoProjects and works just fine. 

I am starting on all the code for the FIFOs and RAM access control, after which I can finish the SPI link protocol state machines and begin testing the interaction with the Arduino. I should be able to push down a virtual cartridge file and read it back correctly, when all works properly.