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

RetroArch advertises "over 200 cores." You will never see two hundred of anything in your Core Downloader, and the first time you go hunting for the missing half you will decide the app is broken. It is not broken. That number is a catalogue — every emulator, game engine, and media player the libretro project has ever compiled, across every platform it has ever targeted — and your particular device is entitled to a subset of it. A Windows x86_64 box gets the fat list. An ARM handheld gets a leaner one. A webOS television gets whatever the webosbrew maintainers last rebuilt, which as of December 2025 was roughly 170 armv7 cores plus a handful of experimental aarch64 ones.

This guide closes the gap between the marketing number and a working system. It covers, in order: what a core is at the binary level; the exact versions and hardware you need in mid-2026; a twelve-step download procedure with the one step nobody performs; which core to actually pick for each console, because the bundled defaults are frequently wrong; the override hierarchy that silently eats your settings; and a complete configuration you can copy. RetroArch is GPLv3, free, and carries north of 13,200 stars on GitHub. None of your problems will be money. All of them will be menus.

What a Core Actually Is

A dynamic library that speaks libretro

A core is a shared library — .dll on Windows, .so on Linux and Android, .dylib on macOS — that implements the libretro API. That API is a small, stable contract: RetroArch hands the core a ROM and a chunk of memory, calls retro_run() sixty-odd times a second, and the core hands back one frame of video, one slice of audio, and a description of the input it expects. RetroArch itself emulates nothing. It is the frontend: the menu, the shader pipeline, the netplay stack, the RetroAchievements client, the input autoconfiguration. Every actual console is somebody else's emulator, wrapped to speak libretro. This separation is the whole point. It is also the source of every piece of confusion you are about to have, because "install a core" and "install an emulator" are the same sentence and people use them interchangeably until the day the distinction matters.

Why "200+ cores" is a catalogue, not an inventory

The libretro buildbot compiles each core for every platform it supports and every CPU architecture within that platform. Your Core Downloader queries the buildbot for exactly one of those slices — say, windows/x86_64 — and shows you what exists there. The catalogue figure counts the union of all slices, plus cores that only ever built for one obscure target. So the honest translation of "200+ cores" is "the project has, cumulatively, shipped more than two hundred distinct cores across its history and its platforms." What you get is bounded by your hardware. This is not a bug to be worked around; it is the correct behaviour of a cross-platform build system, and any tutorial that promises you literally two hundred working systems on a phone is lying to you. If you want the widest possible list, run RetroArch on a 64-bit desktop. If you are on an ARM handheld, budget for a real but smaller number and read the per-system section below before you get attached to PlayStation 2.

Cores versus emulators versus frontends

Three words, three layers, and the retro forums use all three loosely. The frontend is RetroArch. The core is the libretro build of an emulator — Beetle PSX HW, Mesen, Snes9x. The upstream emulator is the standalone project the core is derived from — Mednafen, Mesen, snes9x — which usually also ships as its own application with its own GUI. A core generally lags its standalone parent, because someone has to port each upstream change across the libretro boundary. That lag is why you will sometimes hear "use the standalone" for cutting-edge systems, and why the interesting 2025–2026 story in this hobby is a handful of cores catching their standalones back up. Hardware purists skip the entire stack and put the logic on an FPGA instead; if that is your temperament, the MiSTer Multisystem 2 is the current object of desire, and it is a genuinely different set of trade-offs from software cores — cycle-accurate, latency-minimal, and far more expensive per system.

Prerequisites & Versions

Software: which RetroArch, exactly

Use the 1.22 line. The current stable as of mid-2026 is RetroArch 1.22.2, released 20 November 2025. Do not install 1.22.0 if you can help it: that build shipped a shader regression that produced a black screen on some configurations, and it was fixed across 1.22.1 and 1.22.2. The prior milestone worth knowing is 1.21.0 (29 April 2025), which brought the Apple Vulkan work, CoreMIDI, and a batch of 3DS fixes. Version matters here for one specific reason that most people learn the hard way: a core built against a newer libretro API than your frontend will refuse to load with an "unrecognized" error. Keeping RetroArch current is not cosmetic — it is the precondition for the cores loading at all. Confirm your version from Main Menu → Information → System Information, or on Linux from a shell:

# Linux / Steam Deck — confirm the frontend version
retroarch --version

# expected output (yours should be 1.22.x or newer):
# RetroArch 1.22.2 (Git 1a2b3c4)
# Built: Nov 20 2025

Hardware: the honest floor per tier

Emulation cost scales with the accuracy of the core, not the age of the console, and this trips people constantly. A cycle-accurate Super Nintendo core is heavier than a fast Nintendo 64 core. Concretely: bsnes in its accuracy profile wants a CPU in the neighbourhood of 4 GHz single-thread to hold full speed, because it emulates the SNES at the cycle level. A PlayStation 1 core like Beetle PSX HW is comfortable on a modern desktop but punishing on a phone. The LRPS2 PlayStation 2 core is x86_64-only — there is no ARM build, full stop — so no amount of prerequisites will conjure PS2 onto a Snapdragon handheld through this core. If your target is an ARM device, assume the light cores (Snes9x, mGBA, Genesis Plus GX, PCSX ReARMed) and treat anything sixth-generation as a maybe. For a sense of where the ARM ceiling sits in 2026, the current Retroid Pocket lineup is a useful yardstick; the cheapest units run the 8- and 16-bit cores flawlessly and start sweating exactly where you would expect.

What you assemble before Step 1

Three things. Storage: cores themselves are small (single-digit to low-tens of megabytes each), but the info-file manifest, thumbnails, and shader packs add up; leave a couple of gigabytes free. BIOS files: several cores will not run without the original console firmware — PlayStation, PlayStation 2, Sega CD, and others expect specific files, by exact filename and often exact hash, dropped into RetroArch's system/ directory. RetroArch does not and will not distribute these; that is your problem to source legally from hardware you own. Content: your ROMs and disc images, which are likewise your legal responsibility. The Machine will not lecture you about dumping your own cartridges, but it will point out that a "failed to load content" error is far more often a missing BIOS than a bad core, and you will save yourself an hour by getting the firmware right before you start blaming the emulator.

Install It, Then Update Info Files First

Installing per platform

Install from the package manager your platform blesses, not from a random mirror. The official channels are Steam, the platform stores, and the buildbot; on the desktop the one-liners are:

# Windows (winget)
winget install Libretro.RetroArch
winget upgrade Libretro.RetroArch

# Linux / Steam Deck (Flatpak, from Flathub)
flatpak install flathub org.libretro.RetroArch
flatpak update org.libretro.RetroArch

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

Avoid the SEO-farm "download RetroArch 2026" pages that clutter search results — several are ad wrappers and at least one domain in that space (tech-insider.org) recycles fabricated version numbers. The canonical downloads live at retroarch.com and the release notes at github.com/libretro/RetroArch/releases. If you would rather not manage any of this by hand, a distribution like Batocera bundles RetroArch with a curated core set and sane defaults, and RetroPie does the same on the Raspberry Pi — though RetroPie has been frozen at v4.8 since 2022, so its bundled cores are older than what you would pull fresh from the buildbot.

The one step everyone skips: Update Core Info Files

This is the single most important instruction in the entire guide, so it gets its own paragraph. Before you open the Core Downloader, go to Main Menu → Online Updater and run Update Core Info Files first. The info files are the manifest — the list of which cores exist, what systems they emulate, what file extensions they accept, and what BIOS they require. If that manifest is stale or missing, one of two things happens: the Core Downloader shows an empty or truncated list, or cores you download "fail to load" and appear "unrecognized" because RetroArch has no metadata to match them against. Ninety percent of the "my Core Downloader is empty" threads on the libretro forums are this and only this. Run Update Core Info Files, then run Update Installed Cores if you already have some, and the phantom problems evaporate.

Making the Core Downloader visible

On a fresh install the Core Downloader entry is sometimes hidden, depending on your menu driver and whether you are in a restricted "kiosk" layout. If Load Core → Download a Core is not where you expect it, un-hide it explicitly:

Settings
  -> User Interface
    -> Menu Item Visibility
      -> Show Core Downloader   [ON]

The same menu governs whether the Online Updater, the thumbnail updater, and the other network features appear at all. This visibility toggle is the reason two people running the same version see different menus, and it is worth knowing exists before you conclude your build is missing features.

The 12-Step Core Download

Steps 1–4: manifest, updater, list, choice

1. Update Core Info Files. Online Updater → Update Core Info Files. Rationale: this is the manifest, covered above; without it the next three steps misbehave. It takes a few seconds and downloads a small metadata bundle, not the cores themselves.
2. Open the Online Updater and note the buildbot. Every core you fetch comes from the libretro nightly buildbot. Rationale: knowing where the bytes originate matters the day a stable core breaks and you need to grab a specific dated build by hand, which the advanced section covers.
3. Open the Core Downloader. Main Menu → Load Core → Download a Core. Rationale: this is the per-platform, per-architecture list — what your device can actually run. If it is empty, you skipped Step 1; go back.
4. Pick the correct core for the system, not the first one alphabetically. Rationale: several systems have three or four cores with very different accuracy and performance profiles, and the alphabetically-first is rarely the right default. The per-system table further down exists specifically for this step.

Steps 5–8: fetch, load, verify, save

5. Download the core. Select it; RetroArch fetches the compressed core and unpacks it into your cores/ directory. Rationale: nothing is installed system-wide — cores are self-contained files, which is why backing up that one folder backs up your whole core set.
6. Load content with the core. Load Content, browse to a ROM, and when prompted pick the core you just downloaded. Rationale: this both tests the core and creates the association RetroArch uses to auto-suggest the same core next time for that file type.
7. Verify it actually launched. You want a running game, not just a returned menu. Rationale: a core that loads its library but fails on content almost always means a missing BIOS or a wrong-region/format ROM — diagnose it now, at the point of a single known-good game, not later across a whole library.
8. Check the log if it did not launch. Settings → Logging → set Logging Verbosity to Debug, reload, and read the on-screen log or the log file. Rationale: the log names the missing BIOS file or the rejected extension explicitly, which turns a guessing game into a two-minute fix.

Steps 9–12: tune, refresh, override, back up

9. Set the core's options. In-game, Quick Menu → Core Options. Rationale: defaults are conservative; this is where you raise internal resolution, pick a renderer, or enable a compatibility hack. Change one thing at a time so you can tell which setting fixed or broke something.
10. Keep everything current with Update Installed Cores. Online Updater → Update Installed Cores. Rationale: this refreshes every core you own in a single pass against the latest buildbot builds, which is how you pick up bug fixes without re-downloading each core by hand.
11. Save your settings as an override, not to the global config. Quick Menu → Overrides → Save Core Overrides (or Game Overrides). Rationale: this writes a small per-core or per-game file instead of mutating your master config, so a setting that helps one game does not silently apply to all of them. The hierarchy section explains why this distinction is load-bearing.
12. Back up your cores and config directories. Copy cores/ and config/ somewhere safe. Rationale: a bad Update Installed Cores or a corrupted config is trivially recoverable from a folder copy, and it costs you nothing to have it before it costs you an evening not to.

Expected result after the twelve steps: a Core Downloader that lists your platform's full slice, at least one game confirmed running, and a per-core override saved. On a mid-range desktop the whole procedure — including one game per system you care about — runs about forty minutes, most of it spent deciding which cores you want rather than waiting on downloads.

Picking a Core per System

The heavy hitters: N64, PS1, PS2

Nintendo 64. The recommended default is Mupen64Plus-Next, which bundles the GLideN64 high-level renderer plus the angrylion software renderer and the ParaLLEl-RDP/RSP low-level plugins — one core, several accuracy levels. The official docs name it the recommended core, and for most of the library it is correct. But be warned: it regressed in early 2025, and a couple of titles — Stunt Racer 64 and World Driver Championship among them — stopped loading. The community workaround is to pin an older nightly, or to switch to ParalleN64 (Vulkan LLE) for those specific games, accepting its narrower compatibility elsewhere. N64 is the system where "just use the default" fails most often.

PlayStation 1. Three cores, three temperaments. Beetle PSX HW (Mednafen-derived, hardware renderer) is the most accurate and the heaviest — the desktop choice, with PGXP to straighten out the console's infamous wobbling polygons. SwanStation is the DuckStation-derived libretro port, a strong middle option. PCSX ReARMed is the lightweight ARM-optimized core that powers essentially every budget handheld — muOS, ROCKNIX, OnionOS — because it runs PS1 at full speed on hardware that would choke on Beetle. This is exactly the core doing the work on a device like the Miyoo Mini Plus, and it is the reason those sub-$100 units play PlayStation at all.

PlayStation 2. The 2025–2026 headline. LRPS2 is a hard fork of PCSX2 built for libretro; in the project's own words it is "a heavily modified version of PCSX2 custom made for the Libretro API, and it currently runs on Windows, macOS and Linux." Its centerpiece is a new renderer: "By far the star of the show is paraLLEl-GS... a brand new renderer made by Themaister written entirely as a compute program," aiming to match software-renderer accuracy on the GPU. Read the constraint carefully, because it is absolute — per the Libretro announcement, the core "is available for Windows, Linux (x86_64), and MacOS. It is NOT available for Android or iOS, nor for ARM Linux." It needs a real PS2 BIOS; the GameIndex compatibility data is now embedded in the core. LRPS2 landed in the downloader alongside the 1.22 line in November 2025.

The 8- and 16-bit tier: the cores that just work

This is the drama-free zone. NES: Mesen — PPU-accurate, exhaustive mapper support, a built-in debugger, and the current accuracy king. SNES: bsnes in its accuracy profile if your CPU can take the ~4 GHz hit, otherwise Snes9x, which is the sensible handheld default and correct for the overwhelming majority of the library. Game Boy / Game Boy Color: Gambatte or mGBA. Game Boy Advance: mGBA, unambiguously — accurate, fast, and actively maintained. Sega Genesis / Mega Drive: Genesis Plus GX, which covers Mega Drive, Sega CD, Master System, Game Gear, SG-1000, and the Pico at essentially 100% — a former Wii homebrew emulator that grew into one of the most complete cores in the project. On Android specifically, the Core Downloader steers you to PicoDrive for Genesis, which is the lighter option. Arcade: Final Burn Neo (FBNeo), whose romset support reaches back into the 1970s and which the RetroBat frontend was still bumping to fresh builds — a 22 April 2026 build in that case — well into this year.

The awkward cases: 32X, 3DS, GameCube/Wii

Three systems that break the pattern. Sega 32X: Genesis Plus GX does not emulate it — use PicoDrive, which does. People lose an evening to this because GPGX is otherwise so complete that they assume it covers the 32X too. Nintendo 3DS: the old Citra core is dead — the project was taken down — and the successor is Azahar, a merge of the prominent Citra forks (PabloMK7's among them). Azahar shipped its first official libretro core in 2125.0 Alpha 4, building for six operating systems (Linux, Windows, macOS, Android, iOS, tvOS); the line has since advanced toward 2126.0 in release-candidate form through mid-2026. Note that it dropped support for encrypted games and the old Nintendo CDN path in favour of the Artic Setup Tool, and the libretro binaries are now stripped, which shrinks the Android core. Until the full 2125.0 stable lands, you may need the nightly buildbot to get the core; releases live at github.com/azahar-emu/azahar. GameCube / Wii: the Dolphin core exists and was matched to the standalone Dolphin stream as of October 2025, but Dolphin is one of the systems where the standalone typically leads the core; for demanding titles, keep the standalone in your back pocket. The full compatibility rundown lives in the libretro core list.

Core Options & the Override Hierarchy

The precedence order that decides who wins

RetroArch layers configuration from general to specific, and the more specific layer wins. The precedence, highest to lowest, is game → content-directory → core → global. In practice: your global retroarch.cfg is the base; a per-core override adjusts it for everything that core runs; a per-content-directory override narrows that to one folder; and a per-game override is the final word for a single title. RetroArch loads them in that outward-to-inward order, each one overwriting the keys the previous layer set. Once this model is in your head, the entire configuration system stops being mysterious: a setting that "won't stick" is almost always a more-specific override quietly winning, or your global config being rewritten on exit and clobbering what you thought you saved.

Where the files actually live

Overrides and options are separate systems with separate files, which is the second source of confusion. General overrides (video, audio, input driver, and so on) live under config/; per-core core options — the emulator-specific toggles like internal resolution — live in their own files. The layout:

# --- General overrides (video/audio/input) ---
config/<core>/<core>.cfg          # per-core override
config/<core>/<content-dir>.cfg   # per-content-directory override
config/<core>/<rom-name>.cfg      # per-game override (most specific)

# --- Core options (emulator-specific toggles) ---
retroarch-core-options.cfg          # global core options for every core
config/<core>/<rom-name>.opt        # per-game core options

# --- Input remaps (controller layout) ---
config/remaps/<core>/<core>.rmp     # per-core remap
config/remaps/<core>/<rom-name>.rmp # per-game remap

The naming uses the core's display name and the ROM's filename verbatim, which is why a renamed ROM "loses" its per-game settings — the filename is the key. The authoritative reference is the libretro overrides guide; when in doubt, it is correct and this paragraph is a summary.

Saving overrides without nuking your global config

The mechanics from the menu: after you change core options or driver settings in-game, use Quick Menu → Overrides → Save Core Overrides or Save Game Overrides to write a scoped .cfg; for core options specifically, Quick Menu → Core Options → Manage Core Options → Create game-options file writes the per-game .opt. The single most important global setting in this whole discussion is config_save_on_exit. If it is true, RetroArch rewrites your master retroarch.cfg every time you quit, folding in whatever was on screen — which will happily overwrite a carefully-built config with a stray change. Set it to false and save deliberately via the override menus. The relevant keys, for when you edit the config by hand:

# retroarch.cfg — the keys that govern overrides
config_save_on_exit    = "false"   # do NOT auto-rewrite the master config
auto_overrides_enable  = "true"    # auto-load matching .cfg overrides
auto_remaps_enable     = "true"    # auto-load matching .rmp remaps
game_specific_options  = "true"    # auto-load matching per-game .opt files

Five Pitfalls That Waste an Afternoon

Manifest, catalogue, and BIOS mistakes

1. Skipping Update Core Info Files. The symptom is an empty Core Downloader or cores that download and then "fail to load" as "unrecognized." The fix is one menu entry, run first, every time — Online Updater → Update Core Info Files. If you take one thing from this guide, take this.
2. Expecting the whole 200+ catalogue on ARM. The catalogue is cross-platform; your device gets a slice. A missing core on a phone or handheld usually is not missing — it was never built for that architecture. Confirm against the platform's actual list before assuming a fault; the webosbrew number of ~170 armv7 cores is a realistic ARM ceiling, not 200.
3. Loading LRPS2 without a BIOS, or on ARM at all. LRPS2 needs a genuine PlayStation 2 BIOS in system/, and it does not exist for ARM. "My PS2 core is gone" on a handheld is not a bug; there is no build. On the desktop, "failed to load" is almost always the absent BIOS.

Configuration self-sabotage

4. Letting config_save_on_exit clobber your overrides. With it enabled, every quit rewrites the master config and can erase a scoped setting you thought was saved. Set it false, save overrides explicitly, and the "my settings keep resetting" problem disappears.
5. Chasing accuracy your CPU cannot run. Selecting bsnes accuracy on a handheld, or Beetle PSX HW at 8x internal resolution on a phone, produces stutter that people then misdiagnose as a broken core. Match the core to the silicon: Snes9x and PCSX ReARMed exist precisely for hardware that bsnes and Beetle will bury.

Bonus pitfall. Treating "200+ cores" as "200+ working systems on my device," then treating every gap as a defect. It is the same misunderstanding as pitfall two, wearing a different hat, and it generates more forum noise than any genuine bug. The catalogue is a ceiling for the project, not a promise to your hardware.

Troubleshooting Table

Symptom, cause, fix

Most core problems reduce to one of a dozen recurring causes. Find your symptom, apply the fix, and only then escalate to a forum. The table is ordered roughly by how often each one is the actual answer.

Reading the log when the table runs out

When none of the above fits, turn on verbose logging (Settings → Logging → Logging Verbosity → Debug), reproduce the failure, and read what the core prints at load time. It will name the specific missing file, the rejected extension, or the API mismatch in plain text. The log converts "it doesn't work" — a sentence a forum cannot help with — into "it wants scph39001.bin and I gave it scph5501.bin," which you can fix in thirty seconds. Verbose logging is the difference between debugging and guessing.

Advanced: Buildbot, PPAs, Achievements

Grabbing a specific build from the nightly buildbot

When a stable core regresses — as Mupen64Plus-Next did in early 2025 — the fix is to sidestep the downloader and pull a dated build directly from the nightly buildbot. Every core RetroArch offers originates there, organized by platform and architecture, and you can download an individual core zip, extract the library, and drop it into your cores/ directory by hand. This is also how you bisect a regression: grab builds from before and after the break to find the one that changed behaviour. A note for anyone who installed before 24 May 2026 — a buildbot change on that date replaced older core files, so a manual refresh (or a plain Update Installed Cores) is worth running once; installs made after that date need nothing special.

# Nightly cores, browsable by platform/arch:
#   http://buildbot.libretro.com/nightly/windows/x86_64/latest/
#   http://buildbot.libretro.com/nightly/linux/x86_64/latest/
#
# Manual install of a single core:
#   1. download <core>_libretro.dll.zip
#   2. extract <core>_libretro.dll
#   3. drop it into:  <retroarch>/cores/
#   4. Load Core -> the file now appears alongside downloaded cores

Installing individual cores from the Ubuntu PPA

On Debian and Ubuntu you can bypass the in-app downloader entirely and manage cores as system packages from the Libretro PPA. This is handy for scripted or headless setups, and for keeping cores under the same apt update umbrella as everything else on the box:

# Ubuntu / Debian — cores as apt packages
sudo add-apt-repository ppa:libretro/stable
sudo apt-get update

# install specific cores by name
sudo apt-get install libretro-mupen64plus-next \
                     libretro-mgba \
                     libretro-genesisplusgx

# expected: three libretro-* packages resolve and install to the
# system core directory, visible in RetroArch after a rescan

Per-game options, remaps, and native RetroAchievements

Three power features worth wiring up once. Per-game core options: Quick Menu → Core Options → Manage Core Options → Create game-options file writes a .opt that binds settings to a single title — 8x internal resolution for the pre-rendered-background games, native for everything else, and no compromise applied library-wide. Per-game remaps: saved under config/remaps/, these let a single game use a different button layout without touching your global controls — essential for the odd title that expects an unusual pad. RetroAchievements: it is built into RetroArch natively — no third-party plugin, unlike some standalone emulators — so Settings → Achievements, log in, and it works across every supported core. Enable hardcore mode only if you want savestates and rewind disabled in exchange for the leaderboard-eligible version, which is a genuine trade, not a formality.

A Complete Working Configuration

A sane retroarch.cfg baseline

Here is a starting retroarch.cfg excerpt that encodes every decision this guide argued for: Vulkan video, the override system fully armed, and — critically — automatic config rewriting turned off so your deliberate saves survive. Merge these keys into your existing file rather than replacing it wholesale; the file has hundreds of keys and you only want to set these.

# ~/.config/retroarch/retroarch.cfg  (excerpt — merge, do not replace)

# --- Drivers ---
video_driver           = "vulkan"
menu_driver            = "ozone"

# --- Updater / buildbot ---
core_updater_buildbot_url        = "http://buildbot.libretro.com/nightly"
core_updater_auto_extract_archive = "true"

# --- Override system (the whole point) ---
config_save_on_exit    = "false"   # never auto-clobber this file
auto_overrides_enable  = "true"
auto_remaps_enable     = "true"
game_specific_options  = "true"

# --- Convenience ---
savestate_auto_save    = "false"
cheevos_enable         = "true"    # native RetroAchievements
log_verbosity          = "false"   # flip to true only when debugging

A per-core override for Beetle PSX HW

PlayStation 1, done properly on the desktop: the Vulkan hardware renderer, a 4x internal resolution as a sensible default, and PGXP in "memory only" mode to correct the wobbling geometry without the heavier CPU-side correction. These are the real core-option keys — beetle_psx_hw_renderer, _internal_resolution, _pgxp_mode, _dither_mode, _widescreen_hack — so this maps one-to-one onto what you set in the Core Options menu.

# Quick Menu -> Core Options  (Beetle PSX HW), or as a saved .opt file
beetle_psx_hw_renderer            = "hardware_vk"   # Vulkan HW renderer
beetle_psx_hw_internal_resolution = "4x"            # ~4x native
beetle_psx_hw_pgxp_mode           = "memory only"   # straighten polygons
beetle_psx_hw_dither_mode         = "internal resolution"
beetle_psx_hw_widescreen_hack     = "disabled"      # on only for 3D-only games

A per-game options file, and where it goes

Finally, the most specific layer: a per-game .opt that overrides the core defaults for exactly one title. Say a pre-rendered-background RPG that benefits from a higher internal resolution than you would push library-wide. RetroArch keys the file on the ROM's filename, so the name must match your content exactly.

# config/Beetle PSX HW/Final Fantasy VII (USA).opt
beetle_psx_hw_renderer            = "hardware_vk"
beetle_psx_hw_internal_resolution = "8x"            # crisper than the 4x default
beetle_psx_hw_pgxp_mode           = "memory only"
beetle_psx_hw_widescreen_hack     = "disabled"

That is the entire system: a global baseline, a per-core override, and a per-game file that wins over both. Cores are free, the frontend is free, and once the manifest is current and config_save_on_exit is off, RetroArch stops fighting you. The two hundred number was always a catalogue. What you build from it is an inventory — one you chose, per system, on purpose. If your target hardware is a handheld rather than a desktop, take the per-system picks here and cross-reference them against the current Retroid Pocket models before you commit to a core; the right choice on x86_64 is frequently the wrong one on ARM, and knowing which is which is the difference between a library that runs and a folder of "failed to load."