View unanswered posts | View active topics It is currently Wed Jul 08, 2020 5:22 am

Reply to topic  [ 25 posts ]  Go to page 1, 2  Next
 Gigatron - A TTL machine with integrated VGA 
Author Message

Joined: Mon Aug 14, 2017 8:23 am
Posts: 106
Since its conception in 2017, this elegant TTL microcomputer has come a long way - with over 200 kits sold by July 2018.

An update will appear at the end of this thread.

As seen on Hackaday 6-11-17

This is an 8 bit machine made entirely from 34 simple TTL ICs, a 70nS SRAM and a 16-bit wide ROM.

The machine can generate scrolling text and simple games in colour - such as Breakout.

The VGA generation hardware (from a previous project) has cleverly been combined with an ALU to make a highly integrated design.

It was first built on a raft of breadboards but later converted to a pcb.

The ALU does not use the now hard to find 74xx181 but is built from simple multiplexers and 4 bit adders. 10 ICs are used in the complete 8-bit ALU.

The interesting thing about the ALU is that it requires just 4 control lines to select the ALU operation - making for almost no decoding needed.

Here's the link to the ALU ... est&page=4

The rest of the design can be followed in the project log here: ... r-from-ttl

Running at 6.25MHz, the author describes it as smaller, cheaper and faster than the 1981 IBM PC. Not bad for a bag of TTL.


Last edited by monsonite on Sun Mar 24, 2019 10:36 am, edited 4 times in total.

Wed Nov 08, 2017 2:32 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1419

Wed Nov 08, 2017 4:41 pm

Joined: Mon Aug 14, 2017 8:23 am
Posts: 106
Hi All,

Since reading about the TTL VGA computer on Hackaday last November, it's designer Marcel van Kervinck assisted by friend Walter Belgers have released it as a nicely presented kit.

I purchased one of these kits - now known as the "Gigatron TTL Microcomputer" and spent an evening constructing it. There are 36 TTL ICs to solder - I chose to use turned pin sockets, plus a 64Kx16bit EPROM and a 32Kx8 SRAM.

The design uses 74HCT series logic - so is low power, and can easily be powered from a USB supply or USB port on a laptop.

The machine produces a 160 x 120 pixel VGA output in 64 colours - and there are some example programs/games provided. The overall look and feel is of the mid to late 70s - when the first TV and arcade video games appeared.

The design is a triumph of TTL minimalism. It uses standard TTL parts - such as multiplexers, decoders, registers and simple logic gates.

Whilst Marcel could have use the 74xx181 ALU - he felt that these chips are so rare now, that it would not make commercial sense. Instead he chose an ALU design promoted by Dieter Muller - based on eight 74xx153 multiplexers and a pair of 74xx283 4 bit adders.

If you enjoy elegant design - it's worth looking at this ALU design, as it could easily be used elsewhere with a little adaptation. Just five 16 pin packages will give you a 4-bit wide slice - capable of more than the old '181, and much cheaper.

Dieter's original article begins here

Marcel's instruction set has only 8 instructions, ADD, SUB, AND, OR, XOR, LOAD, STORE and JUMP.

These are combined with 4 data sources, and 8 addressing modes - making a full 256 instructions. There are also 8 conditions available in the jump instruction.

The 8 bit instruction is held in the upper byte of the program ROM, allowing an 8-bit immediate data to be held in the lower byte.

The output of the ROM is held in an 8-bit Instruction Register and an 8-bit Data Register. A new instruction is fetched on every clock cycle - with the registers providing a basic pipelining method.

The program counter is just four 74xx161 counters, with control signals to load either the top byte or the bottom byte. This allows local jumps plus long jumps that cross page boundaries to be performed.

At the heart of the design is the control unit which decodes the various fields of the Instruction byte and generates the necessary signals to control the ALU, data source selector, conditional branch etc. Again, Marcel has reduced this to just six TTL parts, including 74xx138 and '139 for decoding the instruction, source and condition fields - and by using a ROM consisting of 30 diodes, generates the control signals for the ALU, registers and RAM access.

During the design exercise, Marcel kept a record of the equivalent number of gates used in the TTL devices. Not counting ROM, RAM or the input shift register, there is a remarkable low gate count of 930 basic gates.

VGA Generation

The microcomputer was designed to generate 1/4 VGA, and for this reason it has both an X counter and a Y register - to allow pixels to be efficiently accessed from RAM and output to a resistor network to provide a 6-bit VGA signal - plus the Hsync and Vsync. The use of an auto-increment X counter and [X,Y] addressing mode makes this easy in software. Smooth scrolling video, and other effects are possible in software.

16-bit Virtual Machine

Whilst this is an 8-bit Harvard machine, Marcel has written a 16-bit virtual (Von Neuman) machine interpreter that executes out of RAM. His interpreter is inspired by Wozniack's "Sweet 16" and is remarkably quick. It can interpret 34 primitive instructions - generally between 14 and 28 clock cycles long. The longest - a 16-bit ADD takes 28 cycles, which the stock machine executes in 4.48uS. I believe on a 1MHz 6502 this would be 20uS.


Whilst supplied with a 6.25MHz crystal - the machine will accept an 8MHz crystal and still produce VGA output that most modern monitors will sync to.

I have replaced most of the ICs in the ALU, instruction decoder and registers with 74Fxx series logic. This allows the machine to run on a 10MHz crystal, allbeit at the expense of extra operating current.

The machine uses a 100nS M27C1024-10F1 EPROM (or a pin compatible 45nS OTP AT27C1024) and a 55nS SRAM.

I'm taking steps to replace the RAM with a 10nS part, and hope to source a faster OTP ROM. It will be interesting to see just how fast this design can be pushed.

Here is a fascinating TTL processor made from low cost parts. (Average cost about $0.50 per package). It's supplied on a generously track spaced 6"x 9.5" 2 sided pcb in an attractive wooden case.

If, like me, you wanted a TTL cpu - but didn't want all the hard-work, this is an excellent starting point for your learning and experimentation.

Kits and further information from

All ROM software on Github

control_unit.JPG [ 68.84 KiB | Viewed 9341 times ]
condition_decodes.JPG [ 66.97 KiB | Viewed 9341 times ]
architecture.JPG [ 64.84 KiB | Viewed 9341 times ]
Sun Apr 29, 2018 11:02 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1419
Excellent - I do like the idea of a simple machine which then runs a useful VM. Best of both worlds: simple to understand CPU and easy to use for programming. Plus a free lesson in Turing equivalence and virtualisation!

I hadn't realised this is the same machine that's now called Gigatron: in another thread Marcel showed up:

Sun Apr 29, 2018 2:57 pm

Joined: Mon Aug 14, 2017 8:23 am
Posts: 106
Hi Ed,

It was in November 2017, that I first mentioned the Gigatron on this forum.

This is the excellent work of Marcel and Walter - and can be found on the website here

It's available as a DIY kit - and if you really want to make your own TTL Computer this is a great starting point.

Since the kit was introduced in the spring, there have been a number of innovations. This is like 1975 all over again - just like the Altair 8800.

Now you can have a PS/2 keyboard interface, Tiny BASIC (with line/pixel graphics capability) and WozMon - Wozniak's first monitor - as used on the Apple 1.

This machine highlights what you can do with a handful of TTL plus some very clever software. If you are looking for a new project for 2019 to explore the capabilities of simple TTL machine I suggest that you check out the Gigatron site.

I'm sure that this architecture will prosper as an FPGA friendly design - there's the first implementation in Verilog described here:

Also - there's now a Gigatron clone with an integrated keyboard - documented here

Who would have imagined that so much could be achived from a modest pile of TTL chips......

Happy New Year


Fri Dec 28, 2018 4:07 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1419
monsonite wrote:
I'm sure that this architecture will prosper as an FPGA friendly design - there's the first implementation in Verilog described here:

Also - there's now a Gigatron clone with an integrated keyboard - documented here

Who would have imagined that so much could be achived from a modest pile of TTL chips......

Great news! (Might be worth updating the head post subject, aka thread title, to add Gigatron?)

Happy new year to you too, and everyone here.

Fri Dec 28, 2018 4:57 pm

Joined: Tue Jan 15, 2013 10:11 am
Posts: 114
Location: Norway/Japan
I'm ordering a kit.

Fri Dec 28, 2018 5:32 pm

Joined: Mon Aug 14, 2017 8:23 am
Posts: 106
Hi All,

Yesterday I read some of the material on the TTL "Weeny Bitter" design - promoted by the Amateur Computer Club, in the UK.

I noticed the date of the first article - Summer 1975, and realised that within a couple of months, the Weeny Bitter would be consigned to history by the launch of the $25 6502.

The Weeny Bitter was an 8-bit machine, capable of addressing a 64K address space. Built from standard 74XX series TTL using about 86 packages to implement the simplest version with just 256 bytes of memory. This would require three wiring boards - each 8" x 8" - a major undertaking for even the most enthusiastic ACC members.

By December of 1975, the ACC newsletter had a round up of all the available and now affordable microcontrollers - which I suspect deterred most readers of embarking on the Weeny Bitter project.

Moving forwards 40+ years, and Marcel van Kervinck launches the Gigatron - a TTL microcomputer with colour VGA graphics, as an affordable DIY kit. I had thoughts of building a TTL microcomputer - but Marcel had worked tirelessly to eliminate all the "beginners pitfalls" and the 150 Euro kit seemed like great value for a weekend project.

What had made this possible? It was not the TTL itself - as that had been around for over 40 years. A TTL processor with roughly the same performance as a 6502 capable of generating colour graphics and hosting simple games such as Tetris etc.

Here are my thoughts on how this is now achievable.

1. This is a retrocomputer. It's easier to reproduce the capabilities of something that has previously existed - using modern technology, than create something new for the first time. Marcel was influenced by Steve Wozniak's Sweet 16, WozMon, Apple 1 and Dennis Allison/Tom Pittman's Tiny BASIC.

2. Modern laptops can be used to host all the design tools. Within a few weeks of Marcel publishing his instruction set and ROM, there was a full emulator, assembler and compiler for the virtual machine available. New ROM images could be assembled, simulated and generated quickly.

3. Gigatron makes clever use of ROM and RAM components that were inconceivable in the mid-1970s. The design uses a 16-bit 128K EPROM to hold 8-bit instruction and 8-bit data side by side in the same word - effectively an 8-bit Harvard architecture. This is an efficient approach to passing instruction plus data/address to the ALU.

4. The code in ROM implements a 16-bit virtual machine with 34 primitive instructions. Each opcode is just a jump address offset into the code that implements the virtual machine interpreter. The virtual machine implements a Von Neuman architecture - executing code out of RAM. Whilst the interpreter runs at about one 20th of the speed of the native machine - the slowest interpreted instruction, a 16-bit ADD executes in 28 cycles of 6.25MHz clock or 4.5uS. A 1MHz 6502 would take 20 cycles or 20uS for the equivalent instruction. So the combination of faster TTL logic and an interpreter can match or exceed the sort of performance available from the mid-1970s microprocessors.

5. Creating video to drive a TV set was hard work in 1975. Don Lancaster's TV Typewriter led the way in 1973 - but this needed about 40 TTL devices to produce the 32 char x 16 line monochrome video and read the keyboard. Using a now dated VGA monitor significantly reduces the overhead of producing a colour display - so the Gigatron can offer so much more with a similar chip count.

6. Early machines had to deal with the practicalities of keyboard scanning and cassette interfaces. These led to further complexity and increase in package count. Marcel has found a practical and economic solution to this by using an ATtiny85 to decode a PS/2 keyboard and allow RAM code to be uploaded to the Gigatron. Whilst purists might scream "That's Cheating" using an ATtiny - it was a quick an sensible approach to make the Gigatron more accessible to its Users.

7. Low cost pcb design tools are available - such as Eagle and KiCAD, plus very cheap pcb manufacturing - mainly in China. These allow the hobbyist to take on an ambitious hardware project, that previously would have demanded far greater financial resources.

8. The Internet - allows instant sharing of information, ideas and source code. Search engines can find anything within a couple of clicks - even the 1975 ACC newsletters that started this whole process off.

Thoughts for 2019:

I have overclocked the Gigatron at 10MHz an increase from the standard 6.25MHz crystal. If I can get up to 12.5 MHz there will be opportunities to increase the graphics resolution from 160x120. Can the Gigatron design be pushed further? We now have TTL gates with 3nS propagation delay and flip-flops that clock at 210MHz. 10nS RAM and 45nS EPROM is available cheaply.

The Gigatron emulator has been ported to run on Mac OS X. Gigatron also has been emulated on a STM32F405 ARM Cortex M4 and exists as a soft core written in verilog.

This opens up the ability to run the Gigatron on a low cost FPGA board - and possibly extend its capabilities to greater video resolution and speed.

The basic Gigatron design has been reproduced with an integral keyboard layed out on a single pcb.

There is now a forum for Gigatron users here:

With the Gigatron project now supporting an active user group and forum, I hope that it helps to promote what can be done with TTL microcomputers and serves to stimulate further interest and discussion of TTL machines on this forum.



Sun Jan 20, 2019 2:40 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1419
Nice analysis! I would think the mindset through to at least the mid-70s would be that to understand computers, you need a CPU. Microprocessors changed that quite thoroughly by the mid-80s - microcomputers are a black box, compared to a CPU built from TTL.

It would be interesting to see a faster Gigatron with more pixels - although, it might be that if your CPU speedup by 2x allows you to provide 4x the number of pixels, that actually has you falling behind with regard to making changes on screen.

Sun Jan 20, 2019 4:47 pm

Joined: Mon Aug 14, 2017 8:23 am
Posts: 106
Hi Ed,

I wanted to highlight in my analysis that there are several converging reasons why the task of implementing a TTL microcomputer has got a whole lot easier in recent times.

We seem to be able to do so much more, with less - and that is partly to do with hindsight, better technology and better tools.

I re-read Dr. Jefyll's post of Feb 2016 - about tiny TTL gates with 3nS propagation time, and flip-flops that would clock at 175MHz. Another good reason for re-thinking simple designs based on TTL.

There's even a 3 input NOR - if anyone wants to make an Apollo Guidance Computer in Tiny TTL!

A faster, more powerful Gigatron would be good to see. Perhaps one which could have a much faster clock during horizontal and vertical blanking. Alternatively one that uses a video coprocessor (James Bowman's Gameduino possibly) which takes care of all the graphics allowing the TTL processor to run at full speed.

With 10nS RAM we could theoretically have a 100MHz clock - but I suspect that this will be severely restricted by the access time of the ROM and the time needed to propagate the carry through the adder.

By switching to FPGA technology rather than discrete TTL, we must be close to having a simple processor (of the 6502 class) that will run at 100MHz, and provide 2 orders of magnitude of speed improvement over the original devices. Perhaps the 25,000 transistor ARM 1 would be a suitable candidate to recreate as a soft core in verilog for an FPGA implementation.

There are many opportunities for experimenting here, we are blessed with a wealth of cheap hardware, software tools and good ideas. Even if wiring up TTL does not appeal, early cpus can be emulated on low cost boards - such as ARM M4 "Blue Pill" or the bunch of new FPGA boards - now available for around $50 or less.

Hopefully 2019 will prove to be a fruitful year.



Last edited by monsonite on Sun Mar 24, 2019 11:51 am, edited 1 time in total.

Sun Jan 20, 2019 5:32 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1419
Yes, it's a good analysis. Everything is cheaper now, and reasonable sized memories (both RAM and ROM) are ridiculously cheaper.

Sun Jan 20, 2019 6:41 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1419
Here are some links to the software layers of the Gigatron:

The TinyBasic interpreter source can be seen here, in a language 'gcl'.

This is the gcl compiler, in python.

But the docs might be the best start for gcl and for the machine language, gt1.

For an assembler, debugger, emulator, and more, see here.

Sun Mar 24, 2019 9:02 am

Joined: Mon Aug 14, 2017 8:23 am
Posts: 106
Hi Joan, Ed

The designer of the Gigatron is Marcel van Kervinck - and he sometimes appears on this forum.

All of the Gigatron software is held on this Github repository:

You are correct in assuming that the sophistication of the machine came from clever software designed to extract the most from the minimal hardware. Marcel is a software engineer - and like you, he wanted to explore the hardware - in particular, what could be done with a few simple TTL chips.

The Gigatron uses an 8-bit instruction word usually paired with an 8-bit data word. The two are packed side by side into the 16-bit wide EPROM.

The 8-bit instruction is decoded by the control unit - to create 19 individual signals which control the entire operation of the machine. A diagram of the control unit is shown on the Gigatron thread. It uses 74HCT138 and '139 decoders and a wired OR array of diodes. A 74HCT240 buffer/driver chip ensures that the 5 signals that drive the ALU - have sufficient drive for the 8 multiplexers used in the ALU.

The inspiration behind the design of the ALU is credited to Dieter Muller (from who found a very elegant way of combining multiplexers and adders to make an ALU with a useful instruction set (ADD, SUB, AND, OR, XOR) as well as generating a carry bit from which conditional jumps can be decoded. The Gigatron ALU does not provide shift operations (two further shift registers and more control signals would be needed) - so these are programmed in look-up tables in ROM. The ALU is compact - just 10 chips, costing around $5 to implement, and can be extended to 16-bit or longer wordsizes.

As one of the key aims of the Gigatron was to produce colour video and sound, - much of the low level firmware written in assembler is concerned with generating carefully timed horizontal and vertical sync signals to meet the VGA specification - and the moving of 6 bit pixel data from RAM. As these processes must always be going on in the background, the cpu processing can only occur during the video-blanking periods. Marcel wrote an interpreted virtual machine, which implements a 16-bit Von Neuman architecture - with 34 instructions executing out of RAM - which are carefully timed, so that they will only be executed if there is sufficient time remaining in the video blanking period. The overhead of timing the virtual machine instructions adds a few clock cycles - but all execute in 14 to 28 (6.25MHz) clock cycles.

This is a very clever bit of program design - to ensure synchronisation of all of the video generation tasks, and provide a more capable 16-bit virtual machine - which is easier to program, than the underlying 8-bit Harvard machine.

The virtual machine - it's ISA and the interpreted language it executes, is unique to Gigatron, and took a significant amount of time to develop. It does not attempt to model any other processor - like 6502 - so there is not the luxury of being able to borrow existing code from that source.

Marcel wrote a simple simulator in about 110 lines of C code - that would simulate the TTL hardware, and give him a platform from which he could develop the ROM and the native assembly code needed to execute the virtual machine instructions. This simulator listing is available in the Gigatron Github repository. ... cs/gtemu.c

There is a forum to discuss the Gigatron at - plus a whole lot of project details and notes from the early development of the machine on the website. Both these sources have useful snippets of information - detailing some of the design challenges and decisions taken that influenced the overall design.

Hackaday. io ... rocomputer

My own involvement is that I bought a Gigatron kit from Marcel - and I have replaced most of the 74HCT chips with 74F. I have pushed the clock frequency up to nearly 12MHz, but this is now limited by the 100nS access time of the ROM chip. I have sourced a faster ROM with 45nS access - and with this I hope to get the design up to 16MHz.

However at this point it will probably be the length of pcb tracks which prevent further increase in clock speed. The pcb was designed around DIP packages and generous spacing between ICs. The main databus travels most of the way around the perimeter of the pcb - about 50cm or more of tracks. To get reliable operation at higher speed it will probably be necessary to use surface mount ICs which have smaller overall dimensions, a reduced pcb size - with emphasis on reducing track lengths, and a 4 layer pcb, to reduce EMI. The current Gigatron produces a lot of interference - that can be heard on a nearby radio.

I am looking to create some modules that package the main parts of the Gigatron onto smaller plug-in pcbs - using 74F surface mount components. The first and obvious candidate is the 8-bit ALU - where 2 modules can be used together as a 16 bit ALU. One speed limiting factor will be the speed at which the ALU can propagate the carry when adding two large 16-bit numbers.



Last edited by monsonite on Sun Mar 24, 2019 3:18 pm, edited 1 time in total.

Sun Mar 24, 2019 11:43 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1419
Thanks for the overview!

As it happens I was idly thinking about this kind of thing:
monsonite wrote:
One speed limiting factor will be the speed at which the ALU can propagate the carry when adding two large 16-bit numbers.

It feels like the kind of thing where one extra clock cycle could be quite a help. A bit like the 65C02's decimal arithmetic. In the specific case of the gigatron with the software-driven video, that might be more trouble than it would be elsewhere. (I'm reminded of the Alto, which did all disk I/O in microcode, if I remember correctly. Oh, even more: "The display, disk, Ethernet, and even the refreshing of the Alto’s dynamic RAM was driven by microcode running on the Alto’s processor.")

Sun Mar 24, 2019 12:05 pm

Joined: Wed Apr 24, 2013 9:40 pm
Posts: 188
Location: Huntsville, AL
Second that. I have certainly enjoyed the discussion.

Michael A.

Sun Mar 24, 2019 6:09 pm
Display posts from previous:  Sort by  
Reply to topic   [ 25 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software