RetroArch Cores 2026: Install 200+ in 12 Steps, 30 Min

RetroArch does not contain a single line of emulation code. It never has. Internalize that before you touch a menu, because roughly ninety percent of the confusion people have with this program dissolves the moment they accept it. RetroArch is a frontend — a shell, a cockpit — and the actual work of pretending to be a Super Nintendo or a Sega Saturn is done by separate, swappable plugins called cores. You download them, you manage them, and at some point you will curse at them. This tutorial is about doing all three without wasting an evening.

The mechanism is the libretro API. A core is any emulator, game engine, or media player that speaks libretro; RetroArch is the reference implementation of a program that speaks the other half of that conversation. That contract is why the same core binary runs inside RetroArch on Windows, inside a Batocera image on a Raspberry Pi, and inside a handheld's custom launcher, all reading the same ROM library without a recompile. It is also why "core" and "libretro core" mean the same thing, and why nobody who knows what they are doing calls RetroArch "an emulator."

As of its last edit, the official cores page puts the catalog at over 200 cores and notes, in the project's own words, that the list "keeps expanding over time." That figure is real. It is also a trap, because the number of cores you can actually install on your device is smaller — sometimes by half. We will get to why. First, definitions, because precision here is what separates a thirty-minute setup from a lost weekend.

What a Core Actually Is (and Why It Isn't an "Emulator")

If you remember only one section of this guide, make it this one. Every later step assumes you have the mental model right.

The frontend does the boring half; the core does the hard half

RetroArch owns everything that is the same across every system: input mapping, video and audio output, the shader pipeline, netplay, save states, rewind, the RetroAchievements hooks, the config system, and the menu you are staring at. The core owns exactly one thing — being the machine. When you load a SNES ROM, RetroArch hands the bytes to a SNES core, the core executes the 65816 and the PPU and hands back a framebuffer and an audio stream, and RetroArch paints it on your screen. Neither half knows much about the other beyond the libretro contract. That separation is the entire design, and it is why a bug in "RetroArch" is often actually a bug in a core, and a broken game is often a bad core choice rather than a bad frontend. Diagnosing which is which is half the skill.

One system, many cores, and the accuracy-versus-speed tax

There is rarely a single "SNES core." There is Snes9x, Snes9x 2010 (an older, lighter fork), bsnes and its mercury variants, and Mesen-S — all emulating the same console with wildly different priorities. bsnes in its accuracy profile is cycle-accurate and wants roughly a 4GHz core to hold full speed; Snes9x will run on a potato. Neither is "correct" and the other "wrong." They are points on a curve whose axes are accuracy and the hardware you can afford to throw at it. Picking the right point on that curve for your device is the single most valuable thing this tutorial teaches, and it is why a $90 handheld and a gaming PC do not run the same core list even for the same console.

Cores aren't only emulators

The libretro net is wider than consoles. The official App Store listing bundles families like PUAE (Commodore Amiga), Beetle Cygne (Bandai WonderSwan), Holani (Atari Lynx), and DICE — a discrete-logic simulator for the pre-microprocessor arcade era, the Pong-and-transistors games that have no CPU to emulate at all. There are media-player cores, a 2048 clone, and game-engine reimplementations. When the project says the catalog "keeps expanding," this long tail is where most of the growth happens. It is also why "how many cores are there" is a genuinely slippery question, which brings us to the state of the library in 2026.

The 2026 State of the Core Library

The library is large, actively maintained, and quietly churning underneath you. Here is what the numbers actually mean this year.

"200+ cores" and "100+ cores" are both true

retroarch.com says over 200 cores. Two separate 2026 setup guides — a Spanish one dated 5 July 2026 and an English one dated 25 June 2026 — both describe the Online Updater as offering "100+" or "well over 100" cores, spanning everything from the Atari 2600 and NES up through PlayStation, Sega Saturn, and arcade boards. A third, dated 8 July 2026, quotes a "100+ RetroArch cores" catalog in the Core Downloader. None of these sources is wrong. The 200+ figure is the catalogue — every core the project maintains source for, across every platform. The 100+ figure is what a given platform's buildbot actually compiles and serves to your Core Downloader. Desktop x86_64 gets close to the full set; ARM handhelds get a curated subset; the webosbrew rebuild for older armv7 devices topped out around 170 cores in December 2025. So the honest answer to "how many cores can I install" is: open your own downloader and count, because the catalog number is a ceiling you will never see.

The project is still shipping, not coasting

This is not abandonware living on a 2019 build. Libretro pushed a maintenance update, 3.7.1, on 29 April 2025 that brought "RetroArch and libretro cores updated to the same versions as in the 4.0 release." The cores page itself carries a page-update stamp of 23 June 2026 and a text-update stamp of 13 August 2026. Demand is visible too: the Libretro forum's Core and Feature Requests board sat at 880 replies and 129,782 views as of 22 June 2026 — a lot of people still asking for more machines. Even the plumbing moves: the libretro-super repository's update-cores.sh packaging script showed commit activity as recently as 22 May 2025. Cores get rebuilt on the buildbot continuously; the version you downloaded last year is not the version on the server today.

New names, renamed cores, and dead ends

Two changes you must know for 2026, because searching for the old names will send you in circles. First, Citra, the Nintendo 3DS emulator, is dead — taken down, gone. Its successor is Azahar, a merge of the surviving Citra forks, which landed as an official libretro core in the 2125.0 line and has since advanced to the 2126.0 series. If a guide tells you to grab "the Citra core," that guide is stale. Second, the PlayStation 2 core LRPS2 is the renamed, hard-forked successor to the old "PCSX2 libretro" — same lineage, new name, new ParaLLEl-GS renderer. Track these renames, because the Core Downloader lists the current names only, and half the outdated tutorials on the web still use the old ones.

Prerequisites: Versions, Hardware, and BIOS

Get these three things right before you download a single core. Skipping this section is the number-one reason people end up in the troubleshooting table.

Software: get a current RetroArch from the right place

The current stable line is RetroArch 1.22.2, released 17 November 2025. (The 1.22.0 point release shipped with a shader black-screen bug fixed in 1.22.1 and 1.22.2 — do not run 1.22.0.) The cores page still headlines the earlier 1.21.0 milestone from 29 April 2025, which is why you will see that version cited around the web; either 1.22.x is fine, but there is no reason to run anything older. Install from the official builds where you can — the Steam release and some locked-down store versions restrict where cores may be written, which turns Step 3 below into a fight you do not need. Standard commands:

Windows (winget):   winget install Libretro.RetroArch
Steam Deck / Linux: flatpak install flathub org.libretro.RetroArch
macOS (Homebrew):   brew install --cask retroarch

# Update later (do this BEFORE touching cores):
winget upgrade Libretro.RetroArch
flatpak update org.libretro.RetroArch
brew upgrade --cask retroarch

Hardware: match the core to the silicon

Cores are not equally hungry. This is the reality check before you try to run a Saturn on a handheld:

The PS2 row is not a performance note; it is a hard wall. LRPS2 is compiled for x86_64 (Windows, Linux, and macOS via Rosetta) and there is no ARM build, so no amount of overclocking your handheld will summon one. If you want that class of hardware doing PS2, you are looking at a different device — or at the FPGA world, for which our MiSTer FPGA hub is the rabbit hole.

BIOS files and folder layout

Some cores need a real console BIOS you legally own — PS1, PS2, and Saturn will refuse to boot or fall back to low-compatibility HLE without one. BIOS files live in RetroArch's system directory. Cores live in a writable libretro_directory, and their metadata "info" files live in libretro_info_path. On a stock install these are set for you, but if you moved your install or you are on Linux, confirm them. A sane layout:

~/.config/retroarch/
├── retroarch.cfg              # main config
├── cores/                     # libretro_directory  (the .dll/.so/.dylib cores)
├── info/                      # libretro_info_path  (the .info metadata files)
├── system/                    # BIOS files (scph5501.bin, saturn_bios.bin, ...)
├── config/                    # per-core and per-game override .cfg / .opt files
│   └── remaps/                # per-core input remaps (.rmp)
├── saves/                     # .srm battery saves
└── states/                    # save states

Note the split between cores/ and info/. It matters more than it looks, and it is the subject of the very next step.

Install and Update Cores in 12 Steps

Here is the whole procedure, start to finish, with the reasoning for each step. Follow the order — it is not decorative. Step 3 in particular prevents the most common failure in the entire program.

The twelve-step procedure

1. Confirm your RetroArch version. Main Menu → Information → System Information. You want 1.22.x, or at minimum 1.21.0. Rationale: cores built on the current buildbot occasionally use libretro API features a years-old frontend lacks, and the mismatch produces vague "failed to load" errors that look like a broken core but are a stale RetroArch.
2. Verify your directories. Settings → Directory. Confirm Cores and Core Info point somewhere writable. Rationale: on portable or store-installed builds these sometimes land read-only, and the downloader will appear to work while silently saving nothing.
3. Update Core Info Files FIRST. Online Updater → Update Core Info Files, before downloading any core. Rationale: the info files are the manifest that tells RetroArch which core handles which system, what BIOS it needs, and what its display name is. Download a core without a matching info file and it either fails to load or shows as an unrecognized binary. This is the single most common self-inflicted wound in RetroArch, and it is a ten-second fix done in the right order.
4. Update the databases. Online Updater → Update Databases. Rationale: this refreshes the ROM-scanning fingerprints so the playlist scanner recognizes your games and auto-assigns the right core.
5. Open the Core Downloader. Online Updater → Core Downloader (the cores page calls this "Update Cores"). If you do not see it, it is hidden: Settings → User Interface → Menu Item Visibility → Show Core Downloader. Rationale: the downloader pulls only builds compiled for your exact platform and CPU architecture, which is why it is the correct source rather than random binaries off the web.
6. Download only the cores you will use. Resist "install all." Pick per system using the matrix below. Rationale: every installed core is another thing to update and another info-file dependency; a lean core folder is a fast, debuggable one.
7. Watch for architecture mismatches. If an expected core is missing, it is almost always because no build exists for your platform (LRPS2 on ARM), not because you erred. Rationale: knowing "not built for me" from "I broke it" saves hours of pointless reinstalling.
8. Load content to verify. Load Content → pick a ROM → accept the suggested core, or Load Core first then Load Content. Rationale: a core that downloads cleanly can still fail on first boot for BIOS or permission reasons, and you want to catch that now, not mid-session.
9. Open Core Options and set them. In-game: Quick Menu → Core Options. Rationale: defaults are conservative. Internal resolution, renderer, and hack toggles all live here, and the good values for your hardware are almost never the defaults.
10. Save an override so settings stick. Quick Menu → Overrides → Save Core Overrides (or Save Game Overrides). Rationale: without an override, tweaks either vanish or leak into every other core. Use the hierarchy — game beats directory beats core beats global — deliberately.
11. Update installed cores periodically. Online Updater → Update Installed Cores refreshes everything in one pass. Rationale: the buildbot rebuilds cores constantly (a 24 May 2026 buildbot change even replaced core files for older installs), and compatibility fixes reach you only if you pull them.
12. Back up your config. Copy retroarch.cfg and the config/ tree somewhere safe. Rationale: your overrides and remaps are real hours of tuning, and a botched update or wiped SD card should cost you minutes to restore, not a weekend.

Expected output

When Step 5 works, the Core Downloader shows a scrolling list keyed by system, and selecting one triggers a brief download-and-extract. A successful core load (Step 8) writes a log tail like this:

[INFO] [Core]: Using core: Beetle PSX HW
[INFO] [Core]: Loading dynamic library: cores/mednafen_psx_hw_libretro.so
[INFO] [Content]: Loading content: Ridge Racer (USA).chd
[INFO] [Core]: Version of libretro API: 1
[INFO] [Environ]: SYSTEM_DIRECTORY: system/
[INFO] [Video]: Set up viewport: 1920 x 1080

If instead you see [ERROR] Failed to open libretro core or the content bounces straight back to the menu, jump to the troubleshooting table — nine times out of ten it is the info files from Step 3.

The Right Core for Each System

This is the part worth bookmarking. For every major system there is a default worth running and, usually, a lighter fallback for weaker hardware. These picks reflect the state of the cores in 2026, including the ones that regressed.

Nintendo

For the NES, Mesen is the accuracy pick — PPU-accurate, full mapper coverage, a built-in debugger — with Nestopia UE and FCEUmm as lighter, entirely respectable alternatives. SNES: Snes9x is the practical default everywhere, Snes9x 2010 the featherweight fallback for old ARM chips, and bsnes Accuracy the choice if you have the ~4GHz to spend. Game Boy and Game Boy Color go to Gambatte or SameBoy; Game Boy Advance to mGBA. Nintendo DS is melonDS; Nintendo 3DS is Azahar, the post-Citra core discussed above.

The N64 deserves its own paragraph because it is the 2026 trap. The mainline core, Mupen64Plus-Next, is normally the recommended default, but it regressed in early 2025 — certain titles (Stunt Racer 64, World Driver Championship) stopped loading, and the community workaround was to pin an older January build. If a game refuses to boot under Mupen64Plus-Next, switch to ParaLLEl N64, whose Vulkan low-level renderer is more accurate even if its overall compatibility list is narrower. And if you would rather sidestep software emulation entirely, dedicated N64 hardware like the Analogue 3D is the FPGA answer to the same problem.

Sega

Genesis Plus GX is the Sega workhorse: 100% compatible across Genesis/Mega Drive, Sega CD, Master System, Game Gear, and SG-1000. Note the one gap — it does not do the 32X. For 32X (and as an alternative Genesis core, particularly on Android and weak ARM) use PicoDrive. The Sega Saturn belongs to Beetle Saturn — accurate, demanding, BIOS required. The Dreamcast is Flycast, mature and comfortable on any modern desktop and the stronger handhelds.

Sony and arcade

PlayStation 1 has three good cores for three situations: Beetle PSX HW is the most accurate, with a hardware renderer, and is the desktop pick; SwanStation (a DuckStation-derived port) is a strong all-rounder; and PCSX ReARMed is the lightweight ARM core powering most budget handhelds and firmware like muOS and ROCKNIX. PlayStation 2 is LRPS2, x86_64-only, BIOS required. PSP is PPSSPP. Arcade is FinalBurn Neo (coverage stretching back to 1970s boards) or MAME when you need a specific driver FBNeo lacks. The full matrix:

On ARM handhelds the whole calculus shifts toward the lighter column — see how the picks change across devices in our 2026 Retroid Pocket comparison.

Core Options, Overrides, and the Config Hierarchy

RetroArch's config system is powerful and completely unforgiving of vagueness. Understand the hierarchy and you can tune per game; misunderstand it and your settings smear across cores or vanish on restart.

Four layers, most specific wins

Settings resolve in this order, most specific first: game > content directory > core > global. A global setting is the baseline in retroarch.cfg. A core override applies to every game run under that core. A content-directory override covers everything in a folder. A game override applies to one ROM. When two layers disagree, the more specific wins. The files live under config/<core>/:

config/mednafen_psx_hw/mednafen_psx_hw.cfg      # core override (all PS1 games)
config/mednafen_psx_hw/Ridge Racer (USA).cfg    # game override (one game)
config/remaps/mednafen_psx_hw/Ridge Racer (USA).rmp   # per-game input remap

Core options are a separate file

Do not confuse RetroArch settings (video, audio, input) with core options (renderer, internal resolution, region — things only the core understands). Global core options live in retroarch-core-options.cfg; per-game core options live in config/<core>/<game>.opt. Here is a real Beetle PSX HW block, upscaling to 4x internal resolution with the PGXP geometry fixes on:

# retroarch-core-options.cfg  (Beetle PSX HW section)
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"

Those keys are the core's actual option identifiers — renderer, internal_resolution (1x through 16x), pgxp_mode, dither_mode, and widescreen_hack. You will not memorize them; you set them from the Core Options menu and RetroArch writes the file for you. Knowing the file exists is what lets you copy a tuned profile between machines.

Making overrides actually save

Four global keys decide whether any of this persists. Set them once in retroarch.cfg:

config_save_on_exit = "true"
game_specific_options = "true"
auto_overrides_enable = "true"
auto_remaps_enable = "true"

With config_save_on_exit off, RetroArch discards your global changes on quit — deliberately, so you can experiment without consequence, but maddening if you did not expect it. With auto_overrides_enable and auto_remaps_enable on, saved per-core and per-game overrides load automatically at content start. The canonical reference is the libretro overrides guide; read it once and the whole system stops feeling like guesswork.

Five Pitfalls That Will Waste Your Evening

Every one of these is common, avoidable, and has cost someone a night of confused forum posting.

Info files, arch mismatches, and accuracy greed

1. Downloading a core but not its info file. The classic. You grab a core, it "fails to load" or shows as an unknown binary, and you assume the core is broken. It is not — you skipped Update Core Info Files. The info file is the manifest; without it the core is an orphan. Fix: Online Updater → Update Core Info Files, then reload. This is Step 3 for a reason.
2. Blaming the software for an architecture wall. A core missing from your downloader is usually not built for your platform. LRPS2 will never appear on an ARM handheld; some cores have no macOS build. Fix: confirm a build exists for your platform before hunting for a phantom binary.
3. Running an accuracy core on hardware that can't feed it. bsnes Accuracy on a handheld, Beetle Saturn on a Pi — technically installable, practically a slideshow. Fix: use the lighter column of the matrix. Snes9x, PCSX ReARMed, and PicoDrive exist precisely for this.

The N64 and PS2 traps specifically

4. Fighting the N64 regression instead of switching cores. If a specific N64 game will not load under Mupen64Plus-Next, you are likely hitting the early-2025 regression, not a bad ROM. Fix: switch that game to ParaLLEl N64 via a game override, or pin the older Mupen build. Do not re-dump the ROM ten times.
5. Expecting arcade to "just work." FinalBurn Neo and MAME are version-locked to their romset. A romset matching core version 1.0 throws checksum errors on a newer core, and vice versa. Fix: match the romset to your exact installed core version, and update them together.

The config-clobbering trap

A sixth, thrown in free because it bites everyone eventually: letting the global config eat your per-game work. Tune a game, then change a global setting with config_save_on_exit on and no override saved, and the global write can bury your intent. Fix: save a game or core override the instant you are happy with a tune, and let the hierarchy protect it. Overrides are not optional polish; they are how you keep RetroArch from overwriting itself.

Troubleshooting Table

These symptoms cover the overwhelming majority of core problems. Work top to bottom; the common causes are near the top.

Symptom, cause, fix

When the log is your only friend

If none of the above fits, raise the logging level: Settings → Logging → Frontend Logging Level → Debug, reproduce the failure, and read the tail of the log. RetroArch is unusually honest in its logs — the exact missing file, the exact failed dlopen, the exact BIOS hash it wanted are all printed in plain text. Ninety percent of "unsolvable" core problems solve themselves the moment you read the log instead of guessing.

Advanced Tips

Once the basics work, these are the techniques that separate a working setup from a good one.

Run-Ahead to erase input latency

Run-Ahead is RetroArch's best-kept feature: it internally runs the core one or more frames into the future and discards the intermediate frames, hiding the input lag that the original hardware — and every emulator — carries. Settings → Latency → Run-Ahead to Reduce Latency; start at one frame. The catch is cost: the core is effectively running two-plus times per displayed frame, so it needs fast save-state support and spare CPU headroom. It is transformative on 2D cores on a strong host and a non-starter on a struggling handheld. Use it where you have the budget; a well-tuned Miyoo Mini Plus can manage a frame of run-ahead on 8-bit systems but not much beyond.

Manual and ARM-handheld core installs

The Core Downloader is not the only source. Every core the buildbot compiles is browsable and downloadable directly from buildbot.libretro.com/nightly, which is how you grab a build for a platform whose in-app downloader is limited, or roll back to a specific nightly. For ARM handhelds and single-board Linux devices, the community christianhaitian/retroarch-cores repository publishes prebuilt arm64 and armhf cores (last refreshed 2 June 2025) that cover the gaps in the official ARM buildbot. To sideload one, drop the .so into cores/ and the matching .info into info/:

# Sideload a manually downloaded core onto a Linux handheld
cp picodrive_libretro.so   ~/.config/retroarch/cores/
cp picodrive_libretro.info ~/.config/retroarch/info/
# then: Load Core → pick it from the list

The .so/.info pairing is the same info-file dependency from Step 3, done by hand. Forget the .info and the core is an orphan again.

Multiple variants and building your own

The App Store deliberately keeps generation-specific variants of the same family — Stella 2014, Stella 2023, and the current Stella all coexist — so a device that chokes on the current build can fall back to an older, lighter one for the same system. When you want a variant no buildbot ships, or you want to build against a patch, the libretro-super repo and its update-cores.sh workflow are the supported way to fetch, build, and package cores yourself. That is deeper than most users ever go — but it is why the ecosystem can claim 200+ cores and keep the number climbing: the build pipeline is public, scripted, and still being committed to in 2026.

A Complete Working Configuration

Here is a coherent, copy-ready configuration that ties the guide together: the core-relevant block of retroarch.cfg, and one worked per-game override. Adjust paths to your platform.

The retroarch.cfg core block

# ---- retroarch.cfg : core + directory + override settings ----

# Where cores and their info manifests live (keep them separate + writable)
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/info"
system_directory   = "~/.config/retroarch/system"

# Buildbot the Core Downloader pulls from (default; change only to pin nightlies)
core_updater_buildbot_cores_url = "http://buildbot.libretro.com/nightly"
core_updater_auto_extract_archive = "true"

# Make tuning persist and load automatically
config_save_on_exit   = "true"
game_specific_options = "true"
auto_overrides_enable = "true"
auto_remaps_enable    = "true"

# Sensible default video driver for 3D cores (N64/PS1/Saturn/DC)
video_driver = "vulkan"

A per-game override

Say Ridge Racer looks soft at default resolution. You upscale it, save a game override, and RetroArch writes two tiny files that touch nothing else in your setup:

# config/mednafen_psx_hw/Ridge Racer (USA).cfg
video_smooth = "false"

# config/mednafen_psx_hw/Ridge Racer (USA).opt   (core options, this game only)
beetle_psx_hw_renderer = "hardware_vk"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_pgxp_mode = "memory only"

Verifying it all works

Load that game and open Quick Menu → Information; the active core and the applied overrides are listed there. Cross-check against the official download-cores guide and the per-core pages under docs.libretro.com if a specific option key differs on your build — core options do occasionally get renamed between versions, which is exactly why you keep the frontend and the cores updated together. Get this far and you have done the thing most RetroArch users never do: understood that the frontend and the cores are two different programs, and configured each on purpose. The 200-plus number on the cores page stops being intimidating trivia and becomes what it actually is — a menu.