Title: Could the RP2354B (Pico 2) be the basis for a next-gen, level-shifter-less Neo Geo Flash Cart?

Hi everyone,

I’ve long been fascinated by how the SNES used enhancement chips to push its hardware limits. Back in the day, while we were analyzing those mappers, the Neo Geo remained that "luxury" console every kid dreamed of but few could afford.

However, with the upcoming AES+ scheduled for November 2026, I believe we are on the verge of a massive scene revival. Between this new hardware and the fact that Neo Geo ROMs are now legally and affordably accessible via GOG, Steam, and Humble Bundle, the only thing missing is a modern, low-cost hardware bridge. We need a way to legally enjoy these titles on official or next-gen platforms without the "gatekeeping" of expensive vintage carts or complex FPGA designs.

I’m wondering if the RP2354B (A4 revision) could be the key to this. I’d love to get the community’s take on a specific architecture I’ve been thinking about.

Before I explain some of the details here is an illustration of the general idea :

graph LR
    %% Définition des styles
    classDef console fill:#fbbf24,stroke:#b45309,stroke-width:2px,color:#000
    classDef mcu fill:#e11d48,stroke:#9f1239,stroke-width:2px,color:#fff
    classDef storage fill:#1e293b,stroke:#475569,stroke-width:1px,color:#fff

    subgraph NEO_GEO [NEO GEO CONSOLE - 5V]
        direction TB
        BUS_MAIN[68K / Z80 BUS]:::console
        BUS_CHA[CHA BUS - MUX]:::console
    end

    subgraph CARTRIDGE [NEO-PICO-CART - 3.3V]
        direction TB
        
        subgraph CLUSTER [RP2350B CLUSTER]
            direction TB
            M1[[MCU #1: MASTER / 68K]]:::mcu
            M2[[MCU #2: CHA SLICE A]]:::mcu
            M3[[MCU #3: CHA SLICE B]]:::mcu
        end

        subgraph MEMORY [STORAGE]
            direction TB
            P1[(PSRAM 32MB)]:::storage
            P2[(PSRAM 32MB)]:::storage
            P3[(PSRAM 32MB)]:::storage
            SD[MicroSD Slot]:::storage
        end
    end

    %% Connexions
    BUS_MAIN <==>|Direct 5V Link| M1
    BUS_CHA  ==>|PIO Demux| M2
    BUS_CHA  ==>|PIO Demux| M3

    %% Bus internes
    M1 --- P1
    M2 --- P2
    M3 --- P3
    SD -.->|SPI Load| P1
    SD -.->|SPI Load| P2
    SD -.->|SPI Load| P3

    linkStyle 0,1,2 stroke:#fbbf24,stroke-width:3px

Loading

1. A 5V-Tolerant, Shifter-less Design? The RP2354B (A4) is officially 5V tolerant (with IOVDD at 3.3V) and offers 48 GPIOs.

• The Concept: Direct connection to the Neo Geo buses (68k, Z80, CHA). Removing dozens of level shifters would drastically reduce the BOM and PCB size.
• The Evidence: The One ROM project already uses the RP2350 to replace 5V ROMs (27 series, etc.) in systems like the Amiga, C64, and Atari without external level shifters.
• The Question: For those who have spent years probing the AES/MVS: how "clean" is the bus in reality? Is the RP23xx’s tolerance robust enough to handle the inductive spikes of a 30-year-old console, or is this a "too good to be true" scenario for a full cart?

2. Overcoming the CHA Bus Latency & Multiplexing with an "MCU Cluster" The CHA bus is notoriously fast (80-100ns window). Crucially, it is also multiplexed (traditionally handled by the NEO-257/NEO-G0 chips on original carts). Since low-cost QSPI PSRAMs are usually limited to 16MB per chip, reaching the 96MB limit is a challenge.

• The Concept: Instead of one massive chip, could we use a cluster of three RP2354s? Each MCU would manage a 32MB "slice" of the ROM. The PIO would be tasked with emulating the bank-switching and multiplexing logic of the NEO-257 in real-time.
• The Question: Given the way the Neo Geo (LSPC) fetches sprite data through its multiplexed lines, is the access pattern predictable enough to implement a "pre-fetching" logic? Could the dual-core M33 keep the data ready in internal SRAM fast enough to hit that 80ns window?

3. PIO & DMA: A viable alternative to CPLDs?

• The Concept: Offload the entire bus protocol and the bank-selection logic to the PIO (Programmable I/O) and use DMA to move data from Look-Up Tables (LUTs) in internal SRAM directly to the pins.
• The Question: In your experience with existing flash carts, what is the absolute "point of no return" for timing jitter on the CHA bus? Since the PIO can handle complex state machines, can it effectively replace the custom Neo Geo multiplexing chips?

Why this feels viable (Existing POCs): I’m basing this idea on several successful projects that have pushed the RP2xxx series to handle complex, multiplexed, and high-speed buses:

• PicoCart64: This is perhaps the most relevant proof: it proves the PIO can handle the N64’s notoriously difficult multiplexed Address/Data bus. If the PIO can de-multiplex N64 cycles in real-time, handling the Neo Geo’s CHA multiplexing (NEO-257 logic) is a logical next step.
• PicoDS: This project demonstrates that an RP2040 can emulate a high-speed Nintendo DS cartridge bus. It’s a massive milestone showing that complex, command-based multiplexed protocols are well within reach of the PIO.
• One ROM (Universal ROM Replacement): This project proves the RP2350 can emulate a wide variety of 5V ROMs at a very low cost (sub-$5), handling the electrical and timing requirements of vintage 8/16-bit hardware without external shifters.
• NeoPico HD: This project directly addresses the Neo Geo ecosystem, using an RP2350B to tap into digital video signals. It highlights the chip's capability for direct hardware interfacing and high-speed data handling (HSTX) within the specific timing constraints of the console.

Conclusion: I’m not a hardware engineer myself, but seeing these POCs—especially how the PIO handles the multiplexed buses of the N64 and DS—makes me think that a "distributed MCU" approach could open some very interesting doors for a modern, lower-cost Neo Geo project.

I’d love to hear from the experts here: is this a viable path for a collaborative community project, or am I overlooking a major bottleneck?

---

Full disclosure: I am not a Neo Geo hardware expert or a native English speaker. I have used AI to help organize my thoughts, translate technical concepts, and refine this proposal to ensure it is as clear as possible for the community. My goal is simply to spark a discussion around these new possibilities!