PSOne Handheld Mod Explained: MicroSD, HDMI, and Boot Exploits
A PSOne motherboard modified to load games from a microSD card, authorize unsigned code through a memory-card exploit on every boot, and output video over HDMI to any modern display. It works reliably. That last part is what makes this build worth examining.
This PSOne handheld mod is really a portable PSOne for hotel TVs, not a palm-sized handheld. The HDMI output is the tell: you set this next to a television, plug in, and play. But the engineering problem it solves is more interesting than the form factor. The build succeeds not because any single component is clever, but because three independent open-source tools, PicoStation, PicoMemcard, and a fork of exploit-boot firmware, were configured to stop interfering with each other. Getting there required finding and fixing an interaction bug that none of the three projects had documented.
The boot chain, in order: PicoMemcard presents the exploit image in memory card slot one. FreePSXBoot triggers, handing control to Tonyhax International. Tonyhax launches the game loaded by PicoStation from the microSD card. Once the game is running, Tonyhax switches the active memory card context to a game-specific save image, leaving the exploit image untouched in slot one for the next reboot. Each piece depends on the one before it. The subtle failure mode, described below, broke that chain at step one without any warning.
The baseline matters here. PSIO has allowed standard PlayStation hardware to load games from SD cards for years, but the PSOne was never a supported target. Even reaching a working optical drive emulator on this platform requires a workaround, as Hackaday noted in January. PicoStation fills that gap using commodity parts at a fraction of the cost of commercial alternatives.
The load path: getting a game off a card and into the console
An optical drive emulator does one thing: it intercepts the signals a console expects from a spinning disc and answers with data read from storage instead. The console never detects the substitution.
PicoStation handles that job here, built from an RP2040-based Raspberry Pi Pico and a microSD card module. It fills the same functional role as xStation or PSIO, but assembled from hardware that costs significantly less than either commercial option, according to forum documentation from last September. One builder's testing found that Class 4 cards performed reliably. That's a single forum report rather than a formal specification, so treat it as a floor, not a guarantee.
Multi-disc handling is where the rough edges show. PSIO supports .m3u playlist files that reference per-disc .cue files, giving multi-disc games a clean, standardized path. PicoStation doesn't support that format. The available workarounds are:
- Toggling the lid switch to cycle through discs in a folder, where each open-and-close advances to the next disc image
- Using the button combination
L2 + R2 + SELECT + L1to swap discs without touching the hardware
Both approaches work, but only if the lid switch is physically wired to the PicoStation board. Whether multi-track BIN files need to be merged into a single file also depends on that same wiring decision. The forum thread contains both answers to that question because both answers are correct under different hardware configurations.
That's not a documentation failure so much as a sign of where PicoStation sits on the maturity curve. XStation added disc queue support and a dedicated Memory Card Manager in firmware version 1.4.4, RetroRGB reported in October 2021. XStation shows what usually gets built next once the basic ODE works: better disc handling, better card management, fewer edge cases. PicoStation is earlier on that same arc.
The exploit path in a PSOne portable build: why the memory card has to survive every reboot
Most PSOne builds that run unsigned code depend on FreePSXBoot or Tonyhax International. Both require a specific memory card image, the exploit payload, to be present in slot one at startup. That image is managed by PicoMemcard, a second Raspberry Pi Pico running firmware that emulates a physical memory card entirely in software, as documented in the alex-free/PicoMemcard repository from September 2025.
This is where the integration problem became concrete.
Standard picomemcard+ firmware tracks the last-used memory card image and restores it silently on the next boot. In isolation, that's a reasonable convenience feature. Inside this build, it means the firmware quietly overwrites the FreePSXBoot exploit slot with the save image from the last game played. No warning, no error, no indication anything went wrong. The user reboots, opens the Memory Card Manager to trigger the exploit, and finds the wrong file sitting in slot one, per the repository.
The fix is a single behavioral change. A fork of the project stops writing to LASTMEMCARD in index.txt. The exploit image stays in slot one across every reboot. Once a game launches, Tonyhax International automatically switches the active memory card to a game-specific image, giving the player up to 15 save slots per game. On the next reboot, the exploit is still in slot one, ready to run, as the fork's README describes.
The full loop runs cleanly: enter the Memory Card Manager, trigger FreePSXBoot, let Tonyhax International launch the game and swap the card context, play, save, reboot, repeat from the beginning.
This was the most non-obvious failure mode in the entire stack. Not a wiring error. Not a firmware crash. A default behavior in one component that silently broke the one thing a different component depended on at a specific moment. The fork fixed it, and the fix required someone to understand what both components expected at boot and trace the conflict back to a single variable write.
The output decision: HDMI on hardware that never had it
Composite output works fine on a PSOne, so the HDMI choice needs justification. The answer is straightforward: HDMI removes the need for a capture card or a CRT to get a usable picture on modern equipment. For a build designed to travel somewhere and plug into a TV, it eliminates the last dependency on legacy display hardware.
Adding HDMI to a PSOne requires board-level work that demands real soldering confidence. This is not a beginner step. The payoff is a cleaner signal path and a machine that works with any display made in the last two decades, which matters if the device is actually going somewhere.
The broader design logic here is familiar from other portable console projects. A PS4 portable build covered by Yanko Design in January made the same HDMI-out choice for the same reason: once you've built something meant to sit next to a hotel TV, legacy video outputs become the friction point, not the solution. The output decision follows directly from the use case, regardless of what's inside the box.
What this PSOne microSD mod proves for anyone thinking about attempting one
The parts list for a working PSOne microSD mod is short, the ODE hardware is cheap, and the PicoMemcard fork resolves the most subtle integration failure in the stack. That specific fix, stopping the silent overwrite of the FreePSXBoot image by never updating LASTMEMCARD in index.txt, is what separates a build that works reliably from one that fails intermittently in a way that's genuinely hard to diagnose, according to the fork's README.
Be equally clear-eyed about what still requires care. Multi-disc handling depends on lid-switch wiring, and the documentation is inconsistent because the hardware configuration changes the correct answer. That's a solvable problem. XStation's path from basic ODE to disc queues and a full Memory Card Manager, completed by version 1.4.4 according to RetroRGB, shows how quickly usability features accumulate once the core integration stabilizes. PicoStation is now where xStation was several years back, with the same work ahead of it.
This is no longer a one-off build held together by luck and scattered forum posts. The individual components are documented, the cross-component failure mode has been patched, and a builder who reads the right fork's README will avoid the reboot problem that made earlier versions brittle. The hard parts that remain are the kind that get solved the same way this one was: someone finds the failure mode, names it precisely, and pushes a fix.
Comments
Be the first, drop a comment!