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

RetroArch is not an emulator. This is the single fact that separates people who understand the software from people who file bug reports beginning with your emulator will not run my game. RetroArch is a frontend: a menu system, a settings database, a shader pipeline, an input abstraction layer, and a netplay stack wrapped around a plug-in loader. The emulators live outside it, compiled separately, as modules called cores. Everything you actually want RetroArch to do, from running a Super Nintendo cartridge to a PlayStation disc to a Neo Geo arcade board, it does by handing the work to a core. Delete the cores and you are left with a very handsome way to browse an empty menu.

This arrangement is the entire point, and it is also where every problem you will ever have with RetroArch originates. A core is software with its own author, its own release cadence, its own bugs, its own license, and its own opinion about how much of your CPU it deserves. RetroArch loads it and gets out of the way. Your job, and the reason this tutorial exists, is to install the correct cores, keep them in lockstep with your RetroArch build, configure them without detonating the settings tree, and know which ones to avoid this month because someone pushed a regression to the buildbot.

We are going to do all of that in twelve numbered steps, on desktop and on ARM handhelds, with the version numbers current as of August 2026. Then we are going to fix the things that break, because they will. This is a tutorial, not a brochure.

What a Core Actually Is

The 200-core number is a catalogue, not an inventory

RetroArch’s own site, in its 2025-04-29 update, stated the project had over 200 cores, framing them as the emulator and game-engine modules that power content inside RetroArch. That number is true, and it is also the most misleading figure on the website. Two hundred is the size of the catalogue: the total set of cores the buildbot compiles across every platform and CPU architecture it targets. It is not the number of cores you can install on your machine, and it is very much not the number you should.

A separate 2026 guide put the practically installable set at well over 100 cores reachable through the Online Updater, spanning everything from the Atari 2600 to PlayStation, Sega Saturn, and arcade boards. On a webOS TV build in December 2025 the armv7 catalogue was rebuilt at roughly 170 cores plus a handful of experimental aarch64 additions. On a locked-down retro handheld it can be a few dozen. The 200 figure is a ceiling nobody reaches, quoted as if it were a shelf you can sweep into a basket.

The practical consequence: you will install somewhere between five and fifteen cores. One per system you care about, occasionally two when you want an accuracy option and a speed option for the same console. Treat the catalogue as a restaurant menu, not a grocery list. Nobody orders the whole menu.

Cores are dynamic libraries, not applications

libretro’s GitHub description defines a core as a program instantiated as a dynamic library: a .dll on Windows, a .so on Linux and Android, a .dylib on macOS. Each core exposes a fixed C interface, the libretro API, that RetroArch calls into. The frontend says load this content, then run one frame, and the core hands back a framebuffer, an audio chunk, and a request for the next input poll. Because the interface is frozen and the implementation is swappable, the identical Sega Genesis core runs unmodified under RetroArch, Lakka, Batocera, RetroPie, and every other libretro frontend. Write once, run under any shell that speaks the API.

This design is also the source of the version coupling that trips people up. A core built against one revision of the API is not guaranteed to load into a frontend built against a different one. In theory the API is stable; in practice the buildbot compiles cores against the current stable RetroArch, and a core that was fine last month can refuse to load the day after you update the frontend but not the cores, or vice versa. The rule that falls out of this, and which you will see repeated throughout this article, is blunt: update the frontend and the cores together, never one alone.

Version markers: 1.21.0 to 1.22.2

The cores page announced RetroArch 1.21.0 on 2025-04-29, which makes that a clean milestone to anchor a timeline against. By the time the downloads page was refreshed in 2026, the current stable had advanced to 1.22.2, released 17 November 2025. The 1.22 line had a rough birth: 1.22.0 shipped with a shader black-screen bug that was patched in 1.22.1 and 1.22.2, which is exactly the sort of thing that convinces people the whole stack is fragile when in fact the fix arrived within days. The project is GPLv3, the source lives on GitHub with north of thirteen thousand stars, and the release notes are public. There is no excuse for running a mystery build. Know your version, because half of core troubleshooting is discovering that the frontend and the cores disagree about what year it is.

Prerequisites: Versions and Hardware

Software you need before touching a core

The list is short and non-negotiable. First, RetroArch 1.22.2 or newer, obtained from the official site, your platform’s store, or a trusted package channel. Do not run a build from a random file host that promises a thousand games pre-loaded; those are ROM-bundle scams wearing a RetroArch skin, and they ship stale cores. Second, a current set of core info files, which are the small metadata manifests that tell RetroArch what each core is, what content it accepts, and what BIOS it wants. These are updated separately from the cores themselves and, as we will hammer repeatedly, must be refreshed first. Third, a working internet connection for the Online Updater, unless you are on a platform where cores arrive through a package manager instead.

Update the frontend through the channel that matches your install. On Windows the one-liner is winget upgrade Libretro.RetroArch; on Linux or a Steam Deck flatpak it is flatpak update org.libretro.RetroArch; on macOS it is brew upgrade --cask retroarch. Whatever you use, immediately follow it with the in-app core refresh. The buildbot quietly replaced a batch of core files on 24 May 2026 for installs predating that date, so a stack that has not been touched since spring may be carrying obsolete manifests without telling you.

# Windows: update RetroArch itself
winget upgrade Libretro.RetroArch
# Linux / Steam Deck flatpak:
flatpak update org.libretro.RetroArch
# macOS:
brew upgrade --cask retroarch

# Then, INSIDE RetroArch, always in this order:
#   Online Updater > Update Core Info Files
#   Online Updater > Update Installed Cores

Hardware: what bsnes and LRPS2 actually demand

Cores are not equally hungry, and the marketing habit of treating emulation as a solved commodity falls apart the moment you load an accuracy core. bsnes, the cycle-accurate descendant of Near’s higan lineage, wants roughly a 4 GHz CPU core to hold full speed on Super Nintendo, because it is simulating the console at a level of fidelity that snes9x cheerfully approximates away. If your machine cannot feed it, bsnes will run at seventy percent speed and you will blame RetroArch for a choice the core made on your behalf.

The PlayStation 2 core, LRPS2, is even more selective. It is x86_64 only: Windows, Linux, and macOS under Rosetta. There is no Android build, no iOS build, no ARM-Linux build, which means it does not exist on your handheld no matter how many cores the catalogue advertises. It also wants a real BIOS and enough GPU to drive its ParaLLEl-GS renderer. Dreamcast through Flycast, Saturn through Beetle Saturn, and PSP through PPSSPP all sit in the middle: comfortable on a modern desktop, variable on ARM. Match the core to the silicon before you match it to the game.

Content and BIOS: the part nobody wants to hear

RetroArch does not ship games, and this tutorial does not tell you where to get them, because the honest answer is that you dump your own. The law here is not subtle: you may make a personal backup of media you physically own in most jurisdictions, and downloading a ROM of a cartridge you do not own is infringement regardless of how many forums insist otherwise. If you want a clean conscience and clean dumps, get a cartridge reader and dump your own SNES and Genesis carts. Several cores also require a genuine BIOS image, PlayStation and PlayStation 2 and Saturn among them, and again those come from hardware you own. A core that boots to a black screen is very often a core that cannot find the BIOS it politely listed in its info file.

Installing Cores in 12 Steps

The twelve steps

Every step below has a reason attached, because a sequence you follow without understanding is a sequence you cannot debug. Do them in order the first time; after that you will internalize the shape and only revisit the parts that matter.

1. Confirm your RetroArch version. Open the Information menu and verify you are on 1.22.2 or newer. Rationale: cores are compiled against the current stable, and a stale frontend is the most common cause of a core that downloads fine but refuses to load.
2. Update the frontend if it is behind. Use winget, flatpak, or brew as shown above. Rationale: you want the frontend and cores built for the same API revision, and updating the frontend after the cores leaves you mismatched in the other direction.
3. Verify your core and info directories. Under Settings, Directory, confirm that the Cores path and the Core Info path point somewhere writable. Rationale: on some packaged builds these default to read-only locations, and the downloader will silently fail to save anything.
4. Enable the Core Downloader if it is hidden. Some builds and skins hide it. The path is Settings, User Interface, Menu Item Visibility, Show Core Downloader. Rationale: you cannot use a menu entry you cannot see, and hunting for it wastes more time than flipping the toggle.
5. Run Update Core Info Files first. Online Updater, Update Core Info Files. Rationale: this is the manifest of what exists and what each core needs. Skip it and the downloader shows an empty or stale list, and freshly installed cores report themselves as unrecognized.
6. Open the Core Downloader. Online Updater, Core Downloader. Rationale: this is the canonical, signed distribution path that pulls architecture-correct builds from the libretro buildbot, rather than whatever a stranger zipped up.
7. Download one core for the first system you care about. Scroll to the system, pick the recommended core, select it. Rationale: install per-need, not per-catalogue. One working core teaches you more than fifty untested ones.
8. Watch for the download confirmation. RetroArch shows a brief on-screen notice and the core appears in Load Core. Rationale: this is your expected-output checkpoint; no notice usually means a directory permission problem from step three.
9. Run Update Installed Cores. Online Updater, Update Installed Cores. Rationale: this refreshes everything you have in one pass and keeps the whole set on the same build, which is the state the buildbot tests.
10. Load content to verify. Load Content, pick a ROM, choose the core you just installed. Rationale: a core that installs is not a core that works; only content proves the pairing, the BIOS, and the renderer all agree.
11. Set core options and save an override. Adjust the core’s options, then save a core or game override. Rationale: defaults are conservative, and saving deliberately prevents the global config from being polluted.
12. On Linux PPA or ARM handhelds, use the platform path instead of the downloader. Install with apt, or copy prebuilt cores onto the device. Rationale: the in-app downloader is disabled or empty on those targets, covered in the two sections below.

What Update Core Info Files actually does

The order in step five is not superstition. The info files are plain-text manifests, one per core, describing the display name, the systems the core supports, the file extensions it accepts, whether it needs a full-path ROM or can stream from an archive, and crucially which BIOS files it expects and their checksums. The Core Downloader reads these manifests to build the list you scroll through. If the manifests are older than the buildbot’s current cores, three things happen: the list is missing recently added cores, some entries point at builds that no longer exist, and any core you do manage to install shows up with a generic name and a warning that RetroArch cannot identify it. Refreshing the info files first costs about two seconds and prevents an afternoon of confusion. The official download-cores guide spells out the same sequence, and the menu path it documents is Settings, User Interface, Menu Item Visibility, Show Core Downloader, then Online Updater, then Select Core Downloader.

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

Main Menu
  > Online Updater
    > Core Downloader             (now visible)
    > Update Core Info Files      (run this FIRST)
    > Update Installed Cores

Expected output when it works

Success is quiet, which is why people miss it. After a download, RetroArch flashes a small notification in the corner and the core becomes selectable under Load Core. On the filesystem, a new dynamic library appears in your cores directory with a name ending in _libretro.so, _libretro.dll, or _libretro.dylib, alongside a matching .info file. If you want to confirm from a shell on Linux, the listing looks like the block below. The count of info files roughly tracks how many cores your platform actually offers, and it will be well short of 200.

$ ls -1 ~/.config/retroarch/cores/
beetle_psx_hw_libretro.so
flycast_libretro.so
genesis_plus_gx_libretro.so
mesen_libretro.so
mgba_libretro.so
parallel_n64_libretro.so
ppsspp_libretro.so
snes9x_libretro.so

$ ls -1 ~/.config/retroarch/cores/*.info | wc -l
137

Picking the Right Core Per System

Nintendo: NES, SNES, N64, and the 3DS shuffle

For the NES, the pick is Mesen, which is PPU-accurate, handles obscure mappers, and carries a debugger for people who care why a game misbehaves rather than merely that it does. For the SNES, the choice is a fork in the road: bsnes if your CPU clears the roughly 4 GHz bar and you want cycle accuracy, snes9x if you are on anything weaker and want the game to simply run. A 2026 recommended-cores roundup named Mesen, bsnes, and mGBA among its preferred picks for exactly these reasons, and mGBA is indeed the correct Game Boy Advance core, doubling as a competent Game Boy and Game Boy Color option.

The Nintendo 64 is the section’s open wound. The mainline core, mupen64plus-next, bundles the GLideN64 HLE renderer plus the angrylion and ParaLLEl plugins and is the documented default per the libretro N64 library page. But a widely referenced N64 status thread flagged a regression that prevented Stunt Racer 64 and World Driver Championship from loading at all. Until it is resolved upstream, the fallback for affected titles is ParaLLEl N64, the Vulkan low-level core, at the cost of narrower overall compatibility. The 3DS story is a takedown and a rebirth: Citra is dead, pulled offline, and its successor is Azahar, a merge of the prominent Citra forks that arrived as a proper libretro core around version 2125.0 and has since advanced past 2126.0. A 2026 Spanish editorial correctly filed Azahar as the new official 3DS-era core.

Sega and Sony: Genesis through Saturn, PS1 through PSP

For Sega’s eight and sixteen-bit line, Genesis Plus GX is the answer for Genesis, Mega Drive, Sega CD, Master System, Game Gear, and SG-1000, with one loud caveat documented on its core page: it does not do the 32X. For 32X you switch to PicoDrive, which is also the pragmatic Genesis pick on weak ARM. Beetle Saturn covers the Saturn if your CPU is strong enough, and Flycast is the Dreamcast core, both endorsed in the same 2026 roundup that named Beetle Saturn and Flycast explicitly.

Sony splits by horsepower. On the PlayStation the most accurate desktop option is Beetle PSX HW, a hardware-rendered Mednafen derivative that is heavy but gorgeous; SwanStation, a DuckStation-derived core, is a lighter middle ground; and PCSX ReARMed is the featherweight that powers budget handhelds and distributions like muOS and OnionOS. The PlayStation 2 is LRPS2, which a 2026 ranking correctly noted was formerly called PCSX2 libretro before its rework into an x86_64-only hard fork with the ParaLLEl-GS renderer. The PSP is PPSSPP, the same engine as the standalone, wrapped as a core.

Arcade and the accuracy-versus-speed axis

Arcade is its own discipline. FinalBurn Neo is the broad, well-curated choice, reaching back into 1970s hardware, while the various MAME cores trade compatibility for weight and romset fussiness. The meta-lesson across every system is the axis you are always choosing a point on: accuracy against speed. Accuracy cores simulate the hardware faithfully and demand more CPU; speed cores approximate and run on less. There is no universally correct answer, only the correct answer for your silicon and your tolerance for the one game in fifty that an approximation gets wrong. When in doubt, install both, keep the fast one as default, and switch to the accurate one for the specific title that misbehaves. This is precisely why per-game overrides exist, and why we cover them below.

The Linux PPA Trap

Why the PPA kills the Core Downloader

Here is the gotcha that eats an evening for every Ubuntu newcomer. The libretro guide is explicit: installing RetroArch through the Ubuntu PPA disables the built-in Core Downloader. This is not a bug. When RetroArch is packaged for a distribution, the cores become distribution packages too, managed by the package manager for the sake of dependency tracking and signed updates. The in-app downloader would fight the package manager over who owns the files, so the packaged build simply switches it off. If you installed via the PPA and then spend twenty minutes looking for a Core Downloader that is not there, you have found the trap rather than a defect.

Installing cores with apt

Once you understand that cores are now apt packages, the workflow is ordinary Debian administration. Each core is its own package with a libretro- prefix, and the libretro guide gives libretro-nestopia as the worked example. The pattern generalizes to every core the archive carries.

# The PPA build DISABLES the in-app Core Downloader.
# After this, cores come from apt, not the Online Updater.
sudo add-apt-repository ppa:libretro/stable
sudo apt-get update
sudo apt-get install retroarch

# Cores become individual packages:
sudo apt-get install libretro-nestopia      # NES
sudo apt-get install libretro-snes9x        # SNES
sudo apt-get install libretro-mgba          # GBA
sudo apt-get install libretro-beetle-psx    # PS1

The tradeoff is real. Package-managed cores update on the distribution’s schedule, which is slower than the buildbot’s nightly cadence, so you lose access to same-week fixes and same-week regressions alike. For a stable living-room machine that is a feature. For chasing the latest Dolphin or LRPS2 work it is a limitation, and the answer is to install RetroArch from Flatpak or the official build instead of the PPA, which restores the in-app downloader.

RetroPie, Batocera, and the distro question

If you are running a dedicated emulation distribution rather than a general Linux desktop, the core question is largely answered for you. Batocera ships a curated, tested core set and manages updates as part of the OS image, so you rarely touch the Core Downloader at all. RetroPie, which remains a script-driven Ubuntu affair, installs libretro cores through its own setup script rather than the in-app updater, the same package-manager philosophy as the PPA in a friendlier wrapper. On these systems, resist the urge to hand-install cores from elsewhere; you will only desync yourself from the versions the distribution actually tests against.

Cores on ARM Handhelds

Why your handheld does not get 200 cores

The catalogue is compiled per architecture, and ARM handhelds get a subset for two reasons. First, some cores are architecture-locked by design; LRPS2 is x86_64 only and will never appear on an ARM device, full stop. Second, many cores exist for ARM but are too heavy to be useful, so a well-behaved distribution curates them out rather than let you install a Saturn core that runs at a third speed. The webOS armv7 rebuild in December 2025 landed around 170 cores, which sounds close to 200 until you notice how many of them are lightweight 8 and 16-bit systems and how few are the demanding 3D consoles. The number shrinks further on cheaper silicon.

christianhaitian’s arm64 and armhf builds

The core ecosystem extends past RetroArch’s own buildbot, and on handhelds the most important external source is a GitHub project maintained by christianhaitian, which provides libretro cores built for arm64 and armhf, used primarily by ArkOS and TheRA. If you run one of those distributions, or you are hand-assembling a setup on a device the official buildbot ignores, that repository is where the correct-architecture cores come from. The repo was last refreshed in mid-2025 and remains the reference set for the budget-handheld world.

# On an ArkOS / TheRA style device, cores are dropped in as files,
# not fetched by the in-app downloader. Typical layout:
/roms/../cores/pcsx_rearmed_libretro.so
/roms/../cores/gpsp_libretro.so
/roms/../cores/snes9x2005_plus_libretro.so
/roms/../cores/genesis_plus_gx_libretro.so

# Prebuilt arm64/armhf cores: github.com/christianhaitian/retroarch-cores

The PS1 ceiling and what it means

On modest ARM hardware there is a hard practical wall, and it sits at the original PlayStation. A device that comfortably runs SNES, Genesis, GBA, and PS1 through PCSX ReARMed will choke on Saturn, PS2, and GameCube, because those need either an x86_64 core that does not exist for ARM or more GPU than the chip provides. This is the exact reasoning behind the buying advice in our look at the PS1 wall on cheap handhelds, and it is why the more capable Retroid Pocket 6 exists as a category above it. Buy the device for the ceiling you want, then install the cores that ceiling supports. Installing a Dreamcast core on a two-dollar chip does not raise the ceiling; it only teaches you what fifteen frames per second feels like.

Config Files and Override Order

Where the config lives

RetroArch’s master configuration is a single plain-text file, retroarch.cfg, one key-value pair per line. On Linux it defaults to ~/.config/retroarch/retroarch.cfg; on Windows it sits beside the executable or under your user profile depending on install type. Two directory keys matter most for cores: libretro_directory, which is where the cores live, and libretro_info_path, which is where the info files live. The Debian wiki recommends keeping these as separate writable locations, and there is a reason to respect that: if the info path is read-only, Update Core Info Files fails silently and you are back to the empty-downloader problem.

The override hierarchy: game beats core beats global

This is the single most useful thing to understand about RetroArch configuration, and the thing that turns it from a wall of settings into a scalpel. Settings resolve in a strict precedence, highest wins: a game override beats a content-directory override, which beats a core override, which beats the global retroarch.cfg. The files live under the config directory, named by core and target: config/<core>/<core>.cfg for a whole core, config/<core>/<dir>.cfg for a content folder, and config/<core>/<game>.cfg for one game. The overrides guide documents the full scheme. The practical payoff: set a sensible global default, then override only the exceptions, so the one game that needs a different renderer gets it without disturbing the other four hundred.

# Precedence (highest wins):
#   game > content-dir > core > global
#
# config/Mupen64Plus-Next/Legend of Zelda, The - Ocarina of Time.cfg
video_driver = "vulkan"
input_libretro_device_p1 = "1"
video_fullscreen = "true"

Core options versus overrides

There is a second, parallel system that people conflate with overrides and should not. Overrides control RetroArch settings: video driver, aspect ratio, input device. Core options control the core’s own internal knobs: the PlayStation renderer, the internal resolution, the PGXP mode. Core options save globally to retroarch-core-options.cfg or per-game to config/<core>/<game>.opt, and per-game requires the game_specific_options key to be enabled. Input remaps are a third file type, .rmp under config/remaps. Below is a real Beetle PSX HW options file using the core’s actual option keys, cranking internal resolution and enabling PGXP for the one game whose warping polygons you cannot forgive.

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

Common Pitfalls and Fixes

Update and downloader pitfalls

Pitfall one: downloading cores before updating info files. This is the most common self-inflicted wound. You open the Core Downloader against a stale manifest, install a core, and it either fails to load or shows up unidentified. The fix is the discipline from step five: Update Core Info Files, then Update Installed Cores, every single time, before you touch anything else.

Pitfall two: hunting for a Core Downloader the PPA removed. You installed via the Ubuntu PPA, the downloader is gone, and you assume RetroArch is broken. It is not; the PPA disables it by design. The fix is to install cores with apt-get install libretro-..., or to switch to a Flatpak or official build if you want the in-app updater back.

Pitfall three: believing 200 cores are waiting for your device. The catalogue is 200-plus; your platform gets a subset, and your handheld gets a smaller one. The fix is expectation management: pick cores by system, verify each one loads content, and stop treating the number on the homepage as a promise.

Wrong-core and hardware pitfalls

Pitfall four: using an accuracy core on hardware that cannot feed it. bsnes at seventy percent speed is not RetroArch stuttering; it is a 4 GHz core running on a slower chip. The fix is to switch to snes9x, or on ARM to snes9x2005, and reserve the accuracy core for the desktop.

Pitfall five: the wrong PlayStation core for the wrong hardware. Beetle PSX HW on a weak handheld is a slideshow; PCSX ReARMed on a strong desktop leaves image quality on the table. The fix is to match the core to the silicon: Beetle PSX HW or SwanStation on desktop, PCSX ReARMed on ARM. The same logic sinks people who load a 32X game into Genesis Plus GX, which does not support 32X at all; that content needs PicoDrive.

Config and file pitfalls

Pitfall six: editing retroarch.cfg while RetroArch is running. RetroArch rewrites the file on exit when config_save_on_exit is enabled, so your hand edits are overwritten the moment you quit. The fix is to edit the file with RetroArch closed, or to make the change in the menu and let RetroArch persist it. Pitfall seven: a stale N64 core. If Stunt Racer 64 or World Driver Championship refuse to load under mupen64plus-next, you have hit the documented regression, not a bad dump. The fix is ParaLLEl N64 for those titles until the mainline core is repaired, as tracked in the libretro N64 status thread.

Troubleshooting Table

Turn on logging before you guess

Before you diagnose anything, enable logging under Settings, Logging, set the log level to verbose, and reproduce the failure. A core that fails to load almost always writes the reason to the log: a missing BIOS by exact filename, an architecture mismatch, a version conflict. Guessing at symptoms without reading the log is how people spend an hour on a problem the log named in one line.

The symptom-to-fix table

The table below covers the failures you will actually meet, mapped to the cause and the fix. It is deliberately blunt.

When the log lies

Occasionally the log points at a BIOS that is present, or a version that matches, and the core still will not load. In that case the usual culprit is a half-written download from a dropped connection or a directory permission problem. Delete the offending core file, confirm the cores and info directories are writable, and reinstall through the downloader. If a specific system-level core like Dolphin is misbehaving, check the libretro forum thread for that core, because active cores are refreshed on a schedule and the fix may already be waiting in Update Installed Cores.

Advanced Tips

Buildbot, nightlies, and living on the edge

The Core Downloader pulls from the libretro buildbot, and by default you get builds that track the current stable. If you want same-day fixes, you can point at nightlies and enable experimental cores, at the cost of the occasional regression like the N64 one above. The tradeoff is philosophical: stable is for people who want to play games, nightly is for people who want to file useful bug reports. Know which one you are today, and do not run nightly cores under a frontend you also depend on for a Friday-night session.

Shaders, run-ahead, and per-core video drivers

Two features justify the whole override system. Run-ahead hides input latency by running the core one or more frames into the future and rolling back, which is transformative on fighting and platform games but doubles or triples CPU cost, so it belongs in a per-core or per-game override rather than global. Shaders that emulate a CRT mask are similarly worth pinning per system, because a scanline shader tuned for 240p Genesis looks wrong stretched over a 480p PSP game. And some cores prefer a specific video driver: Beetle PSX HW and Flycast shine under Vulkan, while a handful of older cores are happier on GL. Set the driver in a core override, not globally, so one demanding core does not dictate the whole setup.

Managing cores across multiple devices

If you run RetroArch on a desktop, a handheld, and a living-room box, resist the temptation to copy cores between them. Cores are architecture-specific, and a desktop x86_64 core dropped onto an ARM handheld is inert weight that clutters the menu and confuses the info system. Sync your ROMs, your saves, and your override files, which are portable text, but let each device fetch its own cores from its own correct source: the buildbot on desktop, the distribution on Batocera or RetroPie, and christianhaitian’s repository or the device image on ARK-class handhelds. Playlists reference cores by name, so a well-named override set survives the trip even when the binaries do not.

A Complete Working Configuration

The retroarch.cfg core block

Below is a complete, working set of the core-relevant lines from retroarch.cfg as of RetroArch 1.22.2. It keeps cores and info files in writable locations, points the downloader at the buildbot, and enables the per-core and per-game override machinery so your settings actually persist. Drop these into your config with RetroArch closed, or set the equivalents in the menu and let RetroArch write them for you.

# ---- Core-relevant retroarch.cfg (RetroArch 1.22.2) ----

# Where cores and their info files live (keep them writable):
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/cores"

# Where the Core Downloader fetches from:
core_updater_buildbot_cores_url = "http://buildbot.libretro.com/nightly"
core_updater_auto_extract_archive = "true"
core_updater_show_experimental_cores = "false"

# Let per-core and per-game settings actually stick:
game_specific_options = "true"
auto_overrides_enable = "true"
auto_remaps_enable = "true"
config_save_on_exit = "true"

# Stop RetroArch from silently loading a dummy core:
load_dummy_on_core_shutdown = "true"
core_set_supports_no_game_enable = "true"

A per-game override example

Pair the global config above with targeted overrides. The example below forces Vulkan and fullscreen for one N64 game without touching the rest, demonstrating the game-beats-everything precedence. Save it at the documented path and RetroArch loads it automatically whenever that content runs, then reverts to your defaults when you exit.

# config/Mupen64Plus-Next/Super Mario 64.cfg
video_driver = "vulkan"
video_fullscreen = "true"
aspect_ratio_index = "22"          # core-provided aspect
runahead_enable = "false"          # 3D N64 rarely benefits

The recommended-core cheat sheet

Finally, the reference you will actually come back to: one recommended core per system, a lighter alternative where the accuracy pick is demanding, and the note that matters. Install from the top of this list down as you need each system, verify each one loads content, and ignore the other 190 cores until you have a reason not to.

That is the whole discipline. RetroArch will keep advertising 200-plus cores, the buildbot will keep pushing fixes and the occasional regression, and the honest number for your machine will keep being a dozen or so. Install the right ones, keep the frontend and the cores on the same build, override the exceptions instead of the defaults, and read the log before you guess. Do that and RetroArch stops being a wall of menus and becomes what it was designed to be: a single, consistent shell in front of thirty years of hardware.