Your Pokémon game will not start

Which symptom do you have?

Return to the main menu

1. For the documented auto-resume loop, Onion says to hold POWER for 10 seconds or longer, waiting for the second rumble.
2. If that does not work, shut down and put the SD card in a computer. Back up its readable contents first.
3. The FAQ's next step is to delete .tmp_update/cmd_to_run.sh to disable the next auto-resume. Preserve a copy outside that location before following the documented removal.

See the Onion FAQ's black-screen recovery instructions. If the card cannot be read or the symptom is different, stop this file procedure and record what you actually observe. Do not format the card as a launch test.

Build a clean-launch comparison

After returning to the menu, the next question is whether the prepared game can reach its title screen independently of the broken resume. Write down two results: what happens on a normal resume, and what happens when the same file starts without loading its old state. Keep the file and core unchanged for this comparison.

If the clean launch works, the evidence points toward the resume/state route rather than an inability to open that game at all. If both fail, investigate the file and selected core before diagnosing a lost adventure. Neither result alone tells you whether the cartridge save is readable.

These are troubleshooting branches, not compatibility promises. Use a game you already own and have previously opened for the comparison; acquiring a random replacement file introduces another not documented.

Investigate one game after recovery

Record Onion version, core, exact game filename and when the failure began. Keep your known cartridge save and state backups untouched. Compare a clean launch with the failing resumed session using a disposable copy where possible.

For a patched Pokémon game, revisit the maker's required source-game revision and patching instructions. Check the selected emulator against the game's requirements. Use the local patching tool only with your own legally obtained source and the maker's patch.

If Continue is missing after a successful launch, follow the save-location checklist. Do not overwrite established progress while testing a new-game screen.

After an Onion update

The FAQ also identifies old save-state compatibility as a possible post-update launch issue. Back up states and cartridge saves before moving any relevant state aside. If a state contains progress that was never saved in-game, removing it from active use does not recover that progress.

For changed speed after an update, use the fast-forward guide's update checks. Investigate launch, speed and progress separately so you can tell which change mattered.

Worked example: a failure after an update

1. Record the update as the last known change. Preserve both kinds of progress and the previous version information.
2. Use the documented loop-recovery action to regain access to the menu.
3. Compare a clean launch of the same game with the resumed session. Do not update the hack at the same time.
4. If the title screen appears, inspect Continue. Check trainer, location and party to identify which progress survived in the cartridge save.
5. If Continue contains older progress than the state, record that gap. A successful launch does not recover actions that existed only in the failing state.
6. If a clean launch still fails, collect the file/build/core details rather than repeating forced shutdowns or making several unrelated changes.

This sequence produces a useful report: the exact transition, whether MainUI returned, whether the title screen appeared, and whether cartridge progress loaded. “Still broken” leaves those separate stages unclear.

Did installation finish, or did an old session fail to resume?

When a black screen follows an update, first establish whether Onion’s installation completed and its menu opens. A package copied into an extra outer directory or a missing hidden installation folder concerns installation; a menu that opens but immediately restores one failing game concerns a different stage.

Example: after updating, the menu is available and another game opens, but one Pokémon session remains black. That narrows the failure to the selected launch/session rather than proving the whole installation failed. Preserve its progress and compare the clean launch before repeating the update or replacing the game.

Inspect a per-game core choice before a global reset

Onion’s GLO documentation provides Game core for choosing a custom RetroArch core per game, with mGBA and gpSP as its example. This gives you a concrete setting to inspect when one selected game behaves differently from the rest of the library.

1. After recovering the menu, record the affected file, current core and last change. Preserve its cartridge save and states.
2. Select that exact library entry and open GLO, normally with Y.
3. Inspect Game core before changing it. Compare the game maker’s emulator requirements with the selected option.
4. If a justified comparison is possible, keep the same prepared file and profile, choose one available documented core and start without the previous core’s state.
5. Record title-screen, input and Continue results separately. Restore the previous per-game choice if the comparison is unsuccessful.

Example: the library contains a playable prepared file and the menu works, but one game fails after a custom core selection. The next useful evidence is the selected core and a clean-start comparison. Repatching the game and resetting every RetroArch setting at the same time would obscure that transition.

If the game reaches the title screen but Continue is absent, use the core-specific save-location check rather than calling the launch comparison a failure.

Capture one RetroArch failure for a useful report

Once the menu is accessible, the Onion FAQ documents Apps → RetroArch → Settings → Logging → Log to File, followed by Configuration File → Save Current Configuration. After reproducing the action, its output is at .tmp_update/logs/retroarch.log.

1. Record the current logging setting and preserve the configuration before enabling the diagnostic option.
2. Use the documented route, then launch the exact game or perform the one action that fails.
3. Retain the log with a note naming the file/build, Onion version, selected core and whether the attempt used resume or a clean start.
4. Review the relevant error lines alongside your observed symptom. Remove private paths or identifiers before sharing a report.
5. Return the diagnostic setting to its previous value and save that configuration after the comparison.

Example report: “MainUI works; this prepared build on the recorded core reaches a black screen before the title; clean launch and resume results are attached.” Pair that observation with the relevant log excerpt. It tells a helper which stage failed, instead of attributing every blank screen to a bad save.

If no log appears, record that too; do not invent an error or assume a different launch path uses RetroArch logging. The procedure does not apply automatically to standalone emulators. Keep the normal loop-recovery instructions available while testing.

When to stop changing settings

If you cannot reach the menu, cannot read the card, or cannot identify the active game and save, retain the original files and seek help with that evidence. Avoid stacking firmware, core and patch changes during recovery.

Miyoo Mini Plus overview. Onion 4.3 documentation checked 6 Oct 2026.

Does the same file open directly in standalone mGBA?

First distinguish a missing library entry, a failed Steam launch and a game that opens but does not behave correctly. Those are different observations. This guide concerns EmuDeck’s standalone mGBA path, not the RetroArch core with the same name.

1. Record the game filename and the Steam entry that fails.
2. Close the game and retain an independent progress backup before testing.
3. In Desktop Mode, open standalone mGBA and select that exact playable file.
4. Observe whether it reaches the title or menu; do not save a blank adventure over old progress.
5. Return to the recorded Steam entry and compare the result.

“It works on desktop” is only useful when both attempts use the same game output and emulator.

The documented special-character filename issue

EmuDeck lists special characters in a game filename as a cause of failed Steam launching, including the é in Pokémon. It directs users to remove the character in the actual game folder and rerun Steam ROM Manager when it was previously used.

Test this on a separate working copy before renaming the installation that owns established progress. A human-readable title inside Steam and the file that its entry opens are separate things.

These are example names, not a game recommendation or a required naming convention. Keep the real playable extension. A patch or ZIP renamed to .gba does not become a playable game.

Expected observation: the test copy opens directly and its refreshed Steam entry also opens. That supports a launch-path correction for this attempt. If it still fails, keep the result and investigate the entry/runtime instead of repeatedly renaming more files.

Refresh the entry after changing the test filename

EmuDeck documents Steam ROM Manager and mGBA parsers for the standalone path, alongside ES-DE and emulator entries. Record which entry you actually use before refreshing the library.

1. Keep the original game and save setup intact.
2. Identify the folder containing the launch-test copy.
3. Rerun Steam ROM Manager if that was the tool used to create the entry.
4. Identify the entry that now targets the test copy, rather than selecting by artwork alone.
5. Open it and compare with the direct mGBA attempt.

Two entries can show similar titles while opening different files. Before deleting a presumed duplicate, establish its target and which progress you normally load from it. This guide does not require removing the old entry to perform the launch test.

Worked example: you copy a game under a simpler name but keep selecting the old icon. The new file’s direct launch tells you it exists; it does not show that the old shortcut now points to it. Identify the target or select the refreshed test entry before evaluating the change.

A successful title screen is not a recovered save

Once the test entry launches, stop and choose whether the next task is continuing established progress or just verifying a new installation. Missing Continue after using a different filename is a save question; it is not enough evidence to declare the original progress lost.

EmuDeck lists standalone mGBA’s ordinary saves under Emulation/saves/mgba/saves and states separately under Emulation/saves/mgba/states. The Emulation root depends on your installation.

1. Retain the old game, ordinary save and states.
2. Identify the actual file/player-save selection used by the working installation.
3. Keep a copied game’s progress mapping separate from its launch result.
4. Use the documented save workflow before trying to continue the experiment.
5. Check trainer, party and location through Continue before making a new save.

The multiple player-save guide explains the separate player-file choice. A state slot, Steam shortcut and ordinary save file are not interchangeable identities.

If the original file still opens the correct progress, preserve it while resolving the new entry. Do not start a new game merely to see whether saving works when the goal is to recover an existing adventure.

Launch works, but the shortcuts do not

After a successful launch, verify ordinary movement and a harmless Pokémon menu. If they work but fast-forward or pause does not, the next task is the Steam Input/hotkey layer rather than creating another patch output.

Use the standalone mGBA hotkey guide. Record whether you launched through a direct Steam shortcut or ES-DE and which profile that entry uses. A new entry may need its own control check.

Example: the old entry has a convenient hotkey layout, while the freshly generated test entry opens the game with ordinary controls only. The file now launches. Investigate the selected profile on that entry, then test pause or fullscreen before experimenting with load-state shortcuts.

This sequence separates two results: the game file opens through the chosen entry, and the intended controls reach the emulator.

Identify the executable and configuration you are testing

The checked EmuDeck mGBA reference describes an AppImage at /home/deck/Applications/mGBA.AppImage and configuration in /home/deck/.config/mgba, including config.ini, library.sqlite3 and qt.ini. Those roles differ from the prepared game and cartridge save.

1. Record the executable used by the working direct launch and the failing entry.
2. Identify the prepared game passed to that executable.
3. Keep a configuration copy before investigating settings or an emulator update.
4. Compare the same executable and game before concluding the game output is faulty.

In Dolphin, use the menu’s hidden-file view to inspect the dotted configuration folder. A card containing your Emulation folder does not imply that every emulator setting lives on that card: the reference separately places these configuration files on internal storage.

Example: a Steam entry targets a different emulator installation from the one that opens the game directly. Keep the prepared file unchanged and record that difference. Repatching would change a separate part of the comparison without resolving which executable the shortcut invokes.

If a custom setup differs, record its actual paths. Do not delete the configuration database as a test of whether a cartridge save exists.

Read the parser name before choosing an mGBA guide

Example: two shortcuts have the same artwork and both include “mGBA” in their setup history. Record the parser and launched runtime before comparing hotkeys or saves. Similar names do not establish identical configuration.

If the intended entry uses the core, changing standalone mGBA’s files would investigate the wrong owner. If it uses the standalone path, continue with the actual save-backup checks.

If both direct and Steam launching fail

Revisit the file’s role. A creator patch, a prepared game output and a cartridge save are different inputs. Keep the failure stage clear: a patch tool refusing the source is not the same result as a valid output failing in a runtime.

Use the patch-to-play diagnosis for the actual stage, and the game’s profile for its maker requirements. Check the installed build before changing an unrelated controller setting.

For a useful support note, record the project/build, exact launched file, standalone mGBA identity, direct-launch result, Steam entry and any displayed error. Keep the result factual: “this copy reached the title directly but its entry closed” is more actionable than “the Deck cannot play Pokémon.”

Steam launch questions

Sources and software scope

• EmuDeck: standalone mGBA launch, filename and save documentation

The software details are paraphrased from the linked documentation. Worked examples and comparison steps are Pocket Deal Radar’s proposed checks, not physical-device test results. Record your own outcome and installed software.

Use the GBA handheld guide for other setup paths. This page supplies no ROMs, BIOS files, prepatched games or mirrors.