Gigatron TTL microcomputer

"Just because", a microcomputer that runs without a microprocessor

Similar projects worth following
In 1975 Wozniak famously designed the Breakout arcade game out of 44 simple chips, without using a microprocessor, simply because those weren't available to him at the time. When one year later the MOS 6502 and Zilog Z80 were launched, his Apple 1 started the microcomputer revolution. The debate still rages about which processor was the better one. But more interesting is to investigate if these devices were really necessary for the personal computer revolution at all: what would have happened if they had never appeared?

Update: For more info on the kit version of this project, check out:

History followed one path
There were many other ways
It will always be like that

Can fewer than 40 old-skool TTL chips implement a multi-megahertz microcomputer with video and sound?

This project started as an exploration of what you can build from 30-40 simple logic chips. It has turned into a general purpose 8-bit microcomputer without any microprocessor driving it. I initially designed this on a breadboard, but last summer I converted it all to a small PCB. It has VGA-compatible 60 Hz video in 64 colors and can display full-screen images, scroll them and play sound. Soon it will be running games like Pac Man and Space Invaders. But just for fun, I'll keep everything compatible with the breadboard design.

This is what we have now:
• 8-bits system built out of 1970s TTL chips (74LS)
• 34 TTL ICs, or 930 logic gates, for the CPU proper
• No microcontroller and no complex chips (such as the 74181 ALU)
• Only simple ICs, such as AND/OR, 4-bit adders, multiplexers, registers and so on
• 6.3 MHz. Might be pushed to 8 MHz
• 32kB 70ns RAM
• Harvard architecture with EPROM for program/data
• Operates on 2.5W, or below 0.5W for the 74HCT version
• RISC with pipelining:  1 instructions per clock (sometimes 2...)
• Instruction decoding with diodes
• Nice instruction set: ADD/SUB/AND/OR/XOR, conditional jumps, many useful addressing modes
• 60Hz 64 color VGA and 4 sound channels bit-banged from software
• Designed and built on a solderless breadboard in 6 weeks

The build has become a contradiction of itself. To reduce the parts count, every hardware function is essentially software-defined: video, audio and I/O are all handled by software. Video at the pixel level. Audio at the sample level, in 4 channels. Even the applications themselves will be running in an interpreter (aka a virtual processor). Yet there is no microprocessor that runs any of that. And not only does it work, the board is smaller and faster than the microcomputers of the day, including the first IBM PC. Having no microprocessor might have been better than having any of the time :-)

Check the videos for the current capabilities. The HaD blog section has the full story in all detail, so don't miss that if you're interested.

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...

Read more »


Modules, buses and control signals

Adobe Portable Document Format - 150.57 kB - 04/14/2018 at 20:12



EBNF and railroad diagrams for Gigatron Command Language

xhtml+xml - 66.74 kB - 03/12/2018 at 15:29



2-clause BSD license

license - 1.30 kB - 02/27/2018 at 20:45



Object ROM file for 27C1024

rom - 128.00 kB - 02/27/2018 at 20:44


  • Gigatron as TV Typewriter

    Marcel van Kervinck3 days ago 0 comments

    The video shows how an Arduino can be hooked up and pretend to be an ASCII keyboard. No EPROM change is needed. After powering the Arduino, it takes over control by resetting the Gigatron, navigating the menu and starting Loader. It fakes game controller signals to do that. Then it pushes a tiny precompiled Terminal program into the RAM. From there on, it sends simple ASCII codes which the board dutifully displays. This is step 1 towards interacting with the system for direct hacking.

    The source code for the sketch is in GitHub. Hookup is with 4 male-to-female jumper wires.

    P.S: At the third test in the video the stream stops because the power bank that drives the Arduino was already empty :-)

  • 1 year later, a new Gigatron is born every day

    Marcel van Kervinck03/31/2018 at 09:28 3 comments

    It is amazing to start getting almost daily reports back from all over the world of new Gigatrons seeing the light of day. This project started one year ago here on HaD with no more than a bunch of empty breadboards and some chips. Without any clue if the crazy minimalistic concept would be viable, and no clue on how the ALU or control unit were going to work. Thanks for your pictures and please keep sending them in!

    For reference I took this breadboard photo on March 31, 2017. It accurately portrays the project status of exactly one year ago today:

  • Gigatron kits are shipping!

    Marcel van Kervinck03/17/2018 at 02:58 2 comments

    Double good news today. The first good news is that we will be speaking about Gigatron at the upcoming Hackaday conference on May 26 in Belgrade. We’re super excited that our talk was accepted, and hopefully this event is a chance to meet with many of you. The second and even greater news is that our supplier has sorted out their delivery issue. This means that now we’ve all parts in-house for a first batch of kits. Gigatron is ready to ship, and we're open to take orders!

    Ordering details on our website: We have some stock prepared:

  • Updated grammar using EBNF

    Marcel van Kervinck03/12/2018 at 18:15 0 comments

    With ROM v1 done and arrival of the last kit parts confirmed for this week (yeah), now is the time for chores. The syntax I used for writing the apps has some rough ends. It was grown bottom-up, hand in hand with the GCL-to-vCPU compiler, while vCPU was still evolving. As I'll need a new compiler for the Arduino interface anyway, why not fix what can be fixed? So now here is the formal EBNF definition of the updated notation, or call it a language if you wish.

    There is a great online visualizer that turns these grammars into easy-to-understand railroad diagrams. I've always liked these since I first encountered them in the "Pascal User Manual and Report". A webpage with all diagrams sits here on HaD.

    GCL will never look pretty, but it at least it isn't Perl.

  • Small hiccup, but almost there!

    Marcel van Kervinck03/04/2018 at 15:41 0 comments

    With great anticipation we received our last parts for the batch last week. Panic ensued when we discovered they were of the wrong type. Not a few, all of them... Did we place a wrong order? Frantic discussions with the supplier followed and yesterday it became clear: they messed up, apologised, and they are now sending us a new batch. We expect the total impact will be a two-week delay. Bummer, but at least we didn’t lose any money on a stupid mistake.

    So please bear with us a little bit longer, soon you will be heating up your soldering iron!

  • TTL computer ROM is feature complete

    Marcel van Kervinck02/18/2018 at 14:28 0 comments

    After 360 commits my coding frenzy has reached a conclusion: ROM v1 is feature complete! The kit will ship not with one but with two fast paced games: Snake and Racer. Sound improved and the serial loader is reliable, which is great for hacking and making more games. The fractal program now doubles as a clock, to give a valid excuse for keeping a unit on permanent display in the living room.

    The unused ROM space is filled with three classic hires images from my previous projects. By packing 4 pixels in 3 bytes I got three images in where the ROM otherwise would only have space left for two.

    This doesn't mean the to do list is empty, far from that: "make todo" lists 90 ideas I apparently still have in mind. But after 6 months of breadboard prototyping, 3 months of PCB design and 4 months of software hacking, this is a good point to shift focus again. For example, towards demonstrations, tutorials and documentation. Keep you posted.

  • Wrapping up the software for ROM v1

    Marcel van Kervinck02/11/2018 at 14:46 2 comments

    The software to be included with the kit release later this month is nearly done. Just in time as we're now also waiting for the last parts shipment to arrive, expected in two weeks. When those are good we know if we can meet our target selling price and will announce it to those interested on the mailing list. All other parts are in house already, manuals printed, packaging ready and beta tests successfully completed. Our living rooms look like a warehouse now.

    Of course the kit will ship with some demo applications built-in. My focus is for a part still on those, but equally important is that the programming core is stable and tested. For me it is crucial that the memory map is well-defined and the 16-bit interpreter is fully tested and useful. After all, the vCPU opcodes are jump offsets, so it will be impossible to fix any of that later while maintaining compatibility as well. Last week I found I had some unused space in the interpreter code page, so I added some new bit-wise logic instructions and support stack variables. Surprisingly, none of the applications I wrote so far needed those.

    To test, I ported my old n-Queens solver. It exercises bitwise logic and recursion, so it is a good test for these new instructions. On the screenshot above you can see it gets the correct answers for the sequence.  The solver uses 5 stack variables. That, plus one for the the return address, gives 12 bytes per invocation. With the stack living in the top half of the zero page, this means we can go 10 levels deep. The solver needs less than a minute to compute the list, or at about 850 recursions per second. [Edit: I just figured that it should be easy to go down to using 4 variables or 10 bytes, and with that up to 12 levels deep.]

    Although 8-bit assembly programs must be programmed in the EPROM, interpreted programs run from RAM. The built-in applications are of course stored in ROM also, but they are loaded into RAM first, so they use the ROM merely as a disk. Interpreted programs can also be loaded into RAM directly over the input port, and this is how you can program the Gigatron without using an EPROM eraser and programmer. For this I hook up the input port pins, that normally go to the game controller, to a simple Arduino. The Arduino can send data at the same rate as the horizontal sync. With some checksumming overhead, this boils down to exactly 28k8 payload bits per second. Much faster than loading C64 programs from tape back in the day... (3000 baud with speed loaders!)

    The loader was the last part of the software that needed debugging with a scope.

  • Mandelbrot from TTL

    Marcel van Kervinck01/22/2018 at 00:33 7 comments

    I got a bit stuck with the work I was planning for today, so I wrote something else to regain motivation: a fractal! Rendering takes a while (8242 seconds), being fully interpreted and lacking multiplication, and even without the "right-shift" operation you badly need for this. All those must be mimicked with slow high-level code using just addition and subtraction. [Edit: it takes 1127 seconds now with native code for "right-shift"]

    It should be easy to speed the whole thing up a lot just by adding a right-shift assembly function. Next time... GCL source code:

    |                                                                       |
    |       Mandelbrot fractal                                              |
    |                                                                       |
      Plot the Mandelbrot set
      - 160x120 pixels and 64 colors
      - Faithful translation of mandelbrot.c pre-study
      - Use 16-bit vCPU math as 7-bit fixed point arithmetic (1.00 -> 128)
      - Implement multiplication in interpreter
      - Implement shift-right in interpreter as well
      - A bit slow (8242.655 seconds)
      XXX At the end change all to grey tones and redo
      XXX Redo at different sections
      XXX Tone for every pixel value
    |                       RAM page 3                                      |
    { Pretty accurate multiply-shift ((A*B)>>7), but it can be off by one }
      {Extract sign and absolute values}
      0 sign= C=
     {0}A- [if>0 A= 1 sign=]
      0 B- [if>0 B= sign 1^ sign=]
      7 shift= {Pending shift}
        -$4000 C+ [if<0
          C C+ C=
          {Shift prematurely in an attempt to avoid overflow}
          B ShiftRight! B=
          shift 1- shift=]
        {Add partial product}
        A bit- [if>=0
          C B+ C=]
        bit ShiftRight! if<>0loop]
        C ShiftRight! C=
        shift 1- shift= if>0loop]
      {Apply sign to return value}
      sign [if<>0 0 C- else C]
      pop ret
    ] MulShift7=
    { Calculate color for (X0,Y0) }
      0 X= XX= Y= YY= i=
        i 1+ i= 64^ if<>0           {Break after 64 iterations}
                                    {Mandelbrot function: z' := z^2 + c}
        X A= Y Y+ B= MulShift7! Y0+ Y= {Y = 2*X*Y + Y0}
        XX YY- X0+                  X= {X = X^2 - Y^2 + X0}
                                    {Calculate squares}
       {X}A= B= MulShift7!          XX=
        Y A= B= MulShift7!          YY=
        -$200 XX+ YY+ if<0loop]     {Also break when X^2 + Y^2 >= 4}
      pop ret
    ] CalcPixel=
    |}\vLR>++ ret{          RAM page 4                                      |
      $7ff p= {Start of video (minus 1 to compensate for 1st step)}
      -323 X0= 3 DX= 161 Width=  {Horizontal parameters}
      -180 Y0= 0 DY= 120 Height= {Vertical parameters}
        {Length of next segment, either horizontal or vertical}
        DX [if<>0 Width 1- Width= else Height 1- Height=] if>0
          {Step in the fractal plane}
          X0 DX+ X0=
          Y0 DY+ Y0=
          {Matching step in video frame}
          DX [if<0 p 1-     p=]
          DX [if>0 p 1+     p=]
          DY [if<0 -$100 p+ p=]
          DY [if>0  $100 p+ p=]
          63 p. {White while busy here}
          {First check if we are inside one of the main bulbs for
           a quick bailout (Wikipedia)
           (x+1)^ + y^2 < 1/16}
          Y0 A= B= MulShift7! YY=
          X0 128+ A= B= MulShift7! YY+ 8- [if<0 0
          {q*(q + x - 1/4) < 1/4*y^2, where q = (x - 1/4)^2 + y^2}
          X0 32- A= B= MulShift7! YY+ {q}
          A= X0+ 32- B= MulShift7! tmp=
          tmp+ tmp= tmp+ tmp= {*4} YY- [if<0 0
          {Otherwise run the escape algorithm}
          p. {Plot pixel}
          len 1- if>0loop]
        DY tmp= DX DY= 0 tmp- DX= {Turn right}
      pop ret
    ] CalcSet=
    |}\vLR>++ ret{          RAM page 5                                      |
    { Stupid shift-right function }
    { XXX Better make a SYS extension for this }
      a= 0 b=
      $8000 a+ [if>=0 a= $4000 b+ b=]
      $c000 a+ [if>=0 a= $2000 b+ b=]
      $e000 a+ [if>=0 a= $1000 b+ b=]
      $f000 a+ [if>=0 a= $0800 b+ b=]
      $f800 a+ [if>=0 a= $0400 b+ b=]
     $fc00 a+...
    Read more »

  • Hacker spaced

    Marcel van Kervinck01/19/2018 at 23:54 0 comments

    While waiting for the last parts to come in for the kit version (waiting can be so tedious), Walter and I had the privilege to be invited at two nice hacker spaces last month where we could talk about the project. So besides 34c3, we also visited RevSpace and Hack42 in the previous weeks. What a blast and what a great diversion from endlessly plowing through the kit details! Each time we met with plenty of great people with cool projects and had the chance the pick up many new ideas an suggestions.

    The first talk at Hack42 was recorded and is on youtube. It is a bit over an hour where Walter talks through the entire design including Q&A. Enjoy!

  • 930 logic gates

    Marcel van Kervinck12/30/2017 at 23:41 0 comments

    While playing Gigatron Snake at 34C3 we got asked: "how many gates are in there?". This isn't the first time someone has asked, so today I finally went through the TTL datasheets and counted little blocks from their logic diagrams. TL;DR: the CPU has 930 logic gates.

    And because 34C3 is such an inspiring place, after one day of hacking those gates now happily animate this beginning of a Racer game:

    Gate counting isn't as straightforward as it seems though. RAM and ROM are clear: they each have thousands of logic gates in their word line decoders alone, but those aren't part of the CPU proper. The clock isn't part of the CPU either, but that's just a couple of inverters. For decoding the game controller it isn't as clear cut: the kit version has a 74HC595 shift register which has roughly 80 gates. But only 10 buffer gates are really needed by the CPU and are directly controlled by it. I fact, on the breadboard version, the input chip is just a 10-gate 74LS244 non-inverting buffer. So I count that as one 10 for the CPU. I also didn't count the "extended output" register as part of the CPU because that is an extension on top of its primary output.

    I did include all other gates that are in the IC packages: An unused module is in the count (there is one unused decoder in the control unit), as well as gates that are hooked to fixed inputs (L or H), even though all of those can be optimised away in VHDL. The 4-bit adders each have 4 non-inverting buffers internally that have no logic function, but I still include them. Furthermore, I count D-type flipflops as 5 gates, and SR-types as 4. Still, the total gate count of 930 is a lot lower than I would have guessed.

View all 49 project logs

Enjoy this project?



Bob wrote 5 days ago point

Kit worked great, placing the chips in position on the foam like that simplified things hugely and the build manual was very clear - my only soldering error was leaving one pin unsoldered which resulted in a strange offset on the VGA signal, till I spotted it.  I'd be keen to learn more about exactly why it is that for instance this clump of 74xx chips are the ALU and that clump are a register, etc - once that kind of info is made available it could be a great teaching resource along the lines of the excellent Elements of Computer Systems / From NAND to Tetris ( which @monsonite once pointed me towards.

Might I suggest Google Groups as a quick & easy way to get a forum community up?

  Are you sure? yes | no

lion mclionhead wrote 04/14/2018 at 20:41 point

Interesting video from 8bit guy.  It's sort of extraordinary that the gigatron outperforms a VIC 20 using only discrete logic gates for a CPU, but the trick is using modern memory chips & cost.  If it just drove a serial port instead of driving a CRT, it could run much more powerful demos.  8 bit guy was hard on it because he only saw the default firmware spending all its clockcycles driving the CRT.  

  Are you sure? yes | no

Marcel van Kervinck wrote 04/14/2018 at 21:02 point

We absolutely love his episode! We don't think he is hard on it at all... He presents the project in a superb manner. As he mentions at the end, the programmability is a matter of software, and it is the next phase of the project. The Apple-1 didn't come with a built-in BASIC either, for the same reason: it takes time to build a software environment.

  Are you sure? yes | no

Ruud van Falier wrote 03/27/2018 at 09:57 point

Such a cool project and also very extensive!
Ordered the kit and built it this week:

Now for diving into the mechanics and figuring out how everything works exactly :-)

  Are you sure? yes | no

Marcel van Kervinck wrote 03/27/2018 at 10:18 point

So cool to see it work!

  Are you sure? yes | no

Stuart Longland wrote 02/24/2018 at 21:47 point

I'm guessing the tail end of "On The Turning Away" heard in the bouncing ball video is an artefact of something playing elsewhere in the background and not being played by the computer itself?

Still, damn good effort for purely TTL.

  Are you sure? yes | no

Marcel van Kervinck wrote 02/24/2018 at 21:52 point

Thanks :-) It can make proper bleeping sounds though. It has 4-bits sound output (16 levels) and the default loop squeezes 4 software channels through that. They can synthesise pulse, triangle, sawtooth, etc. It sounds crappy but charming, just right!

  Are you sure? yes | no

Stuart Longland wrote 02/24/2018 at 21:56 point

Given a lot of music was constructed with those four primitives… that's probably just fine.  The SID chip does similar with 3 voices.

My only concern here is look out for the DMCA trolls, while it's clear to us (and anyone with intelligence) that the music is just co-incidentally playing in the background … some lawyer might have a momentary lapse of reason and declare the entire video a derivative work. :-)

  Are you sure? yes | no

Marcel van Kervinck wrote 12/26/2017 at 07:12 point

Anyone attending 34C3 in Leipzig this week: we will be strolling around, and of course we'll bring Gigatron prototypes!

  Are you sure? yes | no

monsonite wrote 11/08/2017 at 18:28 point

Hi Marcel,

Great work!  Faster, simpler and cheaper than the original IBM PC - love it!

Is there a schematic available for your design?  I'm interested in the final approach you took for your ALU.

Interested to hear some more about the virtual machine you hinted upon.

I have shared your work with

Well Done


  Are you sure? yes | no

Marcel van Kervinck wrote 11/08/2017 at 19:10 point

The full schematic might appear in some later stage as it is quite a mess in need of serious cleanup and I'm working on software the upcoming weeks. But the ALU is described adequately elsewhere: the "Logic" stage comes from here  (bottom of the page) and the ALU uses two of those with two 4-bit adders, as described here:  except that my design does without the 3rd stage that only provides right-shifting. So in total it is 8x'153 and 2x'283 with 5 control signals going in. Dieter's pages suggest that you need 8 signals, but most of them have the same value for the common operations. The carry-out goes back into the condition decoder where it acts as an allzero-indicator during jumps. There is no flags register as it costs too many chips for too little added value. I do right-shifting in software using the "single-instruction subroutine" technique described in the log on pipelining. This computer doesn't need shifting that much because the graphics layout is 1 byte = 1 pixel.

  Are you sure? yes | no

monsonite wrote 11/11/2017 at 18:33 point

Hi Marcel,

I'm suitably impressed with the elegance of your design that I have taken time to transcribe it to EagleCAD, so that I can get a better understanding of the control and data paths.

After pondering your Control Unit schematic for an hour yesterday lunchtime, and how it decodes the ALU instructions and generates the various addressing modes and jumps, I was happy that I could figure from the bus and dataflow diagram how most of the rest of it worked. 

Now that the bulk of the design is captured, I'm figuring out a way of using an ATmega1284 as an easy to update ROMulator device, running code from faster RAM and a way of extending by adding more VRAM.

When you consider that the first Sinclair ZX80 machine took 18 TTL chips, plus Z80, ROM and RAM to create a monochrome TV picture of 32 x 24 8x8 characters, for just another 18 chips they could have replaced the Z80 and had something that produced colour graphics and ran at 4 or 5 times the speed.



  Are you sure? yes | no

Justin Davis wrote 01/02/2018 at 16:51 point

I don't think schematics are ever really "finished", but the schematic that the layout was made from would be most helpful even if it is a mess.  I would like to see them because I would like to try to recreate it in an FPGA.  You could post them now, and then replacement them with a cleaned up version once you have it finished.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 10/28/2017 at 12:41 point

Amazinger :-D

  Are you sure? yes | no

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