• Please review our updated Terms and Rules here

Visualizing the Intel 4004 - Opening the "black box" of the MCS-4 architecture

J

Jaime Clot

New Member
Joined
Apr 24, 2026
Messages
6
Hello everyone,

I've been a bit of a silent observer here, especially following the threads on MCS-4 based industrial systems. Being 63, I’ve spent a lifetime around micros, but the 4004 always had that "mysterious" aura for being the first.

I got tired of emulators that just show you a hex dump and a "Run" button. I wanted to actually see the 4-bit bus moving, the timing, and how the 4004/4001/4002/4003 chips dance together.

So, I’ve spent the last few months building what I call Quadium 4004 Workbench. It’s a visual workbench where every register and chip is exposed.
I even ended up writing a custom transpiler (QuadBasic) because I wanted to see how high-level logic actually translates into those specific 4-bit instructions in real-time.

Let's face it: the 4004 is strange. Really strange. If you come from modern architectures, its logic feels almost alien at first. But after a lot of head-scratching, you finally have that 'AHA!' moment where everything finally clicks...

I’d love to hear from anyone who has poked at the real hardware or struggled with the quirks of the MCS-4 family.

I’m wide open to your feedback, suggestions, or any 'you should have done it this way' comments—I'd much rather have the technical truth than a pat on the back.

Cheers,

Jaime Clot

workbench.png
 
That looks beautiful. The 4004 / MCS-4 is a really fun chipset. I love the idea of a basic compiler for the 4004. Is this on github?
 
Hi dfnr2,

Thank you so much for the feedback! I’m really glad you like the visual approach; it’s encouraging to hear that.

Regarding GitHub, I don’t have plans to open-source the code for now. I’m currently leaning towards a more formal, standalone release once the system is fully stable and polished.

I'm glad you liked the idea of the compiler! I ended up creating QuadBasic specifically to handle the 4004's architecture. It’s a 4-bit high-level language that handles things like nibble-range variables and direct mapping to the 4001/4002 memory banks.

I’ve attached the draft manuals for the Workbench and the language. Please keep in mind they are very much a work in progress; in fact, the layout and readability are currently quite horrible, and they still contain some rough edges and inconsistencies, but they should give you a good idea of the internal logic.

To be honest, even though I started tinkering with Z80 machine code years ago, I must confess the 4004 left me completely baffled for a while. I remember those first days thinking... Wait, to load data into RAM I have to do... what? Or looking for the XOR instruction and realizing it just isn't there! And don't even get me started on the stack.

It took quite a bit of head-scratching to stop thinking in 'standard' logic and embrace the 4004's quirks. But once you finally get into that 4-bit mindset, you start to see how incredibly elegant the whole 'machine' and its timing really are. It’s a strange dance, but a beautiful one.

Cheers!
 

Attachments

Glad you liked it!
Right now the 4004 is pretty much eating up all my time, though I've definitely thought about the 4040 for the future.

The 8008 is a whole different beast, obviously... but hey, who knows? ;-)
 
I have a couple of 4004 machines. One was the early development board, 1702A programming card and connector backplane. I also have a recreation of an early project done with the 4004. It is a form of calculator called a maneuver board. It would be used to do things like closest point of approach. It would be used by ships to keep track of other ships and shore line. The original project was done by two students at the Navy Post Graduate School, in Monterey, Ca. They were working under an instructor, Gary Kildall, how would later create CPM. I created the hardware based on the listing and operational description. I created my own simulator to fix issues with the pdf listing that was poorly printed on a ARS33 with a rutted platen.
Years ago, I worked at Intel and was responsible to keep the manufacturing of the UPP prom programmer that use a 4040 processor. While there I created hardware to test the 4040 PROMs used for the UPP. The most common problem was capacitors legs put in the wrong holes ( on the bus ).
Most simulators available on the web are not very useful. They simply execute code ( sometimes with errors, not understanding the stack the most common ).
I wanted a simulator that I could connect an entry keyboard to, a simulated display and the specific RAM used in the maneuver board program. I also used the same simulator to work on code I used on the development board I had. This includes simulation of the serial TTY inputs and outputs. This requires keeping track of time of execution.
I call this process of simulating real hardware "instrumenting the simulator". It must do more then just execute instructions. It must keep track of simulation cycles read data input files, write output files, allow debug traps at various steps and essentially work like the machine it is simulating.
I never did a visual display as my main intent was to be used interactively as something other than just doing instructions. I had several keyboard instructions to print out things like registers, ports and cycle times. Also, for things like the maneuver board, allowed keyboard entry and result display of what the maneuver board was calculating.
Your display simulation is cool but I never got into having too much displayed and was more into debugging hardware or code that wasn't working.
 
Hi Dwight,

I’m honestly a bit floored by the level of feedback here. Having Dwight, Paul and Dave review my work is a real privilege.

Dwight, your Intel background and the 'maneuver board' story are truly fascinating. What really hits home is hearing about those capacitor legs. My background is in industrial electronics, and your mention of the ASR-33 triggered some serious flashbacks. I still remember my early days with a custom-built 'computer' box connected to a modified teletype that was my 'paper 4K monitor' back then, using punched tape for loading programs. Once you’ve lived through that, you never see hardware the same way again.

This whole project started as a mix of nostalgia and curiosity. Later on, I figured that for most modern devs, the MCS-4 is difficult to visualize through a terminal alone. I wanted to bridge that gap visually. That’s the reason behind QuadBasic: if they can write in a familiar syntax and see it translate into 4-bit logic in real-time, the lightbulb finally goes on.

Regarding the simulation itself, I made a conscious choice to focus on the instruction level rather than cycle-accurate emulation. The simulator steps through instructions one at a time, consistent with the 4004 ISA model. It’s designed to be a fast, practical workbench for debugging and teaching, not workloads that depend on exact cycle-by-cycle hardware timing.

And about those stack issues you've seen in other emulators... Stack? What stack? ;-) Debugging a 4004 stack overflow usually means checking who called whom… exactly three calls ago. ;-)

Thanks again for the warm welcome and for sharing these gems of history. It's an honor to talk shop with the guys who were actually there.

Best regards,

Jaime
 
Hi cruff,

The primary target platform is Windows. That said, given how the Workbench is structured, it should behave correctly under Wine/Proton on Linux. I haven’t had the chance to test that configuration myself yet, so I can’t say with complete certainty

The Workbench is already in its final testing cycle, but on the development side I’m still wrestling with a couple of architectural decisions. Right now I’m extending the transpiler to support an “8-bit Basic” layer.

Betraying my own principles just this once, and purely to add a bit more visual flavor, I’m also experimenting with a custom virtual VDP. It’s loosely inspired by the Texas Instruments TMS9918, very much from a different era, of course, but it’s strictly for entertainment and aesthetic purposes. Just something fun for users who want a bit more visual feedback. And since all virtual peripherals in the Workbench are fully configurable, each user can decide which ones to add and wire them exactly the way they prefer, whether they want to stay historically strict with a few LEDs or jump ahead a bit and attach an LCD. The final choice is entirely theirs.

My biggest ongoing battle with the transpiler, unsurprisingly, is ROM space. Some things never change. I keep an entire page reserved for core helpers such as logical operations and PRINT routines. Even though the transpiler only injects those helpers when the user’s program actually requires them, I still find myself fighting for every last byte. Much tighter than I’d prefer, but that’s the nature of generating compact 4‑bit code. Of course, an experienced user can always bypass the transpiler entirely and write raw assembly to squeeze every single nibble out of the machine, but for the high-level layer, it’s a constant puzzle.

In short, trying to write a compiler that produces elegant, efficient machine code gives you a renewed respect for the constraints you all worked under back in the day. And while there are days when I catch myself wondering why on earth I decided to take on something this demanding, the truth is that the whole project is turning out to be both demanding and genuinely enjoyable.

Cheers,
Jaime
 
You must log in or register to reply here.
Back
Top