Tag: firmware

The console's USB host port meets a cartridge reader that pretends to be a CH340 serial chip. By the end of the day the firmware read and validated a real cartridge header.

The SNES core was losing four million cycles a frame waiting on a sound chip on another board. Predicting the answer lifted Super Mario World from 35 to about 50 fps.

Building a recorder that captures a good run and a bad run of the same firmware workload so a tool can find the first difference that matters.

Days optimising the HDMI coprocessor because every symptom said it was holding the SNES back. The measurements pointed at the wire instead.

Two bodge wires taught the HDMI coprocessor to talk back and run the SNES sound chip with real Super Mario World music. It reached 97 per cent of realtime.

The from-scratch SNES core matches the reference emulator to the cycle. Five optimisations measured on hardware, and a profiler that says the problem is memory.

Mouse input for the emulated Amiga, then a commercial game whose custom trackloader refused to work until the floppy drive learned to spin.

The Amiga core on the STM32H753 boots a real Workbench 1.3 floppy to the desktop, and what it took to get the floppy controller right.

A host tool that turns one ROM into the matching H7 runtime, RP2040 receiver and cartridge image, and refuses to declare success until the cart reads back the exact bytes.

First hardware numbers for the Amiga core: a real Kickstart 1.3 ROM executing deterministically at a p99 of 2.51M cycles per PAL frame, against a gate of 3.35M.

A Mega Drive emulator on a 480 MHz Cortex-M7 with perfect music beside a screen that tore in half. The fix was to make a slow frame arrive atomically.

The cart was byte-identical to the BBS copy, so the fault was in the synth: a music clock cutting bars to a quarter, and a noise fit matched to the wrong metric.

Four transport dialects from 1998 and a FAT12 layer nobody ships, which is why the first firmware milestone is just reading descriptors.

Two days building the console's second shell, including a crash hunt that ended eight kilobytes from the stack floor.

One day of hardware A/B tests on the H753. The biggest single win was a compiler flag I should have set weeks ago.

Two days from a feasibility study to DMG code on the TV, with the console's SPI video wire carrying two frame geometries at once.

Giving the console a crash reporter that survives the reset and emails me, and the ways an STM32H7 loses data across a warm reset.

The launcher's blinking sparkle became a 9 by 9 pixel demoscene with seventeen tiny effects dealt from a shuffled deck.

A tour of Rusty Nail as it stands, from the OS on screen to the four breakout boards and the cartridge shell with a 16 MiB flash chip inside.

The HDMI picture was pixel-perfect and still looked soft. A full-resolution palette scanout fixed that, after an afternoon lost to a heap that only sometimes existed.

The morning after deleting the old Lua core, everything played and then the speakers started clicking. A command trace found three lines of channel semantics and a missing crossfade.

Stage 9 of the runtime migration, ending the night at 59 fps on jumper wires after a one-byte regression that cost 19 carts.

Three unrelated fixes from one evening. The biggest was a cartridge that finally keeps its saves; the strangest was an iterator that duplicated the player.

The new Lua core measured against the old one on identical silicon, with a licensed PICO-8 as the oracle and a per-cart compatibility matrix.

A permanent benchmark and input tapes recorded from real play, so the new Lua VM has numbers to beat before it lands.

Rusty Nail can download carts from a pop-up launcher. The WiFi reason-15 failure was my own off-by-one, and a GPIO pin really did die on the bench.

The standalone build sends nothing back to a host, so before I could redesign the boot splash I had to work out how to screenshot a screen my Mac cannot see.

Picking a W25Q flash chip for a physical PICO-8 cartridge and mapping how the firmware would read it. Nothing is built yet.

I bought a 50-pin RGB888-to-HDMI board, then counted the pins. The Nucleo never had 24 to give, so the fix is probably a second microcontroller whose whole job is HDMI.

Profiling the PICO-8 runtime found a stretched-sprite blit doing an integer divide on every pixel, on a chip with no fast divide.

The SPI blit was a blocking row-by-row write that stalled the console for about 13 ms every frame. DMA fixed it and the data cache nearly broke it.

I picked an ESP32-C6 for the controller bridge and learned that BLE-only is a property of the silicon, so the fix was a different chip and one build flag.

I had a working HDMI path at 12:48am. The next morning I picked up the tiny SPI screen instead and spent nine hours reinventing flicker.

Getting the desktop off the USB stream and onto a real LCD, then climbing from 1 MHz to 25 MHz without losing the audio.

Wiring an I2S DAC to the console over SAI and DMA, and why the audio stayed silent for most of a day.

Vendoring Lua 5.4 into bare-metal firmware, and why a hardware watchdog beat an instruction-count hook for stopping runaway carts.

Rusty Nail is a windowed pixel desktop running bare metal on a Nucleo-H753ZI. This is the architecture, and why the display is an abstraction from the start.