Breadboard color computer from TTL

"Just because"

Similar projects worth following
Can fewer than 40 old-skool simple TTL chips on a breadboard implement a 8-bits, multi-MHz 64-color computer? This is what we have now:

* 8-bits computer built out of 1970s TTL chips (74LS series)
* 34 chips are used for the CPU
* Only simple SSI and MSI chips, such as AND/OR, 4-bit adders, multiplexers and registers. Typically no more than 10-20 gates per IC.
* So no microcontroller and no relatively complex ALU chips are used (such as the 74181)
* 32 kB SRAM (70ns)
* Harvard architecture with program and data stored in EEPROM
* Runs at 6.3 MHz. It can probably be pushed to 8 MHz.
* RISC-like instruction set with pipelining: 1 instruction per clock cycle
* Instruction decoding partly done with diodes
* Comfortable instruction set: add, sub, and, or, xor, conditional jumps, several useful addressing modes, etc.
* Capable of generating VGA signals from software. Typically 160x120 pixels with 64 colors
* Designed and built on a solderless breadboard in roughly 6 weeks

This will be [Edit: is] a general purpose breadboard computer made out of TTL-grade logic chips and no CPU or microcontroller. It will have video out, at least 160x120 pixels in 16 colors [Edit: 6-bit / 64 colors in the current protoboard]. It should be capable of displaying arbitrary full-screen images and running games like Pac Man and Space Invaders. Ideally the project should stay under 30 chips, but definitely no more than 40. Can it be done?The project is not built yet. I will describe it as I make progress in the upcoming weeks. I don't work on it all the time and updates will be irregular. I have done some concept tests with video before, see my other projects on this site for that. Now is time for the big leap.

[Edit: see the video for the resulting capabilities ]

[ Note: I don't maintain this "Project Details" section very often. See the blog for the real updates. ]

    Some concepts to ponder about before starting

    1. How many bits? 4, 8, 16, 32, ...
    2. Software-generated video or hardwired?
    3. Harvard or Von Neumann architecture?
    4. Single cycle or multi cycle? Pipelining?
    5. ALU chips or not?
    6. Sliced ALU or full width?

    A rule of thumb is that a minimalistic four bit system can be done in 10 chips, an eight bitter needs no more than 20 chips and going to 16 bits roughly doubles that again. Not all units double in chip count, but by extending the buses you will also have need for more addressing modes for it all to make sense. For example, a four bitter might work fine with a 256 word memory and absolute addressing, but with larger memories you'll need ways to construct addresses dynamically. Also, add more chips if extra functionality is required, such as high speed, a stack pointer, interrupts, a custom ALU or video.

    Simplest possible concept

    One concept, probably the simplest, is to replace the TrinketPro from the earlier breadboard VGA from TTL and SRAM with a minimalistic 4-bit TTL CPU. We will then get a working system with around 25 chips, or about 30 if we make a custom ALU. It will indeed be good enough for Pac Man and Space Invaders, but that will then also be the limit: no chance at all to have any fast scrolling, fast color changes, smooth moving objects, large objects, etcetera. Upgrading the CPU part to 8-bits won't bring much, because there will still be a communication bottleneck between the two parts. For any more exciting video we will need more complexity in the video part. If we do both, we certainly end up with more than 40 chips. It is absolutely interesting to try out this 25 chip concept (I would do it with a 74'181 ALU chip), because Space Invaders from such a small system can be very appealing. But first I want to explore another path.

    A more daring approach

    Lets look at it from another angle. If we look at the current video generation circuit it already contains many elements for a CPU: there are counters, ROM, RAM and buses. So the idea I'm going to pursue first is to extend the video part to gain full CPU capability: we will combine video with the CPU logic. The software will bit bang the sync and pixel signals at the right time. The dead time can be used for application code.

    I don't know how this choice is going to turn out, it might make the application software timing really complicated, but it has the potential to make more interesting video possible because all flexibility is now in software. It also requires the CPU part to be very fast.


    The ALU is the Arithmetic and Logic unit, or the inner calculator in a processor. For the ALU there is the option to use a 74'181 or to roll your own. I have several '181s lying around, so that is not the issue. But they have become hard to obtain, so duplicating this project becomes a bit more difficult if it requires them. Therefore I will do a custom ALU. We could still cut functionality, for example only do ADD and NAND. But I really don't like compromising the software in such extreme ways.

    Data paths and control signals...

    Read more »

    • Audio output

      Marcel van Kervinck08/06/2017 at 16:16 0 comments

      I've been busy adding audio output while trying to keep the component count down. First I figured out a way to insert a second output register into the circuit. It's a 74'273 that takes its input data from the accumulator and the clock from the video hsync. Good enough for 31 kHz software-generated samples and with a bit of luck I can squeeze out 4 voices. I will split this extended output register into 4 bits for audio and 4 bits for blinkenlights.

      This is the circuit for the audio out part. The idea is that this is good enough to connect PC speakers to. The attenuation from logic level to line level is done by the filters. The calculated output signal should be ok:

      My tests run fine over the interesting audio frequency range. Here's a 555 hiding behind a pot and driving a 74HCT161 that in turn generates a 16-step sawtooth. The DAC is a 10kΩ R-2R ladder whose output gets filtered by the simple RC stage. Overall output impedance is quite high but more than suitable for the PC speakers.

      Close up of the unfiltered DAC output:

      All in all, it seems that I won't need an op-amp for this stage, which is what I was after.

    • Wire wrap sockets meet solderless breadboard

      Marcel van Kervinck07/02/2017 at 10:28 0 comments

      As the programming is done externally, the breadboard suffers from the continuous removal and insertion of EEPROM's, to the point where they barely stay in place anymore. Following a comment in the Hackaday feature, this looks like a promising solution:

      These are IC sockets intended for wire wrapping. I just use them for a better mechanical interface to the breadboard.

    • ... and a blinking LED

      Marcel van Kervinck06/13/2017 at 22:44 2 comments

      Today I realised that no homebrew CPU project can claim completeness without a blinking light. Lacking free output pins (all 8 are used for video), I hooked up an LED to the unused address pin 15, and use that as alternative.

      I'm getting into some serious problems with breadboard fatigue in the EEPROM area. One of the ROM's just keeps popping out. The next phase is therefore to document the circuit in KiCad and convert it into a PCB.

      [ Spoiler: the display is an older selfie, as witnessed by the incomplete wiring and background. The on-screen LED is just a 3x2 pixel area turning red at the same time as the breadboard LED. The scrolling is smooth in real life, but due to mismatch with my phone, it may appear jumpy. ]

    • Self-awareness

      Marcel van Kervinck06/07/2017 at 07:38 0 comments

    • Undefined opcodes

      Marcel van Kervinck05/29/2017 at 04:54 0 comments

      From the assembler/disassembler it is easy to generate a complete instruction table. Most opcodes result in a valid instruction. Only memory writes while RAM is on the bus result in an undefined value ($??) being stored.

      I found out I had some undefined instructions that are actually very useful. They store a value in memory as well as in X or Y. Their existence is entirely accidental: Unlike AC and OUT, the X and Y registers are not "muted" while writing to memory. The purpose of muting is solely to provide all addressing modes to store instructions without destroying the contents of AC or OUT. As X and Y don't have addressing modes that AC and OUT already have as well, I didn't bother to give them an OR-gate that suppresses the enable signal to them ("you don't need these modes"). This omission turns out to be quite useful! Because X and Y are essentially "write-only" registers, each time you use them and you're not sure of their value you have to reload them. Now you can first do a computation, in AC, and then move the result both to X/Y and also back to memory. Both moves in the same clock cycle. With that, you can keep track of what is in X/Y, for example in the zero page. I suppose this will be used a lot. I already use it in the video loop.

      Now they are no longer undefined. They are part of the family.

    • On the move

      Marcel van Kervinck05/28/2017 at 14:06 0 comments

      First moving video output from my breadboard TTL color computer. Again, the test image is just initialised SRAM garbage with some lines drawn over it. Line 60 to 90 are scrolling 1 pixel per frame.

      The scrolling looks a bit jumpy in the recording, but that is just the mismatch between the camera and monitor frequencies. In real life it is stable and smooth.

    • Stable video with help of a canary

      Marcel van Kervinck05/27/2017 at 12:33 0 comments

      The control unit (CU) uses decoder IC's and diodes for decoding the operation and addressing modes. I'm toying with plain 1N4148 (silicon), 1N60 and BAT85 (both Schottky) diodes. Surprisingly, all seem to work pretty well. Here they are all mixed more or less randomly on the breadboard.

      The diodes between INS (74LS155) and INV (74LS240) form the operation decoding ROM matrix. The diodes connected to MODE (75LS138) pull the control lines for register loads and RAM address generation. The diode mess looks fragile, but in reality it all stays in place rather well.

      When combining diodes with TTL, there is only 400mV voltage drop to play with before entering undefined territory. Some of the diode logic outputs travel all the way across the circuit, which means that supply voltage and ground differences must be controlled over that distance. Also, 74LS requires 4.75V as absolute minimum, or no more than 5% drop.

      When I installed the supervisory MCP100 some weeks ago, I already noticed that I had to connect the 5V supply on the same segment in order to boot. If I connected it further away, it simply wouldn't release the reset. This means there is too much resistance between the segments, more than the equivalent of 250mV. A couple of extra bridges solves that. But to troubleshoot this, I found a useful second use for the MCP:

      First recall that the MCP keeps the reset line low for as long as the supply voltage is not stable above 4.75V. (Well, the MCP100-475DI/TO does that. In ordering these, every letter means something important). In my circuit it sits next to the reset button, as you can see here:

      You can spot the reset switch with its 10kΩ pull-up resistor. It controls pin 1, or /CLR, of the PC counter IC's (all four of them). The red LED is just lurking on the reset line as an indicator. The MCP is the three-legged black component that looks like a transistor. It has one leg on the reset line. The other two legs are on Vcc and GND. It is a clever and useful little device. Now it turns out you can make a super easy voltage tester from an MCP, an LED and a current limiting diode (330Ω), as follows:

      The "reset" leg is now connected to the LED and not to the circuit. If the LED is on, the voltage difference on the supply rails is stable above 4.75V. With this device it is easy to test the voltages everywhere, much easier than with a multimeter or scope. I call this the "canary" because of the yellow light, and because when the light goes out, it signals that that part of the circuit is in danger.

      With all voltages controlled, the video image is now stable. I'm still emitting uninitialised SRAM data, but to verify that I'm streaming from the right addresses, I let the CPU draw some lines across the screen, vertically and diagonally. All addressing modes and registers are now exercised, so this is a pretty good system test.

    • First pixels

      Marcel van Kervinck05/25/2017 at 16:25 0 comments

      160x120 in 64 colors, simply displaying uninitialised SRAM. A bit unstable, but a nice little step. All wiring is now connected. The next steps are to get stable signals, tidy up the wiring and make more interesting software.

    • Two birds with one stone

      Marcel van Kervinck05/21/2017 at 16:01 2 comments

      An Atari joystick will do as input device for the games I have in mind. But the breadboard computer has the potential to run a BASIC. For that, keyboard input would be great. USB is out of the question, and even PS/2 looks a bit involved. A simple matrix keyboard would be a better starting point.

      Also, at some point I'll need an enclosure to keep dust out and to be able to bring it to places.

      Today, I might have stumbled upon the solution for both problems.

      [ Edit: to the millions of voices that suddenly cried out in terror: it had a broken PLA chip ]

    • Homebrew CPU webring

      Marcel van Kervinck05/21/2017 at 08:40 0 comments

      My breadboard TTL color computer is now included in David R. Brooks' Homebrew CPU webring. How cool is that!

      In the meantime I have figured out how to mix video with application code. Next week we'll have a 5-day holiday, and if there are some rainy days in there I expect to get some animated output from this thing by then.

    View all 24 project logs

    Enjoy this project?



    f4hdk wrote 05/26/2017 at 11:34 point

    I like it! 

    Every homebrew computer should have video output, even made with TTL!

    Have you seen my project? It is quite similar (custom CPU architecture, video output) even if I used an FPGA  instead of TTL components.

    It's fully documented and open source. 

    And welcome on the "homebrew CPU Webring" !

      Are you sure? yes | no

    Marcel van Kervinck wrote 05/26/2017 at 13:52 point

    Nice! FPGA's are a step up for me. Clearly the TTL and the RAM size are limiting my video resolution, but it is also cute in its own way.

      Are you sure? yes | no

    Peabody1929 wrote 04/01/2017 at 18:46 point

    Consider one or two AMD2901 or a single CY7C115/116/117 -> More computer, fewer chips.

      Are you sure? yes | no

    Marcel van Kervinck wrote 04/02/2017 at 20:09 point

    Thanks. I can find the first. I do have ALU chips available, I just don't feel like using them in this build. Do you have data sheets for the second series? I have trouble finding out what it is. Some memory? I plan on using 62256 for RAM and 2x AT28C256 for ROM, with a possibility to extend the memory using the AT27C1024.

      Are you sure? yes | no

    Big Boy Pete wrote 03/31/2017 at 18:19 point

    Good luck Marcel.

      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