Two 8008s that ran and got thrown out

What I tried

The first version, s8008, was a single behavioral VHDL file. v1.0 went in on 2025-11-03. It had all 48 instructions, I/O and interrupts, and by 2025-11-08 it was blinking an LED on the ECP5-5G Versa through an OUT instruction. The week after that it ran a cylon sweep, an interrupt-driven cylon, UART transmit, UART receive, and a monitor with a command shell through VHPIDIRECT.

Then I started scoping it against the datasheet. The timing model didn’t match a real 8008. Some ALU operations were wrong on hardware and right in simulation, and the single-cycle structure hid why. The whole thing was too tangled to read.

v8008 was the fix attempt, starting 2025-11-17. Same monolith with a behavioral state machine bolted on for multi-cycle timing, and one testbench per instruction: MOV, MVI, LrM, JMP, INR, DCR, ALU, CALL, RET, HLT, INP, OUT. About 5000 lines by the end.

What broke

v8008 collected conditionals. Every edge case got another clause, and by the end lines looked like if state = X and flag = Y and not interrupt and cycle = 2. I couldn’t debug it because I couldn’t hold it in my head. It never reached a working state for basic instruction execution.

The commit sunsetting it on 2025-11-22 says it plainly: s8008 made it all the way to hardware before I realized it was fundamentally incorrect, and v8008 had too much abstraction and shared logic.

What I decided

b8008 starts from nothing. One module per box on Intel’s block diagram, each 50 to 100 lines, each with its own testbench, and none of them allowed to know what an instruction is. Only the timing and control unit gets to be smart. The stack pointer went first, 69 lines, push and pop.

The old FPGA projects moved to a legacy directory. They still work with s8008. I’ll bring them back on the real thing if I get there.

Next

Modules one at a time: state timing generator, machine cycle control, instruction decoder, then the datapath.