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

Nobody actually downloads RetroArch. They download the idea of RetroArch — one program that plays everything — and then spend a confused evening wondering why the icon they installed cannot open a single ROM. The missing piece is the core, and the core is the entire point. What follows is a working tutorial for installing, updating, choosing, locking, and configuring cores in 2026, on the version of RetroArch that exists right now, with the cores that work right now, including the two or three that quietly stopped working in 2025 and nobody sent you a memo about. Read the prerequisites section. The support forums are a monument to people who did not.

The plan is simple and the order is not negotiable: understand what a core is, satisfy the prerequisites, run the twelve-step install-and-update loop, pick the correct core for each system instead of the first one alphabetically, then bolt down your configuration with overrides so a routine update never eats an evening of tuning. Budget about forty minutes for a full first pass across a handful of systems. Budget more if you insist on N64.

What a Core Actually Is

Start here, because almost every doomed support thread begins with someone who skipped it. A core is not RetroArch. RetroArch is the frontend: the menu system, the input abstraction, the shader pipeline, the netplay stack, the save-state and rewind plumbing, the RetroAchievements client. A core is a shared library that plugs into that frontend and does the actual work of pretending to be a Super Nintendo, a DOS box, a Game Boy, a PlayStation, or a plain video player. The official cores page is blunt about the arrangement: cores are essentially other programs and games that run through RetroArch, and RetroArch requires cores to run any content. No core, no game. The frontend on its own is an empty museum with the lights on.

The frontend and the libretro contract

The thing that lets any of this work is the libretro API — a small, stable contract that says: a core will expose a handful of functions (load this content, run one frame, hand me video here, hand me audio there, tell me what inputs you want), and the frontend promises to call them and to draw the results. Because the contract is stable, one frontend can drive hundreds of unrelated emulators, and one emulator, wrapped as a core, can run under any libretro frontend — RetroArch, yes, but also the distros built on top of it. If you have ever set up a Batocera build or wrangled RetroPie on a Raspberry Pi, you were using libretro cores the whole time; those projects simply hide the frontend behind a friendlier launcher and pre-seed the cores for you. The core is the emulator. RetroArch is the chrome around it.

Dynamic loading and the buildbot

RetroArch supports dynamic module loading on most platforms, and that single design decision is the reason this tutorial exists at all. Cores are shipped as .dll on Windows, .so on Linux and Android, and .dylib on macOS, and RetroArch loads them at runtime the way a browser loads a plugin. You do not recompile the app when bsnes gets a bugfix. You do not wait for a new store listing when a fresh PlayStation 2 core lands. You open the built-in updater, pull the new module from the project's buildbot at buildbot.libretro.com/nightly, and it drops into your cores folder. The buildbot rebuilds cores continuously, per platform and per CPU architecture, which is a blessing when it works and, as we will see, the source of most of the fragmentation misery when it does not.

"Over 200 cores" is a catalogue, not a promise

The headline number is over 200 cores, spanning game engines, games, multimedia programs, and emulators. That figure is true as a catalogue. It is not true for your specific device, and confusing the two is the single most common disappointment in the RetroArch experience. The Core Downloader only ever shows the builds that exist for your exact platform and architecture. The Steam release, curated by hand, reached sixty-five cores in a community milestone after Dosbox Pure was added, up from sixty after DirkSimple — a whole distribution channel two hundred cores short of the catalogue. The webOS armv7 rebuild passed one hundred seventy cores in December 2025. A typical desktop downloader lists north of one hundred. All of these are RetroArch; none of them is "200+." The catalogue is the ceiling. Your platform is the floor, and the floor is what you actually stand on. This is not a purely software problem, either: hardware purists sidestep the entire question with an FPGA board like the MiSTer Multisystem 2, which reimplements the console in logic gates instead of loading a core — a different philosophy with a different, much shorter, and much more expensive catalogue.

Prerequisites: Versions & Hardware

Cores are versioned against the frontend that loads them, and the hardware underneath decides which cores are fantasy. Get these three things straight — software version, silicon, and BIOS — before you touch the downloader, or you will spend the evening debugging a problem you created in the first five minutes.

The software versions that matter in 2026

The current stable line is RetroArch 1.22.2, published in November 2025. It is worth knowing the shape of that line, because it bit people: 1.22.0 shipped a shader black-screen regression that was fixed across 1.22.1 and 1.22.2, so "just grab 1.22" was briefly bad advice. The prior milestone is RetroArch 1.21.0, released on 29 April 2025, which is the build that introduced the modern PlayStation 2 core and cleaned up a pile of Apple Vulkan, CoreMIDI, and 3DS issues. RetroArch is GPLv3, its repository sits north of thirteen thousand stars, and the canonical place to confirm what version is current — and what each release actually changed — is the GitHub releases page, not a screenshot on a forum. Install the frontend from an official channel: the project's own installer, winget on Windows, Flatpak on Linux and the Steam Deck, or the Homebrew cask on macOS. Avoid whatever ancient build your Linux distribution's default repository is shipping; a stale frontend downloads stale cores and then blames you.

Hardware, stated honestly

Eight- and sixteen-bit systems are trivial on anything with a pulse; a potato handheld runs them. The trouble starts higher up. bsnes in its accuracy configuration is cycle-accurate and wants roughly a 4 GHz core to hold full speed — glorious on a desktop, a slideshow on a weak CPU, which is exactly why Snes9x exists as the practical alternative. PlayStation with a hardware renderer wants a real GPU. Nintendo 64 wants patience and, frequently, a second core. The PlayStation 2 core is x86_64 only — Windows, Linux, and macOS via Rosetta — with no Android, iOS, or ARM-Linux build in existence, so no amount of wishing puts it on an ARM handheld. If you are running on a phone-class SoC, a device like the Retroid Pocket 5 or 6 defines your realistic ceiling: PlayStation 1 and lighter, comfortably; PlayStation 2, not through this core. And if you own the desktop muscle but your frame times still stutter under a cycle-accurate core, the fix may be thermal rather than architectural — undervolting that CPU can claw back the sustained clocks that bsnes quietly demands.

BIOS, storage, and the system directory

Some cores are self-contained. Many are not. PlayStation 1, PlayStation 2, Sega CD, and various others need genuine BIOS files, and RetroArch expects them in its system directory with the exact filenames the core is looking for — not renamed, not zipped, not "close enough." These files are not shipped with RetroArch and never will be, for the obvious reason: they are copyrighted firmware. The Machine will state the law plainly and then decline to hold your hand around it — dumping the BIOS from hardware you own is your responsibility, and the core will simply refuse to boot content until the right bytes are sitting in the right folder. Point system_directory somewhere sane, keep your saves and states on fast storage, and leave yourself a few gigabytes of headroom; the core downloader, thumbnail packs, and shader collections add up faster than anyone expects.

Install & Update Cores: 12 Steps

This is the loop. Do it in order the first time; after that you will internalise it and run the relevant half in thirty seconds. The single most important idea in the whole procedure is that the frontend and the cores are versioned together, so you update the binary first and the cores second — never the other way around.

Prep: update the binary, then the info files

Before you open a single menu, bring the frontend itself current from your package manager. A core built for this week's buildbot expects this week's frontend; feed it a six-month-old binary and it "fails to load" with no useful explanation.

# Windows (winget)
winget upgrade Libretro.RetroArch

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

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

Now launch RetroArch and open Online Updater. You are looking at something like this, and the order of operations inside it matters more than the menu lets on:

Online Updater
 |- Core Downloader
 |- Update Installed Cores
 |- Update Core Info Files      # do this FIRST
 |- Update Assets
 |- Update Controller Profiles
 |- Update Databases
 |- Update Cheats
 |- Update Overlays

The twelve steps

1. Update the RetroArch binary. Run the package-manager command above (or the project installer). Rationale: cores are compiled against the frontend's ABI. Update cores onto an old binary and they crash on load; this one mistake accounts for a startling share of "my core is broken" reports.
2. Open Online Updater. From the main menu, not from a game. Rationale: everything that follows lives here, and doing it before you load content keeps the frontend in a clean state.
3. Update Core Info Files — first, always. This pulls the manifest that tells RetroArch which cores exist, what they are called, and what systems they claim. Rationale: skip it and the Core Downloader shows a blank or stale list, freshly downloaded cores appear as "unrecognized," and you file a bug against a problem you caused by clicking in the wrong order.
4. Update Databases and Assets (optional but wise). Rationale: the databases drive content scanning and correct game identification, and the assets are the menu icons and fonts. Cores run without them, but playlists and thumbnails do not populate correctly, which people also misread as a core failure.
5. Open the Core Downloader and install a core. Pick your system, pick the core, let it fetch from the buildbot. Rationale: this is the actual install, and it only lists builds that exist for your platform and architecture — the per-device reality behind the catalogue's "200+." The canonical reference for this screen is the libretro Core Downloader guide.
6. Read the filename. Every core lands as something_libretro with the platform extension — mgba_libretro.dll, mgba_libretro.so, mgba_libretro.dylib. Rationale: knowing the on-disk name lets you sideload, script, or launch a core from the command line later, and it demystifies the cores folder when something goes wrong.
7. Load Core, then Load Content. Point RetroArch at the core, then at a ROM. Rationale: this proves the core initialises before you complicate matters with BIOS, shaders, or overrides. If it boots to a black screen with audio, that is a video-driver or renderer issue, not a broken core — noted below.
8. Verify BIOS for cores that demand it. For PlayStation, Sega CD, and friends, drop the correct firmware into the system directory and reload. Rationale: a missing or misnamed BIOS produces a "failed to load content" error that looks identical to a broken core but is entirely on you.
9. Run Update Installed Cores. One pass refreshes every core you have to the current buildbot build. Rationale: keeping cores current picks up compatibility and accuracy fixes — but read the next step before you make this a mindless habit.
10. Lock any core you depend on. Load the core, open the Quick Menu, and lock it (Manage Cores) so bulk updates cannot overwrite it. Rationale: buildbot cores are living code, and living code regresses. The Nintendo 64 core regression of early 2025 is the cautionary tale — a locked, known-good core is immune to it.
11. Set an override so your tuning survives. Configure a core or a game the way you like it, then save it as a scoped override rather than to the global config. Rationale: this is the difference between a setup that persists and one that resets the next time you touch a menu. Full mechanics are in the overrides section below.
12. Back up your config folder and your working cores. Copy the config directory and archive the exact core builds that work. Rationale: when an update breaks something a week later — and eventually one will — restoring a known-good core is a thirty-second copy, not a research project.

Expected output

A healthy core download writes something like the following to the log. If you see the fetch, the extract, and a matching "core info updated" line, the install worked and the core is ready to load:

[INFO] [Core Downloader] Fetching core list from buildbot...
[INFO] Downloading mupen64plus_next_libretro.dll.zip
[INFO] Extracting to cores/mupen64plus_next_libretro.dll
[INFO] Core info updated: Nintendo - Nintendo 64 (Mupen64Plus-Next)

If the Core Downloader entry is missing from the menu entirely, it is hidden, not broken: go to Settings, then User Interface, then Menu Item Visibility, and switch on Show Core Downloader. If you installed RetroArch from the Ubuntu PPA specifically, the Core Downloader is disabled by design and you install cores from the terminal instead, with sudo apt-get install libretro-corename. That is a packaging decision, not a fault.

Picking the Right Core Per System

RetroArch will happily let you run the wrong core forever. Multiple cores exist for most systems precisely because they make different trades — accuracy against speed, features against portability — and the "best" core is a function of your hardware and your priorities, not a single name. Here is the 2026 shape of it, tier by tier.

The 8- and 16-bit tier

For the NES, the accuracy pick is Mesen, a PPU-accurate core with deep mapper support and a proper debugger; it was still seeing active development in May 2026. For the SNES, choose by CPU: bsnes in accuracy mode is cycle-accurate and demands roughly 4 GHz, while Snes9x is the sane, fast choice on handhelds and modest machines and is indistinguishable to most eyes. Game Boy Advance belongs to mGBA; Game Boy and Game Boy Color are happy on mGBA or Gambatte. For Sega, Genesis Plus GX is a near-perfect all-rounder covering Mega Drive, Sega CD, Master System, Game Gear, SG-1000, and Pico — but note the one gap that trips everyone: it does not do 32X. For 32X, and as the standard lightweight Genesis core on Android and budget handhelds, you want PicoDrive instead. Arcade is Final Burn Neo, whose supported set now reaches back into 1970s hardware. Here is what a well-chosen cores folder looks like on disk:

cores/
 |- mesen_libretro.dll             # NES (PPU-accurate)
 |- bsnes_libretro.dll             # SNES, accuracy (~4 GHz CPU)
 |- snes9x_libretro.dll            # SNES, speed / handhelds
 |- mgba_libretro.dll              # GBA / GB / GBC
 |- genesis_plus_gx_libretro.dll   # MD / CD / SMS / GG / SG-1000 (no 32X)
 |- picodrive_libretro.dll         # 32X + the light Genesis pick
 |- fbneo_libretro.dll             # arcade
 |- mupen64plus_next_libretro.dll  # N64, mainline
 |- parallel_n64_libretro.dll      # N64, Vulkan LLE fallback
 |- beetle_psx_hw_libretro.dll     # PS1, hardware renderer
 |- swanstation_libretro.dll       # PS1, DuckStation-derived
 |- pcsx_rearmed_libretro.dll      # PS1, ARM / handhelds
 |- lrps2_libretro.dll             # PS2, x86_64 only

The awkward middle: N64 and PS1

Nintendo 64 is where reputations go to die. The mainline core is Mupen64Plus-Next, which bundles the GLideN64 HLE renderer plus the angrylion and ParaLLEl-RDP/RSP low-level plugins, and the official documentation still lists it as the recommended default. It is the right first choice — with one asterisk. In early 2025 the core hit an upstream regression: titles such as Stunt Racer 64 and World Driver Championship stopped loading, and the community's advice became "pin the January build." If a specific game refuses to boot, that is your prime suspect. The accuracy fallback is Parallel N64, a divergent fork built around a Vulkan LLE path; its compatibility list is narrower and it lacks GLideN64, so it is a targeted tool, not a blanket replacement. If N64 matters to you, keep both cores installed and keep the working Mupen build locked. The whole saga is documented in the libretro N64 emulation status thread.

PlayStation 1 is calmer and comes down to your hardware. Beetle PSX HW (Mednafen-derived) is the accuracy champion with a hardware renderer, internal upscaling, and PGXP geometry correction — the desktop pick, and heavy; its texture-replacement path was still under active testing in May 2026. SwanStation is the DuckStation-derived libretro port, a fine balanced all-rounder. PCSX ReARMed is the featherweight ARM core that powers half the budget handheld firmwares out there — muOS, OnionOS, ROCKNIX — and is the correct answer whenever the silicon is small.

The heavy tier: PS2 and 3DS

The banner addition of the 1.21.0 era is LRPS2, a heavily modified fork of PCSX2 rebuilt for the libretro API. It ships a new ParaLLEl-GS renderer — a Vulkan/GL/D3D11-12 compute path with a software-accurate fallback — and it runs on Windows, macOS, and Linux. The hard limit, again, is architecture: LRPS2 is x86_64 only, so it is a desktop and laptop core with no ARM build. It needs a genuine PlayStation 2 BIOS, and the game-index data that used to be a loose file is now embedded in the core. For the Nintendo 3DS, the situation changed underneath everyone: Citra is dead, taken down, and its lineage now lives in Azahar, a merge of the prominent Citra forks. Azahar became a proper libretro core in its 2125.0 alpha line and has since advanced toward 2126.0; it is demanding, it dropped support for encrypted titles and the old Nintendo CDN, and it is strictly a job for capable hardware. GameCube and Wii, via the Dolphin core, track the current Dolphin stream and belong to the same "powerful desktop only" bracket.

Core Options, Remaps & Overrides

Installing cores is the easy half. Making your settings survive a menu visit is where RetroArch's layered configuration system either rewards you or humiliates you. There are three distinct mechanisms — core options, config overrides, and input remaps — and they are not the same thing, no matter how often people conflate them.

Core options versus config overrides

Core options are settings the core exposes to RetroArch: internal resolution, renderer, geometry correction, region. They live globally in retroarch-core-options.cfg and can be scoped per game to config/corename/gamename.opt. Config overrides, by contrast, are ordinary RetroArch settings — video driver, aspect ratio, shaders, audio latency — saved as a scoped .cfg that layers on top of your global retroarch.cfg. The distinction matters because they save from different menus: core options from Quick Menu, then Core Options, then Manage (create a game-options file); overrides from Quick Menu, then Overrides (save Core or Game override). Here is a real per-game core-options file for Beetle PSX HW, with the actual option keys:

# config/Beetle PSX HW/Crash Bandicoot.opt  (per-game core options)
beetle_psx_hw_renderer            = "hardware_vk"   # software | hardware_gl | hardware_vk
beetle_psx_hw_internal_resolution = "4x"           # 1x .. 16x
beetle_psx_hw_pgxp_mode           = "memory only"  # disabled | memory only | memory + CPU
beetle_psx_hw_dither_mode         = "internal resolution"
beetle_psx_hw_widescreen_hack     = "disabled"

The override precedence, in order

Overrides load from least specific to most specific, and the later ones win. The overrides documentation spells out the exact sequence: the global retroarch.cfg loads first, then the core override, then the content-directory override, then the game override on top. In other words the priority is game > content-directory > core > global. This is enormously powerful once it clicks: set aspect ratio for an entire console with a core override, tweak one folder of imports with a directory override, and fix a single misbehaving game with a game override, all without ever touching your global config. The files are named after the core, the folder, and the game respectively, and they live under the core's own config directory:

# Load order (later wins):
# 1. retroarch.cfg                              global default
# 2. CORENAME.cfg  /  CORENAME.rmp             core override
# 3. CONTENTDIR.cfg / CONTENTDIR.rmp           directory override
# 4. GAMENAME.cfg  /  GAMENAME.rmp             game override (highest priority)

config/
 |- Mupen64Plus-Next/
     |- Mupen64Plus-Next.cfg     # applies to every N64 game
     |- Nintendo 64.cfg          # applies to that content folder
     |- Super Mario 64.cfg       # applies to one game only

Remaps are their own layer

Button remaps are a third, separate system with the .rmp extension, stored under config/remaps/corename/ and scoped by core, content directory, or game exactly like config overrides. Keep them mentally distinct: a remap changes which physical button maps to which virtual button, and it is governed by auto_remaps_enable, while overrides change RetroArch settings and are governed by auto_overrides_enable. Mix them up and you will "lose" a control scheme that was actually saved to the wrong scope the entire time.

Platform Fragmentation: Steam, Apple, webOS

"Install a core" sounds like one action. It is really as many different actions as there are packaging channels, and the channels do not agree with each other. This is the least glamorous part of the RetroArch story and the one that generates the most confusion, so it is worth walking through deliberately.

Steam's hand-curated catalogue

The Steam release does not expose the full buildbot. It ships a curated, vetted subset, and the community announcements track that subset core by core: the count reached sixty after DirkSimple was added and sixty-five after Dosbox Pure — a single new core moving the whole platform total by five. That is a distribution channel deliberately capped roughly one hundred thirty-five cores below the catalogue, for review and store-policy reasons. Nothing is wrong with your install; the Steam build simply is what it is, and expecting the desktop downloader's full list there is a category error.

Apple's separate update machinery

The Apple platforms are maintained with their own tooling. The repository carries a dedicated Apple core-update script at pkg/apple/update-cores.sh, with a documented commit dated 22 May 2025, and the frontend-wide CHANGES.md shows a documented update on 8 June 2025 — both useful as a dated paper trail when you are trying to work out whether a behaviour is a bug or a deliberate 2025-era change. You can read that history yourself in the main RetroArch repository. The practical upshot: the same core can arrive on macOS, iOS, and tvOS on a different cadence than it does on the buildbot, because a separate script is doing the packaging.

ARM, webOS, and the living ecosystem

Architecture is the great fragmenter. The webosbrew rebuild of the cores reached over one hundred seventy armv7 builds, plus experimental aarch64, by December 2025 — an entire parallel core set maintained for LG's TV platform. ARM Linux, Android, and the handheld firmwares each get their own subset, which is why the PlayStation 2 core simply does not appear on ARM and why a core that runs on your desktop may be absent on your Retroid. One more operational wrinkle worth filing away: a buildbot change on 24 May 2026 replaced older core files, so installs predating that date needed a manual refresh, while anything set up afterward did not. That the ecosystem is still moving this fast is itself the reassurance — the libretro forums' Latest Cores feed shows a WindowCast core active on 5 July 2026, a "MAME .288 Core Update?" thread on 1 July 2026, Mesen activity on 3 May 2026, and Beetle PSX HW texture-replacement testing on 23 May 2026. This is a maintained, breathing project, not an abandoned one; the cost of that liveliness is exactly the fragmentation described here.

Common Pitfalls & Fixes

Every one of these has generated a thousand forum posts. None of them is mysterious once you know the cause. Read them now and skip the posts.

Version, ABI, and update-order mistakes

Pitfall: a core that worked yesterday crashes on load today. The usual cause is an ABI mismatch — you updated cores against an old frontend, or updated the frontend and left the cores stale. Fix: update the RetroArch binary from your package manager, then run Update Installed Cores, so both halves match. Pitfall: the Core Downloader is empty or shows unrecognized cores. You skipped Update Core Info Files. Fix: run it first, every time, then reopen the downloader. If the menu item itself is missing, enable Settings, User Interface, Menu Item Visibility, Show Core Downloader — and remember that the Ubuntu PPA build disables the downloader entirely, where the answer is sudo apt-get install libretro-corename.

Regressions and the wrong-core-for-the-hardware trap

Pitfall: a bulk update broke a game that used to run. Living cores regress; the N64 core's early-2025 stumble is the canonical example. Fix: lock known-good cores via Manage Cores before you run Update Installed Cores, and keep an archived copy of the working build. Pitfall: you chose a core your hardware cannot run. bsnes accuracy on a weak CPU stutters; LRPS2 will never appear on an ARM handheld because it is x86_64 only. Fix: match the core to the tier — Snes9x and PCSX ReARMed on small silicon, bsnes and Beetle PSX HW and LRPS2 on desktops.

BIOS, black screens, and settings that vanish

Pitfall: "failed to load content" on a system that needs firmware. The BIOS is missing or misnamed. Fix: place the exact file, with the exact name the core expects, in the system directory — do not zip or rename it. Pitfall: a black screen with working audio. That is a video-driver or renderer problem, not a broken core; a hardware-renderer core with the wrong video driver will do exactly this. Fix: switch the video driver (gl, glcore, or vulkan) or set the core's renderer to software and reload. Pitfall: your tuning resets every session. You saved to the global config instead of an override, or config_save_on_exit is overwriting you. Fix: save a Game or Core override and set config_save_on_exit to false so your careful global config stops rewriting itself.

Troubleshooting Table

The quick-reference version. Match the symptom, apply the fix, move on with your evening.

Symptom, cause, fix

Reading the log before you post

Before you open a forum thread, turn on logging: Settings, Logging, set the verbosity up, reproduce the failure, and read the last few lines. A core that cannot find its BIOS says so. A core that mismatches the frontend says so. A renderer that failed to initialise says so. The overwhelming majority of "help, my core is broken" reports are answered by three lines of the log the poster never looked at, and RetroArch is unusually good about telling you exactly what it could not do.

Advanced Tips

Once the basics are boring, these are the moves that separate a setup that merely works from one that keeps working through months of updates and never surprises you.

Lock cores and keep a known-good archive

Locking is the single most underused feature in RetroArch. Load a core, open the Quick Menu, and lock it; Update Installed Cores will now skip it, which turns a bulk update from a gamble into a safe operation. Pair that with a literal archive: copy the working .dll, .so, or .dylib for your critical systems into a dated folder. When a future buildbot build regresses — and the N64 history guarantees one eventually will — recovery is a file copy, not a bisection. This discipline is exactly what the pre-built distros bake in for you; a frozen RetroPie image is popular precisely because a known-good, unchanging core set is worth more to most people than the newest nightly.

Per-core directories, runahead, and latency

Turn on per-core configuration so each core keeps its own clean settings file instead of polluting a single global config; combined with the override hierarchy, this makes your setup modular and diffable. Then, on systems where it is stable, enable runahead to hide one or more frames of input latency — a genuine, measurable improvement on responsive 2D games that costs CPU headroom you probably have on the lighter cores. Keep audio latency modest, prefer a hard-GPU-sync of one frame on capable hardware, and remember that these are RetroArch settings, so they belong in overrides scoped to the cores that benefit, not smeared across the global config.

Sideloading and the command line

You are not limited to the downloader. Any correctly built libretro core can be dropped straight into the cores folder and loaded, which is how you test a bleeding-edge build or a core the downloader does not list for your platform. And because cores are just modules, you can launch them headless from a shell — useful for scripting front-ends, kiosk setups, or simply confirming a core initialises:

# Launch a specific core + content from a shell:
retroarch -L cores/mupen64plus_next_libretro.so "roms/n64/Ocarina of Time.z64"

# Ask a core to report itself with verbose logging:
retroarch -L cores/lrps2_libretro.so --verbose

One more modern convenience worth enabling: RetroAchievements support is native in current RetroArch, no third-party plugin required — sign in once and compatible cores light up automatically. It is a frontend feature riding on top of whatever core you loaded, which is a neat encapsulation of the whole architecture: the core emulates, the frontend adds everything around it.

A Complete Working Config

Here is a clean, opinionated baseline that ties the whole tutorial together: sensible directories, a buildbot pointing at nightly, per-game core options honoured, overrides loaded automatically, and — critically — the global config told not to overwrite itself on exit. Adjust the paths for your platform; the keys are the point.

The directory layout

Everything hangs off one config root. Cores in their folder, BIOS in system, saves and states separated so a cloud-sync of saves never drags a multi-gigabyte state folder along:

~/.config/retroarch/
 |- retroarch.cfg
 |- cores/                 # the *_libretro modules
 |- system/               # BIOS files, exact names
 |- saves/                # SRAM
 |- states/               # save states
 |- config/               # per-core + override .cfg / .opt
 |- config/remaps/        # per-core .rmp input remaps

The core-relevant retroarch.cfg

These are the keys that govern core loading, updating, and override behaviour — the parts of the config that this tutorial actually touches. Drop them into your retroarch.cfg and the twelve-step loop above will behave predictably every time:

# ~/.config/retroarch/retroarch.cfg  (core-relevant keys only)

libretro_directory                    = "~/.config/retroarch/cores"
libretro_info_path                    = "~/.config/retroarch/cores"
core_updater_buildbot_cores_url       = "http://buildbot.libretro.com/nightly"
core_updater_auto_extract_archive     = "true"
core_updater_show_experimental_cores  = "false"

system_directory                      = "~/.config/retroarch/system"
savefile_directory                    = "~/.config/retroarch/saves"
savestate_directory                   = "~/.config/retroarch/states"

# Make settings persist correctly:
config_save_on_exit                   = "false"   # do NOT let global config eat your tweaks
game_specific_options                 = "true"    # honor per-game .opt core options
auto_overrides_enable                 = "true"    # auto-load GAMENAME.cfg overrides
auto_remaps_enable                    = "true"    # auto-load GAMENAME.rmp input remaps

That is the whole discipline in one screen: cores and their info files in a known place, the buildbot wired up, experimental builds off by default, and the three auto_ keys plus a disabled config_save_on_exit ensuring that your per-game work loads every time and nothing silently overwrites it. Install with the twelve steps, choose cores by tier rather than by alphabet, lock the ones you cannot live without, scope your tuning into overrides, and the RetroArch that most people find baffling becomes what it was always supposed to be: one program that plays everything, and keeps playing it after the next update. If you want to go deeper on any single core's options, the libretro documentation and the project's Wikipedia entry are the honest starting points — and the forums, for all their noise, are where the regressions get caught first.