FujiCard Hardware Notes - FujiNetWIFI/fujinet-firmware GitHub Wiki

One Intellivision cartridge containing an RP2350 (cart bus emulation, board name fujicard, a fork of Minty) and an ESP32-S3-WROOM-1-N16R8 (FujiNet client), linked internally over USB instead of an external cable, with a single USB-C port for flashing the ESP32-S3. This page was previously "PiRTO‐II‐Fuji Hardware Notes"; it's renamed because the board is no longer a PiRTO II derivative — see Licensing below for why that distinction matters.

Design notes and BOM live in ~/Workspace/PiRTOII-Fuji/ (HARDWARE.md, HARDWARE-PROVENANCE.md) — that directory name is a holdover from before the Minty switch and is itself stale relative to this page in places (see Known gaps); this wiki page is the corrected version. Firmware lives in pico/intellivision/firmware/, board files at boards/fujicard.h / boards/fujicard.cmake.

Status

Firmware compiles and links for fujicard; no hardware testing has been performed yet — see Known gaps. Schematic/PCB/enclosure design has not started in the KiCad/FreeCAD GUI.

Revision note (still applies from the pre-Minty design): the RP2350 has no dedicated flashing port. It's put into BOOTSEL programmatically (reset_usb_boot()) via a mailbox doorbell in normal operation, and — for recovery when firmware is bricked or hung — the ESP32-S3 can force it into BOOTSEL in hardware by pulling QSPI_SS low and pulsing RUN#. The RP2350 is then flashed over its internal USB link by a PICOBOOT client running on the S3. One connector, one fewer failure mode, smaller shell.

Components

RP2350 (RP2354A) — cart bus emulation (CP-1610), running the fujicard Minty fork. 2 MB flash (PICO_FLASH_SIZE_BYTES 2097152, W25Q16JVWI part, PICO_BOOT_STAGE2_CHOOSE_W25Q080, PICO_FLASH_SPI_CLKDIV 2).
ESP32-S3-WROOM-1-N16R8 — FujiNet client, runs fujiversal-rs232.

RP2350 pin map (`boards/fujicard.h`)

This table replaces the RP2040-era pin map this page previously carried (BDIR on GPIO16, BC2 on GPIO17, BC1 on GPIO18, MSYNC on GPIO19, selftest trigger on GPIO22, debug UART TX on GPIO28). fujicard.h explicitly retracts that map — it was for the original PiRTO II-derived pinout, which this board does not use. fujicard inherits its bus/control pinout from pintycard instead, its immediate Minty-side starting point.

GPIO	Function	Notes
0-15	D0-D15	CP-1610 data bus, bidirectional (`MI_AD0_PIN` base = GPIO0)
20	RST	`MI_RST_PIN`
21	MSYNC	`MI_MSYNC_PIN`
22	BDIR	`MI_BDIR_PIN` — not GPIO16 as on the old PiRTO-II-derived map
23	FUJI_SELFTEST_TRIGGER	`FUJI_SELFTEST_TRIGGER_PIN`; ground at power-on to run `fujibus_selftest()` — declared but not currently read by the firmware, see Known gaps
24	Debug UART1 TX	`MI_DBG_UART_TX_PIN`; TX-only, Debug builds only
25	LED	`MI_LED_PIN` — onboard indicator; also the `reset_usb_boot()` activity pin
26	BC1	`MI_BC1_PIN`
27	BC2	`MI_BC2_PIN`
—	USB D+/D-	native RP2350 USB PHY → permanently wired to ESP32-S3 (host)
—	RUN#	driven low by an S3-controlled transistor to reset the RP2350 (hardware BOOTSEL forcing) — RP2040-era design, not yet re-verified for RP2350 BOOTSEL/PICOBOOT differences
—	QSPI_SS (BOOTSEL)	pulled low by a second S3-controlled transistor, mimicking the BOOTSEL button — same caveat
—	SWCLK/SWDIO/GND	bring to exposed pads/Tag-Connect footprint; last-resort recovery path

There is no SD card on this board (CONFIG_SD_STORAGE 0 in fujicard.cmake) — game/config storage is LittleFS in the RP2350's internal flash (CONFIG_FLASH_LFS_STORAGE ON). Drop any earlier "on-board microSD slot" claim for this board.

Source of truth for the pinout is boards/fujicard.h, not this table — check it directly before any layout change.

ESP32-S3 pin map

Signal	GPIO	Source
SD_CS	41	reused verbatim from Freenove pinmap
SD_SCK	39	"
SD_MISO	40	"
SD_MOSI	38	"
UART0_TX (to CH343P)	43	"
UART0_RX (to CH343P)	44	"
USB host D-	19	" (permanent internal connection to the RP2350, not a cable)
USB host D+	20	"
Status LED (WS2812)	48	"
RP2350_RUN# (new)	TBD, pick from 4-18	`fujiversal-intv.h` pinmap
RP2350_BOOTSEL (new)	TBD, pick from 4-18	`fujiversal-intv.h` pinmap

Freenove-reused rows: include/pinmap/fujiversal-rs232.h. The two new rows need their own pinmap variant (fujiversal-intv.h) since the reference fujiversal-rs232.h has no RP2350-control signals. GPIO33-37 are consumed by octal PSRAM on the N16R8 part and must be left unconnected/unrouted under the module. GPIO26-32 are the S3's own flash pins — also unrouted. Avoid strapping pins 0/3/45/46 for the two new signals. Card-detect (PIN_CARD_DETECT) is GPIO_NUM_NC in firmware — do not wire a CD switch.

USB / flashing topology

USB-C (single port) ──CC pulldowns──> SRV05-4 ──> CH343P ──> ESP32-S3 UART0 (GPIO43/44)
                                                     DTR/RTS -> EN/GPIO0 autoreset
                                       (S3 native USB stays permanently in HOST mode)

RP2350 D+/D- ───────────────────────────────────────────────> S3 GPIO19/20 (host, permanent)

S3 GPIO (RP2350_RUN#)      ──1 transistor──> RP2350 RUN, active low, Hi-Z when idle
S3 GPIO (RP2350_BOOTSEL)   ──1 transistor──> RP2350 QSPI_SS, active low, Hi-Z when idle

ESP32-S3 flashing: the one USB-C port, via the CH343P bridge — standard pio run -t upload.
RP2350 flashing: no external port at all. Two paths:
1. In-band doorbell (normal path) — poke $B5 into the mailbox's BOOTSEL_DOORBELL cell ($9C1B, see Fujinet Intellivision Mailbox Protocol); the RP2350 sees it in fuji_mailbox_service() and calls reset_usb_boot(), rebooting straight into BOOTSEL/PICOBOOT over the existing internal USB link. Cooperative — requires working RP2350 firmware.
2. Hardware forcing (recovery path) — the S3 drives RP2350_BOOTSEL low, pulses RP2350_RUN# low then releases both. Works even if the RP2350 is bricked or hung.
Once in BOOTSEL, a PICOBOOT client on the S3 (lib/hardware/PicobootClient.{h,cpp}, a second usb_host client alongside ACMChannel) writes a raw .bin read from SD/TNFS, then issues REBOOT. The existing "ACM-reconnect" task in ACMChannel.cpp reopens the CDC link automatically afterward.
No VBUS crosses the RP2350↔S3 internal link — attach detection is via the RP2350's D+ pull-up, same as any USB device/host pair.

Power

console +5V (cart pin 43) ─┐
USB-C VBUS ──────────────────┼─ Schottky OR ─> VIN (470uF) ─> 3.3V buck (>=1.5A) ─> 3V3 rail
                                                                  (220uF + 10uF + 100nF at S3 VDD)

Preserves the original PiRTO II design intent (the OR diode's job: no back-feed into the console) while the one remaining USB leg keeps the board alive on the bench.

Open item — must be measured before finalizing regulator/cap sizing: console 5V rail headroom under load, on each target console variant. Estimated draw ~80 mA average / ~400 mA peak at 5V (WiFi TX bursts dominate); not yet verified against real hardware.

Enclosure

Two zones: the lower insertion tongue is dimensionally frozen at the upstream PiRTO II profile (58.19 x 77.54 mm board, 44-pin edge at the same origin); the upper body grows to clear the second MCU and the single USB-C connector across both PCB faces (no SD slot to clear on this board, unlike the earlier PiRTO-II-derived design). Exact growth is gated by a console cart-bay clearance measurement, not yet taken.

Build

cd pico/intellivision/firmware
cmake -B build -DPICO_BOARD=fujicard -DCMAKE_BUILD_TYPE=Release -G Ninja
ninja -C build
# -> build/Minty_fujicard.uf2 -- flash it in BOOTSEL mode

Notes:

pico-sdk 2.2.0 (toolchainVersion 14_2_Rel1, picotoolVersion 2.2.0-a4), set via $PICO_SDK_PATH or the vendored pico_sdk_import.cmake.
fujicard.cmake forces CONFIG_USB_DEVICE 1 even in Release builds — unlike pintycard, where it's a Debug-only convenience, the USB CDC link to the ESP32-S3 is this board's whole purpose. MAX_ROM_SIZE is trimmed to ~430 KB in both configs to pay for the always-on USB device stack.
JLP is on (CONFIG_JLP ON); ECS audio and Intellivoice emulation are off (CONFIG_ECS_AUDIO OFF, CONFIG_INTELLIVOICE OFF) — fujicard has no audio-mod pin defined.
ESP32-S3 side: ./build.sh -e fujiversal-rs232 for the generic firmware, or -e fujiversal-intv for the board-specific pinmap variant with PIN_RP2040_RUN/ PIN_RP2040_BOOTSEL wired up (include/pinmap/fujiversal-intv.h).

Licensing

Per pico/intellivision/PROVENANCE.md: the vendored firmware is a fork of Minty (Gennaro Tortone, GPLv3, https://github.com/gtortone/Minty), which itself refactors PiRTO II (Andrea Ottaviani, https://github.com/aotta/PiRTOII); PiRTO II's storage layer in turn traces to A8PicoCart (Robin Edwards, https://github.com/robinhedwards/A8PicoCart). The Minty GPLv3 grant is what makes vendoring the firmware possible — it resolves the earlier licensing blocker that stalled the previous PiRTO-II-based prototype (that grant is Tortone's for his own refactor, not retroactive licensing of PiRTO II or A8PicoCart).

The cartridge PCB, board outline, 44-pin edge connector, and enclosure are a separate matter and remain unlicensed. They derive from PiRTO II's own schematic/board files, and neither upstream repo grants a hardware license. Do not publish gerbers, BOM, or STL files for this board until a separate grant is obtained from Andrea Ottaviani. This is presently moot in practice since the PCB never got past schematic planning (see Status above), but it governs what can be shared once it does.

Known gaps / status

fujicard is missing from CI. The vendored firmware/.github/workflows/build.yml matrix (pintycard, pirto_ii_default, pirto_ii_duo, pirto_ii_sd, pirto) and scripts/build-board.sh/build-all.sh's board allowlist don't include fujicard — ./scripts/build-board.sh fujicard currently fails with board fujicard not available.
The five boards CI does build no longer link. Minty's own launcher UI (src/launcher.c, RunLauncher()) was removed as part of vendoring this fork for FujiNet, but src/cartridge.c still calls RunLauncher() in the non-CONFIG_FUJINET branch. Only fujicard (the sole board defining CONFIG_FUJINET) takes the RunFujiConfig() branch and actually links.
FUJI_SELFTEST_TRIGGER_PIN (GPIO23) is declared but not wired up in firmware — nothing currently reads it at runtime; fujibus_selftest() is only invoked from host_test/test_fujibus.c on the desktop, not from the board boot path. Don't treat it as a working feature yet.
The two RP2350-control GPIOs' schematic wiring (transistors for RUN#/BOOTSEL forcing) doesn't exist yet — the ESP32-S3 pinmap numbers above are placeholders, not schematic-verified. PicobootClient has not been tested against a real RP2350 in BOOTSEL.
Console 5V headroom and cart-bay clearance are unmeasured (physical hardware required).
Schematic/PCB/enclosure: not started in KiCad/FreeCAD.
Nothing in this stack — mailbox, boot-mapping, BOOTSEL doorbell, PicobootClient — has run on real silicon yet.