Barry Walker

In my last post I said I was taking NovaVM to FPGA because kids deserve a machine they can actually understand. That was a promise. Here is the receipt.

NovaVM now boots on real hardware. Not in a simulator pretending to be hardware, on an actual FPGA driving an actual monitor over HDMI. Since then I have added a hardware math coprocessor, hardened the whole machine with test-driven development at the RTL level, and written an entire Logo interpreter from scratch in 6502 assembly. And I have started the port to a board that changes the trajectory of the whole project.

Let me walk through it, because honestly, this is the most fun I have had building anything in years.

It Boots on Real Silicon

The active hardware target is the ULX3S, a Lattice ECP5-85F board. The first successful synthesis and boot happened in mid-April, and within a day EhBASIC was up on HDMI output through a TMDS encoder. A blinking cursor on a real screen, driven by synthesized hardware description. That moment never gets old.

The discipline that makes this work is keeping one machine model aligned across three targets at all times:

• Avalonia, the C# reference implementation and development UI.
• Verilator, a fast RTL simulation target.
• ULX3S FPGA, the real silicon, with a small ESP32 companion called NovaHost handling SD storage, ROM loading, debug, and networking.

The rule is simple and strict: custom hardware is not an emulator trick. The same register model and memory behavior has to exist in all three places. If the FPGA disagrees with the emulator, one of them is wrong, and I go find out which.

Since the first boot, the hardware surface has filled out fast:

• Dual SID chips in hardware, 6581 and 8580, with runtime model selection.
• SDRAM-backed expansion memory, taking XRAM from 4KB up to 512KB of flat 24-bit address space.
• A DMA controller, a blitter, and the full sprite and copper pipeline, all in RTL, all matched against the reference model.
• HDMI video at a 720x480 output frame with a centered Nova canvas.

A lot of the hard work was not features at all. It was chasing down nondeterminism: power-on-reset glitches that left twenty percent of the screen rendering wrong until I root-caused it to flip-flop initialization, global set/reset behavior, and clock-domain crossing on the PLL lock signal. That is the unglamorous part of hardware nobody blogs about. It is also exactly the work that separates a demo from a machine.

Correctness Is the Whole Game

Here is the thing about building a CPU and its custom chips in hardware description language: you cannot just eyeball it. A one-cycle timing mistake in a memory read does not crash. It quietly hands you stale data, and three layers up your sprite renders garbage and you have no idea why.

So the entire FPGA effort runs on test-driven development. I write Verilator tests for the hardware blocks before I flash anything to the board. That workflow has paid for itself many times over:

• A new graphics, sprite, and register test suite found three real RTL bugs in the video controller in a single pass.
• Both the DMA controller and the blitter had the same class of bug, a one-cycle dual-port RAM read latency that returned stale data. Found by tests, fixed against tests, regression-locked so they stay dead.
• Exhaustive coverage of the text and graphics clear paths came back clean, which is its own kind of win. Knowing something is correct is worth as much as finding it broken.

To prove the machine runs real, demanding software, I brought up Ozmoo, a Z-machine interpreter, and ran Zork III on it with hardware scrolling and paginated text, backed by smoke tests. If a 1979 Infocom adventure runs clean on your synthesized 6502 with your custom video hardware, you have built something real.

The other quiet hero here is NovaHost, the ESP32 companion. It now does WiFi debug logging, over-the-air firmware updates, SD card I/O, and runtime ROM loading. That last one matters more than it sounds: loading a ROM at runtime instead of re-synthesizing the bitstream took my iteration loop from seventeen minutes down to seconds. When you are debugging hardware, your feedback loop is everything.

NovaLogo: The Right Language for This Machine

This is the part I am most excited about.

NovaVM needed a language that delivers on the original promise, simple enough that a ten-year-old draws a square in thirty seconds, deep enough that the same kid five years later is writing recursive geometry that drives real hardware. BASIC is great, but the language that was literally designed to teach kids to think is Logo. So I wrote one.

NovaLogo is a complete Logo interpreter, written from scratch in 6502 assembly, booting from its own 16KB ROM slot just like NovaBASIC. It is classic UCBLogo-style Logo, and it is not a toy subset. Built up one verified piece at a time:

• A tokenizer, a heap allocator, and a tree-walking evaluator.
• Variables with MAKE and :reference, full arithmetic, comparison, and logic.
• Control flow: REPEAT, IF, IFELSE, FOR, WHILE, UNTIL.
• TO ... END procedure definitions with STOP and OUTPUT, and real recursion. FACT 5 returns 120, verified on the machine, with a proper call stack underneath.
• First-class lists with FPUT, LPUT, LIST, SENTENCE, WORD, and RUN.
• A mark-and-sweep garbage collector, because first-class lists with recursion means you need real memory management.
• CATCH and THROW for structured error handling.

And then the part that only works because of everything underneath it: the turtle. FD, BK, RT, LT, PU, PD, CS, HOME, the whole vocabulary. The turtle is a vsprite with real-time rotation. That detail matters: the hardware sprites do not rotate, so the turtle rides on the vsprite layer precisely because it has to spin smoothly as it turns. It draws into the video controller through Logo-native graphics words like LINE, CIRCLE, RECT, FILL, and PAINT. Sprites, SID sound, and timing are all exposed as first-class Logo commands too.

Two details I am proud of. First, the turtle math runs on the hardware math coprocessor. When you type FD 50 RT 120, the heading and movement go through hardware fixed-point multiply, divide, and a sine/cosine unit, with ATAN2 and a distance approximation available too. Second, the turtle tracks sub-pixel position in 16.8 fixed point, so recursive geometry closes exactly. Draw three sides of a triangle and you land precisely back where you started, with no accumulated drift. That is the difference between a turtle that teaches geometry and one that lies to you.

This is the educational thesis from the last post made concrete. A kid types REPEAT 4 [FD 50 RT 90] and watches the turtle trace a square on a real screen. Then they grow into the same machine instead of out of it.

Next: The Arty Z7, and Why It Matters

The ULX3S has been a fantastic bring-up board, and the open-source toolchain behind it, yosys and nextpnr, is a joy. But the next target is a Digilent Arty Z7-20, and the first blinky is already running on it.

The Arty Z7 is built around a Xilinx Zynq-7000. That part is not just an FPGA. It is a system on a chip with two hard ARM Cortex-A9 cores sitting right next to the programmable logic, on the same die, plus HDMI in and out and DDR3 memory. Here is why that is a big deal for NovaVM specifically:

• The companion chip moves onto the same silicon. Today NovaHost runs on an external ESP32 wired to the board. On the Zynq, those ARM cores can be NovaHost. SD storage, ROM loading, networking, debug transport, all of it running on the same chip as the synthesized 6502 and its custom hardware. The whole machine collapses onto one board.
• It proves the RTL is real, portable hardware. Moving the core from a Lattice ECP5 and an open toolchain to a Xilinx part and the Vivado flow forces the design to be honest. Hardware that ports cleanly across two different FPGA vendors is hardware, not a single-chip accident.
• Headroom. More logic, faster clocks, HDMI input as well as output, and real memory bandwidth give the full architecture room to breathe, with space left for everything still on the roadmap.

It is also still an affordable, widely available board, which keeps the whole thing true to the mission. This is a machine a hobbyist can actually build and a kid can actually use, on a path toward something that could one day be a real product you plug into a TV and turn on.

That is the trajectory. Real hardware today, a language built to teach, and a port underway to a chip that lets the entire computer live on one board.

The software VM that defines the architecture is all open at github.com/barryw/NovaVM. The FPGA and Logo work is active, messy, and moving fast. Clone it, build it, and type RUN. Or soon, FD 50.