CPS2 PicoHD: what our first RP2350 firmware build actually proves

The question behind the project

Can one reasonably priced RP2350B handle an arcade board's digital pixel stream and produce HDMI without a separate FPGA and HDMI transmitter? That is the research goal, not a demonstrated result. Our reference points are marqs85's working CPS2 Digital AV FPGA project and the independent NeoPico-HD RP2350 approach for Neo Geo hardware.

The motivation is clear: capturing video before the analogue RGB stage could preserve the source colours and the CPS2's extra per-pixel fade information. The difficult part is not merely drawing pixels. It is acquiring the original signals safely, reconstructing the correct timing and feeding a display without dropping frames.

What the existing references tell us

The public CPS2 Digital AV RTL describes three four-bit colour buses (R, G and B), a distinct four-bit fade value, HSync and VSync, and a 16 MHz reference clock. Its sampled pixel cadence is approximately 8 MHz, corresponding to a 384 × 224 active game image in a larger timing envelope.

Those are values extracted from the published FPGA implementation; they are not our own oscilloscope results. The fade bits are not another four bits of ordinary RGB. They require explicit reconstruction to reproduce transitions and brightness correctly.

The November 11 build result

Our first linked RP2350 target firmware was reproduced on Windows with the Pico SDK, Ninja, GNU Arm 14.2.1 and picotool 2.3.1. The build completed, creating a .elf and .uf2. It exercises a synthetic-frame HSTX/DMA bring-up path rather than a complete CPS2 capture pipeline.

GNU's size output for that build reported 15,244 bytes of text, no data in the summary category and 349,920 bytes of BSS. A section-by-section linker audit placed the end of current main-SRAM reservations far enough from the 512 KiB bank limit to leave 171,944 bytes of unallocated address space at link time. That number is not a guarantee of runtime heap, stack headroom or support for future concurrent capture.

Separately, the Windows-only release test suite recorded 42 passing tests at an earlier revision. These are useful software facts, not measurements from an arcade PCB.

A quick evidence ledger

Why voltage and timing are the next hard problems

A CPS2 digital signal cannot be assumed to share the RP2350's voltage limits. Buffering and signal integrity have to be characterized against a specific A-board revision before any experimental connection. Capturing at the wrong clock phase can look like colour corruption or duplicate/missing pixels even when the firmware appears to run.

On the output side, the HSTX/DMA pipeline must manage line ownership, missed or coalesced interrupt events, underflow and display reconnects. Host tests help define expected state transitions, but only hardware measurements can establish electrical operation and image stability.

Our actual next gates

• G1: show an independently recorded, stable synthetic pattern on a real HDMI display using a documented RP2350 setup.
• G2: characterize CPS2 colour/fade, clock and sync signals with appropriate instrumentation and input protection.
• G3: demonstrate repeatable real line/frame capture, with dropped-line and buffer-ownership evidence.
• G4: compare fades, colours and geometry to the native output.
• G5: measure latency under documented conditions; do not describe it as zero-lag beforehand.

Why we publish an unfinished experiment

The original research has already produced something useful: a concrete build result, memory accounting, a proposed capture model and an explicit validation ladder. Sharing the distinctions helps other engineers assess similar proposals without mistaking a firmware image for a working accessory.

Atelier Rocky is researching CPS2 restoration electronics, but there is no tested or purchasable PicoHD product. We will update the research when physical evidence exists.