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

RetroArch does not emulate anything. That sentence trips up more newcomers than any BIOS error ever will. RetroArch is a frontend: a menu, an input layer, a video pipeline, a shader stack. The actual work of pretending to be a Super Nintendo is done by a core, a shared library that speaks the libretro API on one side and one specific console on the other. In 2026 there are more than 200 of them, and choosing badly is the difference between Ocarina of Time locked at 60 and a slideshow that dies on the Deku Tree.

This is the long version: what cores are, how to install and update them on RetroArch 1.22.2, which core to load for each system this year, how to configure them without RetroArch quietly eating your changes, and what to do when a core refuses to load at all. Budget about thirty minutes end to end, most of it download time. Everything here is free. RetroArch and every official core are open source, so anyone quoting you a price is selling something that was never theirs.

What a RetroArch Core Actually Is in 2026

The libretro API, in one paragraph

A core is a dynamically linked library, a .dll on Windows, a .so on Linux and Android, a .dylib on macOS, that implements the libretro API. The frontend loads that library at runtime, hands it a ROM or disc image, and then drives it frame by frame: the core hands back a video frame and an audio buffer, the frontend hands the core the state of your controller. That contract is the whole trick. The API dates to roughly 2010, when the project that became RetroArch was still called SSNES, and the decision to standardise the emulator-to-frontend boundary is the entire reason a single menu can front a hundred different machines today. Because the boundary is a stable API rather than a bundled binary, the same core runs unchanged inside RetroArch, Lakka, Batocera, RetroPie, and even KODI. Write once, run under any libretro frontend.

Cores versus the frontend: who does what

The division of labour is strict and worth internalising, because it dictates where every setting lives. The frontend owns the menu, the video driver, shaders, netplay, rewind, run-ahead, save-state plumbing, and configuration. The core owns the actual machine: the CPU interpreter or dynamic recompiler, the picture processing unit, the audio chip, cartridge mapper logic, and the exact byte layout of a save. Some marquee features are collaborative rather than free. Rewind, run-ahead, and deterministic netplay only work if the core exposes fast, side-effect-free save states, which is why a core that emulates a machine flawlessly can still refuse to rewind. When a feature is greyed out, the frontend is usually telling you the core underneath it cannot cooperate.

The 200-plus number, and why it lies a little

Yes, the libretro catalogue passed 200 cores, and it grows continuously. But that is a catalogue figure, not a per-device figure. The Core Downloader only ever shows cores that have been compiled for your operating system and CPU architecture. A Windows x86_64 box sees the largest set; an ARM handheld sees fewer; niche targets fewer still. When webosbrew rebuilt its LG TV repository in December 2025 it shipped just over 170 cores for WebOS armv7, plus an experimental aarch64 set. So treat 200-plus as the size of the shelf, not the size of your cart, and stop expecting an obscure core to appear on a platform nobody compiled it for.

Prerequisites: Versions, Hardware, and Directory Layout

The software, and the versions that matter

Install a current RetroArch. As of this writing the stable line is 1.22.x, with 1.22.2 released on 20 November 2025; the earlier 1.21.0 build from spring 2025 is the one that added Apple Vulkan and CoreMIDI drivers and a raft of 3DS fixes. Version discipline matters more than usual with cores: the info files and buildbot cores track the frontend, so a badly out-of-date RetroArch can download a core it then cannot load. You also need a live internet connection for the Online Updater and a writable cores directory, which sounds obvious until you meet the Flatpak sandbox or an Android build that keeps its cores in scoped storage. For any disc-based or BIOS-gated system you will additionally need BIOS files, which you are expected to dump from hardware you own; nobody here is going to hand you a Sony ROM, and the legality begins and ends with the console on your shelf.

A hardware reality check

8-bit and 16-bit cores run on a potato. The demanding ones are specific and predictable. The bsnes Accuracy core wants roughly a 4 GHz CPU because it refuses to use speed or compatibility hacks and emulates SNES timing cycle by cycle. N64 and PS1 hardware renderers want a real GPU exposed through Vulkan or OpenGL. Saturn is heavier still, and LRPS2, the PlayStation 2 core, is x86_64-only and effectively wants Vulkan. On ARM handhelds you should assume the lighter tier of every core by default and be pleasantly surprised when a heavy one runs. Reddit is full of 2025 and 2026 reports of cores, ColecoVision emulation among them, simply not launching on devices like the Retroid Pocket 3+, which is an architecture-and-build problem, not a user error and not something a settings change will fix.

The directory layout, before you touch anything

RetroArch keeps cores and everything around them in a predictable tree. You do not have to memorise it, but you do have to make sure the cores directory is writable and that the info directory exists, because those two facts cause most silent download failures.

RetroArch/
  cores/        libretro cores (.dll / .so / .dylib)
  info/         core info files -- the manifest
  system/       BIOS files you supply yourself
  config/       retroarch.cfg + per-core and per-game overrides
  playlists/    generated game lists (.lpl)
  saves/        in-game SRAM saves
  states/       save states
  downloads/    Online Updater staging area

Two configuration keys point at the first two directories: libretro_directory for the cores and libretro_info_path for the info files. If you ever move your install and the cores vanish, it is because one of those keys still points at the old path.

The 14-Step Core Setup Walkthrough

Before the list: the two settings that prevent most failures

Two decisions, made before you download a single core, prevent the overwhelming majority of support threads. First, set your directories under Settings, Directory, and confirm the cores path is somewhere writable; sandboxed Flatpak and Ubuntu PPA installs default to locations the downloader cannot write to. Second, pick your video driver, Vulkan or OpenGL, up front, because several cores expose their best renderer only under the matching driver and changing it later forces every loaded core to reinitialise. With that done, work the list in order.

1. Install or verify RetroArch itself. On Windows the least painful route is the package manager. Why: cores are compiled against the frontend ABI, and a stale frontend can reject a fresh core outright.
2. Point the directories at writable locations. Settings, Directory: set the Cores and Core Info directories. Why: a read-only cores folder makes the Core Downloader fail without a meaningful error.
3. Choose the video driver first. Settings, Drivers, Video: vulkan or gl. Why: LRPS2's ParaLLEl-GS renderer is Vulkan-only, Beetle PSX HW's best path is Vulkan, and Parallel N64 upscaling behaves differently per driver.
4. Run Online Updater, Update Core Info Files. Why: the info files are the manifest the frontend reads to know a core exists and what it plays. Skip this and the Core Downloader is empty or lists cores that then fail to load.
5. Update Assets, Databases, and Controller Profiles. Same Online Updater menu. Why: thumbnails, the RDB game databases used for scanning, and controller autoconfig all live here and are independent of the cores themselves.
6. Open Online Updater, Core Downloader and pick your systems. Why: each core is a small shared library, generally under 20 MB, so download only what you will actually run rather than the whole shelf.
7. On Windows, keep the app and cores in lockstep. Upgrade the app, then use Update Installed Cores. Why: mismatched app-and-core versions are the classic cause of a core that loaded yesterday and crashes today.
8. Drop BIOS files into system/. PlayStation, PS2, Saturn, Sega CD, and Neo Geo need them. Why: the core will load happily without a BIOS and then black-screen the moment you load content, which reads like a core bug but is not.
9. Load the core. Main Menu, Load Core, then choose it. Why: this is the exact moment the shared library is opened; if it is going to fail on your platform, it fails here, and the log says why.
10. Load content and confirm it boots. Load Content, pick a ROM. Why: verify the pairing works before you spend ten minutes tuning options for a core that was never going to run.
11. Set Core Options. In-game, Quick Menu, Core Options. Why: renderer, internal resolution, and accuracy toggles live here, in the core, not in RetroArch's global settings.
12. Save a per-core override. Quick Menu, Overrides, Save Core Overrides. Why: this pins your settings for that core without polluting the global retroarch.cfg that every other core also reads.
13. Save a per-game override only where needed. Same menu, Save Game Overrides. Why: reserve this for the one title that needs software rendering or a widescreen hack, so the exception does not become the rule.
14. Let RetroArch write the config; do not hand-edit while it runs. Why: with config_save_on_exit enabled, RetroArch rewrites retroarch.cfg on exit and silently discards anything you edited by hand in the meantime.

The Windows fast path

If you are on Windows, steps one and seven collapse into two commands. Install or upgrade with winget, launch, and let RetroArch pull the rest from the Online Updater.

winget upgrade Libretro.RetroArch
# then, inside RetroArch:
#   Online Updater -> Update Core Info Files
#   Online Updater -> Core Downloader
#   Online Updater -> Update Installed Cores

Expected output from the winget step looks like this, confirming the version you now have:

Found RetroArch [Libretro.RetroArch] Version 1.22.2
This application is licensed to you by its owner.
Successfully verified installer hash
Starting package install...
Successfully installed

Expected output: what success looks like

On the Steam Deck or any Linux desktop, install the Flatpak and, on the Deck specifically, grant it access to your SD card so the cores and ROMs survive a reboot.

flatpak install flathub org.libretro.RetroArch
flatpak run org.libretro.RetroArch
# Deck: enable the Flatpak permission for external storage,
# or manage everything through EmuDeck.

When Update Core Info Files finishes you get a brief on-screen notification rather than a dialog. Then, when you actually load a core, the verbose log is the source of truth. A healthy N64 core load reads roughly like this:

[INFO] [Core]: Loading dynamic libretro core from: "cores/parallel_n64_libretro.so"
[INFO] [Overrides]: Redirecting save file to "saves/".
[INFO] [Core]: Version of libretro API: 1, Compiled against API: 1
[INFO] [Content]: Loading content file: "roms/Legend of Zelda, The - Ocarina of Time.z64"
[INFO] [Core]: Content ready.

If instead you see a line about a failed dlopen, or the info file reported missing, stop and re-run step four before touching anything else.

Choosing the Right Core per System (2026)

Nintendo: NES, SNES, N64, Game Boy, and 3DS

For the NES, Mesen is the 2026 pick full stop. It matches the base hardware down to the picture processing unit, handles the mapper edge cases that trip lesser cores, and carries a debugger for anyone poking at ROM hacks. For the SNES the honest answer is two answers: on a real desktop use bsnes Accuracy and accept the roughly 4 GHz appetite; on a handheld or anything older, load Snes9x, which is the practical choice and no embarrassment. The N64 is where 2026 gets ugly. The main mupen64plus-next core suffered a regression early in 2025, after which titles such as Stunt Racer 64 and World Driver Championship stopped loading and the community pinned itself to the last good January build. The safe default is Parallel N64, which pairs current Mupen64 CPU code with the ParaLLEl RDP and RSP for accurate rendering. For Game Boy, Game Boy Color, and Game Boy Advance, mGBA is the near-perfect all-rounder that covers all three from a single core. And for the 3DS, Citra is dead; use Azahar.

Azahar deserves a sentence of its own because it is genuinely new. It is the 2026 continuation of Citra, assembled by merging PabloMK7's Citra fork with the Lime3DS project after Citra's shutdown. Its first official libretro core shipped in the 2125.0 Alpha 4 prerelease across six operating systems, and the full 2125.0 stable puts that core in RetroArch's built-in downloader. Note the legal housekeeping: Azahar dropped support for encrypted games and removed the ability to pull system files straight from Nintendo's CDN, replaced by the Artic Setup Tool.

Sega, Sony, and Arcade

For everything Sega short of the 32X and Saturn, the answer is Genesis Plus GX, which claims full compatibility across Genesis and Mega Drive, Sega CD and Mega CD, Master System, Game Gear, SG-1000, and even the Pico, and does it with excellent accuracy and optional widescreen. It began life as a Wii homebrew emulator and was one of the first cores ported to libretro, which is part of why it is so solid. It will not touch 32X; that is PicoDrive's job, and Saturn belongs to Beetle Saturn, Kronos, or YabaSanshiro depending on your patience and your GPU. For PlayStation, pick by weight. Beetle PSX HW is the Mednafen-derived heavyweight with the hardware renderer and the highest accuracy, and it is the best pure-desktop choice inside RetroArch. On a Steam Deck or handheld, SwanStation, the libretro port of DuckStation, and PCSX ReARMed, the ARM-optimised workhorse behind most budget devices, both run lighter than Beetle PSX HW while keeping the picture clean. PS2 is desktop territory: LRPS2, a hard fork of PCSX2, is x86_64-only and ships the new ParaLLEl-GS renderer, a Vulkan compute program by Themaister that chases software-renderer accuracy while offering up to 16x SSAA. For arcade, Final Burn Neo is the accuracy pick with a library that reaches back to the 1970s, with current MAME as the alternative when FBNeo lacks a board, at the cost of MAME's stricter, version-locked romset requirements.

The one decision that actually matters: accuracy versus performance

Every recommendation above is really one axis. Accuracy cores, bsnes, Mesen, Beetle PSX HW, reproduce the original hardware's timing and quirks and charge you CPU for it. Performance cores, Snes9x, Nestopia, PCSX ReARMed, trade a sliver of edge-case fidelity for speed and portability. Match the core to the silicon in front of you and both camps are happy. Force an accuracy core onto a handheld and you get a slideshow; run a performance core on a workstation and you leave fidelity on the table for no reason. There is no universally best core, only the best core for a given machine and a given tolerance for jank. The table below is the short version.

Configuring Cores: Core Options, Overrides, and Remaps

Core Options are not RetroArch Settings

This is the distinction that ends most confusion. Core Options are toggles the core itself exposes, internal resolution, renderer, accuracy modes, region, and they are written to retroarch-core-options.cfg. RetroArch Settings are frontend concerns, the video driver, audio latency, input binds. They live in different files and obey different scopes. When a guide tells you to raise the internal resolution to 4x, that is a Core Option under Quick Menu, Core Options, not something in the main settings tree. Get this wrong and you will spend an afternoon hunting for a menu entry that lives in the other menu entirely, and half the internet will insist you are looking in the right place.

The override hierarchy: game beats directory beats core beats global

RetroArch resolves configuration in a strict order, most specific wins. Per the official overrides guide, the chain is: game settings, then content-directory settings, then core settings, then the global retroarch.cfg. The content-directory layer is the underrated one, it lets you apply, say, a widescreen shader to an entire folder of one console's games without editing each title. Overrides are deliberately lightweight, they save only the values that differ from the layer beneath, so an override file is usually a handful of lines. Per-core overrides live at config/<core>/<core>.cfg and load every time you run that core; per-game overrides live at config/<core>/<game>.cfg. A minimal per-core override for a pixel-art console might do nothing more than force integer scaling and kill bilinear smoothing:

# config/bsnes/bsnes.cfg  -- loads with every bsnes session
video_scale_integer = "true"
video_smooth = "false"
aspect_ratio_index = "22"
video_shader_enable = "true"

Per-game core options and input remaps

Two related mechanisms handle the exceptions. Per-game core options require game_specific_options set to true, after which Quick Menu, Options, Manage Core Options, Save Game Options writes a file next to the game with a .opt extension. Input remaps are a separate system living under config/remaps, for when one game wants the C-buttons rearranged and the rest of the core does not. Keep them straight: options change the emulated machine, remaps change the controller. A per-game options file is as terse as the override above, and RetroArch loads it automatically when you launch that exact ROM:

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

Five Common Pitfalls (and the Fix for Each)

BIOS, directories, and the downloader

Pitfall 1, skipping Update Core Info Files. This is the single most common failure. Without current info files the Core Downloader is empty or, worse, lists cores that then refuse to load. Fix: run Online Updater, Update Core Info Files before every fresh download, and again after a big app update. Pitfall 2, missing BIOS. A core with no BIOS in system/ loads fine and then black-screens the instant you load content, which everyone misreads as a broken core. Fix: place correctly hashed BIOS files in the system directory and confirm against the core's documented requirements. Pitfall 3, a read-only cores directory. Flatpak sandboxes and Ubuntu PPA packages point the cores path somewhere the downloader cannot write, so downloads appear to do nothing. Fix: set libretro_directory to a writable location; PPA users must instead install cores through apt with names like libretro-genesisplusgx.

Version and driver traps

Pitfall 4, hand-editing retroarch.cfg while RetroArch is running. With config_save_on_exit on, the frontend rewrites the file on close and discards your edits without comment. Fix: edit only with RetroArch closed, or better, make changes in the GUI and capture them as overrides. Pitfall 5, the wrong video driver. Load LRPS2 under OpenGL and you lose the ParaLLEl-GS renderer entirely; drive Parallel N64 upscaling under the wrong backend and frame times spike. Fix: set the video driver before loading the core and restart when RetroArch asks. Pitfall 6, chasing every nightly. The mupen64plus-next regression of early 2025 is the cautionary tale: newer is not always working. Fix: when a nightly breaks a game that worked, roll back to the last good build rather than waiting and hoping.

Architecture mismatches

Pitfall 7, wrong architecture for the device. An x86_64 core will never run on an ARM handheld, and even ARM builds vary; the 2025-2026 reports of ColecoVision and other cores failing to launch on a Retroid Pocket 3+ are build and architecture problems, not settings. Fix: only install cores built for your exact platform and CPU. On non-standard targets, use the platform's own repository, the webosbrew build for LG WebOS being the obvious example, rather than expecting the desktop catalogue to apply.

Troubleshooting Table: Twelve Failures and Their Fixes

Download and load failures

The table covers the failures that actually generate forum threads. Work top to bottom; the first three account for the clear majority of them.

Boot, BIOS, and performance

Two of these deserve expansion. The black-screen-after-load case is almost always BIOS, and the tell is that the core itself loaded without complaint, so nobody thinks to check system/. Match the exact filename and hash the core expects; a BIOS that is one revision off will sometimes boot and then corrupt saves, which is worse than an honest failure. The half-speed bsnes case is not a bug either: Accuracy genuinely needs the clock speed, and the correct response on weaker hardware is to drop to bsnes Performance or Snes9x rather than to fight physics.

Platform and persistence

The vanishing-cores row is the one that eats afternoons. If your cores directory lives inside an app bundle or a sandbox that an update replaces, every update wipes your cores. Point libretro_directory at a stable location outside the app, and the problem never recurs. On ARM handhelds, accept that the catalogue is smaller and some cores will simply not be built for you; that is the price of the form factor, not a fault in your setup.

Platform Notes: Steam Deck, Handhelds, and WebOS

Steam Deck and the desktop

The Deck is x86_64, so it gets the full catalogue: LRPS2 for PS2, Beetle PSX HW for PlayStation, bsnes Accuracy for SNES, all of it. Install through Flatpak or let EmuDeck wire it up, set the video driver to Vulkan, and the only PS1 nuance worth remembering is that SwanStation and PCSX ReARMed run lighter than Beetle PSX HW if you would rather spend the thermal headroom on battery. If hand-managing cores sounds like a chore, a dedicated distribution bundles them for you; our Batocera 43.1 flash guide covers the pre-built route, and on a Raspberry Pi the alternative is RetroPie, though as we documented it has been frozen at v4.8 for years.

ARM handhelds: Retroid, Anbernic, Miyoo

Here you live in the performance tier by design. Snes9x, PCSX ReARMed, Nestopia, mGBA, Genesis Plus GX, and Final Burn Neo are the load-bearing cores; bsnes Accuracy, LRPS2, and heavy N64 upscaling are not for you. On a capable Android unit like the Retroid Pocket 6 you can push further than on the older models we compared across the current Retroid lineup, but the ceiling is real and Saturn or PS2 will still humble it. At the bottom end, on something as slight as a Miyoo Mini Plus, PCSX ReARMed is effectively the only PS1 core worth loading, and the custom firmwares those devices run, muOS, OnionOS, ROCKNIX, ship RetroArch with a curated core set precisely so you do not have to guess.

WebOS, TVs, and other exotics

RetroArch runs on far more than computers and handhelds. The webosbrew cores repository was rebuilt in December 2025 with over 170 cores compiled for LG WebOS on armv7, plus an experimental aarch64 set for the brave. The lesson generalises: on any non-mainstream target, the per-platform repository, not the desktop Core Downloader, is the source of truth, and you should expect a subset of the catalogue rather than all of it.

Advanced: Buildbot, Nightlies, and Manual Core Management

Nightly versus stable, and when to pin

Cores and the frontend move on different clocks. RetroArch tags stable releases periodically, but the cores are built continuously by the libretro buildbot, which is why Update Installed Cores can pull a newer core the same day it was committed. Most of the time that is a gift. Occasionally, as N64 users learned in early 2025, a nightly regresses and you want the previous build back. The skill worth having is knowing how to pin: keep a copy of the last working .so or .dll, or fetch a specific dated build, rather than treating latest as gospel. RetroArch will not stop you from downgrading a single core by hand while leaving the rest current.

Installing a core by hand from the buildbot

When the GUI updater will not give you the build you want, do it manually. The buildbot exposes cores at a predictable path by platform and architecture; download the compressed core, extract the library into your cores directory, and drop the matching .info file into your info directory so the frontend recognises it. The shape of the process, with placeholders, is:

# platform/arch are e.g. windows/x86_64, linux/x86_64, android/arm64-v8a
BASE=https://buildbot.libretro.com/nightly/<platform>/<arch>/latest
curl -O "$BASE/genesis_plus_gx_libretro.so.zip"
unzip genesis_plus_gx_libretro.so.zip -d ~/.config/retroarch/cores/
# then place the matching genesis_plus_gx_libretro.info in info/

Experimental cores and building from source

Some cores are flagged experimental and hidden by default; enable core_updater_show_experimental_cores to see them, and treat them as the label suggests. If you want a core that no buildbot ships for your target, the libretro-super scripts build the whole ecosystem from source, and the libretro-core-info repository is where the .info manifests are maintained. The RetroArch releases page plus the per-core documentation are where you confirm what a given build actually supports. This is also the honest path for a brand-new core like Azahar, whose libretro build first shipped in a 2125.0 alpha before landing in the stable Core Downloader.

A Complete, Working Configuration

The base retroarch.cfg, core-relevant keys

You should let RetroArch author retroarch.cfg through the GUI; hand-editing it while the program runs is pitfall four. But it helps to know which keys govern cores so you can read the file and reason about it. Close RetroArch before editing, and these are the lines that matter:

# --- paths ---
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/info"
system_directory = "~/.config/retroarch/system"

# --- updater ---
core_updater_buildbot_url = "http://buildbot.libretro.com/nightly"
core_updater_auto_extract_archive = "true"
core_updater_show_experimental_cores = "false"

# --- so your work survives ---
config_save_on_exit = "true"
auto_overrides_enable = "true"
auto_remaps_enable = "true"
game_specific_options = "true"

# --- driver most heavy cores prefer ---
video_driver = "vulkan"
menu_driver = "ozone"

A per-core override

The override file is where per-core taste belongs. This one pins clean, filtered output for the N64 without touching any other core's configuration; it lives at config/parallel_n64/parallel_n64.cfg and loads automatically whenever Parallel N64 runs:

# config/parallel_n64/parallel_n64.cfg
video_scale_integer = "false"
video_smooth = "false"
aspect_ratio_index = "22"
video_shader_enable = "true"
video_fullscreen = "true"

A per-game override, the exception

Finally, the narrowest layer, for the single title that misbehaves under the core's defaults. Save it from Quick Menu, Overrides, Save Game Overrides, and RetroArch writes only the differing lines to config/<core>/<game>.cfg:

# config/parallel_n64/Star Wars - Rogue Squadron.cfg
# this one title prefers the alternate plugins
parallel-n64-rsp-plugin = "cxd4"
parallel-n64-gfxplugin = "angrylion"
video_smooth = "true"

That is the whole model: a global config you let the GUI manage, a per-core override for taste, and a per-game override for the one game that argues. Keep those three layers straight and RetroArch stops fighting you. Load the accurate core your hardware can actually afford, feed it a real BIOS, update the info files before the cores, and the other 199 cores on the shelf are just a download away. The Machine rests.