Project Oberon Ditches Its Dead FPGA for RISC-V

Every RISC-V thread eventually collects the same joke: don't confuse it with RISC5, the CPU Niklaus Wirth designed so Project Oberon could own its entire stack, gates included. This week the joke folded in on itself. Rochus Keller — the developer behind Oberon+ and a long list of Oberon-family tooling — published a working port of the Project Oberon System to RV32, swapping Wirth's bespoke processor for the open ISA that accidentally shares its name.

It's easy to file this under retrocomputing whimsy. That would be a mistake. The port is a rescue operation for one of the most instructive artifacts in systems programming, and the choices Keller made — some of them genuinely contrarian — say a lot about what it takes to keep a whole-system design alive after its hardware dies.

The stack that outlived its substrate

Project Oberon 2013 is Wirth's final statement of a lifelong thesis: an operating system, compiler, garbage-collected language, and windowing UI, all comprehensible by one person, running on a CPU simple enough to print in the back of the book. The catch was always that CPU. RISC5 existed only as an FPGA design, and as Keller notes in the HN thread, the low-cost Spartan-3 board it targeted went out of production not long after the book shipped. Emulators kept the system runnable, but "runs in a niche emulator for a one-off ISA" is how systems become museum pieces. Wirth died in January 2024; the hardware problem was never going to fix itself.

RISC-V dissolves that problem. RV32 is the closest thing we have to a permanent 32-bit ISA: emulators everywhere, silicon from dozens of vendors, and — crucially for Oberon — a thriving class of MMU-less microcontrollers that match the system's actual requirements. Oberon needs no MMU, no multi-core, no gigabytes of RAM. A design that looked ascetic against a 2013 laptop looks perfectly sized against a 2026 microcontroller.

Porting backward to move forward

Here's the contrarian part. Keller didn't port Wirth's own Oberon-07 compiler to emit RISC-V. He migrated the system's source code backward, from Wirth's final minimalist Oberon-07 dialect to circa-1990 Oberon, so it would compile with OP2 — the ETH compiler from Régis Crelier's era, built with a front end/back end split that has already produced code for SPARC, MIPS, i386, and more recently ARMv7 and RV32. The migration is mechanical but real: INTEGER becomes LONGINT, missing Oberon-07 built-ins land in a compatibility module, type case statements become type guards.

Compare that with the previous serious attempt, the 2020 academic oberon-riscv project, which took the fidelity route: patch Wirth's own compiler to target RV32IM, keep the dialect intact. It got a self-compiling system to boot in emulation, then stalled — no REAL arithmetic, no interrupts, FPGA deployment left as a TODO. That's the usual fate of fidelity ports: heroic, complete-ish, unmaintained.

Keller is betting on retargetability over purity, and it's the right bet. One multi-backend compiler serving both this system and his parallel Oberon System 3 work means every future target — and he's explicit that the ESP32-P4, a cheap RISC-V part with display output, is the real goal — comes almost for free. The purists lose the Oberon-07 dialect Wirth considered final. What they gain is a system that might still be building in ten years.

What you can actually run

The current state is emulation only, and honestly labeled as such. The repo ships a VM built from a stripped-down rv32emu interpreter plus custom peripherals that reproduce the memory map of Wirth's machine 1:1 — close enough that Kernel.Mod, Display.Mod, and Input.Mod needed no changes beyond the dialect conversion. On Debian, ./build.sh run compiles the modules, packages a disk image, and boots the system; prebuilt Linux and Windows binaries exist if you just want to poke at the tiling UI for an evening.

The honest caveat list matters more than the demo. Everything is statically linked into the boot image; dynamic module loading — arguably the signature Oberon feature, where every exported procedure is a user-invokable command — isn't wired up yet. There's no networking. And nothing has run on real silicon so far, though Keller says self-hosting the compiler on an ESP32-P4 is feasible "with some patience." Until dynamic loading lands, this is a faithful diorama of Oberon rather than the living system.

Who should care

Not embedded teams shipping products — Zephyr and friends aren't losing sleep. The audience is more specific and, I'd argue, more important: anyone who teaches or learns operating systems by reading complete ones. xv6 owns that niche for Unix, and it thrives precisely because it targets RISC-V. Oberon is the non-Unix counterexample — garbage collection in the kernel, modules instead of processes, commands instead of shells — and it has been locked out of that role by its dead ISA. This port, plus the book, plus any $10 RV32 board or emulator, puts it back in play.

Keller calls this project an "intermezzo" on the way to Oberon System 3 on microcontrollers, with his own Micron language as the eventual implementation vehicle. That roadmap is one person deep, which is the standard risk with everything in the Oberon world. But the strategic read holds regardless: RISC-V is quietly becoming the preservation substrate for whole-system designs that outlived their hardware, and this is the cleanest demonstration yet. The system Wirth built to be understood by one person now runs on the one ISA likely to outlive us all. He'd have appreciated the economy of that.