This ESP32 launcher loads Doom and Quake from an SD card without rebooting

Doom gets a file on the SD card. So does Quake. Giltal’s ESP32-P4 Launcher handles the awkward little job between them: loading the next program, giving it access to the screen and controls, then cleaning up when it leaves. The demons can take turns without making the whole board start its day over.

The maker’s repository describes the arrangement as running applications from storage the way a PC does. Its permanent launcher stays in flash. Programs arrive as .papp files, short for PSRAM App, and execute from the board’s external memory. Adding one becomes a file-copy operation after the launcher is installed. Reflashing a device just to change entertainment has always had the hospitality of moving houses to watch another channel.

Loading involves more than copying bytes. The launcher checks the file’s format and checksums, verifies required service interfaces, allocates memory, then patches addresses to match the available location. It links the app to its services and makes the loaded code executable before calling its entry point. The README reports roughly 70 milliseconds to load Quake, including about 20 milliseconds for 2,332 relocations. That is the maker’s loading measurement; it does not promise every game reaches its first playable frame in that time.

Applications ask for display, sound, input and file services through the launcher’s interfaces. They avoid direct board dependencies, so a hardware port has a smaller job. The same app files and SD card reportedly work across the Guition 4.3-inch board, Guition’s 7-inch JC1060P470C and the M5Stack Tab5. The screen can change while the Doom file keeps its address in your life.

The maker’s performance table keeps the expectations pleasantly concrete. Doom is listed at about 33 displayed frames per second and Quake at about 20 in its timedemo demo1 benchmark, using software rendering. Those figures come from older launcher versions named in the table. A fast load and a fast renderer are separate receipts, even when both arrive with the same familiar shotgun.

Resource tracking handles memory, files, threads and surfaces as applications exit. A force-stop path asks a hung program to quit before stopping its threads and reclaiming resources. Crash information can be retained for diagnosis. Those are useful recovery tools for a hobby console; the README’s known limitations put a very specific boundary around them.

It states, “No memory protection between app and launcher.” A misbehaving or malicious application can therefore reach beyond the tidy cleanup story. The preview application interface can also change before version 1.0. Anyone building on the SDK needs to watch that contract, and anyone distributing game-engine bundles needs to check their individual licenses. The launcher’s MIT license does not sweep those engines into the same basket (nice try).

A small app library could grow around this separation if the interface settles and board ports keep honoring it. The immediate experiment is already more interesting than another Doom screenshot: games leave, their resources get collected, and the launcher stays. Mouse support and BLE controllers remain on the README’s unfinished list.

Quake can wait its turn.