Computer based on a homemade 8-bit CPU

Similar projects worth following
The goal of this project is to build a computer centered a homebrew 8-bit CPU. However, unlike most homebrew CPUs, this system will have access to flash memory, a 16-bit address space, floating point math operations, keyboard and timer interrupts, automatically set error indicators, a built-in USB flash programmer, support for external flash memory, support for a 128 byte stack. I'm also writing a compiler for a simple custom programming language for it.

The name is broken German for a combination of 'blinkenlights', the iconic blinky indicators on mainframes, and 'rechner' which roughly translates to calculator - an appropriately derogatory term for a clunky homebrew computer.

The computer has been designed and PCBs are here! I'm currently soldering everything together (as of summer 2021) and hope to have everything ready to test by the end of August! I'll be posting updates as I get modules completed.

Board 1 for ALU. (There is a bug in this board I missed until after I milled it (hence the bodge wires in the photo). You will need to add two clock lines for the registers).

x-zip-compressed - 283.52 kB - 03/22/2018 at 18:47


  • Building Test Chassis

    Grant Giesbrecht08/11/2021 at 17:53 0 comments

    When a critical mass of boards was reached, it became unwieldy to assemble my computer on my lab bench. So I thew together a basic chassis to hold the boards. When the electronics are finished I plan to build a frame from extruded aluminum, but I don't need something that nice just for testing. So here's the test chassis:

    Test Chassis
    The basic plan is simple - bolt most boards to the plywood base and mount the indicator/control panels to the front verticals.
    Front Panel
    Control panel and blinkenplatte installed!
    Front panel cabling
    Lots of ribbon cables. Last I counted, to connect the PCBs I have ready to test will require 443 Dupont cables.

  • Testing, Part 1

    Grant Giesbrecht08/11/2021 at 17:33 0 comments

    All of the PCBs have been assembled, now I'm assembling the computer and testing each system as I install each board.    I started off powering up the system board to make sure everything looked okay. I'll be connecting each module to this as the central hub. 

    System Board Test
    Nothing burning so far...

    The first major system I tested was the RAM. I had to change two bias resistors to pull-down from pull-up because I made an error in one of my logic circuits, but otherwise it's good to go. 

    Testing RAM
    After a small fix, the RAM is up and running.

    Next I tested the flash memory. I'll need it to run any test programs, so I'll need it working reliably before I can test any more exciting systems (*coughs* CPU). I found a bug in one of the data protection circuits - an RC timer is connected to a buffer without hysteresis and causes ringing on the output. Fortunately, this system is somewhat unique in that the ringing is extremely unlikely to cause a problem, but if I make a new revision of the board, that will be one of the first things to change. 

    Testing Flash
    Flash memory works!

    Then I installed the control panel. There's not a whole lot to test until I've connected more boards, but already you can see some of the completed systems lighting up :)

  • New PCBs!

    Grant Giesbrecht07/19/2021 at 03:43 0 comments

    New PCBs are here! Still waiting on some parts to come in, but I've started soldering the boards. This batch of boards is enough to get the computer running basic programs *if* they all work. There have to be a few errors, but hopefully nothing critical. The boards I just got and am preparing to test are:

    • New RAM modules
    • New flash modules
    • System board (like a motherboard, connects all the pieces)
    • CPU - main board
    • CPU - control board
    • FPU emulator (Not an actual homebrew floating point coprocessor. Just a microcontroller that can mimic one and interface with my homebrew machine via registers)
    • Programmable dual digital timebase
    • Control panel

    I went a bit nuts the past two days and soldered four of the boards, including the eminently pokey and daunting system board. Some parts are still in the mail and thus haven't been populated, but otherwise these guys are ready to test!

    System Board:

    FPU Emulator:

    RAM Boards:

    More on the way...

  • Brief Update...

    Grant Giesbrecht01/19/2021 at 03:51 0 comments

    I built my 2nd revision CPU (dubbed Zeta-2 because obviously it needs a badass name) and tested it's basic functionality. Manually operating the control lines, I was able to run each subsystem of the CPU and add, subtract, etc numbers. However, a number of issues cropped up regarding the control unit (ie. instruction decoder) and timing of read vs. write operations. I'll go into more detail about what went right/wrong in a later log. Anyway, I did redesigned the whole computer and added some really exciting features such as timer interrupts, quadruple the RAM, better controls + indicators, a 16 bit memory bus, and tons more. The design is complete and it's now a matter of putting the PCBs together in KiCad and assembling the BOM. Grad school is busy but I hope to have boards for the 3rd CPU design (Zeta-3) by the summer.  Ps. A programming language geared for homebrew CPUs along with lots of other helpful software (such as for generating the lookup table for the control unit) also in the works...

    Here are some photos of 2nd CPU, Zeta-2:

    The CPU is made from 2 PCBs stacked back to back. Headers act as interconnects.

    Head-on view of the CPU. The control lines are wired into a breadboard for manual control

    This side of the CPU contains the control unit. It's based around a lookup table. The backplane, flash memory controller, and a bodge board are visible to the left of the CPU connected by wire spaghetti.

    Both halves of the CPU visible prior to population and connection.

  • Control Unit + New CPU

    Grant Giesbrecht07/03/2020 at 03:39 0 comments

    I recently designed a control unit for my computer. I had been debating about how to do this, and I've finally settled on a design. The crux of the issue was that I'm using EEPROM to store the control logic in a matrix, and the EEPROM has way fewer pins than I need to control. Leaving room to add later modules, I think I'll need between 40 and 100 control lines. Needless to say the 8-bit word from the EEPROM isn't enough, and using 5-13 EEPROMs instead of one isn't super tempting. I decided instead to use 16 8-bit registers to store a total of 128 control bits that are sequentially written by the EEPROM. This means the control unit will have to run about 16 times faster (18x IIRC when you account for register clocks and a reset signal), but that's fine. Assuming I can get the control unit to run at ~1MHz, that gives me a system clock speed around 100 KHz - that's good enough to do basic math in under a second.

    While designing the control unit (CU), I had to tie together whole bunch of other systems and modules I had left alone for a while.  And while it solidified how a lot of the computer's core features would work, it also pointed out some glaring weaknesses. Among them, the keypad relies on interrupts to work - the CPU had no way of supporting this. I also want to be able to do floating point math in the future, and although I made draft designs for what would be required, it's too elaborate to implement now. It'll need its own bus, clock, registers, and hoards of EEPROM + glue logic. Frankly, the floating point math unit will be more complex than my entire CPU, so I'm holding off on it for now and designing into my CPU support for a floating point math co-processor in the distant future.

    Now for the fun part - my new CPU will support keyboard interrupts, conditional instructions with the help of zero & carry flags, and options to run code either in flash memory, RAM, or an external drive, and of course a floating point math co-processor.

    The CPU will be on two boards - one holds the CU, the other holds everything else. They'll both be 200x200 mm PCBs (huge sizes is one of the side effects of using THT parts :) ) and connect to each other, back to back. The CU board is ready for the board house and the 'eveything else' board should be done in the next week or so. 

  • Flash Memory Controller Build

    Grant Giesbrecht09/22/2019 at 05:38 0 comments

    I've finally gotten around to assembling the FMC PCBs, however I ran out of 20 pin sockets half way through .

  • Clock Module 1 - Debug clock

    Grant Giesbrecht09/22/2019 at 05:22 0 comments

    I'm close to having enough modules working to begin putting the pieces together and seeing some basic functionality. I need a control unit and a clock. Here I'm building a clock specifically designed for development - it supports extremely low clock frequencies (single Hz) as well as a manual clock button. I stole the basic design for this clock from Ben Eater. I made a few optimizations, namely switching the clock-select signal debouncer from a timer 555 design to a pair of NAND gates. I also used NAND gates instead of the combination of various gates Ben used - this way I was able to get away with two 74HC132 quad NANDs for debouncing + clock selection rather than the four chip solution Ben landed on. Here's the circuit:

    Here's a photo of the finished board:

    I tested it and it's working as intended.

  • Designing the Flash Memory Controller

    Grant Giesbrecht12/21/2018 at 17:39 0 comments

    The computer uses flash memory to store its programs and save data. Earlier I made the mistake of trying to write to flash memory the same way I did for SRAM - by entering a value on the data and address lines and pulsing write_enable low. I should have RTFM because it is, of course, much more complicated than that. For those of you who aren't intimately familiar with flash chips (as I wasn't), they have a couple of peculiarities which makes them challenging to use (especially compared to reading/writing SRAM, which tends to be more straight-forward). For one, they are often protected by software data protection. This means to erase or overwrite data you must first enter a series of codes on the data and address lines. This prevents the chip from being inadvertently deleted or corrupted, especially during power up and power down. Another peculiarity is a consequence of how flash works physically and is that when you write to flash you can typically only 'set' a bit, but not 'reset' it (ie. you can change it from 1->0, but you can't change it back to 1 without erasing the entire sector). This brings me to the last quirk - sector erase. Flash has to be erased in sectors. For some chips, this means to reset a single bit back to 1 you have reset every bit in the entire chip back to 1s! - Moral of the story: any homebrew flash memory controller will need to support software data protection and be able to erase and write in sectors.

    I decided to buy flash that allowed me to erase sectors that were smaller than in the first chip I tried (4kB instead of the 128kB entire chip). After I settled on a specific flash model, I set about designing a controller for the chip. The duties performed by the flash memory controller (FMC) include:

    • entering software data protection codes
    • Controlling timing of memory registers

    I settled on a design that used registers to hold the address and data values to read/write so that I could free up pins on the microcontroller which would run the FMC. One big hurdle was devising a way to get the software data protection (SDP) codes entered while not taking up 24 pins (8 for data byte, 16 for address bytes) on the MCU.  I noticed that only a few values are used in all of the SDP sequences, so I elected to use a network of logic gates controlled by only a few pins to generate the 24 bits needed for the SDP codes. To write or read to the chip, the address is entered into two 8-bit registers via the computer's main bus, the data (if it's a write operation) is entered into a 3rd 8-bit register, and the FMC takes over entering the necessary SDP codes and timing to complete the operation. An operation is requested by specifying the type of operation (read, write, sector erase, chip erase) on two lines, then triggering interrupt 0 of the AVR MCU.

    I prototyped my design on four breadboards and worked out a few kinks in the hardware. I wrote a C program for the AVR MCU and tested it on the FMC and got the program working. Here's a shot of the prototype:

    This was definitely one of the more complicated modules in the computer. It took me forever to get right because I kept trying to jump right in to building it before actually having a comprehensive plan. After numerous failed attempts I finally committed to carefully re-reading the datasheet and drafting a few different plans. I considered doing everything with microcontrollers but decided that wouldn't work as well as what I settled on - using one micro to synchronize a whole bunch of 74-series chips. 

    If anyone wants to build their own homebrew computer with flash memory, you might consider copying my design. I'm confident it's not the best solution but it does work (err, it works right now. I suppose I can't really claim it works until the whole machine is done). It was a pretty tedious part to get through so taking a short cut here might be worth while.

  • RAM, CPU Boards 1 & 3

    Grant Giesbrecht04/04/2018 at 22:33 1 comment

    I got my PCBs in the mail and assembled them. This batch included the boards for my RAM module, 2 boards for my CPU, along with the remainder of the boards for the ALU. I can't test the ALU yet because I need to order more chips to finish populating the boards. The RAM board works (except for Q1, whose source and drain I swapped in the schematic. It's a simple enough fix, however; you've just got to flip the transistor around 180 degrees), along with CPU board 1 (houses instruction register, flip flops to specify which flash memory device from which to read the program, and the state counter). Alas, CPU board 3 (program counter) needs to be remade - I  made a wiring mistake in the schematic. 

  • ALU: Board 1 & Breakout Boards

    Grant Giesbrecht03/22/2018 at 18:58 0 comments

    The ALU is too complex for me to fit on one PCB, so i've broken it into 5 seprate PCBs which will stack. I finished the first board and made some breakout boards to make testing go faster for this project. One just converts between a 2x5 header (which I'm using to route the main bus and power throughout the computer) to a section of female header pins. The other lets me read high/low values of 8 pins or write high/low values to 8 pins.

    (The blue tape is just covering the strip of 8 LEDs because they are too bright)

    Here is ALU Board 1:

    This board houses the ALU's three registers. I forgot to allow the registers to be clocked individually, so I had to cut the clock trace and add some bodge wires.

    I've got ALU boards 2-5 designed and ordered, along with the RAM module and 2 other boards for the CPU (they house the program counter, instruction register, and a bank of flipflops that lets the user specify at boot-up which flash memory device to load the program from), so those will be coming along shortly.

View all 10 project logs

Enjoy this project?



Retro Chipguy wrote 01/19/2021 at 07:03 point

Awesome. Looking forward to you updates =)

  Are you sure? yes | no

Natalie wrote 12/21/2018 at 04:52 point

Dang, looks incredible!

  Are you sure? yes | no

Dr. Cockroach wrote 04/04/2018 at 23:55 point

I second that, very nice :-)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 03/23/2018 at 03:00 point

Nice !

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates