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

RetroArch is not an emulator, and the sooner that sentence stops sounding like a technicality the better your setup will run. RetroArch is a frontend: a shell that loads emulators as interchangeable plug-ins called cores. Every time someone says "RetroArch runs badly," what they usually mean is that a specific core is running badly, or that the wrong core is loaded, or that a BIOS is missing, or that one of four overlapping config layers is quietly overriding another. None of those are RetroArch's fault, and all of them are fixable once you understand what a core is and where it lives.

This tutorial covers cores end to end: the concept, the prerequisites, a twelve-step install that takes about thirty minutes, which core to pick for each system in 2026, how the override hierarchy works, and how to keep the whole thing from disintegrating the next time you update. We are working against RetroArch 1.22.2, the current stable build dated 17 November 2025. The project claims over 200 cores and says the list "keeps expanding over time." Both statements are true. Both will lie to you if you read them literally, and that is exactly where we begin.

What a Core Actually Is

The frontend and the plug-in

RetroArch is a unified frontend maintained by the Libretro team. Libretro is the API; RetroArch is the reference program that speaks it, documented in full at the official libretro documentation. When an emulator is compiled against the libretro API, it becomes a core — a single shared library (a .dll on Windows, a .so on Linux and Android, a .dylib on macOS) that surrenders its video, audio, and input to the frontend instead of drawing its own window and menus. That surrender is the entire trick. The Snes9x you might have run as a standalone program years ago and the Snes9x core you load in RetroArch share the same emulation heart; the core simply stopped caring about windows and file dialogs and let RetroArch handle them.

This is why one interface can run a Game Boy, a Neo Geo, and a Dreamcast without natively understanding any of them. RetroArch owns the shell — controller mapping, shaders, save states, rewind, run-ahead, netplay — and each core owns its machine. So your first diagnostic question, every time, is the same: is this the frontend's problem or the core's problem? A shader that tanks your framerate is the frontend. A game that renders with garbage polygons is the core. Confusing the two is how people spend a weekend changing the wrong settings.

"Over 200 cores" is a catalogue, not an inventory

The official site says RetroArch has over 200 cores and that the number keeps growing. That is the project-wide catalogue across every platform the team builds for. It is not what you will see on your device. The Core Downloader on a desktop build exposes a 100+ list organized alphabetically by system; the Steam release had only 65 cores available as of 30 April 2025, and a specific update note around that time counted 60; an ARM build such as a webOS TV package showed roughly 170 armv7 cores in late 2025. Same project, wildly different inventories, because a core only appears where someone compiled and shipped it for that CPU and OS.

So when a guide tells you RetroArch has 200-plus cores and your handheld shows 90, nobody lied. You are looking at the intersection of "cores that exist" and "cores built for your hardware." The catalogue keeps expanding — recent additions include DirkSimple for laserdisc games, b2 for the Acorn BBC Micro, and DICE for discrete-logic arcade hardware, the last two arriving with version 1.21.0 — but expansion at the project level does not mean expansion on your specific screen.

The GPLv3 economics of forks and funerals

RetroArch is free and open source under the GPLv3, and at the time of writing the main repository carried more than 13,200 GitHub stars. The license matters more than the star count, because GPLv3 is why the core ecosystem looks the way it does: anyone can fork an emulator, wrap it in libretro, and ship it, and anyone can keep a dead project alive by forking it again. That is a feature and a curse. It is why you often have three cores for one system — a fast one, an accurate one, and a portable one — and it is why cores occasionally vanish upstream and reappear under new names. Citra, the long-standing 3DS emulator, was discontinued; its libretro presence now lives on through the Azahar fork. Nothing about RetroArch stops a core from dying. The license just guarantees someone can resurrect it.

Prerequisites: Versions and Hardware

The software versions that actually matter

Pin your versions before you touch a single core. The current stable release is RetroArch 1.22.2, dated 17 November 2025 on Wikipedia and listed as the current stable build on the official download page. The prior milestone was 1.21.0, dated 29 April 2025 on the cores page and tagged 1 May 2025 in the GitHub releases — worth knowing only because cores and frontends are versioned independently, and a core built against one ABI can misbehave on another. The practical rule: keep the frontend current, then update your cores to match. On Windows the standalone build updates in one command; the Steam build updates through Steam but ships fewer cores.

# Windows (PowerShell) — the standalone build, full core catalogue
winget install Libretro.RetroArch
winget upgrade Libretro.RetroArch   # keep the frontend current

# Linux — the Flatpak build
flatpak install flathub org.libretro.RetroArch
flatpak run org.libretro.RetroArch

Hardware, tier by tier

Cores are emulators, and emulators scale with the difficulty of the machine being emulated, not with the age of the games. An 8-bit NES core is trivial. A cycle-accurate SNES core is not. Here is the honest tiering. Tier one — NES, SNES, Master System, Genesis, Game Boy, GBA, PC Engine — runs on anything, including a budget handheld like the Miyoo Mini Plus, provided you do not insist on the accuracy cores. Tier two — N64, PlayStation, Saturn, Dreamcast — wants a real CPU and a competent GPU; a modern phone or a mid-range handheld handles most of it. Tier three — PS2, GameCube, 3DS, Wii — wants a desktop-class x86_64 machine, and some of those cores do not exist for ARM at all. The PS2 core LRPS2 is x86_64-only; there is no version of it waiting in your handheld's Core Downloader, and no amount of updating will summon one.

The accuracy cores deserve a specific warning. bsnes, the gold standard for SNES accuracy, effectively wants a CPU around the 4GHz class to hold full speed with its heavier profiles. Load it on a passively cooled handheld and it will stutter, and you will blame RetroArch when the culprit is your decision to run a reference-grade emulator on a chip that was never going to keep up. Match the core to the silicon, and read the honest expectation into the marketing: "runs RetroArch" is not the same claim as "runs every core in RetroArch."

BIOS, ROM formats, and the legal housekeeping

Some cores boot on their own; many do not. Sony, Sega Saturn, and Nintendo DS cores generally want real BIOS dumps placed in the system/ directory with the correct file names and hashes, and they will refuse content — or boot to a black screen — without them. RetroArch does not ship BIOS files, for the obvious legal reason that they are copyrighted firmware; dumping them from hardware you own is your responsibility and your jurisdiction's problem, not ours. The same applies to ROMs. This tutorial assumes you have legally obtained the software you intend to run, and it will not help you obtain it otherwise. What it will do is make sure that once you have a legitimate BIOS and a legitimate dump, the core actually finds them, because "the game will not start" is more often a missing BIOS than a broken core.

Installing Cores in 12 Steps

Choosing a build before you start

Three builds, three trade-offs. The standalone desktop build (from the official RetroArch site or winget) gives you the full Core Downloader and the most cores; this is the default recommendation. The Steam build is convenient and auto-updating but sandboxed, with a smaller core list — 65 available and 60 shipped around the 1.21.0 window in April 2025 — so if a core is missing there, that is why. The Flatpak build on Linux is well maintained but keeps its files under a Flatpak path, which matters when you go hunting for the config directory later. Pick one and stay with it; mixing builds is how people end up with two config trees and no idea which one is live.

The twelve steps

1. Confirm your build and version. Open Information > System Information and verify you are on 1.22.2. Rationale: cores are matched to the frontend's ABI, and a mismatched pair is the most common source of "it loaded yesterday" failures.
2. Update Core Info Files first. Online Updater > Update Core Info Files. Rationale: the info files are the manifest that tells RetroArch what each core is, which system it serves, and what content it accepts. Skip this and the Core Downloader shows blanks and cores refuse to associate with your ROMs.
3. Update assets, databases, and controller profiles. Rationale: assets drive thumbnails and the on-screen menu; databases power playlist scanning; controller profiles auto-map your pad. None of these are cores, but all of them make cores usable.
4. Open the Core Downloader. Online Updater > Core Downloader. Rationale: this is the 100+ alphabetical, per-system list — the only supported way to fetch cores that match your platform.
5. Install exactly one core per system you own games for. Rationale: resist the urge to download all 100. Every extra core is another info file, another update, another thing to misconfigure. A focused install is a debuggable install.
6. Verify the core landed on disk. Rationale: confirm the library exists in cores/ before you blame the frontend. If the file is not there, the download failed silently — usually a network or permissions issue.
7. Load Core, then Load Content — in that order. Rationale: RetroArch loads the plug-in first, then feeds it the ROM. Loading content first works via file association but hides which core is active, which is the thing you most need to know when debugging.
8. Place BIOS files in system/ with correct hashes. Rationale: Saturn, PlayStation, and DS cores validate firmware. A wrong-region or wrong-hash BIOS produces a black screen that looks identical to a broken core but is not.
9. Set Core Options per game. Open the Quick Menu > Core Options while content runs. Rationale: this is where renderer, region, and accuracy toggles live — inside the core, not in RetroArch's global settings.
10. Save the tuning as a game override. Quick Menu > Overrides > Save Game Overrides. Rationale: this pins your settings to one title without touching everything else. More on the hierarchy below, because it is where most people lose an afternoon.
11. Set run-ahead or latency options if the hardware allows. Rationale: run-ahead removes emulated input lag, but it costs CPU; enable it only where you have headroom, and only per core.
12. Back up your config directory. Rationale: updates change savestate formats and occasionally reset options. A copy of your config tree is the difference between a five-minute restore and rebuilding everything from memory.

What success looks like

After a clean install your directory should look roughly like this, with the plug-ins in cores/ and their manifests in info/:

RetroArch/
|- retroarch.cfg              # master config
|- cores/                     # the plug-ins live here
|  |- snes9x_libretro.dll
|  |- mesen_libretro.dll
|  \- mupen64plus_next_libretro.dll
|- info/                      # core info files (the manifest)
|  |- snes9x_libretro.info
|  \- mupen64plus_next_libretro.info
|- system/                    # BIOS files go here
|  |- scph5501.bin
|  \- sega_101.bin
|- config/                    # per-core and per-game overrides
\- saves/  states/  screenshots/

And the info file that step two fetched is plain text — this is the manifest RetroArch reads to know what the core is:

# snes9x_libretro.info (excerpt)
display_name = "Nintendo - SNES / SFC (Snes9x)"
categories = "Emulator"
systemname = "Super Nintendo Entertainment System"
manufacturer = "Nintendo"
license = "Non-commercial"
display_version = "1.63"
supports_no_game = "false"

If you would rather skip the manual assembly entirely, a distribution such as a full Batocera install bundles RetroArch, its cores, and a curated config out of the box — useful context for understanding what RetroArch is doing under a friendlier menu.

Picking Cores by System

RetroArch's core choice is almost always a trade between accuracy and performance, and the "right" core depends on your hardware and your tolerance for imperfection. Here are the 2026 defaults, followed by the reasons they are defaults.

The Nintendo stack

For NES and Famicom, Mesen is the accuracy pick and it is not close; it is one of the most faithful 8-bit emulators in existence, and any machine built this decade runs it fine. For the SNES, the safe default is Snes9x — fast, compatible, and forgiving of weak hardware; reserve bsnes for desktops where you actually want cycle accuracy and have the roughly 4GHz-class CPU to feed it. For the Game Boy line and the Game Boy Advance, mGBA is the answer for GB, GBC, and GBA alike: accurate, actively maintained, and light. For Nintendo DS, melonDS is the accuracy-forward choice, though it asks more of your CPU than people expect and it wants BIOS files. Nintendo 64 is its own catastrophe, and it gets its own section below.

The Sega stack

For Master System, Game Gear, and Genesis/Mega Drive, Genesis Plus GX is the default and a genuinely excellent core — with one trap that catches people every year: it does not emulate the 32X. Load a 32X ROM into Genesis Plus GX and it simply will not boot, and nothing in the error tells you why. The fix is to use PicoDrive, which does handle 32X (and Sega CD). For the Saturn — one of the hardest consoles ever built to emulate — Beetle Saturn is the accuracy core, and it is demanding and BIOS-dependent; on weaker hardware people fall back to faster, less faithful options and accept the compromises. For the Dreamcast, Flycast is the standard and a strong one, mature enough that most of the library "just works" on mid-range hardware.

Sony and the heavy iron

The original PlayStation gives you a real choice. Beetle PSX HW is the accuracy-and-enhancement core — hardware renderer, internal resolution scaling, the works — and it wants a capable GPU; its options are documented in the Beetle PSX repository. SwanStation sits in the middle. PCSX ReARMed is the performance core built for ARM handhelds, where it is often the only thing that holds full speed. All three want a PS1 BIOS in system/ matched to your region (the SCPH-550x/750x family). The PlayStation 2 is where the road ends for most portable hardware: the LRPS2 core (a libretro port of PCSX2) is x86_64-only, pairs with the ParaLLEl-GS renderer, and will never appear in an ARM Core Downloader. If your device is ARM and you want PS2, RetroArch is not your path. For a sense of what dedicated hardware does with the harder systems, the Analogue 3D's FPGA approach to N64 and the wider MiSTer FPGA project are the accuracy-obsessed alternative to software cores entirely.

Core Options and the Override Hierarchy

Core Options and Settings are two different menus

This is the single most useful distinction in RetroArch after "frontend versus core." Settings (the main menu) are RetroArch's own — video driver, audio latency, input, shaders, directories. Core Options (Quick Menu, while content runs) belong to the loaded core — renderer choice, internal resolution, region, CPU overclock, accuracy toggles. When a guide tells you to change "internal resolution to 4x," that is a Core Option and it will not exist until a core is running. When it says "set audio latency to 64ms," that is a Setting. People burn hours looking for core options in the settings menu and settings in the core menu. They are different menus, populated by different code.

The hierarchy that bites you: game > directory > core > global

RetroArch resolves configuration through a priority stack, and understanding the order is the difference between surgical tuning and inexplicable chaos. From highest priority to lowest: a game (content) override beats a content-directory override, which beats a core override, which beats the global config. A setting saved at a higher level silently wins over the same setting saved lower. This is why a change you make "for everything" appears not to work — some game override you saved months ago is quietly outranking it. When something refuses to change, walk the stack from the top: is there a game override? A directory override? A core override? Only then is the global value in play.

# retroarch.cfg — the GLOBAL layer (lowest priority)
libretro_directory = ":\\cores"
libretro_info_path = ":\\info"
system_directory = ":\\system"
savefile_directory = ":\\saves"
savestate_directory = ":\\states"

Saving an override without poisoning global

The rule of a clean setup: keep the global config sane and generic, and push every specific tweak into an override. To pin settings to one game, run it, tune it in Core Options, then Quick Menu > Overrides > Save Game Overrides. RetroArch writes a small .cfg under config/<CoreName>/<GameName>.cfg containing only the values that differ. That file is the highest-priority layer, so it wins for that title and nothing else.

# config/Mupen64Plus-Next/Legend of Zelda, The - Ocarina of Time.cfg
# a per-GAME override — the highest-priority layer
video_scale_integer = "true"
video_smooth = "false"
mupen64plus-43screensize = "640x480"
input_player1_analog_dpad_mode = "1"

Core Options themselves live separately, in a core-options file, and can also be overridden per game. Here is the global core-options layer:

# retroarch-core-options.cfg — GLOBAL core options
mupen64plus-rdp-plugin = "parallel"
mupen64plus-rsp-plugin = "parallel"
mupen64plus-EnableFBEmulation = "True"
snes9x_overclock_cycles = "disabled"
mesen_ntsc_filter = "Disabled"

The N64 Problem

Why the "recommended" core regressed

Every setup guide, including the 2026 ones, names Mupen64Plus-Next as the N64 core, and on paper that is correct — it is the maintained, general-purpose default. In practice, N64 emulation in RetroArch went through a rough patch: the GLideN64 graphics path inside Mupen64Plus-Next regressed in early 2025, and depending on the build and the game you could hit slowdown, missing effects, or outright rendering garbage that the same core handled fine a year earlier. The N64 is notoriously hostile to emulate — its Reality Coprocessor is a microcode nightmare — so a regression in one renderer ripples across dozens of games, each of which used the hardware slightly differently.

ParaLLEl, Angrylion, and the accuracy tax

The fix, when Mupen64Plus-Next misbehaves, is to change its renderer plug-ins rather than abandon the core. Switching the RDP and RSP plug-ins to ParaLLEl gives you a low-level, highly accurate rendering path — the ParaLLEl-RDP renderer is the closest software cores get to real hardware — at the cost of demanding a stronger GPU. The even-more-accurate Angrylion path is a pure software rasterizer that will run correctly on almost anything and quickly on almost nothing; it is the reference you reach for when you need to know what a frame is supposed to look like. This is the accuracy tax in miniature: the more faithful the renderer, the more silicon it demands, and the N64 makes you pay it more visibly than any other system.

# N64 core options — force the accurate ParaLLEl path
mupen64plus-rdp-plugin = "parallel"
mupen64plus-rsp-plugin = "parallel"
mupen64plus-ParallelRdpUpscaling = "2x"
mupen64plus-ParallelRdpSynchronous = "True"

The forum that never closes the thread

If you want proof that this is unsettled rather than solved, look at the official libretro forum. The cores category's Core and Feature Requests thread stood at 880 replies and 129,782 views as of 22 June 2026, and a thread bluntly titled "N64 emulation status in RetroArch" was still active on 2 January 2026. People do not keep a six-year argument running about a solved problem. If you want to file or track a regression like the GLideN64 one, the RetroArch GitHub repository is where the code and the issue tracker live. N64 in software remains the one system where the "recommended core" and the "core that works for your specific game on your specific hardware" are frequently not the same thing, which is why purpose-built FPGA hardware like the Analogue 3D exists at all.

Common Pitfalls and Fixes

The five that catch everyone

These are the failure modes that account for most first-week frustration, in rough order of frequency:

1. Skipping "Update Core Info Files." Do it first, before the Core Downloader. Without the manifests, cores download but show blank names, refuse to associate with ROMs, and generally behave as if the install is broken. It is not broken; it is unlabeled.
2. Downloading all 100+ cores "to be safe." This is the opposite of safe. Every core is another update to track and another way to load the wrong plug-in. Install one per system you actually play and add more only when you need them.
3. Reading "200+ cores" as a promise about your device. It is a project catalogue. Your device shows what was built for its CPU and OS — 100-ish on desktop, ~65 on Steam, ~170 on some ARM builds. A missing core usually means "not built for you," not "download failed."
4. Running the accuracy core on weak hardware, then blaming RetroArch. bsnes on a handheld, Beetle Saturn on a phone, ParaLLEl-RDP on an integrated GPU — all will stutter, and none of it is a RetroArch bug. Match the core to the silicon.
5. Saving options to global when you meant one game. The override hierarchy is game > directory > core > global. Tune in Core Options, then save a game override, or you will wonder why every system inherited a setting you meant for one title.

The BIOS traps

BIOS problems masquerade as core problems because the symptom is identical: a black screen or a "failed to load content" error. Three specifics catch people repeatedly. First, wrong location: BIOS files go in system/, not next to the ROM. Second, wrong hash: cores validate firmware, and a re-dumped or patched BIOS with the wrong checksum is treated as no BIOS at all. Third, wrong region: a PlayStation core handed a Japanese SCPH-5500 BIOS while loading a US game may boot to black; match the BIOS to the content's region. When a game that should work does not, check the BIOS before you touch the core.

The "I updated and now nothing works" trap

Updates are the other reliable source of grief. A core that changes its savestate format between versions will refuse to load your old states, and there is no fix except keeping the old core build — which is why portable, in-game SRAM saves beat save states for anything you care about long-term. Updates can also reset or migrate core options. This is the entire argument for step twelve: back up your config directory before you update, so that "the update broke it" is a restore rather than a reconstruction. If you run RetroArch on a handheld such as a Retroid Pocket or a budget device running custom firmware, this matters double, because those builds update on their own schedules and do not always ask first.

Troubleshooting Table

How to read the table

The pattern across almost every RetroArch failure is that the symptom is generic and the cause is specific. A black screen can be a missing BIOS, a wrong-region BIOS, an incompatible core, or a bad renderer setting — four causes, one symptom. The table below maps the common symptoms to their most likely causes and the fix that resolves each in the majority of cases. Work top to bottom; the earlier rows are the more frequent culprits.

Symptoms, causes, and fixes

Symptom	Likely cause	Fix
Cores show blank names or "No items" under Load Core	Core info files never updated	Online Updater > Update Core Info Files, then restart RetroArch
"Failed to load content"	Missing BIOS or a ROM format the core rejects	Put the correct BIOS (right hash) in system/; check the core's accepted formats in its docs
Black screen, audio only	Wrong-region BIOS or wrong renderer	Match BIOS region; for PS1 use the SCPH-550x/750x file for your region
N64 games run at half speed or render garbage	Mupen64Plus-Next GLideN64 regression	Set the RDP/RSP plug-ins to ParaLLEl, or fall back to Angrylion for reference accuracy
SNES slowdown or audio crackle on a handheld	bsnes accuracy core exceeds the CPU (~4GHz class)	Switch to the Snes9x core
A core you want is absent from the Core Downloader	Not built for your platform/CPU	Confirm your architecture; LRPS2 is x86_64-only, so use a desktop or build it manually
32X games will not boot in Genesis Plus GX	That core has no 32X support	Use the PicoDrive core
Save states break after an update	The core changed its savestate format	Keep the old core build; prefer in-game SRAM saves for portability
Overrides appear to do nothing	Saved to the wrong layer, or not saved at all	Respect game > directory > core > global; save via Quick Menu > Overrides
Controller dead in one core only	Missing autoconfig or wrong analog/d-pad mode	Update Controller Profiles; set analog-to-d-pad mode in that core's options
3DS core (Citra) has disappeared	Citra was discontinued upstream	Install the Azahar core instead

Advanced Tips

Run-ahead: buying back input latency

Emulated systems add input lag on top of your display's lag, partly because the original hardware itself had a frame or two of latency baked in. Run-ahead is RetroArch's answer: it runs the core one or more frames into the future, keeps the audio and video from the "present," and re-simulates when your input lands, effectively cancelling internal lag. It is close to magic and it is not free — it runs the core multiple times per frame, so it wants CPU headroom, and the second-instance mode wants a deterministic core. Enable it per core, start at one frame, and back off if you hear audio artifacts or see the framerate drop.

# run-ahead — enable per core, only with CPU headroom
run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"   # needs a deterministic core
run_ahead_hide_warnings = "false"

Manual core installs and nightly builds

When a core is missing from your Core Downloader, or you need a fix that has not reached stable, you can install a core by hand. The libretro buildbot publishes per-platform core archives; download the matching .dll/.so/.dylib, drop it into cores/, drop its .info file into info/, and restart. The catch is that a hand-placed core with no matching info file will load but will not scan content into playlists or report its capabilities correctly — the info file is not optional, it is the manifest. Nightly cores can also outrun your frontend's ABI; if a manually installed core crashes on load, an ABI mismatch with your 1.22.2 build is the first suspect.

# manual core install (Linux example)
# 1. fetch the core from the libretro buildbot
# 2. place the library and its info file
cp flycast_libretro.so   ~/.config/retroarch/cores/
cp flycast_libretro.info ~/.config/retroarch/info/
# 3. restart RetroArch; verify under Load Core

Per-core and per-content overrides at scale

Once you run more than a handful of systems, treat overrides as a filing system rather than a series of one-off saves. Use core overrides for settings that should apply to every game on a system — a renderer choice for all PS1 titles, an aspect ratio for all Genesis games — and reserve game overrides for the exceptions. Because the hierarchy resolves game over directory over core over global, you can set a sane core-wide default and then override only the three games that need something different, without duplicating settings across your whole library. This is also the maintainable way to handle a large collection on a device you will re-flash: the override files are small, portable text, and copying the config/ tree carries your entire tuning to the next install.

A Complete Working Configuration

The philosophy: global sane, overrides specific

A configuration you can maintain follows one rule: the global config should be boring and correct, and everything opinionated should live in an override. The global layer sets your directories, a conservative video and audio baseline, and nothing system-specific. Per-core overrides then handle renderer and aspect choices for each system, and per-game overrides handle the handful of titles with special needs. If you ever have to explain your setup — or rebuild it — the boring-global rule is what makes that possible.

The configuration

Here is a complete, working global retroarch.cfg skeleton in that spirit — directories first, then a safe video/audio/latency baseline. Adjust the drivers to your platform; the structure is what matters.

# ---- retroarch.cfg : global baseline ----
# directories (the plumbing)
libretro_directory = ":\\cores"
libretro_info_path = ":\\info"
system_directory = ":\\system"
savefile_directory = ":\\saves"
savestate_directory = ":\\states"
screenshot_directory = ":\\screenshots"
core_options_path = ":\\retroarch-core-options.cfg"

# video (conservative, platform-agnostic)
video_driver = "glcore"
video_vsync = "true"
video_fullscreen = "true"
video_scale_integer = "false"
video_smooth = "false"
aspect_ratio_index = "22"          # core-provided aspect

# audio
audio_driver = "wasapi"
audio_latency = "64"
audio_sync = "true"

# input / latency (global default; run-ahead lives per core)
input_poll_type_behavior = "0"      # early polling, lowest lag
run_ahead_enabled = "false"

# updater / logging
core_updater_auto_extract_archive = "true"
log_verbosity = "false"

Pair that global file with a per-core override for each system and a per-game override for the exceptions, and you have a setup that survives updates and re-flashes. The complete picture is three small files per tuned game at most: the global retroarch.cfg, a config/<Core>/<Core>.cfg core override, and a config/<Core>/<Game>.cfg game override.

Backing it up and reading the source of truth

Copy the entire config/ directory plus retroarch.cfg and retroarch-core-options.cfg somewhere safe before every frontend update; that trio is your whole configuration. When a setting's behaviour is unclear, go to the source rather than guessing — the libretro documentation covers core options and directory behaviour, the RetroArch repository holds the code and the issue tracker where regressions like the N64 one get filed, and Wikipedia's RetroArch article tracks the version history if you need to cross-check a release date. RetroArch is not an emulator. It is the most powerful and most confusing shell in the hobby, and once the cores underneath it make sense, it is also the best.