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

RetroArch is not an emulator. It is a frontend, a shell that loads emulators as interchangeable plugins, and the plugins are called cores. Every argument you have ever had with RetroArch, the black screen, the missing system, the core that vanished after an update, traces back to that one sentence not landing. Once it lands, the software stops fighting you.

This is the long version of how cores work: how to install them without corrupting your setup, how to pick the one core per system that will not embarrass you, how the override hierarchy actually resolves, and what to do when the Core Downloader shows a blank list. It maps to our companion 12-step walkthrough but goes considerably deeper into the parts that break. Budget thirty minutes for the install and a lifetime for the opinions.

What a Libretro Core Actually Is

The official project is libretro/RetroArch on GitHub, and it describes itself with unusual honesty: a frontend that runs "libretro cores." Libretro is the ecosystem; RetroArch is one client for it. The distinction matters because it explains why the same Snes9x core runs identically inside RetroArch on Windows, inside a Batocera image on a Raspberry Pi, and inside a dozen other frontends nobody mentions at parties. You are not installing forty emulators. You are installing one host and forty guest brains.

The frontend/backend contract

libretro is an API, not a program. A core is a shared library that implements that API: it exposes a handful of C functions, retro_run, retro_load_game, retro_get_system_av_info and friends, and the frontend calls them once per frame. The frontend owns everything the emulator author would rather not rewrite, video output, audio, input mapping, rewind, netplay, shaders, save states. The core owns exactly one thing, pretending to be a Super Nintendo, and hands the frontend a framebuffer and a batch of audio sixty times a second. The API is versioned. You will see "libretro API version: 1" in the log, and a core compiled against an incompatible major version simply refuses to load. That refusal is a feature, not a fault; it is the version check saving you from a crash.

Cores versus standalone emulators

Most cores are ports of standalone emulators. Snes9x, Genesis Plus GX, mGBA, Flycast and PCSX2 all exist as their own applications. The libretro port wraps the emulator's core loop and throws away its native GUI, because RetroArch is now the GUI. You gain a unified interface, one save-state system, one shader pipeline, and one controller config across every system you own. You lose the standalone's bespoke menus and, occasionally, its newest features, because the port lags upstream by however many free weekends the maintainer has. This is the trade, stated plainly: if you want one emulator done to the last decimal, run it standalone; if you want forty systems behaving like a single machine, you want cores.

The "over 200 cores" catalogue

The official RetroArch Cores page advertises "over 200 cores" and says the list "keeps expanding over time." That number is real, and it is also a catalogue count, not a per-device count. No single install exposes all 200. The Core Downloader on a desktop shows 100-plus cores organized by system; a webOS TV build shows a leaner armv7 subset; a locked-down iOS build shows only what was signed into it. The 200 is the union of every platform. Treat it as a menu, not an inventory. A meaningful fraction of those cores are historical, experimental, or superseded, which is precisely why the middle third of this guide is about choosing rather than collecting.

The pure-software approach has one honest competitor, FPGA recreation, where the console is rebuilt in reprogrammable logic instead of emulated in code. If you have wandered the MiSTer FPGA scene, you already know the argument: hardware-level timing versus software's convenience and breadth. Cores win on breadth and price by a mile. They lose on input lag and a few edge-case accuracy corners by a whisker. For 95% of a library, the whisker does not matter, and the price gap is not close.

Prerequisites: Versions, Hardware, Disk

Before you download a single core, pin down three things: the RetroArch version, the machine's real horsepower, and where the files are going to live. Skipping any of the three is how people end up with a "corrupt" install that was never corrupt, just misconfigured.

Software versions

Install current stable, not whatever your distro shipped in 2022. As of this writing the stable release is RetroArch 1.22.2, published in November 2025. The prior reference point was 1.21.0, dated 29 April 2025 on both the official cores page and the GitHub releases tab, a clean anchor if you need to reason about what "current era" means. Cores from the buildbot are compiled against a recent RetroArch and generally tolerate a version or two of drift, but pairing a 2025 core with a 2019 frontend is asking the API-version check to reject it. Match the era, and the whole class of "why won't this core load" problems evaporates.

Platform matters more than most guides admit. Desktop Windows, macOS and Linux builds ship with the Core Downloader visible and functional. Android pulls cores from the same buildbot. iOS and tvOS are a special, code-signed circle of their own, covered later. And one Linux packaging choice, the Ubuntu PPA, actively removes the Core Downloader from the interface, which we will get to before it ruins your afternoon.

Hardware reality check

Cores are not equally hungry, and the catalogue does not warn you. Rules of thumb that hold in 2026:

• 8-bit and 16-bit (NES, SNES, Mega Drive, Game Boy) run on anything, including a potato. A 90-dollar Miyoo Mini Plus eats them without a fan.
• Cycle-accurate SNES via bsnes wants roughly a 4 GHz core to hold full speed. Snes9x does not, which is why Snes9x is the default recommendation and bsnes is the connoisseur's tax.
• Nintendo 64, Saturn, Dreamcast, PS1 want a real CPU and, for the hardware renderers, a real GPU. Mid-range ARM handhelds like a Retroid Pocket 5 or 6 handle them; a Raspberry Pi wheezes.
• PlayStation 2 via the LRPS2 core is x86_64 only. There is no ARM build. On a phone or an ARM handheld, PS2 through libretro is simply not on the menu, and the ParaLLEl-GS software renderer does not change that arithmetic.

Disk and directory layout

Cores are small, a few megabytes each, but the surrounding furniture is not optional. RetroArch keeps a fixed set of directories, and understanding them prevents most "where did my save go" incidents. A portable install looks like this:

RetroArch/
├── retroarch.cfg          # master configuration
├── cores/                 # *_libretro.so / .dll / .dylib live here
├── info/                  # *.info core metadata (download FIRST)
├── system/                # BIOS and firmware (scph*.bin, etc.)
├── config/                # per-core and per-game overrides
│   └── Snes9x/
│       ├── Snes9x.cfg     # a core override
│       └── Snes9x.opt     # core options
├── saves/                 # .srm battery saves
├── states/                # save states
└── playlists/             # scanned ROM lists

The two directories that decide whether the Core Downloader works are cores/ and info/. The core is the executable code; the .info file is its ID card, telling RetroArch the core's display name, the file extensions it accepts, and whether it needs a BIOS. Download the info files first. This is not a suggestion; it is step one for a reason, and half the troubleshooting table exists because people skip it.

The 12-Step Core Install

This is the canonical path: in-app installation through the Core Downloader, the method the Libretro download-cores guide documents and the one that keeps cores and info files in sync automatically. Every step has a reason attached, because "just click through" is how people miss the one toggle that matters.

Before you click: enable the downloader

On desktop the Core Downloader is usually visible already. On the platforms where it is hidden, the guide's instruction is explicit: turn on Show Core Downloader, then reach it through Online Updater → Core Downloader. If your build has no Online Updater at all, you are almost certainly on a package-managed install (see the PPA pitfall) and these steps do not apply, because your cores come from the OS package manager instead of the buildbot.

The twelve steps, with rationale

1. Install RetroArch 1.22.2 from the official source. Not a random mirror, not a three-year-old distro package. The buildbot cores assume a current frontend, and the API check punishes mismatches.
2. Launch it once and quit. The first run writes a default retroarch.cfg and creates the directory tree. You want that scaffolding to exist before you touch anything.
3. Settings → User Interface → Menu Item Visibility, and confirm Show Core Downloader is on. A hidden downloader is the single most common "RetroArch won't let me install cores" complaint, and it is a one-toggle fix.
4. Online Updater → Update Core Info Files. Do this before downloading any core. Info files populate the downloader with human names and let installed cores advertise which ROMs they accept. Skip this and the list reads like a directory of codenames.
5. Online Updater → Update Assets. Pulls the menu icons, fonts and thumbnails. Not a core, but a bare menu makes every later step harder to read.
6. Online Updater → Core Downloader. This is the actual store. It lists 100-plus cores organized by system, pulled live from the buildbot.
7. Download exactly one core per system you own, starting with the recommended default. Mesen for NES, Snes9x for SNES, and so on (the full table is two sections down). Resist grabbing five cores per console on day one; you will not benchmark them and they only confuse the picker.
8. Online Updater → Update Databases. These are the ROM-identification databases the scanner uses to build clean playlists. Without them the scanner cannot match your files to known titles.
9. Import Content → Scan Directory, and point it at your ROM folder. The scanner reads the databases, matches your files and builds per-system playlists. It does not move or rename anything.
10. Load a game and let RetroArch suggest the core. Because the info files are in place, it offers only cores that accept that file type. Pick your installed default.
11. Verify with the log. Settings → Logging → set the Frontend Logging Level to Info, then watch the core load. The expected lines are shown below; "Content ran for 1 frame(s)" on exit means the core actually executed.
12. Online Updater → Update Installed Cores whenever you remember. This re-pulls only what you already have, matched to your frontend version. It is the maintenance heartbeat; the underlying tooling, the update-cores.sh script in the RetroArch tree, was itself refreshed in May 2025, so the pipeline is alive and worth trusting.

Expected output

A healthy Core Downloader, after Update Core Info Files has run, shows named entries rather than filenames:

Online Updater
  Update Core Info Files
  Core Downloader
    Nintendo - NES / Famicom .......... Mesen
    Nintendo - SNES / Super Famicom ... Snes9x
    Nintendo - Nintendo 64 ............ Mupen64Plus-Next
    Nintendo - Game Boy / Color ....... Gambatte
    Nintendo - Game Boy Advance ....... mGBA
    Nintendo - DS ..................... melonDS
    Sega - Master System / Mega Drive . Genesis Plus GX
    Sega - Saturn ..................... Beetle Saturn
    Sega - Dreamcast / NAOMI .......... Flycast
    Sony - PlayStation ................ Beetle PSX HW

And a clean core load, with logging set to Info, looks like this:

[INFO] RetroArch 1.22.2
[INFO] [Core]: Loading dynamic libretro core from: "cores/snes9x_libretro.so"
[INFO] [Core]: libretro API version: 1, compiled against API: 1
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
[INFO] [Content]: Loading content file: "roms/snes/game.sfc"
[INFO] [Core]: Content ran for 1 frame(s).

If you see those lines, the core is installed correctly and the rest is content. If you see "Failed to load libretro core" instead, jump to the troubleshooting table; the log will already be telling you why.

Manual Installs and the Command Line

The Core Downloader is the easy path, not the only one. When it is missing, disabled, or you simply prefer files you can see, you install cores by hand, and once cores are on disk you can launch them straight from a terminal without touching the menu at all.

Placing cores by hand

A libretro core is a single shared library with a platform-specific extension:

• Linux and Android: corename_libretro.so
• Windows: corename_libretro.dll
• macOS: corename_libretro.dylib

Download the matching archive from the buildbot, decompress it (the downloader normally auto-extracts; by hand you do it yourself), and drop the library into the cores/ directory. Then grab the matching .info file into info/, or run Update Core Info Files once so names resolve. A core without its info file still runs, it just shows up nameless and cannot tell the scanner what it accepts. Put the wrong extension for your OS in there and the core will not load at all; a Windows .dll in a Linux install is inert weight.

Launching a core from the command line

The ArchWiki RetroArch entry, updated in 2026, documents the syntax every scripter eventually needs. The -L flag names the core; the trailing path names the content:

# Linux (Arch): distro cores live in /usr/lib/libretro
retroarch -L /usr/lib/libretro/snes9x_libretro.so ~/roms/snes/game.sfc

# Portable Windows build (PowerShell)
.\\retroarch.exe -L .\\cores\\mupen64plus_next_libretro.dll "D:\\ROMs\\N64\\game.z64"

# Load a core with no content, then choose content from the menu
retroarch -L ~/.config/retroarch/cores/mgba_libretro.so

This is how frontends like EmulationStation and Batocera actually launch games: they shell out to RetroArch with -L core content and a config path. If you have ever wondered what a Batocera install is doing under the hood, it is composing exactly these command lines a few hundred times. Learning the flag by hand demystifies the whole distro, and it is the only sane way to script a batch benchmark.

Reading the log

Append --verbose (or set the Frontend Logging Level to Info in the GUI) and RetroArch narrates the load. This is your ground truth when something fails silently:

[INFO] RetroArch 1.22.2
[INFO] [Core]: Loading dynamic libretro core from: "cores/pcsx2_libretro.so"
[ERROR] [Core]: Failed to load libretro core: "cores/pcsx2_libretro.so"
[ERROR] dlopen failed: wrong ELF class: ELFCLASS64

That error, "wrong ELF class" or, on Windows, "not a valid Win32 application," means an architecture mismatch: a 64-bit core on a 32-bit frontend, or an ARM core on x86. "No such file" with a core sitting right there usually means a missing dependency the core links against. The log tells you which. Guessing does not, and the log is rarely wrong.

Picking the Right Core Per System

Here is where the "200 cores" number turns into a liability. For most systems there are three to six cores, and they are not equivalent; they trade accuracy for speed, or features for portability. The 2026 consensus defaults, drawn from the project's own recommendations, are below. Install the default. Reach for the alternative only when you have a specific reason and the hardware to back it.

The recommendation table

Nintendo systems

Mesen is the current accuracy leader for the NES and it is light enough for almost anything; the older Nestopia and FCEUmm cores survive only for the weakest ARM chips. On the SNES, Snes9x is the default for a reason: bsnes chases cycle accuracy and pays for it with that roughly 4 GHz appetite, which is a real ceiling on handhelds and mini-PCs. The Nintendo 64 is the genuinely awkward one. Mupen64Plus-Next is the catalogue default and the name the project recommends, but it went through accuracy regressions in early 2025 that broke or degraded specific titles; when a game glitches under Mupen, ParaLLEl-N64 with its low-level RDP and RSP is the accuracy fallback, at a higher hardware cost. Gambatte and mGBA are both close to solved problems for Game Boy and GBA respectively, and melonDS has pulled clearly ahead of DeSmuME for the DS in both speed and fidelity.

One Nintendo system is a cautionary tale worth stating plainly: the 3DS. The Citra libretro core is effectively abandoned after the 2024 wave of litigation that also took down Yuzu, and 3DS emulation has moved to the standalone Azahar fork, which is not a maintained RetroArch core. Do not go into the Core Downloader expecting a working 3DS option. That is a standalone-emulator problem now, not a cores problem, and pretending otherwise wastes an evening.

Sega and Sony

Genesis Plus GX covers everything 8-bit and 16-bit Sega, SG-1000, Master System, Game Gear, Mega Drive, Sega CD, with one glaring exception: it does not do 32X. That gap is PicoDrive's job, and forgetting it is the classic "why won't my 32X games run" thread. Saturn is the hard one. Beetle Saturn is the accuracy pick, and it is x86_64 and CPU-brutal; Kronos and YabaSanshiro trade some fidelity for a hardware renderer and lower load. Dreamcast is mercifully simple, Flycast, full stop, and it handles NAOMI and Atomiswave arcade content besides. PlayStation splits on the renderer: Beetle PSX HW gives you internal-resolution upscaling and needs a real GPU plus a BIOS in system/; SwanStation, from the DuckStation lineage, is a strong all-rounder; and PCSX ReARMed is the core that makes PS1 playable on the weakest ARM handhelds. PS2, one more time, is LRPS2, x86_64 only, BIOS required, and completely off the table on ARM.

Core Options and the Override Hierarchy

Once cores are installed, the next thing that confuses people is why a setting they changed for one game leaked into another, or vanished entirely. The answer is RetroArch's layered configuration, which is powerful and completely silent about what it is doing.

Core options versus RetroArch settings

There are two different knob sets, and conflating them causes half the confusion. RetroArch settings (in retroarch.cfg) are frontend-wide: video driver, audio latency, input mapping. Core options are the emulator's own knobs, exposed by the core, Beetle PSX's internal resolution, Genesis Plus GX's region, mGBA's color correction. You reach core options at Quick Menu → Core Options while content is running. Modern RetroArch stores them per core in a .opt file under config/[Core Name]/, and can store per-game variants beside them. Change the internal resolution once for Beetle PSX and it persists for every PS1 game; change it as a per-game option and only that one title is affected. That is the difference between a global habit and a one-off.

The override hierarchy

RetroArch resolves configuration in layers, each overriding the last. From weakest to strongest:

1. Global, retroarch.cfg, the base for everything.
2. Core override, config/[Core Name]/[Core Name].cfg, applied whenever that core loads.
3. Content-directory override, applied to everything in a given ROM folder.
4. Game override, config/[Core Name]/[Game Name].cfg, applied to exactly one title.

The mnemonic: game beats directory beats core beats global. A shader you set globally is overridden by a core override, which is overridden by a per-folder override, which is overridden by a per-game override. This is why "I turned off the CRT shader everywhere but it is still on for Sonic" happens: a game or directory override is quietly winning. When a setting will not stick, you are fighting a higher layer, not a bug, and no amount of re-saving the global config will win that fight.

Saving overrides without wrecking global

Here is the trap. If you change a setting in the menu and then Save Current Configuration, or have "Save Configuration On Quit" enabled, you have just written that change into global retroarch.cfg. To scope a change instead, do not save the main config; use Quick Menu → Overrides → Save Core Overrides / Save Content Directory Overrides / Save Game Overrides. That writes only the deltas to the correct layered file and leaves global clean. An override .cfg holds just the lines that differ from global:

# config/Snes9x/Snes9x.cfg -- a CORE override, Snes9x only
video_shader_enable = "true"
video_smooth = "false"
aspect_ratio_index = "21"

Keep global minimal and push specifics down into overrides. A bloated global config is the hardest kind of RetroArch problem to debug, because every core silently inherits it and you cannot see the inheritance from inside any single game.

Five Pitfalls That Break Installs

These are the failures that generate forum threads. None of them are bugs. All of them are configuration or expectation errors, and each has a one-line fix once you know the shape.

Download-time traps

Pitfall 1: Downloading cores before info files. If you hit the Core Downloader before running Update Core Info Files, the list shows filenames instead of system names and freshly installed cores cannot tell the scanner what they accept. Fix: Online Updater → Update Core Info Files, then re-open the downloader. Info files first, always.

Pitfall 2: The Ubuntu PPA silently disables the Core Downloader. The download-cores guide states it outright: installing RetroArch from the Ubuntu PPA removes the Core Downloader from the interface. This is deliberate, the packager expects you to install cores as system packages. Fix: either install cores with apt (packages like libretro-snes9x), or switch to the official AppImage or Flatpak build, which keeps the downloader intact.

Runtime traps

Pitfall 3: The missing-BIOS black screen. Beetle PSX HW, Beetle Saturn, LRPS2, Sega CD and others need BIOS or firmware files in system/. Without them the core loads and then dies to a black screen, with a quiet log line about a missing file. Fix: place the correct BIOS in the system directory; check the core's info file or docs for the exact filenames and checksums. RetroArch will not, and legally cannot, ship them for you.

Pitfall 4: The wrong core for the hardware. Loading LRPS2 on an ARM handheld, or bsnes on a sub-3 GHz chip, produces either an outright load failure or unplayable slowdown that people misread as a broken install. Fix: match the core to the silicon, PCSX ReARMed rather than Beetle PSX on weak ARM, Snes9x rather than bsnes on a modest CPU, and no PS2 through libretro on ARM at all.

Update traps

Pitfall 5: Version drift between frontend and cores. A core downloaded today is built against current RetroArch. Run it under a frontend two years old and the libretro API-version check may reject it with "Failed to load." Fix: update the frontend to 1.22.2 first, then Update Installed Cores so both sides sit in the same era. Never update cores while leaving an ancient frontend in place.

Bonus pitfall: overrides you forgot you saved. A per-game or per-directory override made months ago will keep winning over your new global setting, forever, in silence. Fix: if a setting refuses to apply, open config/[Core Name]/ and delete the stray .cfg that is quietly overruling you.

Troubleshooting: Symptoms and Fixes

When a core misbehaves, the symptom usually points straight at the cause if you know the mapping. This is the table to bookmark; it covers the failures that account for the overwhelming majority of "core won't work" reports.

How to read the table

Work top to bottom. The earlier rows are the common, boring causes, and the boring cause is almost always the real one. Turn on Info-level logging before you touch anything else, because the log usually names the problem outright and saves you the guessing.

When the table does not cover it

If none of the above fits, reproduce with --verbose from a terminal and read the last ten lines before the failure. RetroArch's log is unusually candid; the fix is almost always spelled out in it. Beyond that, the Libretro documentation and the RetroArch GitHub issue tracker are the authoritative places to look, in that order. Random YouTube tutorials from 2019 are not; they predate half the menu paths above.

Advanced: Buildbot, libretro-super, iOS

Everything so far assumes the Core Downloader. Underneath it sits infrastructure worth knowing for when the easy path is blocked, when you want a core that is not in the downloader, or when you are on a platform that forbids downloading at all.

The buildbot

Every core in the downloader comes from the libretro buildbot, which compiles nightly builds for every supported platform. You can browse it directly and grab a specific core without the menu. The layout is by platform and architecture; the nightly cores live under paths like:

https://buildbot.libretro.com/nightly/windows/x86_64/latest/
https://buildbot.libretro.com/nightly/linux/x86_64/latest/
https://buildbot.libretro.com/nightly/android/latest/
https://buildbot.libretro.com/nightly/apple/tvos-arm64/latest/

Cores arrive compressed, for example snes9x_libretro.so.zip; decompress into cores/. The Libretro docs confirm the buildbot is the sanctioned source of pre-built cores even for the locked platforms, iOS and tvOS pull pre-built cores from here rather than requiring every user to compile from scratch.

Building from source with libretro-super

When you want a core that is not published, or you want to compile for an odd target, the project's own tooling is libretro-super, described in the Libretro docs as the easiest way to fetch RetroArch plus the source for every core in one shot:

git clone https://github.com/libretro/libretro-super.git
cd libretro-super
./libretro-fetch.sh          # pull RetroArch + every core's source
./libretro-build.sh snes9x   # build a single core
./libretro-build.sh          # or build the whole catalogue (hours)

libretro-fetch pulls the source; libretro-build compiles it. Building the entire catalogue takes hours and a working toolchain, which is why almost nobody does it, the buildbot exists precisely so you do not have to. But when a core is broken upstream and you need the fix before the nightly catches up, this is the path, and it is the same pipeline the project itself runs.

iOS, tvOS, and the code-signing wall

Apple's platform is the exception to every "just download a core" instruction. The Libretro iOS/tvOS docs are blunt about it: all cores must be built and added before building RetroArch, because the platform requires code signing and you cannot sign and inject a new binary at runtime. There is no in-app Core Downloader on iOS the way there is on desktop; the cores are baked into the signed app. The docs point to libretro-super as the easiest way to fetch everything, and note that pre-built cores are available from the buildbot to fold into the build. This sits downstream of the same 2024 legal thaw that finally let console emulators onto the App Store at all, Apple allows the emulator, on the condition that it is a fixed, signed artifact. If you have ever wondered why the iOS RetroArch experience feels frozen compared to desktop, that is the reason: on iOS, a core is a compile-time decision, not a click.

A Complete Working Configuration

To close, here is a known-good configuration you can reason about: the core-relevant block of retroarch.cfg, a scoped override, and the maintenance routine that keeps the whole thing from rotting. This is the state your install should be in after the twelve steps.

The retroarch.cfg core block

These are the lines that govern where cores live and how the updater behaves. The : prefix is RetroArch's shorthand for the install's base directory, which keeps a portable setup portable across drives:

# --- Core directories ---
libretro_directory = ":/cores"
libretro_info_path = ":/info"
system_directory = ":/system"

# --- Core Updater / Downloader ---
menu_show_core_updater = "true"
core_updater_buildbot_url = "https://buildbot.libretro.com/nightly"
core_updater_buildbot_assets_url = "https://buildbot.libretro.com/assets/"
core_updater_auto_extract_archive = "true"
core_updater_show_experimental_cores = "false"

# --- Overrides / options behaviour ---
config_save_on_exit = "false"
core_option_category_display = "true"
game_specific_options = "true"

# --- Logging (raise when debugging a core) ---
log_verbosity = "false"
frontend_log_level = "1"

The choice that saves you grief is config_save_on_exit = "false". With it off, RetroArch never quietly rewrites your global config; every change is deliberate, made through the override menus instead. And core_updater_show_experimental_cores = "false" keeps the half-finished cores out of the downloader, so you do not install one by accident and then blame the emulator for its own beta.

A scoped core override

An example core override for Beetle PSX HW, living at config/Beetle PSX HW/Beetle PSX HW.cfg, changing only what that core needs and nothing global:

# Applies only when Beetle PSX HW is the active core
video_scale_integer = "true"
video_smooth = "false"
input_libretro_device_p1 = "517"

Three lines, three effects, zero collateral. Every other core on the machine keeps the global defaults, and you can delete this file to undo all of it at once.

The maintenance routine

Cores are maintained software; a 2025 install left untouched drifts out of date and eventually fails the version check. The routine is short and worth doing monthly:

1. Update RetroArch to the current stable (1.22.2 or newer).
2. Online Updater → Update Core Info Files.
3. Online Updater → Update Installed Cores.
4. Online Updater → Update Databases and Update Assets.

Info files before cores, frontend before cores, and you will never see the version-drift failure. That is the entire discipline, four menu items and an order of operations. The catalogue will keep expanding, the official page promises as much, but the mechanics you have just set up do not change. And the machine, finally, stops fighting you.