In Building a C64 from Scratch: Sprite Engine, Dr. Matt Regan continues his ambitious hardware series. His mission? Build a Commodore 64 without using the original VIC-II, SID, or 6510 chips. Instead, he’s using EPROMs, SRAM, and TTL logic.
This episode marks the start of the second trilogy—focusing entirely on the C64 sprite engine. It’s an eye-opening journey through hardware-level sprite rendering and microcontroller logic.
No Chips? No Problem.
Rather than simulating existing hardware, Matt creates it from scratch. He handwires the sprite engine using TTL chips and builds logic circuits that replicate VIC-II behavior.
Each sprite engine handles a single sprite. Since the VIC-II supports eight, Matt will eventually need eight identical modules. To ensure clarity, he designs with extra memory buffers and avoids optimization shortcuts.
Understanding Sprite Behavior
Matt breaks down how sprites work on the C64. Each sprite is 24×21 pixels, stored as three bytes per row in memory. He explains how these are read from RAM, buffered, and displayed during specific scan lines.
The key? Synchronization. Every scan line, data must be loaded and held steady for rendering. Matt uses front and back buffers to double-buffer the sprite data—just like modern graphics systems.
The Magic of Timing and Positioning
To position sprites on screen, Matt builds a 12-bit counter. It starts with a negative offset to delay the pixel burst until the right moment. This allows sprites to appear anywhere on a scan line—even in the border.
He explains how to preload the counter with a two’s complement value. For example, to display a sprite 200 pixels in, the counter starts at -200.
Once the counter reaches zero, it triggers a load signal. This loads the sprite’s data into a cascade of three 8-bit shift registers, which serialize and display one pixel per clock cycle.
Deeper into the Design
The engine uses shadow RAM to store a copy of the sprite data. When the CPU writes to sprite memory, the data is duplicated into memory reserved for the sprite engine.
This RAM is now triplicated: once for the CPU, once for the raster text generator, and once for the sprite system. The goal isn’t efficiency. It’s understanding.
The same finite state machine used in the CPU controls the sprite engine. That shared logic reinforces Matt’s deeper point: at the heart of a C64, it’s all just states and memory.
Multi-Color Mode and Shift Register Trickery
Matt tackles the complexities of multi-color sprites. These require outputting two pixels at a time, with two bits per display cycle.
To handle this, he restructures the sprite engine’s shift registers into two 12-bit units. This lets the system scan out either monochrome or multi-color pixels with minimal additional logic.
External hardware (not yet built) will choose how to interpret those bits. Either way, the architecture remains impressively flexible.
Debugging and What’s Next
For now, Matt includes a second raster generator to make testing easier. Eventually, he’ll merge it with the main system.
He finishes the episode by showing how each part of the circuit aligns with the schematic. From shift registers to X position counters, every part has a purpose and a place.
In the next episode, he’ll program the sprite microcontroller and attempt to render the first on-screen sprite. If you’ve been following the build, you won’t want to miss it.
Why This Episode Matters
This isn’t just about building a sprite engine. It’s about learning how one works—down to the wire. Dr. Regan’s approach brings clarity and excitement to retro computing.
Whether you’re a hardware tinkerer, retro game lover, or just curious how Pac-Man knew he hit a ghost, this is a must-watch.
