RetroArch Cores 2026: Install 200+ in 12 Steps

RetroArch does not emulate anything. Read that again, because it is the single fact that explains every confused forum thread you have ever skimmed. RetroArch is a frontend, a shell, a chrome-plated lobby. The emulation happens inside cores: dynamically loadable modules that each implement one game engine, one console, or one media program through a shared contract called the Libretro API. As of 2026 the official library lists over 200 of them, and platform-specific repositories push the real number far higher. The frontend you downloaded knows how to draw menus and read controllers. It knows nothing about the Super Nintendo until you hand it a core that does.

This tutorial is about acquiring, choosing, and configuring those cores without the trial-and-error that consumes most people's first weekend. We will install RetroArch, update the scaffolding that cores depend on, download cores the correct way and in the correct order, pick the right module for each system instead of the first one alphabetically, and then strip out the input lag that makes modern emulation feel worse than the cartridge did in 1994. There are twelve numbered steps in the middle, a troubleshooting table near the end, and a complete working configuration you can paste. If you want the short version, you do not, so keep reading.

What A Core Actually Is

The Libretro contract

Libretro is an API, not a program. It defines a small set of functions that a core must expose and the frontend must call: initialize, load a game, run exactly one frame, report video and audio, accept input, deinitialize. Any frontend that implements the Libretro API can load any core that implements it, as long as the lifecycle is honored properly. That is the entire trick. The 2026 documentation hammers this point because it is the reason a single core file runs identically under RetroArch on a desktop, under a Lakka box, or inside a third-party launcher you have never heard of. The core does not know or care which frontend is driving it.

Mechanically, a core is a shared library. On Linux and Android it is a .so file, on Windows a .dll, on macOS a .dylib. RetroArch loads it at runtime with the platform's dynamic linker, resolves the Libretro symbols, and starts the lifecycle. Because cores are loaded dynamically rather than baked into the binary, you download only what you use, you update a single emulator without reinstalling the application, and you can run a forty-megabyte build that grows core by core instead of a gigabyte monolith.

Cores are not all emulators

Most cores emulate hardware, but the API does not require it. There are cores that run game engines directly: a Doom core that executes the original game logic, a Cave Story core, a ScummVM core that drives dozens of adventure games. There are media cores that turn RetroArch into a video player. There are even cores that are functionally tech demos. When you browse the downloader and wonder why there is something called 2048 sitting next to a Saturn emulator, this is why. The Libretro API treats them all as the same kind of object, which is elegant and occasionally baffling.

Why the count keeps climbing

The official RetroArch and Libretro ecosystem advertises over 200 cores and the number is not static. New emulators get adapted to the API regularly, and the libretro fork of an upstream emulator is sometimes the most actively maintained version that emulator has. Platform forks balloon the total further. The webosbrew/retroarch-cores repository carried over 170 cores compiled for WebOS armv7 as of December 2025, a single-platform expansion that would have been unthinkable a few years earlier. The point is that "200 cores" is a floor, not a ceiling, and the right number for you is somewhere between eight and fifteen.

Prerequisites: Versions And Hardware

Software you need

Get RetroArch from an official channel. The desktop builds come from the project's own download page; the Android build belongs on the Play Store or the official site, not on a sideloaded mirror that bundles a pre-loaded ROM set. The current 1.x series is what these instructions assume. Anything labeled 1.16 or newer behaves the same way for the purposes of this guide; the menu paths described here are stable across the recent releases. If you are on a handheld running a custom distribution, your RetroArch is bundled and updated by the distro maintainer, which changes some of the update steps below in ways the troubleshooting section addresses.

Minimum software baseline for this tutorial:

  RetroArch        1.16 or newer (desktop, Android, or distro-bundled)
  GPU driver       Vulkan-capable on desktop/Android, or GL 3.x fallback
  Storage          2 GB free for cores, info, assets, shaders, databases
  Network          required for Online Updater (cores are not bundled)
  BIOS files       per-system, user-supplied (PSX, Saturn, etc.)

Hardware reality check

Cores are not equal in their appetite. A Game Boy core runs on a potato. A cycle-accurate SNES core does not. BSNES is identified across 2025 and 2026 technical analyses as a high-power-demand emulator precisely because it is cycle-exact, and it is explicitly called unsuitable for weaker hardware and older mobile devices. Beetle PSX HW wants a real GPU once you start upscaling. Saturn and N64 are still where budget hardware goes to stutter. If you are buying a device specifically to run the heavy cores, the spread between tiers is large enough that we wrote about it at length in the Retroid Pocket 6 review, and the generational jump it represents is the subject of the Pocket 6 versus Pocket 5 comparison.

Rough core-to-hardware tiers (2026):

  Tier 1  NES, SNES (Snes9x), GB/GBC/GBA, Genesis, SMS
          runs on anything, including $90 handhelds
  Tier 2  SNES (BSNES), PS1 (Beetle PSX HW), N64 (Mupen64Plus-Next)
          needs a recent flagship handheld or any modern PC
  Tier 3  Saturn (Beetle Saturn), Dreamcast (Flycast at scale)
          desktop-class CPU/GPU or you will feel it

BIOS and the legal posture

Several systems require BIOS or firmware images that RetroArch does not and will not distribute. PlayStation, Saturn, and a handful of others will refuse to boot, or will boot in a degraded high-level mode, without the correct files in your system directory. The Machine is not your lawyer, but the position is simple: you are responsible for the legality of every BIOS image and every ROM you load, the emulator authors are not, and dumping firmware from hardware you own is a different legal question than downloading a set someone uploaded. Put the files where RetroArch expects them, named exactly as the core info file specifies, and move on.

Installing RetroArch The Right Way

Pick the correct build for your platform

The most common installation mistake is choosing the wrong architecture. On Windows, the 64-bit build is what you want unless you have a specific reason otherwise; a 64-bit core will not load into a 32-bit frontend and the error message is not helpful about it. On Android, the package handles the ABI for you, but if you sideload a core manually you must match it to your device's ABI, which is arm64-v8a on essentially every phone made in the last several years. On Linux, the Flatpak and the distro package put their directories in different places, which matters the first time you go looking for your config file.

# Linux, Flatpak install (recommended for predictable paths)
flatpak install flathub org.libretro.RetroArch

# Config and core locations under Flatpak:
~/.var/app/org.libretro.RetroArch/config/retroarch/retroarch.cfg
~/.var/app/org.libretro.RetroArch/config/retroarch/cores/

First launch leaves you with nothing

Launch RetroArch and notice what is not there. There are no systems, no games, and critically no cores. The frontend does not pre-load any cores on first installation; you must explicitly download them. This is deliberate and it is correct, because the alternative is shipping 200 emulators you will never open. The empty state is not a bug, and the first thing a new user should do is not hunt for a ROM but open the Online Updater, which is the subject of the next section.

Set your video driver before anything else

Go to Settings, then Drivers, and look at the Video driver. On a modern desktop or a newer Android phone, Vulkan is the right answer. The 2025 Android guidance specifically recommends Vulkan over the older OpenGL drivers for better performance and higher frame rates on newer phones, and the hardware-rendering PlayStation and Saturn cores prefer it. If RetroArch will not start after you switch, your GPU or driver does not support Vulkan and you fall back to gl or glcore. Set this now, because changing the video driver requires a restart and you would rather discover an incompatibility before you have a game loaded.

Update Everything Before You Touch Cores

The order that prevents 90% of failures

This is the step everyone skips and then posts about. Cores do not run in isolation; they depend on metadata that lives outside the core file. The most consequential of these is the Core Info File, a small text file that tells RetroArch what the core is called, which file extensions it accepts, which BIOS it needs, and which features it supports. If your info files are older than your cores, the frontend will mislabel cores, hide them from the playlist association menu, or fail to load them with cryptic errors. The mandatory update order, as outlined in the widely cited Retro Game Corps RetroArch Starter Guide, is to refresh the scaffolding first and download cores second.

Online Updater, run these in this order BEFORE downloading any core:

  1. Update Core Info Files       (lets the frontend describe cores)
  2. Update Assets                (menu icons, fonts, backgrounds)
  3. Update Controller Profiles   (auto-config for known gamepads)
  4. Update Cheats                (the cheat database)
  5. Update Databases             (so playlist scanning recognizes ROMs)
  6. Update Overlays              (on-screen controls, bezels)
  7. Update GLSL/Slang Shaders    (scanline and CRT presets)

  THEN: Core Downloader / Update Installed Cores

Why the info files matter most

If you do exactly one thing from this section, update the Core Info Files. They are tiny, they update in seconds, and a stale set is the single most common cause of "the core downloaded but it will not appear" and "missing symbol" complaints. When you later update your cores, the info files can fall behind again, so treat "Update Core Info Files" as a reflex you run alongside any core update, not a one-time chore. The asset and database updates matter for usability and scanning respectively, but the info files matter for the cores actually loading.

Expected output

Each update streams a small progress notification in the bottom corner and a completion toast. There is no dramatic confirmation screen. You should see something like the following in the on-screen log, abbreviated:

[INFO] Updating assets...
[INFO] Download complete: assets.zip
[INFO] Extracting: 1.0 / 1.0
[INFO] Updating core info files...
[INFO] Download complete: core_info.zip
[INFO] Task finished.

Downloading Cores In 12 Numbered Steps

The procedure

Now the actual download. The path through the menu is short, but the order and the choices matter. Follow these in sequence. Each step includes the reason it exists, because doing this blindly is how people end up with three SNES cores and no idea which one their playlist uses.

1. Open Main Menu, then Online Updater. This is the only sanctioned way to fetch cores; it pulls signed builds matched to your platform. Rationale: a manually downloaded core from a random mirror may be the wrong architecture or an outdated nightly, and the updater removes that entire class of mistake.
2. Confirm the scaffolding is updated. If you have not already run the seven updates from the previous section, do them now. Rationale: cores downloaded against stale info files are the leading cause of load failures, and you fix it cheaply by updating first.
3. Select "Core Downloader." This opens the full list of available cores for your platform, alphabetized and grouped by system. Rationale: this is the live library, so it reflects the current 200-plus catalog rather than whatever shipped in your build.
4. Use the search to filter by system. Press the search key and type a system name, for example SNES. The downloader lets you search by name and displays every available variant for that console. Rationale: typing the system surfaces the competing cores side by side so you choose deliberately instead of scrolling.
5. Read the variant names before clicking. For SNES you will see Snes9x, Snes9x 2010, Snes9x 2005, BSNES variants, and more. Rationale: the differences are accuracy versus performance, and grabbing the first one alphabetically is how you end up with the wrong trade-off for your hardware.
6. Download your accuracy-first pick. If your hardware can take it, choose the most accurate core for the system per the next section's table. Rationale: accuracy cores reproduce timing and edge-case behavior that performance cores approximate, and you want the best your device can sustain.
7. Download a fallback performance core too. Grab a lighter core for the same system, such as Snes9x 2010 alongside BSNES. Rationale: when a specific game chugs or a device runs hot, switching cores per game is faster than rebuilding your whole setup.
8. Repeat for each system you actually own games for. Resist the urge to download all 200. Rationale: every core is storage and update overhead, and you will never play most systems, so a focused eight-to-fifteen-core set stays maintainable.
9. Run "Update Installed Cores" after the batch. Back in Online Updater, this refreshes everything you just grabbed to the latest build. Rationale: the downloader and the nightly builds can drift, and this guarantees a consistent, current set.
10. Re-run "Update Core Info Files." Yes, again. Rationale: updating cores can leave the info files a step behind, and a second pass keeps labels and BIOS hints correct.
11. Restart RetroArch. Fully close and reopen it. Rationale: some core and info changes only take full effect on a clean start, and this preempts a category of phantom "it does not work" problems.
12. Load a core manually once to confirm. Main Menu, then Load Core, and verify your downloads are listed with correct names. Rationale: confirming the core list before you start associating playlists isolates download problems from scanning problems.

Expected output after the batch

Open Main Menu and then Load Core. You should see your downloaded modules listed by their friendly names, each with a version string, not by raw filename. A correct list looks like this:

Load Core
  Nintendo - SNES / SFC (bsnes)               v115
  Nintendo - SNES / SFC (Snes9x)              v1.62.3
  Sega - MS/GG/MD/CD (Genesis Plus GX)        v1.7.4
  Sony - PlayStation (Beetle PSX HW)          vHEAD
  Arcade (FinalBurn Neo)                      v1.0.0.03
  --- Download a Core ---

If instead you see filenames like bsnes_libretro.so with no friendly name, your info files are stale; go back to step 10.

The Right Core For Each System

The accuracy picks

The downloader gives you choices, and most systems have a clear best answer for accuracy in 2026. For SNES, BSNES is widely cited as the most accurate option because it is cycle-exact, with the understood cost of significantly higher host-hardware demand. For arcade, FinalBurn Neo remains the most accurate option, offering superior precision for classic arcade games compared to other MAME-based alternatives. For Sega's 8-and-16-bit consoles, Genesis Plus GX is the ideal pick, distinguished by accurately emulating not just the Genesis but also the Master System and Game Gear from one core. For PlayStation, Beetle PSX, usually run as Beetle PSX HW for hardware acceleration, is the recommended high-fidelity option in current setup guides. The pattern is that the libretro fork of the most accurate upstream emulator is usually your answer.

System	Accuracy pick	Performance fallback	Notes
SNES / Super Famicom	BSNES	Snes9x 2010	BSNES is cycle-exact and high-demand; not for weak hardware
Arcade	FinalBurn Neo	MAME 2003-Plus	FBNeo is the most accurate arcade option in RetroArch
Genesis / Mega Drive	Genesis Plus GX	PicoDrive	Genesis Plus GX also covers SMS and Game Gear
Genesis on Android	PicoDrive	Genesis Plus GX	PicoDrive is the 2025 mobile recommendation for performance
PlayStation	Beetle PSX HW	PCSX ReARMed	HW adds upscaling and PGXP; PCSX ReARMed is the light option
NES	Mesen	FCEUmm / Nestopia	Mesen is the accuracy benchmark; the others are featherweight
Game Boy / GBC	Gambatte / SameBoy	Gambatte	SameBoy nails timing; Gambatte is light and excellent
N64	Mupen64Plus-Next	ParaLLEl N64	Per-game core swaps still common on N64 in 2026

The mobile exception

Phones and budget handhelds flip the calculus. On Android in 2025 the specific recommendation for Sega Genesis is PicoDrive, optimized for performance on mobile hardware, rather than the more thorough Genesis Plus GX you would run on a desktop. The same logic applies up the stack: PCSX ReARMed over Beetle PSX HW on a weak phone, Snes9x 2010 over BSNES on anything that is not a current flagship. The accuracy cores are objectively better and objectively heavier, and on mobile the heavier choice that drops frames is the worse experience. If your device is a custom-firmware handheld, the bundled distribution often pre-selects sane mobile cores for you, which is one of the few things those builds get unambiguously right; our Batocera flashing walkthrough covers that path.

When to keep two cores per system

There is no rule that says one system gets one core. Keeping an accuracy core and a performance core for the same system is the mark of someone who has done this before. A handful of games hit pathological cases in the accurate core, or a specific romhack only behaves correctly under a particular fork, or a chapter of one game tanks the frame rate on the cycle-exact build. Per-game core overrides, covered next, let you say "this game uses the light core, everything else uses the accurate one" without any global compromise. Storage is cheap and core swaps are free, so the only cost is a few extra megabytes.

Core Options, Overrides, And Why They Override

Core Options versus global Settings

There are two distinct configuration surfaces and conflating them causes endless confusion. Global Settings, reached from the main menu, control RetroArch itself: video driver, audio latency, menu behavior. Core Options, reached from the in-game Quick Menu while a core is loaded, control that specific emulator: internal resolution, region, BIOS behavior, the PGXP geometry correction in Beetle PSX, the cycle-accuracy toggles in some cores. A setting that exists for one core may not exist for another, because core options are defined by the core, not by RetroArch. When a guide tells you to enable upscaling and you cannot find it in Settings, that is because it lives in Core Options under the loaded PlayStation core.

# Quick Menu path while a game is running:
  Quick Menu
    -> Core Options
        -> (per-core settings appear here)

# Example: Beetle PSX HW core options worth setting
  Internal GPU Resolution      4x   (1x is native; raise for sharpness)
  PGXP Operation Mode          memory only   (reduces polygon jitter)
  Renderer                     hardware (Vulkan)
  Texture Filtering            nearest   (keep it crunchy, or bilinear)

The override hierarchy

RetroArch lets you save configuration at three scopes, and they cascade from broad to specific. A global change applies everywhere. A Core Override applies to every game run under that core. A Game Override applies to exactly one ROM. The more specific scope wins. This is how you give a single troublesome game a different internal resolution or a different core entirely while leaving the rest of your library on sane defaults. Save them from the Quick Menu under Overrides, and understand that once a Game Override exists, editing global settings will not touch that game until you delete the override.

# Quick Menu -> Overrides
  Save Core Overrides   -> writes config//.cfg
  Save Game Overrides   -> writes config//.cfg

# Precedence (most specific wins):
  Game Override  >  Core Override  >  Global retroarch.cfg

Where the files actually live

Overrides are plain text. They live under the config directory in a folder named for the core, and they contain only the keys you changed, not the whole config. This is genuinely useful: you can read them, diff them, and copy a tuned override between machines. The libretro documentation at docs.libretro.com documents the full configuration key list, and reading a single override file is the fastest way to understand what the menu actually wrote. If an override ever misbehaves, deleting the file resets that scope cleanly without disturbing your global config.

Run-Ahead And The Latency Menu

Why emulation feels laggier than the cartridge

Original hardware on a CRT had close to zero added latency. Modern emulation stacks input polling, frame buffering, and an LCD's own display lag on top of the game's native input delay, and the result feels mushy to anyone who grew up on the real thing. RetroArch's answer is Run-Ahead, a feature toggled in the Quick Menu's Latency section. It is described in 2026 guidance as a critical setting for competitive retro gaming, and once you feel it you will not turn it off.

How Run-Ahead works

Run-Ahead exploits the fact that a core can run a frame and then be rewound. RetroArch runs the emulator one or more frames into the future every frame, using save-state snapshots internally, so that when you press a button the resulting on-screen change appears earlier than the game's native input latency would allow. In effect it removes the input delay the original game itself added. The cost is CPU: you are running the core multiple times per displayed frame. Start with one frame of Run-Ahead, which removes a meaningful chunk of lag at modest cost, and only raise it if your hardware has headroom.

# Quick Menu -> Latency
  Run-Ahead to Reduce Latency        ON
  Number of Frames to Run-Ahead      1   (try 1 or 2; higher = more CPU)
  Run-Ahead Use Second Instance      ON  (steadier on multi-core CPUs)

# Equivalent retroarch.cfg keys:
  run_ahead_enabled = "true"
  run_ahead_frames = "1"
  run_ahead_secondary_instance = "true"

When not to use it

Run-Ahead has limits. Set too many frames and games that rely on the very input delay you are removing will mispredict, producing visual glitches or audio crackle; back the frame count down until they vanish. It also fights with heavy cores: stacking two frames of Run-Ahead on BSNES on a handheld is asking for dropped frames. And it does nothing for netplay latency, which is a different problem entirely. Treat one frame as the safe default, two as the aggressive setting for light cores on strong hardware, and anything higher as an experiment you verify per game. If you are chasing every last millisecond, the same diminishing-returns logic we applied to GPU overclocking applies here.

Common Pitfalls And Their Fixes

The five that get everyone

These are the recurring failures, ranked roughly by how often they appear in support threads. Each has a real cause and a real fix, and none of them require reinstalling anything.

• Pitfall 1: Stale Core Info Files. You download a core and it either fails to load with a missing-symbol error or never appears in the core list. The cause is info files older than the cores. The fix is Online Updater, then Update Core Info Files, then restart. This is the number-one cause of "it just does not work," and it is a thirty-second fix.
• Pitfall 2: Architecture mismatch. A 32-bit core into a 64-bit frontend, or an Android core for the wrong ABI, fails silently or with an obtuse error. The fix is to only ever fetch cores through the Online Updater, which serves the correct architecture for your build, and to never sideload a core unless you can confirm its ABI.
• Pitfall 3: Missing BIOS. PlayStation, Saturn, and similar systems either refuse to boot or run in a degraded mode. The fix is to place the exact BIOS files, named exactly as the core info file specifies, in your system directory. The core's info file lists the expected filenames and their checksums.
• Pitfall 4: Wrong core for the hardware. BSNES stutters on a budget handheld, Beetle PSX HW crawls without a real GPU. The fix is to match the core to the tier from the prerequisites section, and to keep a performance fallback core for exactly these cases.
• Pitfall 5: A Game Override you forgot about. You change a global setting and one game ignores it entirely. The cause is a leftover game-scoped override that wins over global config. The fix is Quick Menu, Overrides, delete the game override, or edit the file directly under the core's config folder.
• Pitfall 6: Vulkan set on hardware that cannot do it. RetroArch fails to launch or shows a black screen after you switched drivers. The fix is to reset the video driver to gl or glcore by editing video_driver in retroarch.cfg directly, since you cannot reach the menu when the window will not open.

How to read the log when something fails

RetroArch keeps a verbose log that names the failing core and the failing symbol or file. Enable logging in Settings under Logging, set the log verbosity up, and reproduce the failure. The line that names the missing file or symbol is almost always sufficient to diagnose the problem against the four pitfalls above. On desktop you can also launch RetroArch from a terminal and read the log on stdout, which is the fastest path when the menu itself is the problem.

When the distro is the variable

On a custom-firmware handheld, your RetroArch is managed by the distribution, and the Online Updater may be disabled or pointed at the distro's own core repository rather than the official one. The fix is to update cores through the distribution's tooling rather than fighting RetroArch's updater, and to accept that the bundled core versions are what the maintainer tested. This is a feature, not a defect, but it changes the troubleshooting steps and is worth knowing before you assume the updater is broken.

Troubleshooting Table

Symptom to fix, fast

Find your symptom, apply the fix, move on. Most of these resolve in under a minute once you know where to look.

Symptom	Likely cause	Fix
Core not listed after download	Stale core info files	Online Updater, Update Core Info Files, restart RetroArch
"Failed to load core" / missing symbol	Stale info or wrong architecture	Update info files; confirm 64-bit core for 64-bit build
Game will not boot (PSX/Saturn)	Missing or misnamed BIOS	Place exact BIOS in system folder, named per core info
Severe stutter on a heavy core	Core exceeds hardware tier	Switch to performance fallback core; lower internal resolution
Black screen after driver change	Vulkan unsupported on device	Edit retroarch.cfg, set video_driver to gl or glcore
One game ignores your settings	Leftover game override	Quick Menu, Overrides, delete game override file
Visual/audio glitch after enabling Run-Ahead	Too many run-ahead frames	Lower run-ahead frames to 1; test per game
Playlist scan finds nothing	Databases not updated	Online Updater, Update Databases, rescan directory
Core downloader list is empty	No network or wrong repo (distro)	Check connection; on handhelds update via the distro instead
Wrong core auto-loads for a system	Default core association set	Quick Menu, set core association or clear it in playlist settings

The nuclear option done safely

If your configuration is hopelessly tangled, you do not need to reinstall. Rename retroarch.cfg to retroarch.cfg.bak and restart; RetroArch regenerates a clean default config and leaves your cores, saves, and states untouched. This resets every global setting without losing a single download, and you can copy specific keys back from the backup. It is the single most useful recovery move and almost nobody knows it exists.

Confirming a clean state

After any major fix, do the same three-part sanity check: Load Core shows friendly names with versions, a known-good ROM boots on the first try, and Run-Ahead produces no glitches at one frame. If all three pass, your core layer is healthy and any remaining problems are content-specific rather than configuration rot.

Advanced Tips Nobody Tells You

Per-game core swapping by playlist

You can pin a default core to an entire playlist and still override per game. Set the playlist's default core so that double-clicking any entry boots instantly without the core-select prompt, then use a game override to send the three games that need the other core to that core instead. The result is a library where the common case is one tap and the exceptions are handled silently. This is the configuration that makes a handheld feel like an appliance rather than a project.

Shaders are core-independent, treat them so

Shader presets attach at the same override scopes as everything else, which means you can run a sharp integer-scaled look on your accuracy cores and a heavy CRT preset on your arcade core without touching the rest. Save a shader as a core override and it follows that emulator everywhere; save it as a game override and it follows one title. The libretro shader repository, updated through the same Online Updater step, carries the slang presets that the Vulkan driver wants, which is one more reason to be on Vulkan where the hardware allows.

Keep a written core manifest

Maintain a short text file listing which core you settled on for each system and why. When you set up a new device, a Retroid, a fresh PC, a reflashed handheld, you reproduce a known-good setup in minutes instead of relitigating every choice. The manifest also makes the per-game exceptions explicit, so the one N64 title that needs ParaLLEl instead of Mupen64Plus-Next is documented rather than rediscovered. This sounds fussy until the third time you set up RetroArch from scratch, at which point it is obviously correct. The same discipline pays off across an entire device library; our Miyoo Mini Plus game-list breakdown is essentially a manifest for one handheld.

# core_manifest.txt  (example)
SNES       bsnes            accuracy; Snes9x 2010 fallback for SuperFX hacks
Arcade     fbneo            most accurate arcade; 0.2.97.44 romset
Genesis    genesis_plus_gx  covers SMS + GG; picodrive on the phone
PSX        beetle_psx_hw    4x internal, PGXP memory-only, Vulkan
N64        mupen64plus_next parallel_n64 override for a handful of titles
NES        mesen            accuracy; fceumm fallback never needed yet

A Complete Working Configuration

The global retroarch.cfg excerpt

Here is a coherent global configuration that reflects every decision in this tutorial: Vulkan driver, Run-Ahead enabled at one frame with a second instance, sane audio latency, and logging available for when something breaks. These are excerpts of the keys that matter, not the whole multi-hundred-line file. Drop them into your retroarch.cfg, or set them through the menu and confirm they wrote correctly.

# --- retroarch.cfg (global excerpt) ---
video_driver = "vulkan"
video_fullscreen = "true"
video_vsync = "true"
video_smooth = "false"

audio_driver = "alsathread"
audio_latency = "64"

# Run-Ahead for latency reduction
run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"

# Keep updater behavior predictable
core_updater_auto_extract = "true"
core_info_cache_enable = "true"

# Logging, on but quiet until needed
log_verbosity = "false"
frontend_log_level = "1"

A per-core override example

This is what a saved Beetle PSX HW core override looks like on disk, living at config/Beetle PSX HW/Beetle PSX HW.cfg. It contains only the keys that differ from global, which is exactly why overrides are clean to read and safe to copy between machines.

# --- config/Beetle PSX HW/Beetle PSX HW.cfg ---
video_shader_enable = "true"

# Core options are stored separately, in:
#   config/Beetle PSX HW/Beetle PSX HW.opt
beetle_psx_hw_renderer = "hardware"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_pgxp_mode = "memory only"
beetle_psx_hw_filter = "nearest"

Verifying the whole stack

Boot a game under each major core and confirm three things: the core loads by friendly name, the picture is correct at your chosen resolution, and input feels tight with Run-Ahead on. If all three hold across your accuracy cores, your installation is done and correct. For the canonical menu-by-menu reference when something here does not match your build, the official documentation at docs.libretro.com's core download guide is the source of truth, and the broader twelve-step install path is laid out in our companion piece on installing 200-plus cores in twelve steps. Everything else is taste, and taste is what the override system exists to serve.

RetroArch did not emulate anything when you started this tutorial and it still does not. But you now have eight to fifteen cores that do, each matched to your hardware tier, each configurable down to the individual game, with the input lag stripped out and a manifest so you never have to figure it out twice. That is the entire job. The frontend was always just the lobby; the cores were always the building.