Write up of my homebrew CPU build

Recap/Intro

Let’s just get this over with:

So in Part 2 I simulated the whole design in Logisim-Evolution and tweaked it until I was happy. I was emboldened, and felt pretty confident that I wasn’t going to make any Big Mistakes with the real hardware…

This post covers what actually happened when I started building the physical thing. Spoiler: it was humbling. There are backwards LEDs, floating address lines, cursed EEPROMs, and at one point I just learned to read binary by staring at some blinking lights because I’ve been too lazy or distracted to build an output register yet.

This build of WCPU-1 should be seen as a prototype to validate the design and wiring before moving to the “real” PCB design.

I’ve written this in a sort of “don’t make my mistakes, kid” war-story style, so it’s a little crazed at times and probably a little embarrassing, but here we are.

Also it’s very, very long. Sorry.

You already saw the “hero shot” of the build with all the red lights looking like something out of the Upside-Down, but here’s another shot in the light of day:

So Much for “No Breadboards”

Of course, right out the gate I made some decisions which eventually felt like mistakes.

With the schematics roughed out in KiCAD (mostly traced from my Logisim design, which worked shockingly well as a reference), I started ordering parts from Digikey. If you plan ahead you can hit the free shipping threshold, which I’m going to pretend was strategic and not just the result of buying way too many LEDs.

In my mind I was thinking that I want everything on the final build to be Surface Mount Technology (SMT) and so that’s pretty much what I ordered. I was going to make a few PCBs and connect them all together (how??) to experiment/validate ideas. But in the end there was so much rearranging that I decided to only create a couple of PCBs (more on that later) and do the rest breadboard style. Only you can’t put SMT chips into breadboards…

So if I had to do this again, I would always order a bunch of SMT parts, but also 2-4 of the DIP version of the same chip from the same manufacturer for testing/validation. They are almost always available. If I’m going to end up using breadboards everywhere anyway, might as well just get DIP packages for the prototype.

Adapter/breakout boards to the rescue.

Custom PCBs from PCBWay

I ordered three custom PCBs for the first batch:

The EEPROM Programmer Board

This was the first board I needed to have since without it I can’t program the microcode ROMs and nothing else will work.

It’s a standalone tool that lives outside the computer. I put the EEPROM into the socket, and connect via serial to my laptop to upload the binary files.

I had Claude Code help me design and implement a serial protocol for sending files over the wire and having them get written to the chip. This pairs with the microcoding system I created in python, which generates the binary files and then also connects to the serial port directly and uploads them. It’s pretty neat and allowed for pretty quick iteration!

Mistakes

The Arduino Nano (clone) on the board is connected to all the address and data lines via 2 shift registers.

But it’s also connected to the control pins (OE, WE, CE) via the shift registers!! That means the most significant three bits of the data being shifted out also control when and how the data is written.

This unfortunately limited the speed at which I could safely write to the EEPROMs. If I had those 3 pins just connected to free GPIOs on the Arduino, I could have used the Page Write capabilities of the chips, which allows for writes waaaay faster than one byte at a time. In my testing I could rewrite the entire 8KB EEPROM in about 80s one byte at a time, and in about 1.3s with page writes.

That said, in “slow mode” it did work on the first try, which is a win in my book.

The Generic Register Board

This was probably my greatest success in this project so far.

I designed a generic register PCB which contained a 74HC377 octal D type flip flop (to hold the actual data) and a 74HC245 for its tristate bus connection.

This way I could just connect all the registers to the same bus, and differentiate them by which IN and OUT control lines they were connected to. Very tidy.

Other than IN, OUT and power pins, the left set of 8 pins is the I/O connection to the 74HC245. The right-hand set of pins is the output pins from the 74HC377. Of course there are also many blinkenlights showing the internal state of the register. Super handy for debugging!

A Note on the 74HC377

In future builds I would probably choose to work with the 74HC574 instead. The reason being that the ‘377 doesn’t have tristate outputs - so you require something like the ‘245 to connect to a shared data bus, adding 1 extra chip to your count.

The drawback of something like the ‘574 is that there’s no way to see the internal state without outputting it somewhere (like the bus). So for debugging and demonstrator type projects, the 377 is fine because you can connect it to some LEDs as I have done, and then into a bus transceiver, but if you just use the 574 in the exact same way, you ALSO have the option to reduce your chip count since you don’t need the 74HC245. Drawback obviously being fewer blinkenlights.

This board worked perfectly first try and has been rock solid, btw. No big deal.

The Control Module Board

This board is extremely simple. It just holds the 3x AT28C64B EEPROMs that generate the 24-bit control word.

It takes addresses in, and poops out the microcode steps, asserting/deasserting control lines and driving the whole computer. Simple right?

I designed the schematic and the PCBs, sent them off to PCBWay and all was well!

Then a bunch of bad things happened:

• The boards were mis-shipped on the first attempt by PCBWay. I received some other random person’s PCBs. Got it re-made and re-shipped, not a huge deal (more on this below)
• I inverted CE in the schematic which is actually active-HIGH. So in the microcode ROM I have to invert it, again - Oh, and whoops, no decoupling capacitors anywhere. I bodged some in afterwards.
• There was another massive design flaw: the Output Enable and Write Enable pins weren’t connected to anything at all! They were just floating and doing whatever they wanted, meaning that they were corrupting themselves continuously. I performed the worlds smallest bodge 6 times, and that issue was resolved
• I INSTALLED ALL 36 LEDs BACKWARDS. Every single one. I had to rotate them individually with my hot air station and tweezers. Very zen, but very, VERY tedious

After all that, to my surprise, it worked perfectly. Or so I thought… (foreshadowing again!!!).

To see my review of PCBWay’s services, scroll almost all the way to the bottom.

Real-World Demons (a.k.a. stuff Logisim didn’t warn me about)

Spoiler: It was NOT just like the simulations.

1. The Clock

I built my clock on some perfboard, with some little switches to choose between single step, adjustable 555, and a 1MHz crystal oscillator.

This surprisingly actually works OK! I can basically go from ~0.5Hz to about 450Hz with the 555, and the single step button is nicely debounced with another 555 timer.

One minor issue is that the switches to change between modes are not properly debounced and can cause the occasional glitch. A workaround is to just hold the computer in reset, choose the mode, and then take it out of reset. It’s only really an issue going to/from 1MHz mode. I’ll fix it in the real deal.

Gross Edges

The clock module does not produce very nice edges. I eventually fixed this by routing the output into a Schmitt Inverter which has some built-in hysteresis and cleaned those edges right up.

The yellow line here is the drooopy clock signal. This is a combination of poor power distribution and bad wiring. The blue line is an example of a downstream device.