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

RetroArch advertises 'over 200 cores.' Both halves of that phrase are load-bearing. 'Over 200' is the size of the libretro catalogue counted across every operating system and CPU architecture the buildbot compiles for; the number you can actually download onto your machine is smaller, and the number worth installing is smaller still — comfortably under twenty for most collections. This is a guide to that shorter list: what a core is, which ones earn a slot in 2026, how to feed the hungry ones BIOS without breaking the law or your evening, and how RetroArch's four-tier configuration hierarchy quietly decides which of your carefully-saved settings actually win.

Everything here was checked against RetroArch 1.22.2, the stable build from November 2025. Where a core shipped, regressed, or died in the last eighteen months, the version responsible is named. There is no affiliate link, no 'cores you won't BELIEVE,' and no BIOS download. Dump your own hardware; that part is on you.

What a Core Actually Is

The libretro API in one paragraph

RetroArch is a frontend, and a frontend emulates nothing. It draws the menu, reads your controller, runs shaders, records video, manages save states, and then hands the actual work to a core: a dynamic library — .dll on Windows, .so on Linux and Android, .dylib on macOS — that implements the libretro API. libretro is a deliberately thin contract: here is a frame of video, here is a chunk of audio, tell me which buttons are down, give me a block of memory I can save and restore. Any emulator that speaks it can be loaded by any frontend that speaks it. RetroArch is the reference frontend, not the only one. That is the whole trick — Snes9x, Mednafen, PCSX2, and mGBA are unrelated codebases by different authors, and libretro lets them share one interface, one input layer, and one save-state format instead of reinventing all three badly.

The practical upshot: a core is not a feature you toggle inside RetroArch. It is a separate program you download, and it can be updated, regress, or vanish independently of the frontend around it. When someone says 'RetroArch can't run this game,' nine times out of ten they mean a specific core can't, and the fix is a different core, not a different frontend. Read the official core list the way you'd read a parts catalogue: by system, by trade-off, not top to bottom.

Why '200+ cores' is a catalogue, not a promise

The 200-plus figure counts distinct cores the libretro buildbot compiles — not the number your Core Downloader will show. The buildbot builds each core per platform and per architecture, and your RetroArch only advertises the builds matching your OS and CPU. A Windows x64 install sees one set; an Android device sees another; an ARM handheld sees a third, often much shorter, list. In December 2025 the webOS core repository was rebuilt to roughly 170-plus 32-bit ARM (armv7) cores plus a smaller experimental 64-bit set — a good illustration that 'how many cores exist' and 'how many run on this device' are different questions with different answers.

This matters most on handhelds. The budget ARM boxes running OnionOS or muOS lean on lightweight cores compiled for their exact chip, which is why a heavy desktop core simply won't appear or won't load there. If you are choosing hardware around emulation, the CPU architecture decides your core menu before you ever open it — a point worth keeping in mind when you compare something like the Retroid Pocket 5 and 6, where the newer chip unlocks cores the older one struggles with.

Core, core info file, and BIOS are three different files

Three files, three jobs, and conflating them is the single most common way to lose an hour. The core is the emulator library. The core info file — a .info text file that lives beside the cores — is metadata: the human-readable name RetroArch shows, the file extensions the core accepts, the list of BIOS files it needs and their exact checksums, and flags like whether it requires a full path to content. The BIOS is proprietary firmware — the PlayStation boot ROM, the Neo Geo system ROM — that you supply yourself and that no legitimate core ships.

The info files are why the first thing you do after installing RetroArch is update the core info files, before you download a single core. If the manifest is stale, the Core Downloader can look empty, list nothing useful, or hand you a core that then loads as 'unrecognized.' Get this order wrong and you will blame the core; the core is fine.

Prerequisites: Versions and Hardware

Software: RetroArch 1.22.2 and where to get it

Install RetroArch 1.22.2 (November 2025) or newer, and specifically not 1.22.0. The 1.22.0 release shipped a shader regression that could leave games on a black screen; it was fixed in 1.22.1 and 1.22.2, so there is no reason to sit on the broken one. The prior milestone, 1.21.0 from spring 2025, is where a lot of Apple-platform Vulkan and 3DS plumbing landed; if you are on macOS or iOS, 1.21+ is the floor. Grab builds from the official GitHub releases or the platform stores, and verify the version under Information → System Information if you're unsure what a 'latest' installer actually gave you.

You also want the online updater reachable. Everything in this guide assumes you can hit the libretro distribution servers to pull cores, info files, assets, and databases. If you're building a fully offline machine, mirror the nightly buildbot tree yourself; otherwise, leave the machine online for setup.

Hardware, honestly: the 4 GHz problem

Emulation cost is not uniform, and the marketing habit of quoting 'runs thousands of games' hides a brutal spread. 8- and 16-bit systems run on a potato. The expensive cores are the cycle-accurate ones: bsnes Accuracy, the gold standard for SNES correctness, wants roughly a 4 GHz CPU to hold full speed because it models the console at the cycle level rather than the instruction level. Beetle PSX HW with its hardware renderer and PGXP enabled is likewise not a handheld core. If your CPU is modest, you use the practical cores — Snes9x, PCSX ReARMed — and accept that 'accurate' and 'playable' are sometimes different columns.

This is also the honest case for FPGA. Software emulation trades CPU cycles for accuracy; an FPGA reimplements the original silicon and sidesteps the timing question entirely, which is why a board like the MiSTer Multisystem 2 exists and why people pay for it. RetroArch cores are cheaper, more flexible, and run on hardware you already own; they are not, at the margins, more accurate than a good FPGA core. Know which trade you're making.

BIOS files and the legal line

Several systems will not boot without a genuine BIOS: PlayStation and PS2, Sega CD, Saturn, Neo Geo, and others. RetroArch cores never bundle these, for the obvious reason that the firmware is copyrighted and still owned by companies with lawyers. Dumping the BIOS from a console you own sits in the same murky DMCA §1201 territory as dumping your own cartridges — tolerated in practice, not blessed in statute — while downloading a BIOS someone else dumped is unambiguous copyright infringement. This guide will tell you the filenames a core expects and where they go. It will not tell you where to download them, because that is the part the law actually cares about.

Practically: each core's .info file lists the BIOS it needs, by filename and checksum. Put those files in RetroArch's System directory (Settings → Directory → System/BIOS), match the names exactly, and the core will find them. Get a name or a region wrong and you get a black screen with no useful error — see the troubleshooting table.

Install and Populate Cores: 12 Steps

The order that matters (and why)

The single most common failure in every RetroArch setup thread is downloading cores (step 6) before updating the core info files (step 3). The info files are the manifest the downloader reads; without a fresh set, cores arrive as 'unrecognized' and load-fail. Do the twelve in sequence the first time — you can improvise on the second machine. Budget forty minutes end to end, most of it waiting on downloads.

1. Install RetroArch 1.22.2 — not 1.22.0. The .0 build shipped a shader black-screen regression fixed in .1 and .2, and later 1.22.x builds carry core-loading fixes. Start current so the bugs you hit are yours, not ones already patched.
2. Launch once and let it build its directory tree. First run creates config/, cores/, info/, system/, and the playlist folders. You need to know these exist before dropping BIOS and overrides into the right ones.
3. Online Updater → Update Core Info Files. Before downloading any core. This refreshes the manifest the Core Downloader reads. Skip it and the downloader can be empty or hand you cores that load as 'unrecognized.' This one step prevents most 'core won't load' posts.
4. If the Core Downloader is hidden, enable it: Settings → User Interface → Menu Item Visibility → Show Core Downloader. Some distribution builds ship with it off, and you can't download what the menu won't show.
5. Update Assets and Databases (Online Updater → Update Assets, Update Databases). Assets are the menu icons and fonts; the databases are the CRC tables that let RetroArch recognise your ROMs on scan. No databases, no clean playlists.
6. Load Core → Download a Core — only the systems you own games for. Don't install all 200. Each core is dead weight you'll later have to update, and ARM/x86 builds differ; a curated dozen is faster and less confusing than the whole catalogue.
7. Verify each core loads. Load Core → pick the one you just grabbed; RetroArch should return to the menu showing the core name with no error banner. This catches architecture mismatches — an aarch64 build on an armv7 device — the moment they happen rather than three menus deep.
8. Place BIOS in the System directory with the exact filenames the info file specifies. PS1, PS2, Saturn, Sega CD, and Neo Geo cores check for specific, checksum-matched files. Right name, right folder, or it silently won't boot.
9. Import Content → Scan Directory on your ROM folder. Scanning matches files against the databases and builds per-system playlists, associating each game with a core — the thing that makes double-click-to-play work later.
10. Load one game per system as a smoke test. Confirm the core + BIOS + content chain runs end to end before tuning anything. If a system fails here, you fix one link, not a whole config.
11. Set a default core per playlist (open the playlist → Playlist Settings → Default Core). With a default set, launching a game won't prompt you to choose a core every single time.
12. Save your first override: Quick Menu → Overrides → Save Core Overrides (or Save Game Overrides). This writes a small per-core or per-game .cfg instead of editing global config — how you keep a widescreen hack on one game without imposing it on all of them. The hierarchy that makes this work is the next section.

Expected output when it works

At the end of step 12 you should have a Main Menu listing your installed cores, one playlist per system with recognised titles (not a pile of 'unknown' entries), and at least one game per system that boots to gameplay. A correct core load looks like this in the log:

[INFO] [Core]: Loading dynamic library: Beetle PSX HW
[INFO] [Core]: Version of libretro API: 1
[INFO] [Content]: Loading content file: Final Fantasy VII (USA).chd
[INFO] [Core]: Content ready.

If that's what you see, the plumbing is correct and everything downstream is tuning, not repair.

If a step fails

Nearly every failure at this stage is one of two things: stale info files (fix: step 3, again) or a wrong-architecture core (fix: get the build for your CPU and OS). Both, plus the rest, are in the troubleshooting table below. Resist the urge to reinstall RetroArch — it's almost never the frontend, and a reinstall keeps your old config anyway.

The 2026 Core Picks, System by System

Opinion, informed by what actually shipped and broke this cycle. Where two cores are listed, the first is the default recommendation and the second is the escape hatch.

Nintendo: NES through 3DS

NES: Mesen. It's PPU-accurate, has the widest mapper coverage, and ships a real debugger; nothing else is close on correctness. SNES: bsnes (Accuracy profile) if your CPU can feed it, Snes9x if it can't or you're on a handheld — Snes9x is the pragmatic default for anything portable. N64: mupen64plus-next is the mainline default and bundles GLideN64 (HLE), angrylion, and the ParaLLEl-RDP/RSP plugins in one core, which is why the libretro docs recommend it. The asterisk: it regressed in early 2025 — some titles like World Driver Championship and Stunt Racer 64 stopped loading — so keep a January-2025 build pinned, or switch to ParaLLEl N64 (Vulkan low-level rendering) for accuracy on specific games at the cost of narrower compatibility.

Game Boy / Color: Gambatte or mGBA. GBA: mGBA, full stop — accurate, fast, actively maintained. 3DS: this is the year's real change. Citra was taken down and is dead; do not chase old Citra cores. Its successor is Azahar, a merge of the major Citra forks (PabloMK7's and Lime3DS among them). Azahar shipped the first official 3DS libretro core with 2125.0 (Alpha 4) across six operating systems — Linux, Windows, macOS, Android, iOS, tvOS — and the line has since advanced to 2126.0. Note that Azahar dropped encrypted-game and Nintendo-CDN support, so title installation now routes through its Artic Setup Tool; the project site documents it.

Sony: the PS1 triangle and the PS2 fork

PS1 is a three-way choice, not one answer. Beetle PSX HW (Mednafen lineage, hardware renderer) is the most accurate and the heaviest — internal-resolution upscaling, PGXP geometry correction, the works — and it's the desktop pick. SwanStation is the libretro port of DuckStation, a fast and modern middle option. PCSX ReARMed is the lightweight ARM core that powers the budget-handheld world — it's what's under the hood when you play PS1 on OnionOS boxes like the Miyoo Mini Plus. Pick by horsepower: ReARMed on a handheld, SwanStation on a mid machine, Beetle PSX HW on a desktop that can afford it.

PS2 is the headline. The core is LRPS2, a hard fork of PCSX2 rebuilt for libretro, announced on the libretro blog and now shipping in the 1.22 line. It carries a brand-new low-level renderer, ParaLLEl-GS by Themaister — a Vulkan compute renderer aiming for software-level accuracy on the GPU, from the same author as the ParaLLEl-RDP tech now under most N64 emulators. The catch you must plan around: LRPS2 is x86_64-only (Windows, Linux, macOS via Rosetta). There is no Android, iOS, or ARM-Linux build. It needs a real PS2 BIOS, and it now embeds its GameIndex database in the core. The LRPS2 docs are the reference; if you're on ARM, this core is simply not for you, and no amount of updating changes that.

Sega, arcade, and the 32X asterisk

Genesis / Mega Drive and friends: Genesis Plus GX, the ex-Wii homebrew core that grew up. It covers Mega Drive, Sega CD, Master System, Game Gear, SG-1000, and Pico at high accuracy — but not 32X. For 32X you use PicoDrive, which is also the lighter option across the whole Sega range on weak hardware. The Genesis Plus GX docs spell out the coverage; the 32X gap trips people up every year. Saturn: Beetle Saturn or Kronos on a strong desktop; Saturn remains expensive. Arcade: Final Burn Neo (FBNeo) is the broad, well-curated default, reaching back to 1970s hardware and staying current with romset conventions; MAME cores exist if you need a specific driver FBNeo lacks.

Overrides: The Configuration Hierarchy

Four levels, most specific wins

RetroArch resolves configuration in layers, and understanding the order is the difference between 'my settings stick' and 'my settings mysteriously don't.' From least to most specific: global (retroarch.cfg) → core override (applies to every game run under that core) → content-directory override (applies to everything in a folder) → game override (one specific ROM). More specific always wins. A widescreen hack saved as a game override affects that game only; the same key in the global config affects everything. When two levels disagree, the narrower one takes it.

The files live under config/<CoreName>/, and the whole tree looks like this:

config/
  retroarch.cfg                       # global
  retroarch-core-options.cfg          # global core options
  Beetle PSX HW/
    Beetle PSX HW.cfg                 # core override
    Final Fantasy VII (USA).cfg       # game override
    Final Fantasy VII (USA).opt       # per-game core options
  remaps/
    Beetle PSX HW/
      Beetle PSX HW.rmp               # core input remap

Each file contains only the keys that differ from the level below it — RetroArch doesn't duplicate your whole config, it stores the delta. The overrides guide is the canonical reference and worth a bookmark.

Core options are not RetroArch config

There are two separate settings systems and people conflate them constantly. RetroArch settings — video driver, audio, input, shaders — are what overrides cover. Core options are the emulator's own knobs: internal resolution, PGXP mode, region, BIOS selection. These live elsewhere: globally in retroarch-core-options.cfg, and per-game in a .opt file at config/<CoreName>/<gamename>.opt once you create one. Changing 'internal resolution' is a core option; changing 'video driver' is an override. If your setting is under Quick Menu → Core Options, it's the former; if it's under the RetroArch settings menus, it's the latter.

The key that gates per-game core options is game_specific_options; the keys that auto-apply overrides and input remaps are auto_overrides_enable and auto_remaps_enable. All three default sensibly, but if per-game settings aren't loading, those are the flags to check first.

Saving overrides without editing text files

You rarely need a text editor. Set what you want in-game, then Quick Menu → Overrides → Save Core Overrides / Save Content Directory Overrides / Save Game Overrides, and RetroArch writes the delta to the right file at the right level. For per-game core options, Quick Menu → Core Options → Manage Core Options → Create game-options file writes the .opt. The menu route is less error-prone than hand-editing, and it puts the file exactly where the hierarchy expects it. When something won't stick, it's almost always saved at the wrong level — see the pitfalls.

Keeping Cores Current

Windows: winget and Update Installed Cores

Two moving parts: the frontend and the cores, updated separately. On Windows, the frontend goes through winget:

winget upgrade Libretro.RetroArch

Then update the cores from inside RetroArch: Online Updater → Update Installed Cores (and, as always, refresh the core info files first if it's been a while). Updating the frontend does not update your cores, and updating cores does not touch the frontend — a mismatch between a very new core and very old info files is a classic 'suddenly won't load' cause.

Linux: the PPA and your package manager

On Debian/Ubuntu you can pull cores as system packages instead of through the in-app downloader:

sudo apt-get install libretro-<core>

...where <core> is the package name, e.g. libretro-mgba or libretro-genesisplusgx. This is handy on managed systems, but the packaged versions can lag the buildbot; if you need the newest core, the in-app updater or a nightly is fresher. Distro-maintained emulation frontends like Batocera and RetroPie bundle and update cores their own way, which is a feature if you want a turnkey box and a constraint if you want the bleeding edge.

Nightlies from the buildbot

When a core is fixed upstream but the fix hasn't reached a stable release, the nightly buildbot has it. Point RetroArch's core updater at the nightly channel, or download the specific core build and drop it in cores/ manually. Nightlies are exactly as stable as the name suggests — great for chasing a specific regression fix, not what you leave a whole collection on. This is also how you'd pin an older build: keep the known-good file (the January-2025 mupen64plus-next, for instance) and decline to update just that one.

Five Pitfalls That Waste Your Evening

Loading and downloader pitfalls

1. You skipped the core info files. Symptom: the Core Downloader is empty, or a freshly-downloaded core loads as 'unrecognized.' Fix: Online Updater → Update Core Info Files, then retry. This is the number-one cause of 'RetroArch is broken,' and it isn't broken. 2. The core is the wrong architecture. Symptom: the core downloads but 'Failed to load core.' Fix: get the build matching your CPU and OS — an aarch64 core won't run on an armv7 device, and a desktop x86 core won't run on a handheld. On ARM hardware, use the platform-specific repository (the webOS set, your handheld's OS packages) rather than assuming the desktop core exists for you.

BIOS and content pitfalls

3. The BIOS is missing, misnamed, or in the wrong folder. Symptom: PS1/PS2/Saturn/Neo Geo content loads to a black screen or 'cannot load content,' with no useful error. Fix: read the core's .info for the exact filename(s) and checksum(s), place them in the System directory, and match names precisely — region matters (a US game may want a US BIOS). 4. You expected 32X on Genesis Plus GX. Symptom: 32X ROMs fail on an otherwise-perfect Sega core. Fix: Genesis Plus GX doesn't emulate 32X by design; use PicoDrive for those. Same family, different chip, different core.

Configuration pitfalls

5. Your override saved at the wrong level. Symptom: a setting won't persist, or a per-game tweak leaks onto every game. Fix: remember most-specific-wins — a game override beats a core override beats global — and use Quick Menu → Overrides → the correct 'Save … Overrides' entry rather than editing global config. A bonus sixth, because it's common: settings don't survive a restart at all. Fix: check that config_save_on_exit is on, or save an override explicitly; RetroArch does not always persist ad-hoc changes unless you tell it to.

Troubleshooting Table

Cores that refuse to load

The failures cluster into three buckets — won't load, loads-but-wrong, and performance — and almost all trace back to one of the pitfalls above. The table maps symptom to cause to fix; scan the left column for what you're seeing.

Cores that load but misbehave

A core that loads and then renders wrong, ignores your pad, or runs at 40 fps is a different diagnosis from one that won't load at all. The middle band of the table — regressions, missing 32X, remaps, cycle-accurate slowdown — is where most of the 'it works but…' reports land. When a single core misbehaves while everything else is fine, suspect that core's build or its options before you touch anything global.

When the whole install feels wrong

If many cores fail at once, stop poking individual games and update the info files, assets, and databases as a set — a stale manifest breaks broadly, not narrowly. If exactly one system fails, it's that core, its BIOS, or its options. That single distinction — broad versus narrow failure — routes ninety percent of troubleshooting correctly.

Advanced Tips

Per-game core options and the .opt file

Once you've internalised the hierarchy, per-game core options are where the real tuning happens. Internal resolution, PGXP, widescreen hacks, region — set them per title so a demanding game gets 2× render scale while a fussy one stays at native. Quick Menu → Core Options → Manage Core Options → Create game-options file writes config/<CoreName>/<gamename>.opt, and from then on that game carries its own emulator settings independent of every other game on the same core. Confirm game_specific_options is enabled if the file isn't taking effect.

Renderer selection: Vulkan, GL, and software

Heavy cores expose a renderer choice, and it's the biggest single lever on both accuracy and performance. Beetle PSX HW and LRPS2 default toward their high-accuracy paths — ParaLLEl-GS on LRPS2 is a Vulkan compute renderer built to match software accuracy on the GPU — but you can drop to a lighter GL path or true software when a game misrenders or your hardware can't keep up. Vulkan is generally the modern default on desktop; if you get driver-level glitches, testing GL is a legitimate diagnostic, not a superstition. Match the RetroArch video driver to the core's renderer where the core asks for it — a Vulkan-targeted core wants the Vulkan driver underneath it.

Run-ahead, latency, and input remaps

Run-ahead is RetroArch's headline latency feature: it internally runs the core one or more frames into the future and rolls back, cutting the input lag baked into the original hardware. It's CPU-expensive — you're running the core multiple times per frame — so it pairs badly with already-heavy cores and beautifully with light ones (NES, SNES via Snes9x, GBA). Input remaps are their own hierarchy, parallel to overrides: .rmp files under config/remaps/<CoreName>/, savable per-core, per-directory, or per-game. Remap when only the buttons are wrong; override when the settings are wrong; don't reach for a full override to fix a single mismapped button.

A Complete Working Configuration

Global retroarch.cfg essentials

These are the global keys worth setting deliberately rather than leaving to chance. This is a fragment, not the whole file — retroarch.cfg has hundreds of keys; set these and let the rest default.

# retroarch.cfg — global essentials
video_driver = "vulkan"
video_fullscreen = "true"
menu_driver = "ozone"
config_save_on_exit = "true"
game_specific_options = "true"
auto_overrides_enable = "true"
auto_remaps_enable = "true"
savestate_auto_load = "false"
savestate_auto_save = "false"
rewind_enable = "false"

config_save_on_exit = true is the one that fixes 'my settings vanish'; game_specific_options and the two auto_* keys are what make per-game tuning load automatically.

A per-core override: Beetle PSX HW

Saved via Quick Menu → Overrides → Save Core Overrides, this lands at config/Beetle PSX HW/Beetle PSX HW.cfg and applies to every PS1 game run under that core. Keep it small — only the deltas from global.

# config/Beetle PSX HW/Beetle PSX HW.cfg
video_driver = "vulkan"
video_smooth = "false"
video_scale_integer = "false"
video_shader_enable = "true"

A per-game options file

Core options for a single title, written by Create game-options file. This one gives one demanding PS1 game 4× internal resolution and PGXP geometry correction while leaving every other PS1 game at whatever the core default is.

# config/Beetle PSX HW/Final Fantasy VII (USA).opt
beetle_psx_hw_renderer = "hardware"
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"

That's the whole model: a lean global config, a small per-core override for renderer-level defaults, and a per-game .opt for the settings that should belong to exactly one title. Build it in that order, save from the menus rather than by hand, and RetroArch's hierarchy stops being mysterious and starts being useful. For the deepest reference, keep the overrides guide and the per-core pages in the libretro docs open while you work.