More details and hardware to come summer 2021...
Computer based on a homemade 8-bit CPU
To make the experience fit your profile, pick a username and tell us what interests you.
More details and hardware to come summer 2021...
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
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:
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.
I've finally gotten around to assembling the FMC PCBs, however I ran out of 20 pin sockets half way through .
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.
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:
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.
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.
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.
Become a member to follow this project and never miss any updates