PERIHELION 1: An 8 Bit Computer

An 8 bit computer made (mostly) from 7400 series logic.

Similar projects worth following
The goal of this project is to build a computer that is comprised mostly of 7400 series ICs. I depart from this ideal where it would be too difficult, impractical, or boring to achieve the equivalent with 7400 series logic (for example, I'm using specialized RAM ICs, not building memory from logic gates). The other objective of this project is for the computer to be usable for some simple tasks. To this end, it will have lots of memory for storing large programs, a relatively capable homebrew CPU, GPIOs, and lots of tolerance for added modules.

Here's a more detailed description of the computer I'm building:

It'll have flash memory used as a hard drive; this memory will be programmed from my laptop so long programs can be created and written from text files, making complex programs easier to write. The computer will also, of course, be able to rewrite its flash memory to save data.

The CPU will be able to perform 8 operations: Addition, subtraction, left/right bitshift, bitwise NAND, NOR, AND, XOR, and checking to see if all bits in a byte are ones. It is built from 7400 series ICs, except for the control unit which I'm probably going to make from either EEPROM or a CPLD.

It has 32KB of RAM.

It will also have ports to allow external flash memory to be connected to the computer. The purpose of this is to allow programs to be saved externally and plugged into the computer when you want to run them, and to allow you to save data to external memory.

On the I/O side of things, it will have an array of 7-segment displays for outputting computation results. Furthermore, I'm building a control panel with 8 reprogrammable buttons, switches, and LEDs so that your programs can get user input. Lastly, the main bus (along with some control lines from the CPU) will be routed to a port on the side of the computer so keypads, fancier displays, or whatnot can be connected to the computer and controlled at a later date, should the need arise.

On the manufacturing side of things...

I'm going to order or mill my own PCBs for this computer. It will require some 20-30 boards, so this project is certainly going to take a while. As I get the boards designed, made, and assembled, I'll upload the gerbers and KiCad project files. Plus, all the PCBs will be 100x100mm or small so budget boardhouses like JLCPCB will build them for next to nothing.

Once all the electronics are ready to go, I plan on building one gigantic plywood box to house this beast. Lastly, I'll give it a nice pretty control panel with loads of switches and blinkenlights (maybe even a buzzer to yell at you) to really tie the whole thing off.

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


  • Designing the Flash Memory Controller

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

    Perihelion 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 Perihelion. 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 3 project logs

Enjoy this project?



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