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

There is a comfortable lie told to newcomers, repeated on forums, in video titles, and by people who ought to know better: that RetroArch is an emulator. It is not. RetroArch is a frontend — a launcher, a menu system, a save-state manager with strong opinions — and on its own it emulates precisely nothing. The actual work happens inside cores: modular plugins that speak a shared dialect called the Libretro API, loaded and unloaded at runtime like cartridges into a very particular slot.

This distinction is not pedantry. It is the entire reason your Core Downloader shows up empty, why a PlayStation 2 core exists on your desktop but not your phone, and why the same ROM boots on one machine and throws Failed to load content on another. Understand the core model and RetroArch becomes predictable. Ignore it and you will lose an afternoon fighting a menu that was, technically, working correctly the whole time.

As of June 2026, the current stable release is RetroArch 1.22.2, shipped November 20, 2025 — the successor to 1.21.0 from April 29, 2025. The Libretro catalogue now lists over 200 cores — emulators, game engines, and a few multimedia oddities — and the buildbot updates them continuously, sometimes several times a week. This tutorial walks the full loop in 12 steps and roughly 40 minutes: install the manifest, pick the right core per system, load content, override settings without breaking anything, and keep it all current. We will also enumerate the ways it fails, because there are many, and most of them are the same mistake wearing different clothes.

What a Core Actually Is

Before you download anything, spend two minutes on the model. Everything downstream — the empty downloader, the arch mismatch, the phantom PS2 core — falls out of it cleanly once you understand what a core is and, more importantly, what it is not.

The Libretro API in one paragraph

Libretro is a thin, stable contract between two halves. On one side sits the frontend — RetroArch is the reference implementation, though not the only one. On the other sits the core: a shared library (.so on Linux and Android, .dll on Windows, .dylib on macOS) that exposes a fixed set of C functions with names like retro_load_game, retro_run, and retro_get_system_av_info. The frontend hands the core a ROM and a slab of memory; the core hands back video frames, audio samples, and a request for input state. Neither side needs to know the other's internals. That is the whole trick, and it is why a Game Boy emulator and a full PlayStation 2 emulator can live under the same menu without either being remotely aware the other exists. Wikipedia's RetroArch entry documents this modular architecture and the Libretro API lineage if you want the citation trail.

Why "200+ cores" is a catalogue number, not your number

The oft-quoted "over 200 cores" figure is real, but it is a catalogue count: every core the Libretro buildbot compiles for at least one platform. The Core Downloader on your specific device shows only the builds compiled for your operating system and CPU architecture — and that list is frequently much shorter. The clean example is LRPS2, the PlayStation 2 core: it is x86_64-only, so it appears on a Windows or Linux desktop and is simply absent on any ARM phone or handheld. It is not hidden; it does not exist for that target. Homebrew ports narrow the field further — the webOS core rebuild was refreshed in December 2025 to roughly 170+ armv7 cores plus an experimental aarch64 set. So when someone tells you RetroArch "has 200 cores," the correct response is: on which machine?

Cores versus the emulators they descend from

Most cores are ports of standalone emulators, and knowing the parentage tells you what to expect. Beetle PSX is a fork of Mednafen. SwanStation is a port of DuckStation. LRPS2 is a hard fork of PCSX2. Genesis Plus GX began life as Wii homebrew. The Dolphin core for GameCube and Wii was updated to match the current Dolphin stream in October 2025, per the Libretro forums, which matters because a stale Dolphin core carries stale bugs. The lesson: a core is not a magic black box, it is a specific emulator at a specific point in its history, and "which core" is really the question "which emulator, and how old."

Prerequisites: Versions and Hardware

You need three things settled before step one: the right RetroArch build, hardware that can actually run the cores you want, and — for several systems — BIOS files you are expected to supply yourself. Skip any of these and the 12 steps will still "work," they just won't produce a running game.

The RetroArch build you actually need

Install 1.22.2 or newer. Not because older builds are forbidden, but because the core info manifests target the current line, and a mismatched app can pull cores it then refuses to load. There is also a concrete reason to avoid one specific version: 1.22.0 shipped a shader bug that produced a black screen on certain configurations, fixed in 1.22.1 and 1.22.2. If you are on 1.22.0, update before you do anything else. Grab the official build for your platform from the RetroArch releases page — RetroArch is GPLv3 and the source, buildbot, and binaries all live in the open. The 1.21.0 milestone from April 2025 is worth knowing about only as the predecessor; there is no reason to run it in mid-2026.

Hardware floor, system by system

Cores are not equal in appetite, and the single most common self-inflicted wound is running a heavy core on a light machine. A rough hierarchy: 8- and 16-bit systems (NES, SNES, Genesis, Game Boy) run on essentially anything. Cycle-accurate cores are the exception — bsnes Accuracy wants something in the neighborhood of a 4 GHz CPU to hold full speed, while Snes9x is the practical choice on a handheld. PlayStation splits three ways by power (see the next section). The LRPS2 PS2 core is desktop-only and hungry even there. If your target is a handheld — a Retroid, an Anbernic, a Miyoo — plan around the lightweight ARM cores from the start. We compared the current handheld field in the 2026 Retroid Pocket lineup, and the short version is that CPU class dictates which cores are realistic long before you open the downloader.

BIOS files and the law

Several cores will not run a single frame without a BIOS image, and RetroArch ships none of them — deliberately. BIOS files are copyrighted firmware; dumping the ones from hardware you own is your business and your jurisdiction's, and downloading them from a stranger is a different matter entirely, which The Machine will note and decline to elaborate on. Mechanically, BIOS images go in RetroArch's system directory, and the core checks their filenames and MD5 hashes on load. PlayStation 1, PlayStation 2, and a handful of others are hard requirements; get the hashes right or the core reports a missing-BIOS error and refuses. If you are dumping your own carts and firmware, our Retrode 2 dumping walkthrough covers the cartridge side of that chain.

Installing Cores in 12 Steps

Here is the full loop. The single non-negotiable is step 3 — do it before step 5 or nothing else in the list functions. Every step below carries its rationale, because "click this" without "because" is how people end up cargo-culting broken configs.

The sequence, start to finish

1. Confirm your RetroArch version is 1.22.2 or newer. Core info manifests track the current line; an old app pulls cores it can't load, and 1.22.0 specifically carries the shader black-screen bug.
2. Open the Online Updater (Main Menu → Online Updater). This is the sanctioned path. Sideloading a raw .so or .dll skips the info-file validation and is the express route to "failed to load."
3. Run "Update Core Info Files" FIRST. This downloads the manifest that tells RetroArch which cores exist and what content they handle. Without it the Core Downloader is blind — empty, or listing cores that then refuse to run. This is the step everyone skips and the cause of most "my downloader is broken" threads.
4. Run "Update Installed Cores" if you already have cores from a prior session. It refreshes every downloaded core in one pass — the fastest way to stay current without revisiting the downloader core by core.
5. Open the "Core Downloader" (also labeled "Download a Core"). This lists the builds compiled for your platform and architecture, not the abstract 200+ catalogue. If it's missing from the menu, enable it under Settings → User Interface → Menu Item Visibility → Show Core Downloader.
6. Pick the right core for the system, not just the first one listed. Most systems have two or three cores trading accuracy against speed; the default is not always the best for your hardware. The next section is the cheat sheet.
7. Download the core. RetroArch pulls the correct binary — .so, .dll, or .dylib — from the buildbot for your exact target. You'll see it appear under Load Core afterward.
8. Load content with the core (Load Content → select ROM → choose the core). This is the moment of truth: the core runs the ROM. If it boots, you're done with the hard part.
9. Supply BIOS files where the core demands them. Drop the correct images into the system directory and verify their hashes. PS1, PS2, and others simply will not start otherwise, and the error message is explicit about what's missing.
10. Save a per-core or per-game override for any setting you tuned (Quick Menu → Overrides). This locks in your choices without editing the global config, which keeps every other system untouched.
11. Enable RetroAchievements if you want them (Settings → Achievements). Integration is native as of the current builds — no third-party plugin, no external launcher, just log in and toggle it on.
12. Set an update cadence. Cores move on the buildbot weekly; a core you installed and forgot is a bug you're choosing to keep. Once a month, run Update Installed Cores. Done.

Expected output when it works

Step 3 should look boring, which is the point. With logging enabled you'll see the updater fetch and extract the info archive, then report a count of files written:

[INFO] [Updater] Starting core info download...
[INFO] [Updater] Downloading: core_info.7z
[INFO] [Updater] Extracting to: cores/
[INFO] [Updater] 247 core info files updated.
[INFO] [Content] Scanning core info... done.

The exact number varies by build and platform — the figure above is illustrative, not a target. What matters is that it reports a count in the hundreds and does not error. If it writes zero files or fails to reach the buildbot, stop and fix that before touching the downloader; everything after depends on it.

Where the menu hides these commands

All three updater actions — Update Core Info Files, Update Installed Cores, and the Core Downloader itself — live under Online Updater. On a fresh or minimalist install, some are hidden behind the menu-visibility settings mentioned in step 5. On Linux distributions that package Libretro cores separately, you can also skip the in-app downloader entirely and install cores through the system package manager, which we cover in the advanced section. The official Libretro download-cores guide mirrors this flow if you prefer the primary source.

Picking the Right Core Per System

"Which core" is the question that separates a working setup from a frustrating one. Some systems are settled — one obvious pick and you move on. Others force a genuine trade-off between accuracy and performance, and a couple have had their default core quietly go sideways in the last year. Here is the 2026 state of play.

The hard three: PlayStation, N64, PS2

PlayStation 1 is a three-way choice by power budget. Beetle PSX HW — the Mednafen fork — is the most accurate and the heaviest, with a proper hardware renderer, PGXP geometry correction, and internal-resolution upscaling; it is the desktop pick and overkill on a phone. SwanStation — the DuckStation port — is the lighter middle ground with most of the visual niceties. PCSX ReARMed is the lightest, and it is what powers ARM handhelds and the budget-console firmwares like OnionOS, muOS, and ROCKNIX. If you are running a Miyoo or similar, PCSX ReARMed is doing the work whether you chose it or not; our Miyoo Mini Plus game-list breakdown shows that class of hardware in context.

Nintendo 64 is the one to watch. The mainline core, mupen64plus-next, is still the recommended default per the Libretro mupen64plus docs, and it bundles GLideN64 for HLE plus angrylion and the ParaLLEl-RDP/RSP plugins for accuracy. But it regressed in early 2025: certain titles — Stunt Racer 64 and World Driver Championship among them — stopped loading, and the community workaround was to pin an earlier build. If your N64 game refuses to boot on a current core, that is your first suspect. The accuracy-first alternative is Parallel N64 (Vulkan, low-level emulation), which trades broader compatibility for cycle-honest rendering.

PlayStation 2 arrived properly with the 1.22 line in late 2025 via LRPS2, the hard fork of PCSX2. It is x86_64-only — Windows, Linux, and macOS under Rosetta; there is no Android, iOS, or ARM-Linux build, so do not go looking for it on a handheld. Its headline feature is the new ParaLLEl-GS renderer by Themaister, a compute-based GS implementation with Vulkan, GL, and D3D11/12 backends plus a software path for accuracy. It needs a real BIOS, and the GameIndex data that used to live beside PCSX2 is now embedded in the core. The Libretro announcement post is the primary source on the LLE renderer work.

The settled ones: SNES, NES, Genesis, GBA

These are mercifully simple. SNES: bsnes in its Accuracy profile if you have the ~4 GHz to spare and want cycle-accuracy; Snes9x everywhere else. NES: Mesen, which is PPU-accurate, handles obscure mappers, and ships a debugger for the curious. Game Boy Advance: mGBA, no debate; for GB and GBC either mGBA or Gambatte. Sega: Genesis Plus GX covers Mega Drive/Genesis, Sega CD, Master System, Game Gear, SG-1000, and Pico with 100% coverage — but not the 32X, which belongs to PicoDrive. On Android specifically, PicoDrive is the recommended Genesis core, pulled straight from the Core Downloader. Arcade: Final Burn Neo, whose library reaches back to the 1970s; RetroBat bumped its FBNeo build to the 22/04/2026 dated release, a reminder that even the settled cores keep moving.

The dead and the reborn: Citra to Azahar

The 3DS story is the cautionary tale of 2025. Citra was taken down, and the community response was Azahar — a merge of the prominent Citra forks, PabloMK7's and Lime3DS among them. Its first official Libretro core shipped in the 2125.0 line (Alpha 4, spanning six operating systems including Linux, Windows, macOS, Android, iOS, and tvOS), and the line had advanced to 2126.0 at release-candidate stage by mid-2026. Along the way it dropped support for encrypted games and the Nintendo CDN, pushing that responsibility to the separate Artic Setup Tool, and the Libretro binaries are now stripped for a smaller Android footprint. Releases live at the Azahar GitHub. The moral: a core's name is not permanent, and "the 3DS core" means something different than it did eighteen months ago.

Updating Cores Across Platforms

Cores are living software. The buildbot recompiles them constantly, and a core you installed six months ago is a snapshot of six-month-old bugs. Updating is two layers: the RetroArch app itself, and the cores inside it. Keep them roughly in sync.

One-liners for Windows, macOS, and Linux

Update the application through your platform's package manager so the app's core ABI stays current, then update the cores from inside RetroArch. The three canonical commands:

# Windows (App Installer / winget)
winget upgrade Libretro.RetroArch

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

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

After the app updates, launch it and run Update Installed Cores so the cores match the freshly updated frontend. The Homebrew and Flatpak paths in particular keep the app and its installed cores synchronized cleanly, which spares you the arch-mismatch class of failure entirely.

Update Installed Cores versus re-downloading

There are two ways to refresh cores and one is strictly better for the common case. Update Installed Cores walks everything you already have and pulls the current build in a single pass — no clicking through the Core Downloader core by core. Reserve the downloader for adding a core you don't yet have. And while you're in the Online Updater, the same menu offers shaders, controller profiles, cheats, and overlays as separate updatable assets. They are optional, but keeping them current is what makes a fresh core feel plug-and-play instead of a config project.

The May 24, 2026 forced refresh

One dated wrinkle worth knowing: a core update on May 24, 2026 replaced older files on the buildbot for anyone who had installed cores before that date. If you set your machine up prior to late May 2026 and something feels subtly off, run Update Installed Cores once — after that, installations are current and need no manual intervention. This is the same maintenance rhythm that keeps the Dolphin core matched to its upstream stream (as it was in October 2025) and FBNeo pinned to its latest dated build. The buildbot doesn't announce these individually; the cadence of "update monthly" absorbs them for you.

Overrides: Per-Game, Per-Core, Per-Directory

The global config is the wrong place to tune anything system-specific. You want your PS1 core running at 4x internal resolution without forcing that on the Game Boy, and you want one troublesome game widescreen-hacked without touching its siblings. RetroArch's override system exists for exactly this, and once you understand the hierarchy it stops being mysterious.

The override hierarchy

Settings resolve from most specific to least: game > content-directory > core > global. A per-game override beats a per-directory one, which beats a per-core one, which beats the global retroarch.cfg. The files live in predictable places under the config tree:

retroarch/
├─ config/
│  ├─ Beetle PSX HW/
│  │  ├─ Beetle PSX HW.cfg          # per-core override
│  │  ├─ Gran Turismo (USA).cfg     # per-game override
│  │  └─ Gran Turismo (USA).opt     # per-game core options
│  └─ remaps/
│     └─ Beetle PSX HW/
│        └─ Gran Turismo (USA).rmp  # per-game input remap
├─ cores/
│  ├─ mednafen_psx_hw_libretro.so
│  └─ mupen64plus_next_libretro.so
└─ retroarch.cfg                     # global config

Note the split: the .cfg files hold RetroArch settings (video, audio, hotkeys), the .opt files hold core options (renderer, resolution, PGXP), and the .rmp files under remaps/ hold input remaps. They are three separate systems that happen to share the naming scheme, which is the source of a lot of confusion.

Core options versus input remaps

Core options — the settings a core exposes to RetroArch — default to the global retroarch-core-options.cfg and can be pinned per game as config/<core>/<game>.opt. Input remaps are their own file type, .rmp, under config/remaps/<core>/. Here is a real per-game core-options file for Beetle PSX HW, using the actual option keys the core exposes:

beetle_psx_hw_renderer = "hardware_vk"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_pgxp_mode = "memory + CPU"
beetle_psx_hw_dither_mode = "internal resolution"
beetle_psx_hw_widescreen_hack = "disabled"

Those five keys are the ones you'll actually reach for: the Vulkan hardware renderer, 4x upscaling, full PGXP geometry correction, dithering applied at internal resolution, and the widescreen hack left off (turn it on per-game only for titles that tolerate it). Drop this beside the ROM's config and it applies to that one game.

Saving overrides from the menu

You rarely need to hand-edit these. From a running game, Quick Menu → Overrides → Save Core Overrides or Save Game Overrides writes the current RetroArch settings to the right file automatically. For core options specifically, Quick Menu → Core Options → Manage → Create game-options file generates the .opt. The relevant global switches — game_specific_options, auto_overrides_enable, and auto_remaps_enable — must be enabled for these to load on the next launch, and config_save_on_exit governs whether RetroArch writes changes back when you quit. The Libretro overrides guide is the authoritative reference on the precedence rules.

Six Ways This Breaks (and the Fixes)

Almost every "RetroArch cores don't work" complaint reduces to one of six mistakes. None are exotic. All are avoidable once named.

Manifest and download failures

Pitfall 1 — skipping Update Core Info Files. This is the original sin, and it accounts for more broken-downloader threads than everything else combined. Without the info manifest, the Core Downloader has no idea what exists; it shows empty, or lists cores that then "fail to load" or appear as unrecognized. Fix: run Online Updater → Update Core Info Files, then update installed cores, then download. In that order. Every time you set up a new machine.

Pitfall 2 — downloading the wrong architecture. An ARM core will not run on an x86 machine and vice versa; a core built for one platform is inert on another. This mostly bites people who copy a cores folder between devices. Fix: download through the in-app Core Downloader on the target device, which only ever offers the correct builds. Don't ferry .so files between a phone and a PC.

Wrong core, wrong hardware

Pitfall 3 — assuming "200+ cores" means 200 on your device. It's a catalogue figure. Your handheld might see 170; your phone won't see LRPS2 at all. Fix: adjust expectations to the platform, and don't go hunting for a core that was never compiled for your architecture. If it's not in your downloader, it doesn't exist for you.

Pitfall 4 — the heaviest core on the lightest hardware. Running Beetle PSX HW on a budget ARM handheld, or bsnes Accuracy on anything without the clock speed, produces stutter and blame directed at the wrong place. Fix: match core weight to silicon — PCSX ReARMed and Snes9x on handhelds, the heavy accurate cores on desktops. This is a hardware decision as much as a software one, which is why we harp on CPU class in every handheld review.

BIOS and config foot-guns

Pitfall 5 — no BIOS, and expecting the core to conjure one. PS1, PS2, and others need real firmware in the system folder with correct filenames and hashes. RetroArch ships none. Fix: supply the BIOS yourself and verify the MD5 — the core's error message names exactly what it wants.

Pitfall 6 — editing retroarch.cfg while RetroArch is running. With config_save_on_exit enabled, RetroArch overwrites the file on quit and silently discards your hand edits. Fix: edit config only while the app is closed, or make changes through the menu so they're written correctly, or disable config_save_on_exit if you insist on editing by hand. This one wastes an entire evening the first time it happens to you.

Troubleshooting Table

When something fails, resist the urge to reinstall everything. RetroArch tells you what's wrong if you let it — the fix is almost always narrow.

Read the log before you panic

Enable logging under Settings → Logging (set frequency to verbose while diagnosing), then reproduce the failure and read the last few lines. Ninety percent of the time the log names the exact problem — a missing BIOS by filename, a core that failed to open, an info file that never downloaded. The table below maps the symptoms you'll actually see to their causes and fixes.

The most common failures, mapped

When the fix is simply "use a different core"

Some failures aren't configuration at all — they're the wrong tool. A game that won't boot on mupen64plus-next may run fine on Parallel N64. A PS1 title that chugs on Beetle PSX HW is happy on PCSX ReARMed. RetroArch's whole design assumes you'll swap cores freely, so treat "try another core" as a first-class diagnostic step, not a last resort. If two cores both fail the same way, then suspect BIOS or ROM.

Advanced: Buildbot, PPAs, and Nightlies

The in-app updater is the right tool for 95% of users. The other 5% want a specific nightly build, a core the stable channel hasn't picked up, or an install managed entirely by their OS package manager. Here is how.

Pulling a single core from the nightly buildbot

Every core RetroArch offers is compiled and published at the Libretro nightly buildbot, organized by platform and architecture. You can bypass the menu and fetch one by hand — useful for pinning or scripting:

# Grab a single nightly core by hand (Linux x86_64 example)
cd ~/.config/retroarch/cores
wget https://buildbot.libretro.com/nightly/linux/x86_64/latest/mednafen_psx_hw_libretro.so.zip
unzip mednafen_psx_hw_libretro.so.zip
rm mednafen_psx_hw_libretro.so.zip

On Ubuntu and derivatives, the Libretro team also maintains a PPA, so cores can be installed and updated as system packages alongside everything else you manage with apt:

sudo add-apt-repository ppa:libretro/stable
sudo apt-get update
sudo apt-get install libretro-beetle-psx
sudo apt-get install libretro-mupen64plus-next

Package-managed cores land in the system core path and show up in RetroArch normally — just remember that apt upgrade, not the in-app updater, now owns their versions.

RetroAchievements, shaders, and the rest of the updater

RetroAchievements integration is native — no RetroArch Cheevos plugin, no external overlay, no separate launcher. Log in under Settings → Achievements and it hashes your ROM against the server on load. The same Online Updater menu that fetches cores also updates shaders (CRT and handheld-LCD filters), controller profiles (autoconfig for known pads), cheats, and overlays. None are mandatory, but a current shader set and controller-profile database are what turn a bare core into something that just works when you plug a gamepad in.

Homebrew rebuilds and the FPGA alternative

Beyond the official buildbot, community rebuilds keep dead or niche platforms alive — the webOS core set was refreshed to 170+ armv7 cores in December 2025 for LG TVs, and similar efforts exist for other embedded targets. If you'd rather not manage cores at all, the console-firmware frontends bundle a curated set out of the box: our Batocera 43.1 install guide and the RetroPie 2026 status piece both cover distributions that ship Libretro cores pre-selected, trading fine control for zero setup. And for the purist who considers software emulation itself the compromise, the FPGA route recreates hardware in reconfigurable logic rather than approximating it in code — we took apart that philosophy in the MiSTer Multisystem 2 review. Cores, distros, or FPGA: same goal, three very different price and effort curves.

A Complete Working Configuration

Here is the whole thing assembled — the config keys that make core management, overrides, and achievements behave, plus the per-game core-options pattern, plus a final checklist. Copy the relevant blocks, adjust paths for your platform, and you have a setup that survives updates.

The retroarch.cfg essentials

These are the global keys that govern core updating, override loading, and achievements. Everything else can stay at defaults:

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

# --- Overrides & remaps ---
config_save_on_exit = "true"
game_specific_options = "true"
auto_overrides_enable = "true"
auto_remaps_enable = "true"

# --- RetroAchievements ---
cheevos_enable = "true"
cheevos_hardcore_mode_enable = "false"

With auto_overrides_enable and auto_remaps_enable on, RetroArch loads your per-game .cfg and .rmp files automatically; with game_specific_options on, it loads the .opt files too. Leave core_updater_show_experimental_cores off unless you specifically want the half-finished cores in your downloader.

A per-game core-options file that earns its keep

Reprising the Beetle PSX HW example from the overrides section, because it's the one people ask for most — this is the file you save as config/Beetle PSX HW/<game>.opt for a PS1 title you want upscaled and geometry-corrected on a desktop:

beetle_psx_hw_renderer = "hardware_vk"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_pgxp_mode = "memory + CPU"
beetle_psx_hw_dither_mode = "internal resolution"
beetle_psx_hw_widescreen_hack = "disabled"

Drop the renderer to software and the resolution to 1x for the accuracy-first, warts-and-all original look; raise the resolution to 8x if your GPU is bored. The point of the .opt file is that these choices live with the one game and don't leak into anything else.

The final checklist

If you do nothing else, do these, in this order:

• App first: RetroArch 1.22.2+ via winget, flatpak, or brew.
• Manifest second: Online Updater → Update Core Info Files. Never skip this.
• Cores third: Core Downloader for new cores, Update Installed Cores for existing ones.
• BIOS where required: correct files in system/, hashes verified.
• Right core per system: heavy-and-accurate on desktop, light-and-fast on handhelds.
• Overrides, not global edits: save per-game and per-core from the Quick Menu.
• Update monthly: Update Installed Cores catches the buildbot's constant churn, including forced refreshes like the one on May 24, 2026.

That is the whole discipline. RetroArch's core system looks byzantine from the outside and is almost trivial once you internalize two facts: the frontend emulates nothing, and the info manifest must come before everything. Get those right and the other 200 cores fall into line.