"Metal Gear Solid on a $10 chip: what ESP32-S3 retro ports mean for your next handheld"

Metal Gear Solid on a $10 chip: what ESP32-S3 retro ports mean for your next handheld

In 1998, Metal Gear Solid needed a PlayStation, a memory card and about forty dollars. In September 2026, David Montero Crespo demonstrated the same game running natively on an ESP32-S3: a two-dollar microcontroller the size of a postage stamp. Hackaday covered the port at the end of September, and it follows the Wipeout clone that appeared earlier in the year. This is not emulation. Understanding why that distinction matters tells you a lot about what the ESP32-S3 can actually do, and about the legal line Australian makers need to respect when they build retro handhelds.

Why native ports are possible at all

The trick behind the project is decompilation. The FoxdieTeam MGS Reversing project has spent years translating the game's compiled MIPS machine code back into human-readable C, matching every function until the reconstructed source produces byte-identical behaviour. Once a game exists as portable C source, it can be recompiled for any architecture, including the Xtensa cores inside the ESP32-S3. As the developer's own write-up explains, the port runs on a Seeed Studio XIAO ESP32S3 Sense: a dual-core ESP32-S3 with 8 MB of PSRAM and 8 MB of flash, with game data stored on a microSD card.

This matters because emulation is expensive. A PlayStation emulator must interpret foreign machine code instruction by instruction, which normally needs far more headroom than a microcontroller has. A native recompile just runs, because the code has been translated to the chip's own language. The ESP32-S3 at 240 MHz with 8 MB of external PSRAM turns out to sit just over the line where PS1-era 3D becomes feasible: rasterised polygons, software transforms, a framebuffer blitted to a display over SPI.

What hardware you need

The demonstration handheld used in the port was deliberately barebones: the XIAO board, an ILI9341 TFT display, and an analog stick salvaged from a drone controller, wired on perfboard. You do not need that exact combination, and you probably own something closer than you think:

• Any ESP32-S3 board with PSRAM. The PSRAM is the non-negotiable part; boards without it will not hold the framebuffer and game state. Our StealthPuter (A$89.68) is a Cardputer-class ESP32-S3 pocket computer with the memory and a built-in keyboard, which makes it the closest thing we stock to a ready-made retro handheld base.
• A display. The port targets the ILI9341-class SPI TFT. The same display family drives our ESP32-S3 4.3-inch touch board (A$59.01), which gives you a much bigger canvas than the 2.4-inch demonstration unit.
• Input. An analog stick and a few buttons on the ESP32's ADC and GPIO pins. Nothing exotic.
• microSD for game data, since flash alone is too small for the assets.

Difficulty is honest here: porting a game yourself is hard, architecture-level work. But playing an already-ported title is a firmware flash and an SD card copy. The interesting middle ground is studying the port's source, which the developer has published, to see how a 3D pipeline was squeezed into a microcontroller. If your interest is more general firmware than gaming, our Bruce firmware guide covers the multi-tool route on the same silicon.

The wave is wider than one game

The Metal Gear port is the headline, but it is the second data point, not the first. Earlier in 2026 a Wipeout-style racer demonstrated the same recompile pipeline on the S3, and hobbyist forums now carry ports and experiments for several more PS1-era titles. Each one doubles as a performance benchmark: the port authors publish what they had to cut (higher-precision math, certain post-processing effects, cd-audio streaming) and what survived, which is better documentation of the S3's real limits than Espressif's datasheet provides.

For a builder deciding what to buy, the useful signal is the pattern across the ports. Every successful port so far shares the same requirements: a dual-core S3, external PSRAM measured in whole megabytes, an SPI or parallel display, and data on removable storage. Boards missing any of those fail in the same ways, which is why the shopping list in this post is short and stable. If a community port targets a board profile you can already source, you are one firmware flash from trying it; if you spec your own handheld around that profile, you are future-proofed for whatever the community ports next.

There is also a quieter benefit: the porting community's decompilation work produces portable, documented source for games whose original engines were closed. Security researchers occasionally find that old console code, now readable, makes for instructive study material on fixed-point math, memory budgets under extreme constraint, and engine design from an era when every byte was argued over.

The legal line, clearly stated

This is the part Australian readers most often get wrong, so it deserves its own section. Three distinct things are in play:

1. Decompilation projects like FoxdieTeam exist in a legally contested but long-established grey zone that other clean-reimplementation projects (OpenMW, decompiled Super Mario 64, Ship of Harkinian) have occupied for years. The ports themselves are published as source code, not as game data.
2. Game assets (ROMs) are copyrighted. A decompilation port still needs the original game's data files, and the correct way to get them is to make them from a copy you own. Downloading a ROM of a game you do not own is copyright infringement regardless of how lawful the port's source is. The developer's write-up is explicit that you need the game data yourself.
3. Playing a port you built at home is fine. Distribution of the assets is not. Keep your build to yourself and your immediate friends who own the game, and you stay on the sensible side of the line.

Nothing here is legal advice; if you plan to publish or sell anything derived from a decompilation, get actual advice.

Why this matters beyond nostalgia

The retro-port wave is really a capability announcement for the ESP32-S3. The same recipe (PSRAM, SPI display, software 3D) powers lower-stakes projects: Wipeout-style racers, Doom-class engines, and the growing Cheap Yellow Display firmware ecosystem. Every one of those projects raises the odds that your next pocket device, whatever its official purpose, can also carry a PS1-era game engine in reserve. Silicon that was pitched as an IoT sensor controller in 2020 now renders 1998's most demanding console titles. The S3 is quietly the most capable sub-$5 computer ever shipped, and the retro community is the group documenting its limits most honestly.

Parts list, AU-priced

• StealthPuter (Cardputer-class ESP32-S3) - A$89.68 - pocket base with keyboard and PSRAM
• ESP32-S3 4.3-inch touch display board - A$59.01 - big-screen desktop variant
• ESP32-S3 dev board with PSRAM + ILI9341 display (from AU suppliers, ~A$20 total for the barebones route)
• Analog thumb stick + tactile buttons - parts-drawer items
• microSD card you already own

Affiliate disclosure: products linked are our own store.

Build order matters more here than in most projects: confirm the display runs first, get input working second, and only then attempt the game flash. Each stage isolates a failure mode, and the community port's issues list is the fastest reference when a stage misbehaves.

If you build one, start by reproducing the developer's exact hardware before improvising. The perfboard handheld in the write-up looks rough and runs a PlayStation game; that is the whole argument for native ports in one image.

← All posts