Posts

Auxiliary Control Design (Part 3 of 3)

Image
This is the last post in a mini-series of three covering the design of the auxiliary control unit which will ease entering and inspecting programs in the computer's memory. In my last post I covered the design of the auxiliary clock which resulted in the following schematic:


... which generates the following timing pulses ...
This post covers the last part of the puzzle which is designing the control logic that will take the pulses above and use them to drive the appropriate control lines at the right time according to the instruction the user requested as follows:


OK, let's get started ... first thing I want to do is start the auxiliary clock whenever an instruction is requested via the user flicking one of the primary switches. That's easy enough ... just activate the AUX-START line shown in the schematic above ... but ... we mustn't back-feed any of the other instruction types so some diodes are needed:


Next we can add the control logic for 'LOAD ADDRESS' wh…

Auxiliary Control Design (Part 2 of 3)

Image
In my last post I made a start on the auxiliary control design which once completed will make it much easier to load instructions in to memory - effectively it's a computer within a computer. If you haven't read my previous post then it's definitely worth doing so as this post picks up where that one left off. As a reminder though we're looking to perform the following operations:
... which can be derived from the following pulses ...
To make those pulses though we're going to need a clock signal (which is shown in red in the diagrams above). In the main computer the timing signal drives the sequencer and it's from there where the pulses are then derived. As mentioned in my last post it turns out that we can take a shortcut and do without a sequencer in this case but to explain why I'll need to start with how you make a clock signal out of relays ... well, relays and a few other components. Be warned though, this is going to be one of my longest posts yet a…

Auxiliary Control Design (Part 1 of 3)

Image
My relay computer is now at the point where it can execute a program in memory without assistance. In order to do that though, of course, the program needs to be loaded into memory in the first place and at the moment that's a bit of a pain. For each line of the program you need to set the primary data switches to match the desired 'opcode', gate the switches to the data bus, gate the program counter to the address bus, gate the data bus to the memory and then write to the memory - that's four buttons to press simultaneously. Once that's done the program counter needs advancing ready for the next line of the program via holding the select PC and load INC buttons followed by select INC and load PC. This cycle is repeated for each line of the program until it's all loaded into memory. Like I said, it's a pain and there must be a better way to do this.

Fortunately I don't have to look too far for inspiration of how to simplify loading programs. Effectively…

Fetch and Increment - Construction and Test

Image
This is a bit of a landmark moment ... at least for the construction of my relay computer. For a long time now my blog posts have been leading up to the point where my computer will execute a program in memory without any further input from the user. Well, it's this post where that finally happens and all that stands in the way is a tweak to the sequencer and an addition to the controller unit. Here I'll just stick to the pictures (and a video of course) but the design of the sequencer/controller changes is covered in this previous post.

Right, let's start with the sequencer. We need to pull off two new pulses (A and B) from the 8-cycle finite state machine and with the changes in place the sequencer now looks like this:



You'll be forgiven for not spotting the changes straight away (doubly so if you've not been following my blog). The sequencer gains two LEDs to show the new pulses (on the lower card) but other than that it's just wire links. The two cards clos…

Incrementer Test

Image
In my last two posts I covered the construction of the upper and lower incrementer cards. The lower card is a 16-bit half adder and the upper card is a 16-bit register. Together they form the incrementer unit as a whole which can add one to whichever value is currently on the address bus and then hold that value ready for pushing back out to the address bus. More often than not the incrementer will be used to push the program counter on one place but in theory it can be used to increment any value put on the address bus.

Here are the two incrementer cards side-by-side:



... and when stacked together they look like this ...



As in my other 'completion' blog posts I've put together a video which gives an overview of the incrementer and shows it in use:


With the incrementer unit now complete we're incredibly close to a computer that can step through a program held in memory. The last step is to update the sequencer and control units to implement the fetch and load cycle. Th…

Incrementer Construction (Part 2 of 2)

Image
In my last post I covered the construction of the lower incrementer card which is effectively a 16-bit half adder. This time I'm going to cover constructing the upper card of the incrementer which is a 16-bit register that can hold on to the incremented value before pushing it back out to the address bus.

The backplane connectors and LEDs were soldered down in my last post but there's plenty more soldering to do. First up I can add the relay sockets, wire wrap posts and card interconnect wrap posts:


This time around I haven't soldered on the stacking header that connects the two cards together just yet as I've found it gets in the way when wire wrapping or can be damaged if I'm not careful. I'll solder this on just before I bring the two cards together to form the incrementer unit as a whole.

Next up I can solder down the ground and power rails on the back of the card:


Nothing too unusual here besides there being quite a lot of relays on this card and conseque…