RetroArch Cores 2026: 200+ in 12 Steps, 40 Min

RetroArch advertises a number that gets quoted everywhere and understood almost nowhere: over 200 cores. It is true, in the way a library catalogue is true. The catalogue lists two hundred-odd emulators, game engines, and media players. Your fresh install ships with exactly none of them, and the ones you can actually download depend entirely on which CPU architecture you happen to be standing on. The number on the box is not the number on your shelf.

This tutorial is for people who installed RetroArch, opened the Core Downloader, and either found it empty or found themselves staring at forty entries with names like Beetle PSX HW, SwanStation, and PCSX ReARMed, trying to work out which one plays a PlayStation game. All three do. That is the problem. We fix it in twelve steps, name the correct core for every major system, and explain the single menu action — updating the core info files — that silently sabotages every other step if you skip it.

Versions, for the record: RetroArch stable is 1.22.2, published 20 November 2025, the tail end of the 1.22 line that also introduced the new PlayStation 2 core. Everything below is written against it and verified on the current libretro release page. Budget roughly forty minutes start to finish, most of which is downloading. We begin with what a core actually is, because nearly every problem downstream is a misunderstanding of that one word.

What a Core Actually Is

The libretro API, in one paragraph

RetroArch is a frontend. It draws the menu, reads your controller, pushes video and audio, manages save states, netplay, shaders, and achievements. By itself it emulates nothing. The emulation is done by a core: a shared library — .dll on Windows, .so on Linux and Android, .dylib on macOS — that implements the libretro API. libretro is the thin contract between frontend and emulator: here is the controller state, hand me back one frame and a slice of audio. Any emulator ported to speak that contract becomes a core. This is why the identical Beetle PSX code runs the same inside RetroArch, Lakka, Batocera, RetroPie, and a dozen handheld launchers — they are all libretro frontends loading the same file.

The consequence you will feel: a core is a file, and files are architecture-specific. A core compiled for x86_64 Windows will not load on an ARM handheld no matter how many times you copy it across. That one fact explains most of the failed-to-load-core errors on the internet, and we return to it more than once.

"200+ cores" is a catalogue, not a shelf

The 200+ figure counts every core the libretro buildbot compiles across all platforms combined. What your Core Downloader displays is the intersection of that catalogue with your specific operating system and CPU architecture. On desktop x86_64 you will see well over a hundred. On an armv7 handheld you will see a curated subset — the webosbrew community build of the core set, rebuilt in December 2025, ships roughly 170+ armv7 cores plus an experimental aarch64 tier, and that is a generous count for ARM. On a locked-down cheap device you might see forty. None of this is a defect. It is the catalogue meeting hardware.

Core, system, emulator — pick your words carefully

One system frequently has five cores. The original PlayStation alone offers Beetle PSX HW, Beetle PSX (software), SwanStation, PCSX ReARMed, and a couple of historical also-rans. These are different emulators, by different authors, with different accuracy levels and wildly different performance costs — all wearing the libretro uniform. "Which core?" is therefore a genuine question with a genuine answer per system, and the answer flips depending on whether you are on a desktop with a discrete GPU or a sub-$100 handheld running a Cortex-A7. The middle third of this guide is that table.

Prerequisites: Versions and Hardware

Software: get onto 1.22.2 first

Do not start downloading cores against a two-year-old frontend. Cores from the buildbot are compiled against the current libretro API, and a stale RetroArch will refuse them with the maddeningly generic "failed to load core." Update the frontend, then the cores. On the three desktop platforms:

# Windows (winget)
winget upgrade Libretro.RetroArch

# Linux / Steam Deck (Flatpak)
flatpak update org.libretro.RetroArch

# macOS (Homebrew cask)
brew upgrade --cask retroarch

# Debian / Ubuntu: individual cores also live in the PPA
sudo apt-get install libretro-beetle-psx-hw

On Android, update through the Play Store or sideload the current APK; on a handheld running muOS, ROCKNIX, or OnionOS, the core set is managed by the distribution, not by you — more on that in the handhelds section. After the frontend updates, you still have to update the cores separately. They are not the same operation, and assuming they are is pitfall number one.

Hardware reality, by system

Emulation accuracy is bought with clock cycles, and some cores are honest about the bill. A cycle-accurate SNES core (bsnes Accuracy) wants roughly a 4 GHz CPU to hold full speed with special-chip games; on anything weaker it stutters, and the practical answer is Snes9x. The new PlayStation 2 core, LRPS2 — a hard fork of PCSX2 with a fresh ParaLLEl-GS renderer — is x86_64-only (Windows, Linux, and macOS under Rosetta) with no Android, iOS, or ARM-Linux build in existence, so "PS2 on my phone" is not a configuration that exists in 2026; the libretro LRPS2 announcement spells out the scope. Nintendo 64 accuracy via ParaLLEl wants a Vulkan-capable GPU. Everything up to and including the fifth generation runs comfortably on modern desktop silicon; the sixth generation (PS2, GameCube, Wii) is where your hardware starts to matter.

BIOS, ROMs, and the law

Some systems will not boot without a real BIOS image: PlayStation, PlayStation 2, Saturn, and Neo Geo among them. RetroArch does not and legally cannot ship these; they are copyrighted firmware, and you are expected to dump them from hardware you own. The same applies to the games. This site's position is boring and consistent: dump your own cartridges — a Retrode-style cartridge dumper turns your physical library into legal backups in a few minutes — and place BIOS files in RetroArch's System directory with the exact filenames and hashes the core expects. A BIOS with the wrong hash is functionally a missing BIOS, and the symptom is a black screen that tells you nothing.

The 12-Step Install

Why the order is non-negotiable

These twelve steps are sequenced deliberately. The most common failure on forums — an empty Core Downloader, or cores that download but show as "unrecognized" — is caused by doing step six before step four. Read the rationale on each; it is the difference between this working and you filing a bug report against software that is behaving correctly.

1. Confirm your RetroArch version. Settings → Information → System Information. You want 1.22.2, or whatever the current stable is when you read this. Rationale: core builds track the frontend; the buildbot serves cores compiled for the current API.
2. Update the frontend before touching cores. Use the platform command above, or the built-in updater on Android. Rationale: a mismatched frontend loads stale cores and reports the useless "failed to load core."
3. Make the Core Downloader visible. If Online Updater is missing entries: Settings → User Interface → Menu Item Visibility → Show Core Downloader (and Show Online Updater). Rationale: some builds and some distributions hide it by default.
4. Online Updater → Update Core Info Files. Do this before anything else in the updater. Rationale: the info files are the manifest that tells RetroArch which cores exist, what they are called, and which systems and file extensions they claim. Without a fresh manifest the Core Downloader is empty or wrong, and cores you sideload show as unrecognized. This is the single most-skipped, most-consequential step in the entire process.
5. Update Assets, Databases, and Overlays. Same Online Updater menu. Rationale: menu icons, thumbnail scanning, and the content database that lets RetroArch name your games. Cosmetic, but do it now while you are here.
6. Online Updater → Core Downloader → pick your system's core. Now — and only now — the list is populated and filtered to your architecture. Rationale: steps one through four guaranteed the list is correct; downloading before them is where the empty-list complaints come from.
7. Verify the core installed. Main Menu → Load Core; your new core should appear in the list. Rationale: confirms the file actually landed in your cores directory for your platform.
8. Place BIOS files where required. Drop them in the System/BIOS directory (Settings → Directory → System/BIOS reveals the path). Rationale: PS1, PS2, Saturn, and Neo Geo cores will not boot without correctly-named, correct-hash firmware.
9. Load content and test immediately. Load Content, pick a ROM, let RetroArch pair it with the core. Rationale: confirm the core-and-content pairing boots before you spend twenty minutes configuring options for a core that was never going to run on your hardware.
10. Set core options. Quick Menu → Core Options, per system (renderer, internal resolution, and so on). Rationale: defaults are conservative; this is where you buy image quality with whatever headroom you have.
11. Save an override, not a global config. Quick Menu → Overrides → Save Core Override, or Save Game Override. Rationale: persists your settings for this core or game without polluting the global config that every other system inherits.
12. Update Installed Cores periodically. Online Updater → Update Installed Cores refreshes everything in one pass. Rationale: cores get fixes; the libretro buildbot pushed a change on 24 May 2026 that replaced older core files, and installs from before that date needed exactly this action to pick them up.

Expected output

After step six, a correctly-updated Core Downloader on desktop looks approximately like this — an alphabetised list of systems, each expandable to its cores:

Online Updater
  Update Core Info Files          [done]
  Core Downloader
    Nintendo - NES / Famicom
      FCEUmm
      Mesen
      Nestopia UE
    Nintendo - SNES / SFC
      bsnes
      Snes9x
      Snes9x - Current
    Sony - PlayStation
      Beetle PSX
      Beetle PSX HW
      PCSX ReARMed
      SwanStation
    ...

If instead you see an empty list, or a spinner that resolves to nothing, you skipped step four. Go back and run Update Core Info Files. It is always step four.

The Right Core Per System

The desktop-first recommendations

Accuracy and performance trade against each other, and the right answer depends on your hardware. On a modern desktop, prefer the accurate core; on a handheld, prefer the one that holds full speed. Here is the per-system table this whole guide exists to deliver.

The three cores everyone gets wrong

Nintendo 64. The mainline core is mupen64plus-next, which bundles the GLideN64 HLE renderer plus the angrylion and ParaLLEl-RDP/RSP plugins — it is the recommended default per the libretro N64 docs. But it regressed in early 2025: certain titles (Stunt Racer 64, World Driver Championship) stopped loading, and the community fix was to pin an older January build. If you want low-level accuracy instead of speed, ParaLLEl N64 runs a Vulkan LLE path with narrower compatibility. N64 remains the fussiest fifth-generation system in RetroArch, and nothing about that changed in 2026.

PlayStation. Three live options, and they are not interchangeable. Beetle PSX HW (a Mednafen derivative with a hardware renderer) is the most accurate and the heaviest — the desktop pick. SwanStation is the libretro port of DuckStation, a good middle ground. PCSX ReARMed is the lightweight ARM-optimised core that powers budget handhelds and the muOS / OnionOS / ROCKNIX distributions. Picking Beetle PSX HW on a cheap handheld and then complaining about frame drops is a self-inflicted wound.

3DS. If a guide tells you to install the Citra core, that guide is stale. Citra was taken down, and its role passed to Azahar — a merge of the prominent Citra forks, including PabloMK7's — whose first official libretro core shipped as 2125.0 Alpha 4 across six operating systems, with the line advancing toward 2126.0 by mid-2026. Grab it from the Azahar releases page or through the Core Downloader once your info files are current.

Sega, arcade, and the 32X trap

Genesis Plus GX is a superb core — it does Mega Drive, Mega-CD, Master System, Game Gear, SG-1000, and Pico at essentially 100% compatibility, a lineage that traces back to a Wii homebrew emulator. It does not do 32X. For the 32X you want PicoDrive, which is also the core the Core Downloader recommends for Genesis on Android. For arcade, Final Burn Neo is the modern default, with a curated library stretching back to 1970s boards; MAME is the sprawling completist alternative. The libretro core list documents the full roster if you want the systems this table skips.

Core Options That Matter

Where the settings live

Two different things get called "settings," and they are stored separately. RetroArch settings (video, audio, input) live in retroarch.cfg. Core options (renderer, internal resolution, region) are core-specific and live in retroarch-core-options.cfg globally, or in a per-game .opt file. You reach them at Quick Menu → Core Options while content is running. Change them there, then decide whether to keep them global or scope them with an override, which is the next section.

Beetle PSX HW, annotated

The PlayStation core is the one people most want to tune, because internal-resolution upscaling turns a 240p console into something watchable on a 4K panel. The real option keys, as written to retroarch-core-options.cfg:

# Beetle PSX HW - sane 4K-desktop defaults
beetle_psx_hw_renderer            = "hardware_vk"   # Vulkan; "hardware_gl" or "software" also valid
beetle_psx_hw_internal_resolution = "4x"            # 1x..16x; 4x is safe on most GPUs
beetle_psx_hw_pgxp_mode           = "memory only"   # fixes wobbly PSX geometry
beetle_psx_hw_dither_mode         = "internal resolution"
beetle_psx_hw_widescreen_hack     = "disabled"      # enable only for fully-3D games

PGXP is the setting worth understanding: the PlayStation's GPU had no sub-pixel precision, so textures and polygons visibly wobble. pgxp_mode = "memory only" corrects the geometry cheaply; "memory + CPU" is stricter and heavier and occasionally breaks a game, so start with memory-only. The widescreen hack stretches the 3D field of view; it is safe on fully-3D games and hideous on anything with 2D backgrounds, so leave it off by default.

Don't tune what you can't see

Internal resolution above 4x on a 1080p display is spending GPU budget on pixels you will never resolve. Match the upscale to the panel: 2x to 3x for 1080p, 4x to 6x for 4K, and stop. The same restraint applies to run-ahead, to shader stacks, and to accuracy cores generally — the deadpan truth is that most of the image-quality war is won at 4x internal resolution plus a modest CRT shader, and everything past that is you reading a spec sheet instead of playing a game.

Overrides: Game, Core, Directory

The hierarchy, most specific wins

RetroArch resolves configuration from most specific to least: game override → content-directory override → core override → global config. A game override beats a core override beats the global. This is how you keep a widescreen hack on for one PS1 game without inflicting it on the other three hundred. The files live in predictable places under your config directory:

config/<core>/<core>.cfg      # core override  - applies to every game on this core
config/<core>/<dir>.cfg       # content-directory override
config/<core>/<game>.cfg      # game override   - applies to exactly one ROM
config/<core>/<game>.opt      # per-game core options
config/remaps/<core>/*.rmp    # per-core / per-game input remaps
retroarch-core-options.cfg    # global core options

Saving one from the menu

You never have to write these by hand. With content running: Quick Menu → Overrides → Save Core Override writes config/<core>/<core>.cfg; Save Game Override writes the per-game .cfg. For core options specifically, Quick Menu → Core Options → Manage → Create game-options file scopes the current options to just this ROM. RetroArch reads them back automatically on next launch, provided the auto-load switches are on.

The switches that make overrides load

Three settings govern whether your overrides are honoured, and one governs whether they get silently overwritten:

auto_overrides_enable  = "true"    # load .cfg overrides automatically
auto_remaps_enable     = "true"    # load .rmp input remaps automatically
game_specific_options  = "true"    # load per-game .opt core options
config_save_on_exit    = "false"   # do NOT let RetroArch rewrite global config on exit

That last one is the quiet villain. With config_save_on_exit = "true", every change you make anywhere gets flushed into the global config when you quit, and your carefully-scoped overrides slowly drown in global state. Turn it off, save deliberately, and your configuration stays legible. The libretro overrides guide is the authority here and worth a read once you are past the basics.

Cores on ARM Handhelds

The architecture cliff

Everything above assumes a desktop. Move to a handheld and the ground shifts, because now you are on ARM and the catalogue shrinks. The webosbrew build's ~170 armv7 cores is the upper bound; a locked device shows far fewer. Cores that are x86_64-only — LRPS2 for PS2 being the headline — simply do not exist for you. This is not RetroArch failing; it is a Cortex-A-class chip not being an x86 desktop. If PS2 or GameCube is the goal, buy hardware for it, and read our 2026 Retroid Pocket buying guide before you spend, because the SoC is the whole story on these devices.

Distro-managed cores

On muOS, ROCKNIX, OnionOS, and their relatives, you generally do not run the Core Downloader — the distribution ships and pins a known-good core set, and updating cores means updating the distribution. The lightweight picks are chosen for you: PCSX ReARMed for PlayStation, Snes9x (not bsnes) for SNES, Genesis Plus GX and PicoDrive for Sega, gpSP or mGBA for GBA. A Miyoo Mini Plus, for context, is a 3.5-inch, 640x480 device on an SSD202D — it plays up to PS1 beautifully with ReARMed and should not be asked to do more.

When cores refuse to load on ARM

Reports recur — a Retroid Pocket owner finds that ColecoVision or some other minor core will not start while the majors run fine. Almost always this is an architecture or build mismatch: the core was built for a slightly different ABI than the frontend on that device expects. The fix is to update the info files and installed cores from the same source, and failing that, to accept that a given minor core is not maintained for your exact device. It is the same lesson as the desktop, sharpened: the core is a file, and the file has to match the machine.

Common Pitfalls and Fixes

The five that account for most failures

• Skipping Update Core Info Files. Symptom: empty Core Downloader, or sideloaded cores show as "unrecognized." Fix: Online Updater → Update Core Info Files, then retry. This is pitfall zero, and it is always the answer when the list is empty.
• Hand-copying a core from another machine. Symptom: "failed to load core." Fix: never copy core binaries between architectures. A Windows .dll is not an Android .so. Use the Core Downloader on the target device so you get the build for its CPU.
• Missing or wrong-hash BIOS. Symptom: black screen on PS1/PS2/Saturn/Neo Geo boot, with no error. Fix: place the exact BIOS the core expects in the System directory and verify the hash; a renamed wrong file counts as missing.
• Expecting LRPS2 on a phone or handheld. Symptom: no PS2 core in the downloader. Fix: there is not one for ARM. LRPS2 is x86_64-only. Use a desktop.
• Running bsnes Accuracy on weak hardware. Symptom: audio crackle and frame drops in Star Fox or Super Mario RPG. Fix: switch to Snes9x. bsnes wants ~4 GHz; almost nothing else does.

The subtler ones

• Genesis Plus GX for 32X. Symptom: 32X games will not run. Fix: GPGX does not include 32X — use PicoDrive.
• mupen64plus-next and the 2025 regression. Symptom: specific N64 titles will not load. Fix: pin the January build or switch to ParaLLEl N64.
• config_save_on_exit clobbering overrides. Symptom: settings leak between systems. Fix: set it false and save overrides deliberately.

Why "update the info files" fixes so much

If one instruction survives this article, it is this: the info files are the map RetroArch uses to recognise, name, and load every core. They are tiny, they update in seconds, and a stale set produces symptoms — empty lists, unrecognized cores, phantom load failures — that look like a dozen different bugs and are all the same bug. When something core-related misbehaves and you do not know why, Update Core Info Files, then Update Installed Cores, before you touch anything else.

Troubleshooting Table

Symptom, cause, fix

When to reach for the nightly buildbot

If a fix landed upstream but has not reached stable, the libretro nightly buildbot carries bleeding-edge cores. Treat it as diagnostic, not a lifestyle: nightly cores can regress as easily as they fix, and the whole point of the stable channel is that someone already caught the regressions. Pull the nightly for one misbehaving core, confirm the fix, and go back to stable for everything else.

Advanced Tips

RetroAchievements is native

You do not need a third-party plugin for achievements; support is built into RetroArch. Settings → Achievements, log in with your RetroAchievements account, and compatible cores will track unlocks with an optional hardcore mode that disables save states and cheats. It is one of the genuinely modern things RetroArch does well, and it costs nothing.

Run-ahead, and its price

Run-ahead hides input latency by internally running the core a frame or more ahead and rolling back — it can make emulated input feel closer to original hardware than original hardware sometimes did. The catch is cost: it re-runs the core each frame, so it is cheap on an NES core and expensive on a PS1 core. Enable it (Settings → Latency → Run-Ahead) on light systems, measure, and do not bother forcing it on heavy cores that already tax your CPU.

Keep cores current in one pass

Online Updater → Update Installed Cores refreshes every installed core in a single action against the buildbot. Run it after any RetroArch update and after any OS update — the 24 May 2026 buildbot change is the concrete example of why: it swapped out older core files, and only installs that ran Update Installed Cores picked up the new ones cleanly. On the desktop package managers you can also script the frontend upgrade; on Linux the per-core PPA packages (libretro-*) update through apt alongside the rest of your system.

A Complete Working Config

The global baseline

Here is a coherent starting point: a global retroarch.cfg fragment that turns on the override system and turns off the setting that undermines it, a Beetle PSX HW core-options block, and a single per-game scope. Adapt paths to your platform; RetroArch uses forward slashes in config on every OS.

# --- retroarch.cfg (global fragment) ---
config_save_on_exit    = "false"
auto_overrides_enable  = "true"
auto_remaps_enable     = "true"
game_specific_options  = "true"
video_smooth           = "false"    # no bilinear blur; let a shader do the work
video_scale_integer    = "false"
savestate_auto_save    = "false"

# --- retroarch-core-options.cfg (PlayStation, global) ---
beetle_psx_hw_renderer            = "hardware_vk"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_pgxp_mode           = "memory only"
beetle_psx_hw_dither_mode         = "internal resolution"
beetle_psx_hw_widescreen_hack     = "disabled"

# --- config/Beetle PSX HW/<game>.opt (per-game core options) ---
# widescreen and a heavier upscale for ONE fully-3D title;
# every other PS1 game inherits the global set above
beetle_psx_hw_widescreen_hack     = "enabled"
beetle_psx_hw_internal_resolution = "6x"

# --- config/Beetle PSX HW/<game>.cfg (per-game RetroArch override) ---
# a RetroArch setting, not a core option, so it lives in .cfg not .opt
aspect_ratio_index = "23"     # 16:9, to match the widescreen hack above

Note the split in those last two blocks: core options go in .opt, RetroArch settings go in .cfg, and both are scoped to the same game. Getting a setting into the wrong file is a common reason an override appears to be ignored.

The install, distilled

If you skim nothing else: update the frontend, then Update Core Info Files, then Update Assets and Databases, then Core Downloader, then BIOS, then load and test, then core options, then save an override with config_save_on_exit off. Eight actions in that order and the other four steps are verification. Do them out of order and you will spend the forty minutes on a forum instead.

Where to go when this isn't enough

The libretro download-cores guide is the canonical reference for the Core Downloader, and the wider docs cover per-core options the way this article covers Beetle PSX HW. If you would rather not manage cores at all, a purpose-built distribution does it for you — Batocera and the venerable RetroPie ship curated, pinned core sets so the update dance above happens on their schedule, not yours. And if software emulation's per-device fragility grates on you entirely, an FPGA board like the MiSTer Multisystem 2 reconfigures silicon to be the console rather than approximate it — a different philosophy with a much larger bill, and no info files to update. RetroArch's bargain is the opposite: one frontend, two hundred cores in the catalogue, and the small tax of knowing which four steps come first.