Author: BlockWorker

Find the introduction here.

With that, the 8 Bit Computer project was essentially finished.

This was my second large electronics project, and it was a lot of fun to work on. It’s difficult to consider it “completely done” (some minor issues and optional improvements remain), but I decided I’d call it done and maybe get back to it later – though that seems to be a recurring theme with all hobby projects, at least in my experience.
Also, none of these imperfections change what this project is: A fully functional basic computer that, in my opinion, looks great, and is a nice tool to show how computers work on a basic level.

This project was designed and mostly built before I started my university education in computer science. The experience from it helped me a lot in my first computer architecture courses, as I already knew a lot of the concepts. However, there were many things that I didn’t know prior to taking those courses, and many things I’ve learned about computer architecture that I didn’t know when designing this computer. So looking back at it, there are quite a few things I would do differently if I were to start a project like this now. Still, I am proud of it and happy with how it turned out.

In the future, I may design a new computer, perhaps implementing some more advanced computer architecture features and avoiding some of the problems that I encountered and worked around in this one. Until then, I recommend everyone who’s interested to keep looking into this topic – there is much more to learn than what I’ve covered here!

Until the next project!

Find the introduction here.

With the electronics finished and working, the computer now needs to be told what to do. This is realised by implementing instructions that perform small individual tasks on the computer, like moving a value between registers or adding two numbers. These instructions can then be combined to create more complex programs.

Each of these instructions is associated with an opcode (operation code) which is used to identify the instruction in the binary program. The computer reads an opcode from memory, executes the associated instruction, then reads the next opcode, executes that, and so on. This fetch-execute cycle continues until the program ends, i.e., a special instruction tells the computer to stop executing the program.

To the programmer, the instructions are atomic, which means they are the smallest steps the program can be divided into. However, in this computer implementation, these instructions are subdivided into even smaller microinstructions (as discussed in the “Modules, Part 5” chapter). Each of these microinstructions is exactly one clock cycle long and defines the hardware control signals that should be set for the execution of the desired behaviour. For example, to read a value from memory, first the target memory address needs to be moved to the memory address register, then the value at that memory location can be read. Some of these microinstructions are also used to implement the fetch-execute cycle (read next opcode and pass it to the control logic).

To manage the programming of these instructions, I wrote an app in C# where you can define the control signals that exist in the computer, use them to program instructions out of microinstructions/steps, and use those instructions to write programs that can run on the computer:

The instructions and programs can then be written to instruction ROM or computer RAM, respectively, using an Arduino (which is controlled from this same app).

With this, you can program the computer to do essentially anything that it’s physically capable of with the provided hardware. The program shown in the third screenshot above prints “Hello World!” to the LCD screen (bottom left). Here is a video of it running:

To avoid waiting too long for the message to appear, the program is running too quickly for the human eye (tens of clock cycles per second), so you can’t really see the individual instructions running – but it is rather spectacular to watch the control signals (white LEDs) going crazy! If you look closely, you can see the “HLT” LED at the right light up pink at the end – this is the “halt” signal that tells the computer to stop running when the program is done.

So with that, we have a working and programmable computer! In the final post for this project, I will discuss the end result and give an outlook of what may come next.

Find the introduction here.

In the previous posts, I explained the schematics of the different modules of the computer. Based on those, I made a large PCB (printed circuit board). You can click the images to zoom in.

As you can see, the board is quite cramped. I wanted to reduce the board size as much as possible, to save costs and make it more portable. This made signal routing quite challenging, as the through-hole component pads (green) don’t leave a lot of room for the over 2000 wire connections required. I also fit it all into 2 layers (top and bottom) – I didn’t want to use a 4-layer PCB, as it’s significantly more expensive (at this size), and I believed that it could be done with just 2. It seems that I was right.
As expected, given this was my first dense circuit board design ever, it does contain some beginner mistakes – for example, not using any ground planes, and making power/ground traces thinner than ideal. But it’s fine, I learned from it, gained experience with PCB design, and the board did end up working anyway.

The total board size ended up being 31.5 x 16.1 cm (12.4 x 6.4 inches), which is a lot smaller than I initially expected, considering the breadboard prototype was about 40 x 40 cm (15.7 x 15.7 inches).

I wanted to keep the individual modules visually separated on the board, to show how the computer is made of these somewhat independent pieces working together. I went through multiple layout iterations for each module, to make it stand out as a separate entity, but still fit in well with the other modules. Additionally, I drew some thick lines on the silkscreen as rough outlines between the modules and labelled them all. The LEDs are also arranged in nice bit strings in the correct reading order, and labelled if necessary.

Here’s the raw PCB, fresh from the friendly neighbourhood Chinese factory:

And here are some impressions from the assembly process:

The assembly was surprisingly fast, it only took about a week. Most of it was rather repetitive, soldering thousands of component pins, but seeing it come together felt great anyway.

Now that the PCB was assembled, there was still one thing missing for the computer to work: Programming the instruction behaviour. This is what we will look at next.

Find the introduction here. Previous parts: 1, 2, 3, 4.

Program Counter

Another one of Ben’s modules that’s been slightly expanded, the program counter is a basic tool that is required for program execution: The computer needs to keep track of its current position in the running program. That way, it always knows where in memory the next instruction can be found. The program can also overwrite this counter with an arbitrary value, which has the effect of jumping to that point in the program.

The counter itself is implemented using four 74LS161 4-bit binary counter chips which are cascaded to create one 16-bit counter. As the data bus is only 8 bits wide, the counter input and output is divided into two virtual registers, P (“page”, higher 8 bits) and C (“counter”, lower 8 bits). As usual, the output is managed using 74LS245 bus transceivers, and there are some LED packs to display the counter value.

Instruction control logic

Now this module is where the magic happens: It tells all the other modules that we’ve seen what to do and when to do it. Ben’s version can be found here.

Let’s start on the left side: There are two 4-bit register chips that store the current instruction code, which is 7 bits long. Above that, there’s a 4-bit counter that keeps track of the so-called microinstruction. Microinstructions are small steps that are exactly one clock cycle long and do a very basic task like moving a byte from one register to another. Multiple microinstructions are combined in sequence to execute an instruction which does something more complicated, like fetching a value from memory, or adding two numbers. Afterwards, a few extra microinstructions are executed to retrieve the next instruction from memory, this is called the “instruction fetch” cycle.

There are some LED packs to display the instruction and microinstruction values. These two values are then fed into the next part of the circuit, which is combinational logic. Here it’s implemented using three ROM chips, similarly to the numerical output module (see part 4). This logic translates the instruction code and microinstruction step into the control signals that are fed to all other modules in the computer (input enables, output enables, other behaviour controls). The topmost chip’s outputs are fed into two 74HCT154 1-of-16 selectors (also called demultiplexers). This way, the 8 bits from the ROM output can be expanded out into 16 bus input enable controls and 16 bus output enable controls, using the fact that at most one input and one output need to be enabled at any point. All of these control signals are displayed using some white LEDs, and some of them are inverted, if the corresponding modules require a different signal polarity.

To help the computer’s timing, the microinstruction counter increments on an inverted clock pulse (see the inverter on the left of the counter chip). This way, the computer alternates between executing a microinstruction (rising clock edge) and setting the control signals for the next microinstruction (falling clock edge).

The details and implementation of instructions will be discussed in a separate post, but for now, let’s look at the PCB that I made from this schematic.