Around June 2025, I stumbled across a video by JDH on Youtube :
Being a big fan of low-level development, I decided to dig a little deeper into the topic… and I ended up falling into a massive rabbit hole: ALUs, transistors, XNOR gates, Intel 8086, etc.
If I was going to reinvent the wheel, I might as well do it all the way — and have fun with it. So I installed Logisim Evolution, created a playlist of 200 videos on electronics and circuit building, and jumped into the adventure!
Defining the Scope
To begin, I had to define the scope of my project. I wasn’t about to try building some ultra-modern multi-core powerhouse.
Instead, I decided to design a 16-bit, Turing-complete processor with its own assembly language and compiler. Initially, I wasn’t even thinking about a physical implementation, but the more time I spent on it, the more I thought it would be really cool to build it for real using CMOS ICs.
Next up, I needed to give it a cool name — something that would echo the history of computing (since my goal was to recreate a processor equivalent to those from the 1970s). So I decided on the name Organ — inspired by street organs and music boxes, which were among the earliest devices that stored « instructions » to be « executed » later.
And of course, it needed a number, to give it that retro processor feel (like Z80, Intel 8086, IBM 1401). I kept it simple: 16, since it’s a 16-bit processor.
Starting the Design in Logisim
Now that the project had a clear goal and a solid name, I opened up Logisim Evolution to get started. And what do you see when you launch Logisim?
A very austere window.
So I began placing blocks randomly, experimenting a little, testing the results of logic operators, and so on…But pretty quickly I realized that’s not how I was going to build a processor. So I started watching videos and reading a lot of articles (not just Wikipedia!) about processor architecture.
Core Concepts
My processor had to be Turing complete, meaning it needed to support both arithmetic and logic operations.
This is where the ALU (Arithmetic and Logic Unit) comes in. The ALU’s job is to take numbers and an operation as input and output the result. It also handles comparisons by outputting comparison flags.
But then — how do you convert ones and zeros into operations for the ALU?
That’s where the Control Unit becomes essential. The control unit is another part of the processor that decodes the program instructions (sent in binary) and figures out what to do: Does it push a value onto the stack? Call a function? Perform a calculation? If so, which one?
This decoding work is the control unit’s job.
And since we’re moving closer to the code itself, we can ask: how do we know which instruction to send to the control unit?
This brings in more components: RAM, Instruction Registers, and the Program Counter.
- The Program Counter (PC) is a simple 16-bit register that stores the address to be sent to RAM, and increments on each clock cycle.
- RAM stores the program. When you give it an address, it returns the value at that address. Since my processor supports 16-bit addresses, the RAM can hold up to 1 Mbit of data.
- Instruction Registers store the current instruction (fetched directly from RAM). In my processor, some instructions are wider than 16 bits — up to 32 bits — allowing for 16-bit immediate values.
The Clock
Speaking of clocks: most memory-type components in a processor are asynchronous, meaning they need to be told when to update or output values. An oscillator (clock) sends pulses — switching current on and off rapidly and continuously — to drive the processor’s state forward over time.(Modern processor clocks typically run at 100 MHz base, boosted to over 3 GHz — that’s billions of oscillations per second 😮).For now, my processor will run at 1 MHz, which is already plenty!
Instruction Design
Now let’s talk about instruction design.
In my processor, every instruction starts with an opcode, encoded over 3 bits. This represents the category of the instruction. Then comes the sub-opcode, encoded over 4 bits — this distinguishes between instructions within the same category.
With this setup, I can support up to 128 instructions.
Next are the general-purpose registers used for reading/writing. The Organ 16 has 8 general-purpose registers: R0 through R7. Since 3 bits are enough to reference each of them, we get:
- 3 bits for the instruction category (opcode)
- 4 bits for the specific instruction (sub-opcode)
- 3 bits for the destination register
- 3 bits for source register 1
- 3 bits for source register 2
That makes 16 bits total per instruction.
But Why 32 Bits?
Some instructions require immediate values — numeric constants like 3, 12, or 128302. These are useful for instructions like STORE :
STORE R6, 0x1000
This stores the content of register R6 into memory address 0x1000 (4096 in decimal).
The compiler turns this into binary:
Opcode: 011
Sub-opcode: 0001
Destination register: 000 (unused)
Source register 1: 110 (R6)
Source register 2: 000 (unused)
That’s 16 bits already used.
So we define the next word as an extension to the instruction and store the immediate value (4096 → 1000000000000) there.
Memory Layout
I also added a stack, located at the bottom of memory (64 Kbits), while the program sits at the top — reducing the chance of overlap.
And finally, a small circuit checks whether a value was written to the framebuffer (RAM section that stores pixel data) and lights up pixels on a screen accordingly.
Tools Around the CPU
I also wrote:
- A C++ emulator that simulates the processor’s behavior, including a memory viewer, register view, and a display renderer.
- A parser and compiler in Python to write and test programs more easily in Logisim
Current Status
As of October 13, 2025, I’m taking a short break from the project — but I definitely plan to get back to it soon. I’ve already started coding Pong for the emulator!
I’m also seriously considering building the processor physically, using breadboards.
GitHub Repository
The GitHub repository with the full design, compiler, and emulator is here:
https://github.com/Windokk/Organ-16/tree/main
And here’s a screenshot of the emulator :
