Tag: stm32

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.

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.

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.

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.

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.

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.

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 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.