SETUP GUIDE

Setting Up RetroArch Without Losing Your Mind

Cores, BIOS files, and controller mapping — the 15-minute version.

SETUP GUIDE RETROARCH

RetroArch is the engine running under the hood of almost every retro handheld's launcher, whether the menu in front of you says RetroArch, MinUI, muOS, or something the manufacturer skinned to look custom. That's good news — it means the setup steps below apply pretty much everywhere — but RetroArch's own settings menu is famously unfriendly to newcomers. Here's the version that skips the confusion.

If your handheld came with custom firmware already installed, you almost never need to install RetroArch itself — it's already there. What you're actually doing is configuring cores, BIOS, and controls inside an app that already exists on the device.

01Cores

A core is the actual emulator for one system — there's a separate core for SNES, one for PS1, one for Genesis, and so on. RetroArch is just the shell that loads whichever core a game needs.

Most handhelds ship with a reasonable default core per system already selected. Don't go download every core available "just in case" — for each system, pick one well-regarded core and stick with it until you have a specific reason to switch:

SNESSnes9x (compatibility) or bsnes (accuracy)
Genesis / Mega DriveGenesis Plus GX
PS1PCSX ReARMed (handhelds) or Beetle PSX
GBAmGBA

If a game runs badly, the first thing to try isn't a settings deep-dive — it's swapping to a different core for that system.

02BIOS Files

Some systems — PS1, PSP, Saturn, and others — need a BIOS file to boot at all, because RetroArch's cores emulate the console hardware but can't legally include the console's own firmware. You have to supply that yourself, dumped from hardware you actually own.

The single most common "why won't this game load" problem is a BIOS file with the wrong filename. RetroArch checks for exact names, not just the right file:

scph5500.bin — PS1 (Japan)
scph5501.bin — PS1 (US)
scph5502.bin — PS1 (Europe)

These go in the device's system (sometimes called bios) folder — not the ROMs folder. If a core-specific error mentions a missing file by name, that's your filename mismatch, not a corrupted dump.

On my RG35XX, running the stock GarlicOS-based firmware, BIOS files go straight into /Roms/BIOS at the SD card root — not nested inside a system-specific subfolder the way some standalone RetroArch installs expect. Dropping the file in one level too deep, inside a folder named after the console, was the actual fix the one time a PS1 game refused to boot for me.

03Controller Mapping

RetroArch ships with a default control scheme per core, but on a handheld with a non-standard button layout, "default" often doesn't match what's printed on the buttons in your hand. Two settings matter here, and they're easy to confuse:

Global remap (Settings → Input → Port 1 Controls) changes the layout for every core. Core remap (accessed from the in-game Quick Menu → Controls) changes it for just the game you're currently in and is saved per-core or even per-game. If a fighting game's inputs feel wrong but everything else is fine, you want a core remap, not a global one.

Save states and in-game battery-backed saves (SRAM) are also separate things worth not confusing: a save state freezes the emulator itself and is fragile across core updates, while an in-game save behaves like the original cartridge/memory card save and survives long-term. For anything you care about keeping, use the in-game save whenever the game supports one.

The remap I actually needed: RetroArch's own menu defaults to Nintendo-style confirm/cancel (B confirms, A backs out), but my RG35XX's face buttons are laid out Xbox-style. Every menu felt backwards until I went into Settings → Input → Menu Controls and swapped confirm/cancel to match the buttons in my hand — worth doing before you touch any per-core remap.

THE 15-MINUTE VERSION

  1. Pick one core per system — don't download everything.
  2. Drop correctly-named BIOS files into the system/bios folder, not the ROMs folder.
  3. Fix controls globally first, then override per-core only where a specific game needs it.
  4. Use in-game saves for anything you want to keep — treat save states as disposable.