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

RetroArch ships with nothing. No SNES core, no PlayStation core, not one line of emulation logic in the box. The first time you launch it the menu is a beautiful, empty cathedral, and a sizeable fraction of the people who download it conclude the thing is broken and crawl back to standalone emulators inside the hour. That is the design, not the defect. RetroArch is a frontend — a shell, a UI, an input and video and audio plumbing layer — and the actual emulators are separate plugins called cores. You bring the engines. The frontend just runs them.

This is the single most important fact about the entire ecosystem, and it is the one that the breezy “just download RetroArch” tutorials skip. Once you internalise it, the rest of the system stops looking like a maze of menus and starts looking like what it is: a remarkably disciplined piece of software that does one thing — load a core, hand it content, and get out of the way. As of early 2026 the libretro framework officially supports over 200 cores, a number that grows on the buildbot more or less daily. This guide installs them properly, picks the right one per system, and shows you where every setting actually lives on disk. Budget thirty minutes. Bring your own ROMs and your own conscience.

What a Core Actually Is

Before you touch a menu, understand the contract. A core is not “a setting” and it is not “a theme.” It is a compiled shared library — a .dll on Windows, a .so on Linux and Android, a .dylib on macOS — that implements a fixed C API called libretro. The frontend dlopen()s that file, calls a handful of well-defined functions, and the core paints frames into a buffer the frontend then displays. That is the whole magic trick, and it is worth dwelling on because almost every problem later in this guide is really a problem with one half of that handshake.

The libretro API contract

libretro is deliberately small. A core promises to implement functions like retro_init, retro_load_game, retro_run (called once per frame), and retro_get_system_av_info, and in return the frontend promises to feed it input, take its video and audio, and handle the tedious cross-platform misery of windows, controllers, and audio drivers. Because the contract is fixed, the same Genesis Plus GX core binary behaves identically whether the frontend is RetroArch on a Steam Deck or something else entirely. The emulator author writes the emulator once; the frontend authors solve platform plumbing once; nobody reinvents the other half. This division of labour is the entire reason the project can support 200-plus systems with a small team, and it is the part the standalone-emulator crowd genuinely gives up when they install yet another bespoke window with its own half-finished settings menu.

Why the frontend ships empty

RetroArch contains zero pre-installed cores by design, and you must pull them yourself via the Core Downloader after the first install. There are two honest reasons for this. The first is licensing: cores carry a zoo of licenses — GPLv2, GPLv3, the non-commercial Mednafen-derived terms, and a few that simply cannot be bundled into a single redistributable build without lawyers getting involved. Ship them all in one binary and you have manufactured a license conflict. The second reason is size and sanity. Nobody emulating the SNES needs the Vectrex core sitting on disk. Shipping empty lets you take exactly the 5 or the 50 cores you actually use, and no more. For scale, the webosbrew project's December 2025 rebuild of its retroarch-cores repository bundled 173 distinct cores for armv7 webOS, 52 of them freshly compiled for that platform — and that is a curated platform-specific subset, not the full library. The full library is bigger.

200+ cores and counting

The official count sits north of 200 and moves upward. New systems get cores; old cores get forked, renamed, and superseded — the lore is littered with the corpses of abandoned forks and the cores that ate their lunch. The mechanism that keeps this sane is that the buildbot recompiles every core for every supported platform on a rolling basis, and the frontend downloads those binaries on demand. The practical upshot, covered in detail below, is that you almost never reinstall RetroArch to get a newer emulator. You update the core. The frontend and the cores have separate release cadences, and confusing the two is the source of half the support threads on the internet — people reinstalling a 200-megabyte frontend to fetch a bugfix that lived in a one-megabyte core all along.

Prerequisites: Versions & BIOS

You need three things sorted before the first download: a current frontend build, hardware that matches your ambitions, and — for several systems — BIOS files that RetroArch will never, ever provide for you. Skip any of these and the steps later will fail in ways that look mysterious but are not. This section is the boring part that prevents the frustrating part.

Software versions

Install the latest stable RetroArch from retroarch.com or your platform's store, and then immediately do the one thing the installer will not: update the core info files (Step 4 below). Do not chase a specific frontend version number for the sake of cores — because cores update independently through the Online Updater, a clean current stable build is all you need. The trap is the reverse: an ancient frontend build whose ABI no longer matches today's cores, which then refuse to load with an error that blames the core when the frontend is the stale party. If your RetroArch is more than a year old, update the frontend first, then the cores, in that order.

Minimum software baseline (2026):
  RetroArch     : latest stable for your OS (Win/macOS/Linux/Android/console)
  Core info     : updated AFTER first launch (Online Updater)
  Visual C++    : latest x64 redistributable (Windows only)
  GPU drivers   : current Vulkan-capable drivers strongly recommended
  Disk space    : ~2 GB for a sane multi-system core set + assets

Hardware requirements per tier

“Can it run RetroArch” is the wrong question. Anything can run the frontend; a potato can run the frontend. The real question is whether your hardware can run the accurate cores, because accuracy costs cycles and the most accurate core for a system is frequently the most demanding one. Three rough tiers, and you should know which one you are in before you download anything:

• Low power (ARM handhelds, single-board computers): Snes9x, Genesis Plus GX, gambatte, PCSX ReARMed. These are the speed-first cores. A device like the Miyoo Mini Plus running Onion OS lives almost entirely in this tier and is perfectly happy there — its whole curation philosophy is built around cores that sip CPU.
• Mid power (modern ARM SoCs, older x86): Beetle PSX (software renderer), Final Burn Neo, mGBA, and the mednafen-family cores up through Saturn with some effort. A handheld like the Retroid Pocket 6, which is PS2-capable, sits squarely here and reaches into the next tier on a good day.
• High power (desktop x86, Apple Silicon, Steam Deck-class): BSNES, Beetle PSX HW with internal upscaling, FlyCast at high internal resolution, the cycle-accurate everything. This is the tier where accuracy stops being a compromise and starts being free.

BIOS files and the legal line

Here is the law, stated plainly, because The Machine has read the statute. RetroArch does not ship console BIOS images and never will — they are copyrighted firmware, and redistributing them is infringement, full stop, no “abandonware” carve-out that holds up. Cores like Beetle PSX (PlayStation), FlyCast (Dreamcast), and several others require the original system BIOS to boot, and they expect those files in your system directory with exact filenames and exact checksums. There is no legitimate download for these; the lawful path is to dump them from hardware you own. The same applies to the games themselves: dumping a cartridge or disc you physically own is one matter, and acquiring ROMs you do not is another, and this guide is about the software, not your alibi. The libretro documentation lists the required BIOS filenames and MD5 hashes per core, and they are not suggestions — a one-byte-wrong BIOS produces a black screen and zero useful error text, which is precisely the kind of failure that costs an evening.

The Install: 14 Steps

Fourteen steps, each with the reason it exists, because a step without a rationale is just superstition handed down from forum to forum. Do them in order the first time. After that you will internalise the shape and skip straight to the Core Downloader, which is the only step you repeat.

Steps 1–5: Set the foundation

1. Confirm your build and version. Open Settings > Information > System Information and note the build date and architecture (e.g. x86_64). Rationale: cores are ABI-matched to the frontend and the platform. A 64-bit core will not load into a 32-bit frontend, and a wildly stale frontend will reject current cores with the infamous “Failed to load libretro core.” You verify here so you do not debug it at midnight later.
2. Set your directories before anything else. Settings > Directory. Define where cores, system (BIOS), saves, save states, and config live. Rationale: RetroArch will happily scatter files across five default locations and then act surprised it cannot find your BIOS. Pin the directories now and every later step lands where you expect it to.
3. Point the core directory at a writable location and confirm permissions. Rationale: on Windows under Program Files, on locked-down Android, and on read-only console filesystems, the Core Downloader will appear to work and then silently fail to write the binary. A writable core directory is the entire difference between “downloaded” and “downloaded and actually present on disk.”
4. Update the core info files first. Online Updater > Update Core Info Files. Rationale: the Core Downloader list and every core's display name, supported extensions, and required BIOS are read from these info files. Stale info files mean cores show up mislabeled, missing, or with the wrong system associations. This is the single most-skipped step and the cause of nine out of ten “my core is not in the list” complaints.
5. Update assets, databases, and controller profiles. Online Updater > Update Assets, Update Databases, Update Controller Profiles. Rationale: thumbnails, playlist scanning, and automatic controller mapping all depend on these. Do it once now and the cosmetic and input layers stop fighting you for the rest of the install.

Steps 6–10: Download and verify cores

6. Open the Core Downloader. Load Core > Download a Core. Rationale: this is the canonical, signed source — it pulls from the official buildbot over the configured URL. Downloading core binaries from random forums or file lockers is how you get an ABI mismatch, a stale build, or something genuinely malicious. You must manually download cores here because, as established, the default build contains none.
7. Search and filter for your system. In the 2026 menu you can type a system name — “SNES,” “Super Famicom,” “PlayStation” — and press Start to filter the list. Rationale: with 200-plus entries, scrolling the whole list is a punishment. Filtering by system variant surfaces exactly the cores that claim support for what you intend to emulate.
8. Download the recommended core per system — not all of them. One, maybe two cores per system. Rationale: hoarding all 200 cores wastes space and, worse, leaves you with three SNES cores and no memory of which one you meant to use. Pick by the accuracy-vs-performance logic in the next section and download deliberately, like an adult.
9. Place BIOS files in the system directory. Drop the required, correctly-named, correctly-hashed BIOS images into the system folder you set in Step 2. Rationale: Beetle PSX, FlyCast, and friends check for these at content load. Wrong name or wrong hash equals a black screen with no explanation. Verify against the libretro docs before you blame the core, the ROM, or your eyesight.
10. Load the core manually once to confirm it initialises. Load Core > pick the freshly downloaded core. Rationale: this validates the ABI and any runtime dependencies (Windows VC++ redistributable, GPU drivers) before you involve content. If it loads clean, the core is good; if it fails here, you have isolated the problem to the core or its runtime, not the ROM, and saved yourself a false lead.

Steps 11–14: Load content and maintain

11. Load content and let RetroArch associate the core. Load Content > pick a ROM > choose the core when prompted. Rationale: the first time you run a given ROM with a given core, RetroArch records the association and builds a playlist entry. Subsequent launches skip the core-picker entirely. This is also where a wrong association gets baked in, so choose carefully the first time.
12. Set core options. In-game, open the Quick Menu > Core Options. Rationale: this is where the per-core knobs live — internal resolution, region, BIOS selection, software vs hardware renderer. The defaults are conservative on purpose; the good stuff is one menu down and switched off until you ask for it.
13. Save a core override or input remap. Quick Menu > Overrides > Save Core Overrides (or Save Game Overrides); Quick Menu > Controls > Save Core Remap File. Rationale: overrides persist your changes without rewriting the global config. This is the difference between “PS1 uses the analog stick” and “I just broke the controls for every other system I own.” Overrides are scoped; the global config is not.
14. Run Update Cores periodically. Online Updater > Update Installed Cores. Rationale: cores improve independently of the frontend. You do not need a new RetroArch version (v3.0, v3.1, whatever) to get the latest emulator revision — Update Installed Cores pulls fresh buildbot binaries for everything you already have. Do this monthly, or whenever a core misbehaves; an old core is a common, invisible cause of a “new” bug.

Expected output. After Step 1, System Information should read something close to this — the build date and the architecture are the two lines that actually matter:

-- System Information --
Build date            : Jun  5 2026
Git version           : 1a2b3c4
CPU Features          : SSE4.2 AVX2
Current video driver  : vulkan
Frontend identifier   : RetroArch
Frontend architecture : x86_64

And after Step 10, a clean manual core load writes something like this to the log (Settings > Logging > enable verbose logging, or watch the console on desktop):

[INFO] [Core]: Loading dynamic library: "cores/bsnes_libretro.dll"
[INFO] [Core]: Version of libretro API: 1
[INFO] [Core]: Compiled against API: 1
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
[INFO] [Core]: Geometry: 256x224, Aspect: 1.306.
[INFO] Content loading skipped. Implementation will load it on its own.

If instead you see [ERROR] Failed to open libretro core or a complaint about a missing symbol, stop here and resolve it before loading content — that is an ABI or runtime problem, and no ROM will fix it.

Choosing Cores Per System

This is where opinions live, and where the “just download everything” crowd quietly costs you frame rate and accuracy without noticing. Every mature system has at least two cores: a speed core and an accuracy core. Choosing between them is the only real decision in this entire guide, and it is worth making on purpose.

The accuracy-vs-performance axis

Accuracy means the core reproduces the original hardware's behaviour — timing, quirks, bugs and all — rather than approximating it and hoping for the best. The more accurate the core, the more CPU it burns, because faithfully simulating a 1990 console on a 2026 CPU is a fight against the original chip's parallelism and the games that abused it. On a desktop you can afford perfection. On a handheld you cannot, and pretending otherwise just gives you stutter and a worse experience than the honest approximation would have. The honest move is to match the core to the hardware tier from the prerequisites, not to install the “best” one out of pride and then wonder why Star Fox crawls. XDA's 2026 accuracy roundup tracks the current consensus picks; the lore behind each of them is below, because a recommendation without history is just a list.

System-by-system picks

The 2026 consensus, with the reasoning that the listicles leave out:

System	Accuracy pick	Speed pick	The reasoning
SNES / Super Famicom	BSNES	Snes9x	BSNES — the descendant of byuu's accuracy-obsessed bsnes/higan lineage — is the most accurate option in 2026 but demands meaningfully more CPU than Snes9x. On weak hardware, Snes9x is the right call and nobody should feel bad about it.
Sega Genesis / Mega Drive	Genesis Plus GX	Genesis Plus GX	The recommended standard for 2026 — Eke-Eke's enhanced fork balances accuracy and performance and also covers Master System, Game Gear, SG-1000 and Sega CD, so one core handles a whole family of Sega and non-Genesis titles.
PlayStation 1	Beetle PSX	PCSX ReARMed	Beetle PSX (libretro's fork of Mednafen's PSX) is the primary, most accurate PS1 choice in 2026, with a HW variant for upscaling. ReARMed exists precisely because Beetle is too heavy for low-power ARM.
Sega Dreamcast	FlyCast	FlyCast	The default and most accurate Dreamcast core in 2026, descended from the Reicast/nullDC line. Needs the Dreamcast BIOS in your system directory or it simply will not boot.
Arcade	Final Burn Neo	Final Burn Neo	FBNeo is the most accurate arcade core for RetroArch in 2026, with superior compatibility over the abandoned Final Burn Alpha it forked from after the community drama. MAME is more complete but heavier and far pickier about ROM sets.

Note the pattern: in two cases — Genesis and Dreamcast — the accuracy pick is the performance pick, because the cores are well-optimised and the systems are within easy reach of modern hardware. That is the ideal state, and it is why those two columns collapse into one. SNES and PS1 still force the trade-off, and arcade depends entirely on which board you are running.

The Amiga exception

The Amiga deserves its own warning because it breaks the “just pick a core” rule in a way that will waste your afternoon if you do not know about it in advance. In the 2026 cycle the Amiga core carries a known bug: save states and rewind are disabled unless you use ADF disk images instead of WHD (WHDLoad) sets. WHDLoad integration works with the newer core in the 2025–2026 cycle for running games, but state-saving remains incompatible until a future patch. If your library is WHD and you cannot live without save states, convert to ADF or wait. This is the kind of footgun that sends people in circles — the core works, the game runs, and the one feature you want is greyed out for a reason that has nothing to do with your config and everything to do with the file format you happened to acquire.

Config Files & Overrides

Everything you set in the menu is written to plain text on disk. Knowing where, and in what hierarchy, turns RetroArch from a black box into something you can read, back up, and version-control. There are three layers, and they stack in a specific, predictable order.

retroarch.cfg anatomy

The master config is retroarch.cfg. It lives in the config directory (Settings > Directory tells you where; on Windows it is typically alongside the executable, on Linux under ~/.config/retroarch/). It is a flat list of key = "value" lines, no nesting, no sections. The directory keys are the ones worth knowing by hand, because fixing a scattered install is faster in a text editor than clicking through menus one folder at a time:

# retroarch.cfg — the directory block that matters most
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/cores"
system_directory = "~/.config/retroarch/system"
savefile_directory = "~/.config/retroarch/saves"
savestate_directory = "~/.config/retroarch/states"
rgui_config_directory = "~/.config/retroarch/config"
video_driver = "vulkan"
menu_driver = "ozone"
menu_show_advanced_settings = "true"

One iron rule: never edit retroarch.cfg while RetroArch is running. The frontend holds the config in memory and rewrites the entire file on a clean exit, silently discarding your hand edits as if they never happened. Quit first, edit, then relaunch. This single rule prevents more lost-work confusion than any other in the program.

Per-core and per-game overrides

The reason overrides exist is that the global config is global — change the aspect ratio there and you have changed it for every system you own. Overrides let you scope a setting to a single core, or to a single game, without touching the global file. They load after the global config and win any conflict. The hierarchy, lowest to highest priority:

• Global — retroarch.cfg, applies to everything.
• Core override — config/[core name]/[core name].cfg, applies whenever that core runs.
• Game override — config/[core name]/[game name].cfg, applies to one specific ROM and nothing else.

You create these from Quick Menu > Overrides while the game is running. A core override for Beetle PSX might contain only the handful of lines that differ from global — RetroArch is smart enough to write only the deltas, not the whole config, which keeps the override readable:

# config/Beetle PSX HW/Beetle PSX HW.cfg
# Only the keys that differ from global live here.
video_aspect_ratio_auto = "true"
input_libretro_device_p1 = "517"
run_ahead_enabled = "true"
run_ahead_frames = "1"

Core options files

Distinct from overrides are core options — the renderer, region, and BIOS knobs from Step 12. These are stored separately, in config/[core name]/[core name].opt (or in a single global retroarch-core-options.cfg on older layouts). The split matters: overrides are frontend settings (video, input, latency), while .opt files hold settings the core itself exposes. A Beetle PSX options file reads like the emulator's own preferences, because that is exactly what it is — RetroArch is just storing them on the core's behalf:

# config/Beetle PSX HW/Beetle PSX HW.opt
beetle_psx_hw_renderer = "vulkan"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_pgxp_mode = "memory only"
beetle_psx_hw_dither_mode = "internal resolution"
beetle_psx_hw_widescreen_hack = "disabled"

Run-Ahead & Latency

Emulation adds input lag that the original hardware never had — the unavoidable cost of running a frame-based simulation on top of a modern OS, display pipeline, and driver stack. RetroArch's answer is Run-Ahead, and it is genuinely one of the best features in the entire frontend. Used correctly it can make an emulated game feel snappier than the original console did on a CRT, which is a strange and wonderful thing to be able to say about software.

What Run-Ahead does

Most games take one or more frames to react to a button press internally — the input is read, but the visible response is queued for a later frame by the game's own logic. Run-Ahead exploits the fact that emulation is deterministic and re-runnable. It runs the emulator forward by one or more frames, finds the frame where your input actually produces a visible change, displays that frame now, then rewinds the internal state and continues from where it was. The result is that the lag baked into the game's own logic is hidden from you. Run-Ahead is compatible with all 2026 RetroArch cores and can shave up to 2 frames of input lag on supported hardware. RetroGameCorps' starter guide remains the clearest plain-English walkthrough of why this works if you want the long version.

Setting it up

It lives in Quick Menu > Latency, in-game. Enable Run-Ahead, set the number of frames to hide (start at 1, raise until controls feel instant or graphics begin to glitch), and — if your hardware can take it — enable the second instance, which runs a hidden copy of the core to avoid audio artifacts at the cost of roughly doubling CPU load:

# Run-Ahead block (global, or scoped in a per-core override)
run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"
run_ahead_hide_warnings = "false"

When it breaks

Run-Ahead is not free and not universal in practice, even though every core technically supports it. Three failure modes to know about: First, cost — single-instance Run-Ahead runs the core twice per displayed frame, so a heavy core like Beetle PSX HW at 4x internal resolution on a mid-tier handheld may drop below full speed the moment you enable it. Second, frame count too high — push past the game's actual internal lag and you get visual glitches or “negative lag” artifacts where the screen appears to react before it should. Third, cores with their own internal frame buffering can confuse the heuristic and produce judder. The fix for all three is the same triage: lower the frame count first, and if performance still suffers, disable the secondary instance before you disable Run-Ahead entirely. One frame of single-instance Run-Ahead is better than none.

Common Pitfalls

These are the mistakes that cost people the most time, ranked roughly by how often they happen in the wild. None of them produce a useful error message, which is exactly why they are worth enumerating in advance instead of discovering one at a time.

Hoarding, wrong sources, and live edits

Pitfall 1 — Downloading all 200-plus cores. It feels thorough. It is the opposite of useful. You end up with three cores per system, no memory of which one you chose, and a Load Core list you have to scroll through every single time. Fix: install one accuracy core and, where relevant, one speed core per system you actually play. That is typically 8 to 15 cores total, not 200.

Pitfall 2 — Getting cores from anywhere but the buildbot. Random forum mirrors and “modded” core packs are how you get ABI mismatches, stale builds, and the occasional genuinely malicious binary. Fix: use Online Updater and the Core Downloader exclusively. If a core is not on the buildbot for your platform, that is information, not an invitation to go hunting on a sketchy file host.

Pitfall 3 — Editing retroarch.cfg while RetroArch is open. Covered above and worth repeating because it eats hours: the frontend overwrites the file on exit and your edits vanish without a trace. Fix: quit, edit, relaunch — or just use the menu and let the frontend write the file itself.

BIOS, region, and the override trap

Pitfall 4 — Wrong or misnamed BIOS. A BIOS with the wrong MD5, or the right file under the wrong name, produces a silent black screen with no diagnostic. Fix: check the required filename and hash in the libretro docs for that specific core, and confirm the file sits in the system_directory you set in Step 2 — not next to the ROM, not in the core folder, not in Downloads.

Pitfall 5 — Editing the global config per-game. You tweak the aspect ratio for one widescreen-hacked game directly in the global config, and now every 4:3 system you own is stretched and wrong. Fix: use Quick Menu > Overrides > Save Game Override. Scope the change to the one game it belongs to and leave everything else alone.

Pitfall 6 — Assuming the newest or most-accurate core is always right. BSNES is more accurate than Snes9x and will also bring a Raspberry Pi to its knees. Fix: match the core to the hardware tier. Accuracy you cannot run at full speed is strictly worse than an approximation you can.

Pitfall 7 — Forgetting that cores and frontend update separately. People reinstall the entire frontend chasing a core bugfix that a ten-second Update Installed Cores would have delivered. Fix: when a core misbehaves, update the core first. Reinstalling RetroArch is almost never the answer, and it is never the first thing to try.

Troubleshooting Table

Symptom on the left, cause and fix on the right. Most of these trace back to one of the pitfalls above, but the symptoms rarely announce their cause, so here is the lookup table you bookmark and come back to.

Before you blame the core

Two reflexes solve a surprising share of problems before you ever reach the table. First, run Update Core Info Files and then Update Installed Cores — a stale info file or an old binary is invisible and explains an unreasonable number of “sudden” failures. Second, enable verbose logging (Settings > Logging) so the frontend tells you which half of the handshake actually broke instead of failing in dignified silence.

The symptom lookup table

Symptom	Likely cause	Fix
“Failed to load libretro core”	ABI mismatch or missing runtime	Update Core Info Files, redownload the core matching your build's architecture; on Windows install the latest VC++ x64 redistributable.
Black screen, no error (PS1 / Dreamcast)	Missing or wrong-hash BIOS	Verify BIOS filename and MD5 against the libretro docs; place it in system_directory, not beside the ROM.
Core not in the Core Downloader list	Stale core info files	Online Updater > Update Core Info Files, then reopen the downloader.
Download “succeeds” but core is absent	Read-only core directory	Move libretro_directory to a writable path; fix the folder permissions.
Audio crackle / stutter	VSync vs audio-sync conflict, or wrong video driver	Switch video_driver to vulkan or glcore; enable threaded video; verify GPU drivers.
Noticeable input lag	No latency reduction enabled	Quick Menu > Latency > enable Run-Ahead, set frames to 1 then 2.
Save states greyed out (Amiga)	WHD / WHDLoad content format	Convert the set to ADF disk images; WHD save states are unsupported pending a patch.
Wrong aspect ratio / tiny image	Core-provided aspect ratio overridden	Settings > Video > Scaling > Aspect Ratio = Core provided; then save a core override.
Playlist launches the wrong core	Bad core association cached	Quick Menu > set or reset the core association for that playlist entry.
Shaders refuse to load	Shader format mismatched to driver	Use .slangp shaders with Vulkan / glcore, .glslp with the legacy gl driver.

When nothing in the table fits

Rename your config directory and let RetroArch regenerate a clean retroarch.cfg on the next launch — if the problem vanishes, a bad setting was the culprit and you can reintroduce your overrides one at a time. If it persists with a virgin config and a freshly downloaded core, you have found an actual core bug worth reporting upstream on the project's GitHub, not a configuration error you can fix from the menu.

Advanced Tips

Once the basics hold, these are the moves that separate a working install from a good one. None are necessary; all are worth knowing the day you need them.

Manual core installation

When the buildbot does not have a core for your platform, or you have compiled one yourself, you can install it by hand. A libretro core is just a shared library plus its .info file; drop both into your core directory and RetroArch finds them on the next launch. The info file is what gives the core a human-readable name and its system associations, so do not skip it — a core without its info file shows up as a raw filename and refuses to associate with playlists:

# Manual core install (Linux example)
cd ~/.config/retroarch/cores
# core binary + its info file, both required
cp /path/to/genesis_plus_gx_libretro.so .
cp /path/to/genesis_plus_gx_libretro.info .
# verify RetroArch can see both halves
ls -la *_libretro.so *_libretro.info

Expected result: the core appears under Load Core with its proper name (“Sega - MS/GG/MD/CD (Genesis Plus GX)”) rather than as a bare filename. If it shows the filename instead, the .info file is missing, misnamed, or unreadable — fix that before doing anything else.

Cores in other frontends

Because libretro is a published API, the same core binaries run in frontends that are not RetroArch at all. EmulationStation lists installed libretro cores under its “Alternative Emulators” settings, letting you pick a core per system without ever opening the RetroArch UI. Distros built on this idea — most prominently Batocera, which bundles a curated core set out of the box — are really just opinionated libretro frontends with the directory and BIOS plumbing pre-solved for you. If you have followed this guide, you already understand their internals better than their own setup wizards bother to explain. The same is true of the broader install-to-USB distro world covered in our Batocera 4.3 walkthrough — under the friendly menus, it is cores all the way down.

Buildbot, nightlies, and the FPGA alternative

For bleeding-edge fixes, the buildbot serves nightly core builds alongside the stable ones — useful when a bug was fixed last week and you do not want to wait for it to roll into the default channel. Point core_updater_buildbot_url at the nightly path only if you accept that nightlies can also regress without warning. And for the purists: software emulation, however accurate, is still software running on a general-purpose CPU. The FPGA world — hardware that reimplements the original chips at the gate level, as in the MiSTer Multisystem 2 — sidesteps the accuracy-vs-performance trade-off entirely by not emulating at all. It is more expensive, more limited in library, and it is the only thing that genuinely beats a well-configured BSNES on latency. Know that it exists; most people do not need it, and saying so is not a sin.

The Complete Config

The reference retroarch.cfg

Here is a complete, working retroarch.cfg skeleton that encodes every decision in this guide: pinned directories, a Vulkan video path, the Ozone menu, advanced settings exposed, and a sane global Run-Ahead default that per-core overrides can relax for the heavy cores. Adjust the paths to your platform, drop it in your config directory while RetroArch is closed, and relaunch.

# ===== retroarch.cfg — STARESBACK reference config (2026) =====
# Directories — pin everything so nothing scatters
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/cores"
system_directory = "~/.config/retroarch/system"
savefile_directory = "~/.config/retroarch/saves"
savestate_directory = "~/.config/retroarch/states"
rgui_config_directory = "~/.config/retroarch/config"
content_database_path = "~/.config/retroarch/database/rdb"

# Video — Vulkan first, fall back to glcore if your GPU dislikes it
video_driver = "vulkan"
video_fullscreen = "true"
video_vsync = "true"
video_threaded = "false"
video_aspect_ratio_auto = "true"
video_scale_integer = "false"

# Audio
audio_driver = "alsa"
audio_sync = "true"
audio_latency = "64"

# Menu — Ozone, with the advanced knobs visible
menu_driver = "ozone"
menu_show_advanced_settings = "true"

# Latency — global Run-Ahead default (override per heavy core)
run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"
run_ahead_hide_warnings = "false"

# Rewind — off globally (costs performance); enable per-core if wanted
rewind_enable = "false"
rewind_buffer_size = "20971520"

# Updater — point at the official buildbot
core_updater_buildbot_url = "http://buildbot.libretro.com/nightly"
core_updater_buildbot_assets_url = "http://buildbot.libretro.com/assets/"
core_updater_auto_extract_archive = "true"

# Overrides and remaps load automatically on top of this
auto_overrides_enable = "true"
auto_remaps_enable = "true"
game_specific_options = "true"
# ===== end =====

The whole system in six sentences

That is the whole system. RetroArch is empty on purpose, cores are the emulators, the buildbot is the only source you should trust, accuracy costs cycles, overrides keep your global config clean, and the frontend updates separately from the cores it runs. Internalise those six sentences and the 200-plus cores stop being a menu to fear and start being a toolbox to use. The lore is deep and the law is real, but the workflow itself is short: set your directories, update the info files, download deliberately, place your BIOS, and let Run-Ahead do the rest. For the canonical reference when this guide runs out, the libretro documentation and the RetroArch source on GitHub are the only two links you will ever actually need to bookmark.