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

Install RetroArch, launch it, open the menu, and go looking for a system to play. You will find nothing bootable. The shaders are there. The netplay stack is there. The rewind buffer, the achievement client, the shader chains nobody asked for, all present and correct. What is missing is the one thing you actually came for: an emulator. RetroArch does not emulate anything. It is a frontend, and the emulators that turn a ROM into a running game are shipped separately as modules called cores. Everything below exists to solve a single problem: getting the right cores onto your machine, in the right order, without the handful of quiet mistakes that make the whole thing fail without ever showing an error message.

As of 2026 the current stable build is RetroArch 1.22.2, and the project advertises well over 200 cores spanning emulators, game engines, and media players. You will not install 200. Nobody installs 200. You will install somewhere between six and twelve, spend ten minutes arguing with yourself about which Nintendo 64 core to trust, and then discover that the PlayStation 2 core flatly refuses to exist on your handheld. What follows is the entire process: prerequisites with real version numbers, twelve numbered steps, the correct core for each system as of this year, the configuration hierarchy that actually governs behaviour, and the specific, repeatable ways people brick their own setups. Budget thirty minutes the first time and about five minutes every time after.

What a RetroArch Core Actually Is

The libretro API, in one paragraph

libretro is an API. A core is a shared library, a .dll on Windows, a .so on Linux and Android, a .dylib on macOS, that implements that API. RetroArch is a frontend that loads those libraries and hands each one a ROM, a video buffer, an audio buffer, and your controller input. That is the entire arrangement. The core does the emulating; the frontend does the plumbing. Because the boundary is a clean API rather than a pile of glue code, the same Snes9x core runs unchanged under RetroArch on your desktop, under RetroPie's launcher on a Raspberry Pi, and under Lakka on a repurposed thin client. RetroArch itself is free and open-source under the GPLv3 licence, written in C, and maintained by the Libretro team; you can read the source and the tagged release history on the official RetroArch GitHub repository, where v1.21.0 sits tagged as of 1 May 2025, a useful anchor for the project's release cadence into the current 1.22 line.

The 200-core number is a catalogue, not your install

The official RetroArch site frames cores as the primary way the program expands system support, and quotes over 200 of them. That figure is a catalogue count across every platform the buildbot targets. It is not the number you will see in your own Core Downloader, and it is certainly not the number you should install. The downloader only ever lists cores that have been built for your specific operating system and CPU architecture. A 64-bit Windows machine sees the x86_64 Windows builds; an Android tablet sees the aarch64 Android builds; a 32-bit ARM handheld sees armv7, and a good deal fewer of them. The 200-plus headline and the shorter list in front of you are both true at once. They are simply answering different questions. Not every core is even an emulator, either: some are game engines like the Doom-derived and Cave Story ports, and some are media players, which is how the same 200 figure spans emulators, engines, and playback in one count.

Why the frontend ships almost empty

Shipping RetroArch without its emulators looks perverse until you consider the alternatives. Cores carry different licences, different sizes, and different platform builds; a monolithic bundle would be enormous, would drag the whole thing down to the licensing terms of its most restrictive component, and would force a full reinstall every time one emulator fixed one bug. Keeping cores separate lets each one version independently and update on its own schedule through the buildbot. It also keeps RetroArch on the correct side of a line that has mattered since the Bleem and Connectix cases of the late 1990s established that an emulator is legal but the copyrighted BIOS and ROMs it runs are not the emulator author's problem to distribute. RetroArch ships the shell. You supply the contents. This is the design, not an oversight, and it is the reason the first thing this tutorial does is send you to a downloader rather than a settings screen.

Prerequisites: Versions, Hardware, BIOS

The software versions that matter

Start on RetroArch 1.22.2. The official download page lists it as the current stable release for 2026, and it is the build the buildbot targets when it compiles cores. This matters more than it sounds: cores are compiled against a specific frontend ABI, and a core built for the 1.22 line can refuse to load, or load and misbehave, on an older frontend. Avoid 1.22.0 specifically, because it shipped with a shader black-screen bug that the 1.22.1 and 1.22.2 point releases fixed. If you are coming from the 1.21.0 milestone of 29 April 2025, upgrade the frontend first and the cores second, in that order, every single time. The reverse order is the fastest way to end up with cores that will not initialise, and it accounts for a depressing share of the support threads on the topic.

A hardware reality check

Cores are not interchangeable in their appetite for silicon. The cycle-accurate bsnes core in its Accuracy profile wants roughly a 4 GHz single-thread CPU to hold full speed; Snes9x produces a near-identical picture at a fraction of the cost and is the only sane SNES choice on a handheld. The hardware-renderer PlayStation core, Beetle PSX HW, expects a real GPU and will crawl on integrated graphics the moment you push its internal resolution. The PlayStation 2 core is x86_64 only and does not exist for ARM at all. If your target is an Android device such as one of the current Retroid Pocket handhelds, or a budget Linux handheld like the Miyoo Mini Plus, you are living in the world of the light cores, PCSX ReARMed, Snes9x, Genesis Plus GX, gpSP, and no amount of wishing will put LRPS2 on a 1 GHz Cortex-A7. Match the core to the machine before you match it to the system, because the machine gets a veto and the system does not.

BIOS and system files, the part everyone skips

A large number of cores refuse to boot without the original console's BIOS or firmware, and RetroArch will not, cannot legally, provide it. Those files are copyrighted system software; you are expected to dump them from hardware you own, the same way you would dump your own cartridges with a Retrode. The PlayStation cores want the SCPH BIOS set; the PS2 core wants a PS2 BIOS; the DS core wants NDS firmware and BIOS; the Sega CD side of Genesis Plus GX wants its region BIOS. All of it goes in RetroArch's system directory, named exactly as the core expects, before the core will do anything other than throw a black screen at you. Get the version numbers, the hardware tier, and the BIOS folder squared away and everything after this is button-pressing.

Installing Cores in 12 Steps

Update the info files before anything else

The single most common failure in the entire process is skipping the info files. Every core has a matching .info manifest that tells RetroArch its name, the system it emulates, the file extensions it accepts, and which BIOS it needs. If your manifests are stale or missing, the Core Downloader shows up empty, freshly downloaded cores load as Unrecognized core, and content refuses to associate with anything. The Online Updater has a dedicated action for this, and it must run first. A buildbot change on 24 May 2026 replaced the old info files for installs predating that date, so anyone restoring an older configuration should treat a fresh info-file pull as mandatory rather than optional. The libretro download-cores guide documents the same ordering.

The twelve steps

1. Upgrade RetroArch to 1.22.2 first. Cores are built against the current frontend ABI; upgrading cores onto an old frontend is the reverse of the correct order and produces load failures. Do the frontend, then the cores, without exception.
2. Open the Online Updater. From the main menu it is the entry containing every network action: core downloads, info files, assets, databases. If it is missing you are on an offline or locked-down build; enable it under Settings, User Interface, Menu Item Visibility.
3. Run Update Core Info Files before touching a single core. This pulls the manifests. Skipping it is the root cause of the empty-downloader and unrecognised-core symptoms above. This is the step people skip and then file bug reports about.
4. Run Update Assets and Update Databases. Assets are the menu icons and fonts; databases power playlist scanning and thumbnail matching. Neither is strictly required to run a game, but skipping them gives you a menu full of missing-image placeholders and a scanner that matches nothing.
5. Open the Core Downloader. This is the filtered list of cores built for your exact platform and architecture. If it is hidden, Settings, User Interface, Menu Item Visibility, Show Core Downloader turns it back on.
6. Pick cores by system, not by fond memory of a name. The list is alphabetical by core, not by console. Decide the system you want first, say PlayStation, and download the core this tutorial names for it, rather than the first familiar word you happen to recognise.
7. Download the core. RetroArch fetches the compressed build from the buildbot and, with auto-extract enabled, unpacks it into your cores directory. A few seconds each on a normal connection, and the entry moves from the download list to your installed list.
8. Load the core on its own. Main Menu, Load Core, and select what you just fetched. This confirms the library initialises before you complicate matters with content. A core that fails here has an ABI or dependency problem, not a ROM problem, and that distinction saves you an hour of blaming the wrong thing.
9. Load content and boot a game. Load Content, point it at a ROM the core supports, and confirm it runs. This is the first moment you know the core, its info file, and any required BIOS are all agreeing with each other.
10. Set a default core for the content's directory. Once a game runs, use the Quick Menu to associate that core with the folder or the playlist, so a future launch goes straight in without asking you to choose a core each time.
11. Run Update Installed Cores as your maintenance pass. This single action re-fetches the latest build of everything you have installed in one sweep, far faster than reinstalling cores one at a time after an upgrade.
12. Verify the build under Information, Core Information. This screen shows the exact core name, the system, supported extensions, and required firmware. When something misbehaves, this is the screen that tells you whether the core you think you loaded is the core that actually loaded.

Expected output

After step 12, the Core Information screen for a PlayStation core reads roughly like the block below. The firmware list is your fastest confirmation that a BIOS is required and whether RetroArch can actually see it; a MISSING line here is the black screen you are about to get, diagnosed before it happens:

Information > Core Information
----------------------------------------
Core name            : Beetle PSX HW
System manufacturer  : Sony
System name          : PlayStation
Supported extensions : cue|toc|m3u|ccd|exe|pbp|chd
Required firmware    : scph5500.bin   [present]
                       scph5501.bin   [present]
                       scph5502.bin   [MISSING]

The Right Core for Each System

Nintendo: NES, SNES, Game Boy, DS

For the NES, Mesen is the answer and has been for years: it is PPU-accurate, handles the awkward mappers that trip lesser cores, and ships a genuine debugger for the homebrew crowd. On the SNES the honest recommendation splits by hardware. bsnes in its Accuracy profile is cycle-accurate and correspondingly hungry, so plan for that 4 GHz core, while Snes9x gives you a picture almost nobody can distinguish in normal play at a fraction of the cost, which is exactly why it is the default on every handheld. Game Boy and Game Boy Color are best served by Gambatte for precision, or mGBA if you would rather run one core for the entire Game Boy family through to Game Boy Advance. For the DS, melonDS has pulled decisively ahead of DeSmuME on both accuracy and speed. The 3DS is its own saga, and it gets its own section below.

Sony and Sega: PS1, Genesis, and the light-core rule

PlayStation is the system where the choice genuinely matters. Beetle PSX HW, the Mednafen-derived core with a hardware renderer, is the most accurate option and the best picture on a desktop, at the cost of being heavy; SwanStation, a libretro port of the DuckStation lineage, is the balanced middle; and PCSX ReARMed is the light, ARM-optimised core that powers the budget handheld world of muOS, OnionOS and ROCKNIX. That last one is the same core doing the work behind the PS1 ceiling on devices like the Miyoo Mini Plus, and it is the reason a sub-100-dollar handheld plays PlayStation at all. For Sega, Genesis Plus GX covers Mega Drive, Sega CD, Master System, Game Gear, SG-1000 and Pico at full accuracy, the whole 8- and 16-bit Sega stack in one core, with one exception: it does not do 32X. For 32X you switch to PicoDrive, which is also the more sensible Genesis pick on low-end Android. The Genesis Plus GX documentation lists exactly which systems the core claims, so you are not guessing.

Arcade and the accuracy tax

Arcade is a library question, not an accuracy question. FinalBurn Neo is the curated, lighter option with coverage reaching back to the 1970s and is the right default; MAME is the maximalist alternative that documents everything at a correspondingly higher cost and stricter ROM-set demands. Across every system there is a general law worth internalising: accuracy is a tax you pay in CPU cycles. The cycle-accurate cores, bsnes and Mesen and Beetle, reproduce the original hardware's edge cases and quirks precisely and ask for the hardware budget to do it. The performance cores, Snes9x and PCSX ReARMed and PicoDrive, get you ninety-five percent of the picture for a fraction of the cost. On a desktop, take the accuracy. On a handheld, take the frame rate. The table below is the short version; if you want provably exact hardware behaviour rather than a very good software approximation, that is a different product entirely, which is what the FPGA-based MiSTer project exists to sell.

N64, PS2 and 3DS Problem Children

N64: Mupen64Plus-Next and the 2025 regression

The Nintendo 64 core situation is the one that catches people out, so treat it as a special case rather than a table row. Mupen64Plus-Next is the mainline recommendation and bundles the plugin ecosystem that made N64 emulation viable in the first place: GLideN64 for high-level graphics, angrylion for reference-accurate software rendering, and the ParaLLEl-RDP and RSP plugins for low-level accuracy. The libretro mupen64plus documentation still names it the recommended default, and for most of the library it is correct. The catch: early 2025 builds regressed, and a handful of titles, Stunt Racer 64 and World Driver Championship among them, stopped loading outright. The community workaround was to pin a January build until the regression cleared. If a specific N64 game refuses to launch on the current core, that is your first suspect, and the accuracy-focused ParaLLEl N64 core, a Vulkan low-level-emulation renderer with narrower compatibility but excellent precision where it works, is the fallback worth trying before you conclude the ROM itself is bad.

PS2: LRPS2 exists, but not on your ARM device

PlayStation 2 emulation inside RetroArch is real as of the 1.22 line, but it arrives with a hard constraint that no configuration change can lift. LRPS2 is a hard fork of PCSX2, it landed in the downloader alongside the November 2025 release wave, and it introduced a new ParaLLEl-GS renderer written by Themaister. It is also x86_64 only, meaning Windows, Linux, and macOS under Rosetta, with no Android, no iOS, and no ARM Linux build whatsoever. The LRPS2 documentation spells out the platform limits. It needs a real PS2 BIOS in your system folder, and the GameIndex database that PCSX2 relies on for per-game fixes is now embedded in the core rather than shipped loose. If you were hoping to run PS2 on a handheld, the answer in 2026 is still no; the core does not exist for that hardware, and the reason is architectural, not a matter of someone getting around to compiling it.

3DS: Citra is dead, Azahar took over

The Citra 3DS emulator was taken down, and the libretro core that depended on it went with it. Its replacement is Azahar, a merge of the most active surviving Citra forks, the PabloMK7 line and Lime3DS among them, and it is now the maintained path for 3DS emulation. Azahar became an official libretro core with the 2125.0 release, initially across six operating systems including Linux x86_64, with the finished build slated for the Core Downloader on desktop and as a built-in core on iOS and tvOS. By mid-2026 the line had advanced to a 2126.0 release candidate. If you are following an older tutorial that tells you to download a Citra core, stop; it is gone, and Azahar is the name you are looking for now. This is emulation's normal churn, projects get taken down, forks consolidate, the downloader quietly renames the entry, and it is exactly why the info-file update in step 3 is not optional.

Core Options and Override Hierarchy

Core options and settings are two different things

RetroArch keeps two separate sets of knobs and people conflate them constantly. Settings are RetroArch's own, the video driver, audio latency, input binds, and they live in retroarch.cfg. Core options belong to the core, the internal resolution, the renderer, the per-console quirk toggles, and they live in retroarch-core-options.cfg globally or in a per-game .opt file when you save them for one title. The Quick Menu exposes both while a game runs, under Options for the core's own settings and Overrides for the frontend's. Changing a core option affects how the emulator behaves; changing a setting affects how RetroArch wraps it. When advice online tells you to change something and it has no effect, the usual reason is that you changed the wrong one of these two, in the wrong file.

The override hierarchy: game beats directory beats core beats global

Overrides resolve in a strict order of specificity, and the more specific file always wins. From weakest to strongest: the global retroarch.cfg; then a core override at config/<core>/<core>.cfg that applies to everything that core loads; then a content-directory override at config/<core>/<dir>.cfg; then, strongest of all, a per-game override at config/<core>/<game>.cfg. Input remaps follow their own parallel track under config/remaps/<core>/. The behaviour is switched on by a small set of keys, config_save_on_exit, auto_overrides_enable, auto_remaps_enable, and game_specific_options, and the libretro overrides guide is the reference to keep open the first time you set this up. The practical upshot: you can widescreen-hack one game without touching the other nine hundred, provided you save the override at the game level and not the core level.

A worked example: Beetle PSX HW upscaling

Say you want one PlayStation game rendered at four times internal resolution with the hardware Vulkan renderer, but only that game. You load it, open the core Options, set the relevant keys, and save a game-specific options file. The result is a .opt file scoped to that single title, using the core's real option keys:

# config/Beetle PSX HW/Final Fantasy VII.opt
# Per-game core options: this title only
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"

And if you wanted a core-wide visual override instead, say disabling bilinear smoothing for every PlayStation game at once rather than per title, that goes one level up, in the core override file, where it applies to everything Beetle PSX HW touches:

# config/Beetle PSX HW/Beetle PSX HW.cfg
# Core-level override: applies to every game this core loads
video_smooth = "false"
aspect_ratio_index = "22"
video_shader_enable = "true"

Note the direction of specificity: the per-game .opt beats the core-wide .cfg, so a game with its own saved options ignores the broader rule. That is the whole system in one sentence, save narrow to override broad, and the reason a change you made globally sometimes appears to do nothing on one particular game.

Five Pitfalls That Break Installs

Empty menus and unrecognised cores

Pitfall 1: skipping the info files. This is the big one and it is worth stating twice. If the Core Downloader is empty, or a freshly downloaded core loads as Unrecognized core, you did not run Update Core Info Files first. The fix is to run it, then Update Installed Cores, then reload. Pitfall 2: expecting a core the buildbot never built for you. If a system you want has no entry in your Core Downloader, the core almost certainly does not exist for your platform and architecture, LRPS2 on ARM being the canonical example. The fix is not to hunt for a mirror; it is to accept the architecture limit and pick a core that exists, or change hardware.

Wrong core, wrong architecture, wrong BIOS

Pitfall 3: the missing-BIOS black screen. A core that loads but shows only a black screen when you boot content is, nine times in ten, missing its BIOS or firmware. The fix is to place the correctly named system files in RetroArch's system directory and confirm the requirement under Information, Core Information. Pitfall 4: the architecture mismatch on manual installs. If you sideloaded a core file by hand, copying a .dll or .so into the cores folder instead of using the downloader, and it will not load, you very likely grabbed the wrong architecture build. The fix is to delete it and fetch through the Core Downloader, which only ever offers builds that match your frontend. Manual installation is a legitimate technique, but it removes the guardrail that stops this exact mistake.

Overrides that fight each other

Pitfall 5: the override that will not stick. You change a setting, exit, come back, and it has reverted. The usual cause is that config_save_on_exit is off, or you saved the change at the wrong level of the hierarchy and a more specific file overrides it every launch. The fix is to decide deliberately whether a change belongs at the game, directory, or core level, save it there explicitly through the Overrides menu, and confirm auto_overrides_enable is on. Pitfall 6: upgrading the frontend and forgetting the cores. After a RetroArch version jump, old cores built against the previous ABI can start failing to load. The fix is the one-line maintenance habit: after every frontend upgrade, run Update Installed Cores before you conclude anything is broken. Most post-upgrade breakage is nothing more than cores lagging a version behind the shell.

Troubleshooting Table

Loading and download failures

The failures that stop a core from loading at all are almost always about the info files, the architecture, or a missing dependency, and they resolve in that order of likelihood. Work the top of the table first and do not reinstall RetroArch until you have exhausted it.

Performance and rendering

Slowdown and visual glitches are usually a core option, the renderer, the internal resolution, the accuracy profile, rather than a broken core. The fix lives in the Options menu far more often than in a reinstall, and switching the renderer costs nothing to try.

Saves, BIOS, and content

Saves that vanish and content that will not launch trace back to directory permissions, a missing BIOS, or a core-to-content association that was never set. The table below covers the twelve most common reports and the first thing to check for each.

Advanced: Buildbot and Platform Cores

Nightly cores from the buildbot

The stable Core Downloader tracks releases, but the cores themselves are rebuilt continuously on the libretro buildbot, which serves nightly builds for every supported platform. When a core has a fix that has not yet reached a stable tag, the N64 regression being a live example, the nightly is where the fix lands first. You can point RetroArch's updater at the nightly channel through the core_updater_buildbot_url key, or download an individual core's build directly from the buildbot's web listing and drop it into your cores directory. The tradeoff is the usual one: nightlies get fixes earlier and bugs earlier in equal measure. For a machine you rely on, stay on stable and only reach for a nightly to chase a specific, named fix.

Per-platform packs and built-in cores

Some platforms live outside the main buildbot flow entirely. The webOS build of RetroArch, for televisions, is served by the community webosbrew/retroarch-cores project, which rebuilt its set in December 2025 to more than 170 armv7 cores plus an experimental aarch64 batch. ARM handheld distributions, the ones behind muOS, OnionOS and ROCKNIX, pull from prebuilt arm64 and armhf core sets maintained specifically for that hardware. And on Apple's locked-down platforms, some cores ship built into the RetroArch binary itself, because the App Store model forbids downloading executable code at runtime: Azahar, for one, is slated as a built-in core on iOS and tvOS rather than a downloader entry. The lesson is that the Core Downloader is not the only distribution channel, and on non-desktop platforms it is often not even the primary one.

Keeping cores in sync after an upgrade

The maintenance discipline is short. Upgrade the frontend through your platform's package manager, then update the cores from inside RetroArch. The two halves are separate and both must happen:

# Windows (winget)
winget upgrade Libretro.RetroArch

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

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

After any of those, launch RetroArch and run Online Updater, Update Installed Cores, so the cores catch up to the frontend you just moved. Do the frontend in the shell, do the cores in the menu, in that order. Reverse it and you are back to cores that will not load, the single most common self-inflicted wound in this entire exercise, and the one this tutorial has now warned about four separate times because it accounts for most of the support threads on the subject.

A Complete Working Configuration

The directory layout

Here is the whole thing assembled. A correct RetroArch install keeps its cores, its info manifests, its BIOS files, and its overrides in separate, writable directories, so an upgrade never clobbers your saves and a core update never touches your config. The layout below is what a working setup looks like on disk:

~/.config/retroarch/
|-- cores/          # the .so / .dll / .dylib core files
|-- info/           # the .info manifests (update these FIRST)
|-- system/         # BIOS and firmware live here
|-- config/         # per-core and per-game overrides
|   \-- Beetle PSX HW/
|       |-- Beetle PSX HW.cfg      # core-level override
|       \-- Final Fantasy VII.opt  # per-game core options
\-- retroarch.cfg   # the global settings file

The retroarch.cfg core section

These are the config keys that govern core installation and override behaviour specifically, the ones worth setting deliberately rather than leaving to chance. Everything here maps to a menu toggle, but committing them to the file means a fresh install or a restored backup behaves identically without a single click-through:

# --- Core and info directories (must be writable) ---
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/info"
system_directory = "~/.config/retroarch/system"

# --- Core Downloader / buildbot ---
core_updater_buildbot_url = "http://buildbot.libretro.com/nightly"
core_updater_auto_extract_archive = "true"
core_updater_show_experimental_cores = "false"

# --- Override and per-game option behaviour ---
config_save_on_exit = "true"
auto_overrides_enable = "true"
auto_remaps_enable = "true"
game_specific_options = "true"

The two directory keys are the important pair: keep libretro_directory and libretro_info_path pointed at writable locations, because a read-only cores or info directory is exactly how you end up unable to update anything and unsure why. The Debian community documentation for RetroArch is worth a look if you are packaging this on Linux, since it separates those two paths explicitly for that reason.

The maintenance routine

The routine that keeps this working indefinitely is four actions, in order, run whenever you update. One: upgrade the frontend in the shell. Two: open Online Updater and run Update Core Info Files. Three: run Update Installed Cores. Four: launch one game per system you care about to confirm nothing regressed. That is the entire lifecycle. Cores are not a one-time install; the RetroArch project treats the ecosystem as continuously expanding, over 200 cores and counting, with new platform-specific efforts like the LRPS2 PlayStation 2 core and the Azahar 3DS core arriving through 2025 and 2026, and the buildbot pushes changes constantly underneath you. Thirty minutes to set up, five minutes to maintain, and the same four steps every time. The frontend was always the easy part. The cores are the whole point, and now they are handled.