The Gigatron board is missing a fairly important component for a computer: a microprocessor.1

Marcel van Kervinck and Walter Belgers built its CPU instead from a small collection of classic 7400-series logic chips. The registers, multiplexers and logic remain physically visible rather than disappearing into a black rectangle containing billions of transistors and several lifetimes of engineering.1

The result is an 8-bit computer that can display graphics, produce sound, read input and run programs.1

It was not designed to compete with a modern machine. It was designed to make a computer understandable by building it.

Remove the microprocessor and the CPU comes back into view

Learning CPU architecture usually begins with an abstraction.

We draw an arithmetic unit, registers, a program counter and buses. Then we explain that a real processor contains something conceptually related, only several million design decisions deeper.

Gigatron goes the other way.

Its discrete logic chips directly form the 8-bit processor. The project says it uses no complex logic chips at all, including no microprocessor.1 The functional blocks are therefore not only boxes in an educational diagram. They exist on the board the learner assembles.

That is a fairly extreme design choice: simplify the machine until its operation becomes physically inspectable again.

There is an obvious consequence. Remove specialized chips and something else has to perform their jobs.

That something is the CPU.

The processor also has to make the screen

Gigatron does not rely on the usual dedicated peripherals for video, sound and some I/O either.1

The main processor handles those functions itself.

That creates an unusual timing problem. Application work has to coexist with the continuous job of producing the video signal. The CPU cannot simply spend every cycle on whatever program the user launched. It must keep feeding the display at the right moments.

A conventional product would treat that constraint as something to hide.

Gigatron turns it into part of the lesson.

At low level, “display an image” stops being a free service supplied by an invisible graphics subsystem. Something is generating scan lines on schedule while trying to leave enough cycles for useful work.

An old-fashioned limitation becomes a direct way to see where computer time actually goes.

Then it builds another CPU inside the first one

This is where the architecture gets pleasantly strange.

The native hardware processor is intentionally minimal. To make programming more practical, the ROM implements a virtual 16-bit CPU, usually called vCPU.2 3

That software processor runs during time the physical CPU is not spending on critical tasks such as video generation.3

The stack is therefore unusual: TTL logic implements a tiny physical processor, which runs a virtual processor, which gives applications a more convenient instruction set.

This is not merely a later emulator bolted on for novelty. The repository contains the vCPU documentation, compiler, system calls, BASIC programs, C tooling and the ROM used by the computer.2

Hardware simplicity does not remove abstraction. It moves abstraction into a layer you can still open and read.

You can learn by descending one layer at a time

Frans Faase published a detailed exploration after studying Gigatron's emulator and ROM.3

His process captures what makes the machine useful.

He first rewrote native instructions as pseudo-C to understand what the encoded operations actually did. He then worked through the virtual CPU and its instruction encoding. The boundaries between processor, firmware and programming language become much less tidy than they appear on a modern system.3

That mess is educational.

You can begin with a relatively high-level program, descend into vCPU instructions, continue into native instructions and eventually arrive at the physical logic implementing them.

The explanation does not have to stop at “the processor handles it.”

Constraints create weird ideas

The ecosystem kept adding capabilities on top of the tiny machine.

The project documents compilers, games, audio, memory expansions and even 6502 emulation that lets Gigatron run Apple-1 software.1 2

Those results are more interesting as design exercises than as performance claims.

When a machine has very few resources and replacing it with a larger processor is against the point, every new feature requires a careful look at what already exists and where more behavior can fit.

On a modern computer, adding a feature may mean another library, process or chunk of memory. On Gigatron, the question can become: which cycles are genuinely free between pieces of the video signal?

That produces a different kind of programming discipline.

A kit meant to be finished, then mentally dismantled

Gigatron was sold as a kit. The official site reported reaching roughly 1,000 units in 2020 before the creators stopped commercial kit production.1

Its software had been BSD-licensed from the beginning. PCB design files followed, and in June 2020 the project announced that the complete machine was now open source.1 2

That matters for an educational object.

A genuinely inspectable machine should expose more than the components on the board. Its ROM, build tools, schematics and design logic need to remain available too.

Gigatron is now arguably more useful as a system to study, rebuild and modify than as a computer to “use” in the ordinary sense.

That is what keeps it from being merely retro decoration.

Sometimes learning needs a worse computer

A modern processor is vastly faster, more efficient and more capable.

It is also effectively impossible for one person to understand end to end.

Gigatron deliberately builds a less capable computer in order to preserve a rare property: a motivated learner can follow the path from logic gates to the program appearing on screen.

This is not nostalgia for slow machines and displays that demand attention every scan line.

It is a useful principle for educational tools: the best machine for learning is not always the one that hides the most complexity.

Sometimes you have to remove layers until the mechanism becomes visible again.