When 8 Bits is Overkill: Making Blinkenlights with a 1-bit CPU

When 8 Bits is Overkill: Making Blinkenlights with a 1-bit CPU

Speakers: girst (Tobi), Network Engineer

Conference: 39C3

YouTube: https://www.youtube.com/watch?v=XleFjCaHMJc

Overview

In an era dominated by multi-core processors, gigabytes of RAM, and cloud-native applications, Tobi (girst), a network engineer by profession, presented a captivating journey into the extreme minimalism of computing at 39C3. His talk, "When 8 Bits is Overkill: Making Blinkenlights with a 1-bit CPU," detailed his ambitious personal project: building a functional system around the Motorola 14500, a 1-bit Central Processing Unit (CPU) released in 1977. Far from a mere historical curiosity, Tobi’s endeavor involved constructing a 16x16 LED matrix to run Conway's Game of Life, pushing the boundaries of what's possible with severely constrained hardware.

This presentation served as a profound exploration of foundational computing principles, creative problem-solving under severe architectural limitations, and the often-overlooked history of microprocessors. Tobi meticulously detailed the idiosyncrasies of the 14500, its unique instruction set, and the intricate external logic required to make it perform complex tasks. His "blinkenlights" project, while seemingly "useless" by his own humorous admission, became a powerful demonstration of engineering ingenuity, highlighting how core computing concepts can be implemented with astonishing simplicity, offering valuable insights into hardware-software co-design and the art of resourcefulness in system architecture.

The talk not only showcased the technical feat of reviving and programming such an antique chip but also provided a deeper appreciation for the evolution of computing. By stripping away modern abstractions, Tobi revealed the bare metal challenges of CPU design, memory management, and control flow, offering a unique perspective on how even the most basic logical operations are constructed from the ground up.

Background

▶ Watch: Introduction to the 1-bit Motorola 14500 CPU (0:00)

The Motorola 14500 occupies a unique, often forgotten, niche in the history of microprocessors. Released in 1977, it predates the ubiquitous Intel 8086 (which formed the basis of the IBM PC) and was contemporaneous with the 6502 (powering systems like the Commodore 64 and Apple II). However, unlike its 8-bit or 16-bit contemporaries, the 14500 was designed with a singular, minimalist purpose: to replace relay logic. Often referred to as ladder logic due to its circuit diagram representation, relay logic was the backbone of industrial control systems, using electromechanical relays to implement boolean operations. The 14500, which Motorola cautiously termed an Industrial Control Unit (ICU) rather than a CPU, offered a solid-state, electronic alternative, promising greater speed, lower power consumption, and reduced physical footprint.

Its specifications underscore this minimalist philosophy. The 14500 features a 1-bit data bus and operates exclusively on 1-bit words. Crucially, it lacks many components considered fundamental to modern CPUs. There is no integrated program counter (PC); designers must provide external logic to sequence instructions. Similarly, there is no address bus directly connected to the CPU; address decoding and memory selection are entirely off-chip responsibilities. The 14500 also lacks a full Arithmetic and Logic Unit (ALU), possessing only a Logic Unit (LU), as arithmetic operations like addition and subtraction are largely meaningless for single-bit values. Its sole internal register is the Result Register (RR), functioning akin to an accumulator.

The minimal ICU system, as envisioned by Motorola, therefore required significant external components: a binary counter for the program counter, program memory (ROM or RAM), address decoding logic, and at least eight bits of scratch memory (external registers). Input/output operations were managed by external logic that distinguished between read and write signals from the CPU, directing them to inputs or outputs sharing the same addresses.

The instruction set of the 14500, while sparse, offers surprising versatility. Core instructions include LOAD, STORE, OR, AND, and XNOR. Notably absent is an XOR instruction, replaced by XNOR (exclusive not OR), which effectively serves as an equality check. More significantly, there is no direct NOT or inverse instruction. To perform inversion, the 14500 provides complement instructions such as Load Complement and OR Complement, which invert the value from an address before processing it. Other instructions include NOP (No Operation), SKZ (Skip if Result Register is Zero), JMP (Jump), and RET (Return), all of which signal via dedicated output pins that external logic must interpret.

A particular challenge with such a minimalist architecture is handling constants. Modern CPUs typically have immediate load instructions or zero registers. The 14500, however, requires a clever trick: to load a constant 1 into the RR, one can use OR complement RR. Regardless of RR's current value (0 or 1), RR OR (NOT RR) always evaluates to 1. Similarly, AND complement RR yields 0. Flow control is another area where the 14500 deviates from modern paradigms. While SKZ allows skipping a single instruction, more complex conditional blocks require an alternative. Tobi demonstrated how the IN (input enable) and ON (output enable) instructions could be leveraged. By disabling output (ON instruction), STORE operations effectively become NOPs, allowing code to "run through" without side effects, providing a rudimentary form of if/else logic by gating writes to the real world. This intricate dance between the CPU's limited capabilities and the extensive external logic highlights the fundamental challenges of early computing and the ingenuity required to overcome them.

Key Findings

▶ Watch: Understanding the 14500's unique 1-bit architecture (2:00)

Tobi's project with the Motorola 14500 yielded several key findings, demonstrating the potential of extreme minimalist computing and the innovative solutions required when working with such constrained architectures:

1. Feasibility of Complex Logic on a 1-bit CPU: The most striking finding is the successful implementation of Conway's Game of Life on a 1-bit CPU. This project, which involves intricate neighbor calculations, state updates, and display management for a 16x16 matrix, proves that even computationally intensive tasks can be broken down and executed by a processor with severe architectural limitations, given sufficient external support and creative programming.

1. Creative Solutions for Missing CPU Features: The 14500's lack of an integrated program counter, address bus, or NOT instruction necessitated ingenious workarounds. Tobi's design showcases how these fundamental CPU functions can be offloaded to external logic. This includes using binary counters for the PC, a PROM as a makeshift Memory Management Unit (MMU) for address decoding, and leveraging complement instructions and logical identities (RR OR (NOT RR)) for constant generation and inversion.

1. Novel Flow Control Mechanisms: The presentation highlighted the output enable (ON) and input enable (IN) instructions as a unique form of conditional execution. Unlike modern branching, ON and IN effectively gate subsequent STORE or LOAD operations. This allows entire blocks of code to be executed without effect if the output/input is disabled, providing a hardware-level "if/else" construct that bypasses the single-instruction skip limitation of SKZ.

1. "Volatile Non-Random Access Memory" (VRAM) Design: To manage the 512 bits of memory for the 16x16 display, Tobi devised a system he termed volatile non-random access memory. This system uses a shift register-based memory, overcoming the 14500's 4-bit address bus limitation (which only allows 16 addresses). Memory locations are accessed sequentially by incrementing an external counter, rather than direct addressing.

1. Relative Addressing with Hardware Adders: For Game of Life, accessing neighboring pixels is crucial. Tobi's design incorporated two adders into the memory address lines. These adders, controlled by specific address bits, allowed the CPU to temporarily "shift" its view of the sequential memory, effectively enabling relative addressing (e.g., one column right, one row up, or diagonals) without requiring complex address calculations within the 1-bit CPU itself.

1. Efficient Double Buffering: The display system employs double buffering to prevent flickering. This was achieved by using the topmost address bit in conjunction with an XOR gate. While the CPU reads from one memory plane, writes are automatically redirected to the other. Once a full frame is rendered, the planes are swapped, providing a seamless display update.

1. Challenges of Vintage Logic and Obsolescence: The project exposed numerous practical difficulties inherent in working with period-correct components. These included subtle hardware bugs like floating inputs leading to capacitive coupling and CPU resets, mixed edge-triggered logic causing timing issues, and the formidable challenge of programming obsolete bipolar ROMs that require high voltages and currents unsupported by modern programmers, necessitating a custom-built programmer. These issues underscore the complexities of low-level hardware design and debugging.

Technical Deep Dive

▶ Watch: The peculiar 'jump' instruction that 'blips' a pin (4:10)

The technical core of Tobi's project lies in masterfully circumventing the severe architectural limitations of the Motorola 14500 Industrial Control Unit (ICU). The 14500's 1-bit data bus and minimal instruction set demand extensive external logic and creative programming paradigms.

CPU Architecture and Instruction Set

The 14500 is fundamentally a 1-bit processor with a single internal Result Register (RR) (an accumulator). It lacks an integrated program counter (PC) and address bus. Instead, it provides output pins for JMP and RET instructions, which signal external logic (typically a binary counter) to reset or modify the program flow. Memory access relies on external address decoding and data appearing "magically" on the 1-bit data bus.

Its instruction set includes:

• LOAD A: Loads the bit at address A into RR.
• STORE A: Stores the bit from RR to address A.
• OR A, AND A, XNOR A: Logical operations between the bit at address A and RR, storing the result in RR. XNOR acts as an equality check.
• Complement Instructions: Load Complement A, OR Complement A, AND Complement A. These instructions read the bit at address A, invert it, and then perform the specified operation. This is the primary method for performing a NOT operation.
• NOP: No operation. Two versions exist: NOP and NOP F. NOP F is at the highest possible instruction value (all ones in memory) and triggers an output pin, intended for detecting invalid memory access.
• SKZ: Skip the next instruction if RR contains zero. This is the CPU's only direct conditional branch, limited to a single instruction skip.
• IN, ON: Input Enable and Output Enable. These instructions control dedicated output pins that external logic uses to enable or disable input and output operations, respectively. As discussed, they form the basis of advanced flow control.

Implementing Constants and Flow Control

Without immediate load instructions, constants must be generated. Tobi demonstrated:

• Constant 1: OR complement RR. If RR is 0, 0 OR (NOT 0) becomes 0 OR 1 = 1. If RR is 1, 1 OR (NOT 1) becomes 1 OR 0 = 1. The RR is always set to 1.
• Constant 0: AND complement RR. If RR is 0, 0 AND (NOT 0) becomes 0 AND 1 = 0. If RR is 1, 1 AND (NOT 1) becomes 1 AND 0 = 0. The RR is always set to 0.

For complex conditional logic beyond SKZ, the ON and IN instructions are critical. Tobi illustrated an "if/else" construct:

1. Check condition (e.g., LOAD A1).
2. If condition is false (RR is 0), execute ON to disable output.
3. Execute a block of LOAD/OR/AND/STORE instructions. If output is disabled, STORE operations become effective NOPs, discarding computation results.
4. After the block, force RR to 1 (OR complement RR) and then unconditionally re-enable output (ON). This effectively acts as an END IF, ensuring subsequent operations are always written.

Ladder Logic Translation

Tobi provided a practical example of converting ladder logic for a motor control circuit into 14500 assembly. The circuit involved an emergency stop (normally closed), a regular stop (normally closed), a start button (normally open), and a self-sustaining RUN signal for the motor.

The derived boolean equation was: RUN = (NOT EM_STOP AND NOT STOP) AND (START OR RUN).

Since NOT is unavailable, De Morgan's Law was applied: RUN = NOT (EM_STOP OR STOP) AND (START OR RUN).

The assembly sequence begins with CPU initialization: a NOP (to safely skip a potential RET), forcing 1 into RR, and then enabling IN and ON (as they are disabled on power-up). The main loop then implements the logic:

1. LOAD RUN
2. OR START (implements (START OR RUN))
3. AND complement EM_STOP (implements AND NOT EM_STOP)
4. AND complement STOP (implements AND NOT STOP)
5. STORE RUN
6. JMP (loops back to the beginning)

Game of Life Memory and Display Architecture

The most sophisticated aspect of the project is the memory and display system for the 16x16 LED matrix, which requires 256 bits for the current frame and another 256 for the next, plus some scratch memory, totaling 517 bits. This far exceeds the 14500's 4-bit address bus (16 addresses).

Tobi's solution is volatile non-random access memory. The 512-bit main memory is not directly addressable. Instead, it's a large shift register. A dedicated external counter chip, incremented by the CPU, sequentially steps through these 512 locations. This allows access to all bits, albeit only one at a time in sequence.

To implement neighbor lookups for Game of Life, which require relative addressing (e.g., current pixel +1 column, -1 column, +1 row, -1 row, and diagonals), Tobi employed two adders on the memory address lines. The lower two bits of the 4-bit address bus control one adder for column offsets (e.g., 00 for center, 01 for right, 11 for left). The upper two bits control another adder for row offsets. By manipulating these address bits, the CPU can temporarily shift its "view" within the sequentially accessed memory to read adjacent pixels. For example, 0000 accesses the current pixel, 0001 accesses the pixel to its right, 0100 accesses the pixel above, and 0101 accesses the top-right diagonal.

The display itself is double-buffered to prevent flickering. The 512-bit memory is split into two 256-bit planes. The topmost address bit, combined with an XOR gate, controls which plane is being read from and which is being written to. When the CPU performs a STORE operation, the XOR gate automatically swaps the write plane. Once a full frame is calculated, the planes are swapped, and the newly rendered image is latched onto the actual LED display, which is driven by modern 16-bit LED drivers (shift registers with constant current sources) for efficiency and reduced board space.

Firmware and Assembler

The firmware for Game of Life operates in two modes: simulate and generate.

• Simulate Mode: Calculates the next state for one pixel based on its neighbors, updates the memory, and then moves to the next pixel. This loops 256 times per frame.
• Generate Mode: Fills the board with random data using a Linear Feedback Shift Register (LFSR) (implemented with 14599 chips, providing a 255-bit sequence length pseudo-random number generator).

An interrupt, triggered at the end of each frame, checks if the board is "stuck" (i.e., no pixels changing). If so, it switches from simulate to generate mode to create a new pattern, then returns.

Since the 14500 can only JMP to address zero, all inner loops in the Game of Life algorithm had to be unrolled. Tobi wrote a custom Python script assembler to convert mnemonics into hexadecimal machine code, which was then burned onto EEPROMs.

Challenges and Debugging

The project was not without its hurdles:

• Floating Inputs: Leaving inputs of 4000 series logic chips floating caused instability. Capacitive coupling between the clock and reset lines led to the CPU resetting on every clock cycle during partial bring-up.
• Data Bus Contention: A floating input on a bus transceiver led to two peripherals fighting over the data bus, resulting in a "half" voltage state, excessive power consumption, and overheating.
• Mixed Edge-Triggered Logic: Incorrectly mixing rising-edge and falling-edge triggered counter chips caused timing issues and operations to happen "off-beat."
• Line-Level vs. Edge-Triggered Resets: The interrupt flip-flop was edge-triggered, but the program counter reset line was line-level triggered. This caused the PC to remain reset if the interrupt signal stayed high for too long.
• Obsolete Bipolar ROMs: The chosen bipolar ROMs for the makeshift MMU were extremely obsolete, requiring high current/voltage programming that modern programmers don't support. Tobi had to build his own simple, passive programmer using switches.

These challenges highlight the intricate nature of low-level hardware design and the importance of meticulous attention to detail, even for seemingly simple components.

Demo / Proof of Concept

▶ Watch: Exploring the 14500's unusual instruction set (XNOR, complements) (5:30)

The culmination of Tobi's detailed technical work was the physical demonstration of his Motorola 14500-powered "blinkenlights" project, a 16x16 LED matrix running Conway's Game of Life. The board itself is a testament to retro-computing, populated with numerous period-correct integrated circuits (19 chips on the front, 16 for the LED shift registers on the back).

During the talk, the board was displayed, showcasing the dynamic patterns of Game of Life. The LEDs illuminated and extinguished, depicting the birth, survival, and death of cells on the grid. This visual proof of concept elegantly illustrated the successful implementation of complex cellular automata logic using the severely constrained 1-bit CPU. The double-buffered display mechanism ensured smooth, flicker-free transitions between frames, enhancing the visual experience.

A humorous, anachronistic detail of the project was its USB-C power delivery compliance, a stark contrast to the late 1970s/early 1980s components otherwise used. This touch added a modern convenience to the vintage hardware, eliciting laughter from the audience. The demo highlighted the system's ability to autonomously run the simulation, and critically, its intelligent firmware: if the Game of Life pattern became static (stuck), the system would automatically switch to its "generate" mode, filling the board with a new pseudo-random pattern, ensuring continuous visual interest and demonstrating a level of self-awareness within the minimalist design. The live demonstration served as compelling evidence that, despite its limitations, the Motorola 14500 could indeed be engineered to perform tasks far beyond its original industrial control intent.

Defensive Implications

▶ Watch: Clever workaround: loading constants without a 'load immediate' instruction (8:30)

While Tobi's talk is fundamentally about retro-computing and hardware engineering rather than direct cybersecurity, several defensive implications and lessons can be drawn from his deep dive into the Motorola 14500 and its ecosystem. These insights are particularly relevant for understanding embedded systems security, industrial control systems (ICS/SCADA), and the broader challenges of hardware-software co-design.

1. Resilience Through Simplicity (and its limits): The 1-bit CPU's minimalist design inherently features a drastically reduced attack surface compared to modern, complex processors. Fewer instructions, limited registers, and the complete absence of advanced features like virtual memory or privileged modes mean fewer vectors for exploitation. There are no complex memory management units to bypass, no speculative execution vulnerabilities, and no intricate instruction pipelines to corrupt. This extreme simplicity, by design, could be seen as a form of inherent resilience. However, this simplicity also means that any compromise of the external logic (e.g., the program counter, address decoding, I/O control) directly impacts the system, highlighting that security must extend beyond the CPU itself.

1. Understanding Foundational Computing: Working with such a primitive architecture forces a profound understanding of how basic CPU functions, memory access, and control flow are constructed from first principles. This foundational knowledge is invaluable for security professionals, especially those involved in embedded security, firmware analysis, or reverse engineering. By understanding how a CPU could be built with minimal components, one gains a deeper appreciation for the potential vulnerabilities and attack surfaces in more complex systems, where these foundational elements are abstracted away. It helps in identifying subtle hardware Trojans, side-channel attack vectors, or unexpected interactions at the lowest levels of the stack.

1. Hardware-Software Co-design and Trust Boundaries: The Motorola 14500's reliance on extensive external logic for basic CPU functions (PC, address bus, I/O enablement) underscores the critical importance of hardware-software co-design in embedded systems. Security is not just about the software running on the chip, but also about the integrity and correctness of the surrounding hardware. Trust boundaries are not just within the CPU but extend to every component on the board. A vulnerability in the external program counter, for instance, could lead to arbitrary code execution, even if the CPU itself is "secure." This highlights the need for a holistic security approach that considers the entire system-on-a-board.

1. Supply Chain and Obsolescence Risks: Tobi's struggles with sourcing and programming obsolete bipolar ROMs directly illustrate significant supply chain and long-term maintenance risks, especially pertinent to legacy industrial control systems. Many ICS environments still rely on decades-old hardware. If critical components become unavailable or require specialized, unsupported tooling, maintaining and securing these systems becomes incredibly challenging. This can lead to:

• Vulnerable Hardware: Inability to replace or update failing components, potentially leaving systems exposed.
• Counterfeit Parts: Reliance on grey markets for obsolete parts, increasing the risk of counterfeit components with embedded malicious logic.
• Lack of Expertise: The specialized knowledge required to work with such vintage hardware (e.g., building a custom ROM programmer) becomes a rare skill, making incident response and patching difficult.

1. Subtle Hardware Bugs and Debugging Challenges: The various hardware bugs encountered (floating inputs, capacitive coupling, mixed edge-triggered logic, line-level vs. edge-triggered resets) reveal how easily subtle electrical and timing issues can lead to system instability, unexpected behavior, or even denial-of-service conditions. These types of low-level hardware flaws can be incredibly difficult to diagnose and fix. In a security context, such subtle interactions could be exploited by sophisticated adversaries for:

• Reliability Attacks: Causing system crashes or unpredictable behavior.
• Side-Channel Attacks: Exploiting power consumption spikes or timing variations due to unexpected electrical states.
• Hardware Trojans: Malicious circuits designed to induce such subtle, hard-to-detect failures or provide backdoors.

In essence, Tobi's project, while a celebration of minimalist computing, serves as a powerful reminder that security in embedded and industrial systems requires a deep appreciation for the underlying hardware, its historical context, and the complex interplay between physical components and logical operations.

Key Takeaways

• The Motorola 14500, a 1-bit CPU from 1977, demonstrates extreme minimalist computing, designed to replace relay logic in industrial control systems.
• Building complex systems with such primitive architectures necessitates creative hardware-software co-design, offloading fundamental CPU functions like the program counter and address decoding to external logic.
• Non-traditional flow control mechanisms, such as leveraging the IN and ON (input/output enable) instructions to gate memory operations, can enable sophisticated conditional logic beyond simple single-instruction skips.
• The project showcased ingenious solutions for memory management and addressing, including volatile non-random access memory with external counters and hardware adders for relative addressing in a sequential memory space.
• Working with vintage components presents unique engineering challenges, including debugging subtle hardware bugs like floating inputs, capacitive coupling, mixed edge-triggered logic, and the difficulty of programming obsolete bipolar ROMs.
• This deep dive into foundational computing principles provides invaluable insights for understanding embedded systems, highlighting the critical interplay between hardware integrity and software security in even the most basic architectures.

About the Speaker(s)

Tobi, who goes by girst online, is a network engineer by day. His professional work involves interesting projects ranging from in-house data centers to managing very large access networks. To balance the demands of his day job, Tobi dedicates his nights to developing "completely useless electronic projects." His passion lies in exploring the fascinating world of retro computing and pushing the boundaries of what can be achieved with minimalist and vintage hardware, as exemplified by his 1-bit CPU project.