At this point when I reset the Baby Baby it loaded a “Slider” program into main store. This continually moves the data in the bottom 1/3 of the store to the right. If a bit pattern than looks like “text” or a low definition graphics image is stored in this lines it appears to “slide” across the machine. Typically, at MSI a program containing the word “BABY” in those lines is used, although there are others with Boats, Trains and Christmas Trees. I know wanted to test the computer so needed to load additional programs.

When I started on the project my intentions were to write some kind of “Serial Loader” as the Nexys2 board has a serial port on it. However, I am lazy and this would have needed a program producing for the PC, a protocol inventing, and VHDL code writing and testing for the FPGA so I wondered if there was a simpler way that was less work.

I knew that at MOSI the replica can be loaded from a PC. After reading the Baby documentation on the Volunteers web site:-

http://www.cs.man.ac.uk/CCS/SSEM/volunteers/index.html

I decided it might be easier to load programs in the same way as at MOSI. The interface is somewhat ingenious. Williams Tubes are dynamic and so need to be continually refreshed. The PC interface sits in the refresh loop and so over one refresh period sees all the data on the main Store tube. In addition, it can over-write the store by replacing the data as its “refreshed” so on the fly.

It uses a Turbo Pascal program on a Windows/95 PC which interfaces directly to the printer port. The program counts the bits and words as the store is refreshed and if a “download” is in progress it over writes them as needed.

In order to work with this interface, I needed to change the way the clocks were generated in the FPGA. The code at this point generated the “Beats” directly from the 50Mhz FPGA clock, so the only CPU clock signals in the FPGA were the 360 micro-second pulses that it uses to generate each of the four phases of an instruction.

I had to add a 10 micro-second “dot” clock which is the rate at which the Williams tubes are refreshed, and so the rate at which the PC expects to send and receive data. I then used this to generate the 360 microsecond pulses that run control Instruction Execution.

As the data from the PC is synchronised to the Baby Refresh Count I also needed to implement this in the FPGA so it knew where to write data.

Lastly there was an issue with voltage levels. The FPGA is 3.3V and whilst the outputs will drive the TTL in the PC Printer interface, the signals from the PC interface must have 330 Ohm current limiting resisters adding to prevent over load.

After some “hacks” and tweaking of the FPGA code I manged to get the interface working. I tested it using an old Digital VP575 running Windows/95, first reading from the Baby Baby and later writing to it…

.. and after some tweaking I could now load arbitary programs into the Baby Baby…