Custom 8‑bit CPU (emulator, assembler, text screen) — seeking collaborators for FCC compiler backend

[DavidMik]

I’m a 17‑year‑old solo developer, and I’ve spent the last while designing and building a complete custom 8‑bit CPU architecture. The CPU has a 24‑bit address bus, a flat memory model, and a custom instruction set. It’s all implemented in a cycle‑accurate emulator written in C. I also have an assembler and a 40×24 text screen device (ASCII framebuffer, no terminal emulation), all working.

I’ve just pushed everything to GitLab as three separate repositories:

CPU emulator: https://gitlab.com/DavidMik/dcpu-emulator

Assembler: https://gitlab.com/DavidMik/dasm-assembler

TMS text screen emulator: https://gitlab.com/DavidMik/dcpu-tms9918-module

Planned interrupt system
The CPU will support both internal and external interrupts. An internal interrupt instruction saves all ALU flags, register state, and a return address onto the stack, then jumps to an address held in dedicated address registers. rfi restores everything and returns. External interrupts (e.g., from a keyboard) use input ports 0‑2 for the interrupt vector address and port 3 for data input. The hardware side still needs to be implemented in the emulator, but the specification is firm.

What I need help with
My goal is to turn this into a usable computer, and for that I need a C compiler. I’ve been writing a backend for the Fuzix Compiler Kit (FCC), targeting my CPU. It’s close — arithmetic, control flow, inline assembly, and variable storage all work. I’m currently implementing function calls. After that, there’s global variables, structs, and maybe floating point to do.

The problem: I’m exhausted working alone, and the compiler backend is the last big mountain. I’m looking for people who’d like to collaborate on this project with me.

How you could help (any of these):

Help finish the FCC backend (function calls, global variables, structs). The backend code isn’t public yet, but I can share it privately with serious collaborators.

Write a small ROM monitor or bootloader in assembly.

Add a keyboard input device to the emulator (that triggers those external interrupts).

Implement the interrupt hardware in the emulator (spec ready).

Test the toolchain (assembler, emulator, compiler) as features come online.

Just bounce ideas around — I’ve been working in a bubble and would love to talk shop.

If you’re into custom CPUs, retargetable compilers, or 8‑bit systems in general, I think you’ll find this a really fun challenge.

Comment here or DM me if you’re interested. Links to the repos are above. Thanks for reading!

[DavidMik]

If anyone wants to learm more about the architecture i will be happy to explain it to you

[DavidMik]

I have just updated the emulators README if anyone is interested :3

[nullplan]

I finally spent some time looking at the CPU emulator, to get an understanding of the architecture proposed. So far I am not impressed.

The emulator's code quality leaves a lot to be desired. When I browsed the source, I immediately stumbled upon those giant switch statements and thought how much you have to write before noticing that there must be a simpler way. Since everything is in one file, you are also not differentiating between just the CPU emulator and all the faff you need around the emulator. I have no clue what those hardcoded files are doing there, but it doesn't look wholesome. Also, the RAM is part of the CPU, and that is not how normal CPUs work.

Now for the actual architecture: You are using 4 bytes per instruction, and you still only have 16 different instructions. That is very weird. Your ISA doesn't have relative branches, only absolute jumps, which makes position independent code a nightmare. It would be slightly more bearable if you had PC-relative addressing, but you don't.

The proposed interrupt system makes little sense. The interrupt handler is supposed to be in r7:r8:r9, but those registers store the branch destination for any branch. Since an interrupt can occur at any time, whenever I want to branch, I need those registers to simultaneously hold the interrupt handler and the branch target, which is impossible. At least on the 6502, the interrupt handler address was written to ROM.

Overall I don't get why you'd design an 8-bit CPU. 8-bit CPUs have to work around the limitations of their tiny registers by clustering them together, in a way that 32-bit CPUs just don't.

I wish you all the best in your endeavor but at this point I am not interested in further collaboration.

[DavidMik]

I finally spent some time looking at the CPU emulator, to get an understanding of the architecture proposed. So far I am not impressed.

The emulator's code quality leaves a lot to be desired. When I browsed the source, I immediately stumbled upon those giant switch statements and thought how much you have to write before noticing that there must be a simpler way. Since everything is in one file, you are also not differentiating between just the CPU emulator and all the faff you need around the emulator. I have no clue what those hardcoded files are doing there, but it doesn't look wholesome. Also, the RAM is part of the CPU, and that is not how normal CPUs work.

Now for the actual architecture: You are using 4 bytes per instruction, and you still only have 16 different instructions. That is very weird. Your ISA doesn't have relative branches, only absolute jumps, which makes position independent code a nightmare. It would be slightly more bearable if you had PC-relative addressing, but you don't.

The proposed interrupt system makes little sense. The interrupt handler is supposed to be in r7:r8:r9, but those registers store the branch destination for any branch. Since an interrupt can occur at any time, whenever I want to branch, I need those registers to simultaneously hold the interrupt handler and the branch target, which is impossible. At least on the 6502, the interrupt handler address was written to ROM.

Overall I don't get why you'd design an 8-bit CPU. 8-bit CPUs have to work around the limitations of their tiny registers by clustering them together, in a way that 32-bit CPUs just don't.

I wish you all the best in your endeavor but at this point I am not interested in further collaboration.

This is just the first version that i put together just so it works, I will be sorting it into headers and I will try to make it as readable as possible. Sorry if the code is too messy for now.


And the interrupt system uses p0-p2 for the address if an external interrupt happens, r7-r9 is only used for when the interrupt is called by code that the programmer put in the progam

[DavidMik]

I pushed the work in progress DASM backend for the FCC c compiler to my gitlab, if anybody is interested here it is https://gitlab.com/DavidMik/fcc-dcpu-port.
If you have any questions feel free to ask me.
Functions dont really work right now, and i didnt implement anything to get global functions to work yet.