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

RetroArch is not an emulator. That is the first thing to internalize, and the thing the forums will spend three pages failing to explain to a newcomer. RetroArch is a frontend — a menu, an input layer, a video pipeline, a save-state manager — and out of the box it is empty. The actual emulation lives inside cores: separate programs that RetroArch loads at runtime. Hand it no cores and it boots to a tidy menu and does precisely nothing, like a turntable with no records.

This guide walks the whole arc. What a core is, how to install all two-hundred-plus of them or just the six you actually need, which core to run for each system, how to override settings per game, and how to fix it when a core refuses to load at two in the morning. Budget thirty minutes for the install and a lifetime for the tuning. We will point you at the official libretro documentation rather than paraphrase it badly, and we will tell you where the project disagrees with its own wiki.

What a Core Actually Is

People treat "core" as jargon. It is not. It is the most precise word available for the thing, and once you understand the architecture, every confusing behavior in RetroArch suddenly has a reason. So let us be precise about it before touching a single menu.

The libretro API, in one paragraph

A libretro core is a dynamically loadable library — a .so on Linux and Android, a .dll on Windows, a .dylib on macOS — that implements a specific C interface called the libretro API. RetroArch is one frontend that speaks that API; there are others (Lakka, the Kodi game add-on, several handheld launchers), but RetroArch is the reference implementation and the target the cores are built against. The frontend feeds the core input, a clock, and a framebuffer to draw into; the core hands back video, audio, and the occasional demand for a BIOS file. Because the boundary is a clean API, the same SNES core runs unmodified on your desktop, your phone, and a $35 single-board computer. That portability is the entire point of the libretro project, and it is documented in detail on the libretro project site.

Why cores are not interchangeable

A core emulates a system or a family of related systems. A SNES core decodes SNES machine code and mimics SNES silicon; feed it a PlayStation disc image and it will, correctly, refuse. This is the single most common beginner misconception, and the official material says so flatly: cores are not interchangeable for most platforms. Some cores are multi-system by design — Final Burn Neo covers a huge arcade catalogue, MAME covers an even larger one, and the Beetle/Mednafen lineage spans a dozen consoles — but the default assumption should be one core, one system. When in doubt, the core's name and its info file tell you exactly what it accepts.

The two-hundred-core reality

RetroArch and libretro ship over 200 cores. You will use perhaps eight. The catalogue runs from the obvious (NES, SNES, Genesis, PlayStation) out to the genuinely obscure: Game & Watch, ColecoVision, Vectrex, the PC-FX. This is glorious and it is also a trap, because the Core Downloader presents all 200 as an undifferentiated wall, and the newcomer's instinct is to grab everything. Resist it, or at least understand the cost before you do. If your goal is genuinely to populate every system at once, our companion walkthrough on installing all 200+ cores in twelve steps covers the bulk-download path; this article is about doing it deliberately.

Prerequisites: Versions, Hardware, and BIOS

Three things gate a working setup: a current frontend, hardware that can keep up with the core you chose, and — for several systems — a BIOS file that RetroArch will never, ever supply for you. Skip the prerequisites and you will spend the install section troubleshooting instead of installing.

Software versions

Install the latest stable RetroArch. As of 2026 that is the 1.20 lineage (your package manager or the site will tell you the exact point release; nightlies run ahead of stable and are worth it only when you are chasing a specific fix). The version matters more than people think, because the libretro API and the core info format evolve, and a frontend that is two years stale can fail to load cores built this month. The rule is simple and non-negotiable: update the frontend before you update the cores. On Windows you can update in place by overwriting the old .exe with the new one; on Linux use your distro package or the Flatpak; on macOS replace the app bundle. The mupen64plus-next N64 core suffered a visible regression in early 2025, which is the canonical reminder that newest is not always best — sometimes you pin a known-good core against a known-good frontend and leave it alone.

The hardware floor, by system

For 8-bit and 16-bit systems, the floor is a potato. NES, SNES, Genesis, Game Boy, and PC Engine run at full speed on a Raspberry Pi or a budget handheld; the cores are featherweight. The cost climbs with accuracy and with generation. The bsnes SNES core is cycle-accurate and has notably higher power demands than Snes9x — the project documentation says so explicitly — so on weak hardware you trade accuracy for frames. The fifth generation and up (N64, Saturn, PlayStation with upscaling, Dreamcast) genuinely want a real CPU and GPU, especially once you enable hardware renderers and internal resolution multipliers. If you are buying a device specifically to run these cores handheld, the silicon matters a great deal; our Retroid Pocket 6 review goes deep on what the current ARM chips can and cannot sustain. We are not going to invent frame numbers here; test your own combination and believe your own eyes.

BIOS files and the law

Several cores will not load content without a system BIOS or firmware image: PlayStation (the SCPH series), Saturn, Sega CD, Dreamcast (dc_boot.bin), Neo Geo (neogeo.zip), and others. RetroArch ships none of these and never will, for the obvious reason. The Machine knows the law: emulators themselves are legal — Sony v. Connectix and Sony v. Bleem settled that the clean-room reimplementation of a console is lawful in the United States. The copyrighted BIOS and the games are a separate question, and downloading a BIOS set is infringement no matter how normalized the practice has become. The defensible position is dumping the firmware from hardware you own. Place the files, named exactly as the core expects, in the system directory. RetroArch will find them there.

$ ls -1 ~/.config/retroarch/system/
dc_boot.bin
dc_flash.bin
neogeo.zip
scph5500.bin
scph5501.bin
scph5502.bin
saturn_bios.bin
bios_CD_U.bin

The filenames above are case-sensitive on Linux and macOS and must match what the core requests in its info file, byte for byte. A correctly-named-but-wrong-checksum BIOS is the cause of an enormous amount of wasted time; we return to it in the pitfalls section.

The 12-Step Install Walkthrough

Here is the deliberate path from a fresh install to a system you can hand to another human. Each step has a reason attached, because steps without reasons are how people end up cargo-culting forum posts from 2017. If you would rather see this same flow with a 14-step variant covering more systems, the 200-systems-in-14-steps walkthrough is the long-form sibling to this one.

Steps 1–4: Frontend and the updater

1. Update the frontend first. Main Menu > Online Updater is useless if RetroArch itself is stale. Rationale: cores are built against a libretro API version; loading a current core into an old frontend is the single most common cause of "the core just won't load." Get the frontend current before anything else touches the disk.
2. Confirm the core directory. Settings > Directory > Cores. Rationale: the updater downloads into this path, and on locked-down systems (some Linux sandboxes, Android scoped storage, read-only Steam Deck partitions) the default can be non-writable. If the path is wrong, every later step silently fails.
3. Verify you can reach the buildbot. You must be connected to the Internet, and your network must allow buildbot.libretro.com. Rationale: the Online Updater pulls every core from the libretro buildbot; corporate DNS, a paranoid pi-hole, or a captive portal will break the download with a misleading error.
4. Update Core Info Files. Online Updater > Update Core Info Files. Rationale: info files are the metadata that tell RetroArch what each core is named, what content it accepts, and which BIOS it needs. Stale info files make perfectly good cores appear missing or mislabeled. Do this before downloading cores, not after.

Steps 5–8: Download, load, verify

5. Open the Core Downloader. Online Updater > Core Downloader. Rationale: this is the per-core menu. You can scroll the full list of 200-plus here, which is also where you decide between curating and bulk-grabbing.
6. Download deliberately, or download everything. Pick the cores for the systems you own. Rationale: the full set is several hundred megabytes and turns your Load Core list into an unreadable wall. Curate by system unless you have a specific reason to mirror the whole buildbot.
7. Update the supporting assets. Online Updater > Update Assets, then Update Databases, then Overlays and Shaders as desired. Rationale: these are not cores, but the scanner matches your ROMs against the databases by checksum, and thumbnails and overlays come from the asset bundles. A core with no database is a core you have to point at content by hand.
8. Load a core and confirm it appears. Main Menu > Load Core, and check your freshly-downloaded core is in the list. Rationale: this verifies the binary actually landed and matches your CPU architecture. Expected result: the core name appears with no error; if the list is empty, the download went to the wrong directory or the architecture is mismatched.

Steps 9–12: Content, association, persistence

9. Scan your content directory. Main Menu > Import Content > Scan Directory. Rationale: RetroArch identifies games by CRC against its database and builds clean per-system playlists. Manual loading works, but the scanner is what gives you the console-style grid.
10. Associate a default core with each playlist. Open a playlist, then its options, and set the default core. Rationale: so launching a game uses the correct core automatically instead of prompting you every time. This is the difference between an emulator and a toy.
11. Set core options. Launch a game, open the Quick Menu, and visit Core Options. Rationale: region, internal resolution, BIOS handling, and renderer all live here, per core. Defaults are conservative; the good stuff is opt-in.
12. Save and lock it in. Main Menu > Configuration File > Save Current Configuration. Rationale: depending on build, "Save Configuration On Exit" may be off by default, which means your careful tuning evaporates on the next launch. Save explicitly, then decide whether you want auto-save on. We give you a full working config at the end of this article.

Picking the Right Core Per System

This is the section people actually came for, and the one the in-app menu refuses to help with. RetroArch will happily let you run a mediocre core for a system that has an excellent one. Here is the opinionated map.

The accuracy-versus-speed axis

Every system with more than one core sits on a single axis: accuracy on one end, performance on the other. Accuracy cores reproduce hardware quirks, timing, and edge-case behavior that a handful of games depend on; they cost CPU. Performance cores cut corners you will mostly never notice and run on anything. The correct choice is a function of your hardware, not ideology. On a desktop, take the accuracy core every time. On a $90 handheld, take the performance core and stop apologizing for it — the kind of device covered in our Miyoo Mini Plus game-list piece runs the lightweight cores beautifully and the heavy ones not at all.

The cores I actually run

The table below is the short list. Where two cores are named, the first is the default recommendation and the second is the fallback for weaker hardware. Genesis Plus GX, bsnes, Mesen, and Final Burn Neo are the cores the project itself and the wider community point to first, and the reasoning is in their respective repositories — for instance the Genesis Plus GX repository documents exactly which Sega systems it spans.

When to keep two cores for one system

Sometimes the right answer is both. Keep bsnes for the SNES library and Snes9x assigned to the two or three games that need a feature bsnes lacks, or that you play on a low-power device. Keep Beetle PSX HW for upscaling and a lighter core for the handful of titles that misbehave under hardware rendering. RetroArch lets you override the core on a per-game basis from the playlist, so there is no penalty for hedging. The penalty only comes from forgetting which core a game is using when you go to troubleshoot.

Manual Installation and Sideloading

The Online Updater handles the common case. The uncommon cases — a platform with no buildbot, a core you compiled yourself, a build that the updater does not yet carry — need a manual drop. It is not difficult once you know where the core directory is and where the buildbot keeps its files.

The buildbot directory

Every core the updater offers lives at buildbot.libretro.com, organized by platform and architecture. The path structure is predictable: nightly or stable, then the OS, then the CPU architecture, then latest, then the zipped core. This predictability is what makes scripted and offline installs possible. If you are setting up a machine with no Internet at the destination, you fetch the zips on a connected machine and carry them over.

Dropping a core by hand

The procedure is: find your core directory in Settings > Directory > Cores, download the matching zip for your exact architecture, extract the library, and drop it in. Then update the info files in-app so RetroArch recognizes it. The architecture has to match exactly — an x86_64 core will not load on an ARM handheld, and a 32-bit core will not load into a 64-bit frontend.

# Cores live where Settings > Directory > Cores points.
$ cd ~/.config/retroarch/cores/
$ wget https://buildbot.libretro.com/nightly/linux/x86_64/latest/genesis_plus_gx_libretro.so.zip
$ unzip genesis_plus_gx_libretro.so.zip
$ rm genesis_plus_gx_libretro.so.zip
# Now in-app: Online Updater > Update Core Info Files

Expected result after Update Core Info Files: the core shows its proper display name and supported-extensions list in Load Core. If it shows as a raw filename with no metadata, the info file did not update.

Platform quirks

Not every platform is equal. Android cores are architecture-specific (arm64-v8a for any modern phone) and the updater usually gets this right. iOS and tvOS require sideloading the whole app and its cores together because of the platform's restrictions on loading external executables. And the community fills gaps the official buildbot does not: a repository of webOS (armv7) cores for LG smart TVs was rebuilt in December 2025 with over 170 cores, and lives at the webosbrew retroarch-cores repository. If your platform is exotic, search for a community core repo before concluding it is unsupported. If you would rather skip per-platform fiddling entirely, a bundled distribution like Batocera ships RetroArch and its cores preconfigured.

Per-Core and Per-Game Overrides

The thing that elevates RetroArch above a pile of standalone emulators is its override system: settings can be global, or scoped to a single core, or a single content directory, or a single game, with the narrower scope winning. Understand the hierarchy and you stop fighting the config.

The override hierarchy

RetroArch resolves settings from broad to narrow: the global retroarch.cfg is the base, a core override applies on top of it for that core only, a content-directory override is narrower still, and a per-game override is the most specific and wins everything. This is why you can have integer scaling on globally, smoothing on for exactly one blurry arcade game, and a different aspect ratio for your vertical shooters, all without touching the global config. The mechanism is documented thoroughly in the libretro docs under configuration overrides.

Writing a core override

You rarely write these by hand — the usual path is Quick Menu > Overrides > Save Core Overrides, which writes the file for you — but knowing the format demystifies the whole system. A core override is a .cfg file named after the core, in a folder named after the core, containing only the keys that differ from global.

# config/Genesis Plus GX/Genesis Plus GX.cfg
video_scale_integer = "true"
video_smooth = "false"
aspect_ratio_index = "22"
audio_latency = "64"
savestate_auto_save = "true"

Only the keys present here override the global config; everything else falls through to retroarch.cfg. That is the elegance of it — the file stays tiny and legible, and you can read at a glance exactly what is special about this core.

Core options versus config overrides

This trips up nearly everyone, so be clear about it. Config overrides (the .cfg above) change RetroArch's own settings — video, audio, input. Core options are settings the core itself exposes — region, internal resolution multiplier, BIOS behavior, NTSC video filter — and they are stored separately, in per-core .opt files under the config tree, edited via Quick Menu > Core Options. Mixing the two mental models is why someone spends an hour looking for an internal-resolution setting in the wrong menu. Frontend stuff: overrides. System-specific stuff: core options.

Run-Ahead and Latency

Emulated input lag is real and it is worse than original hardware, because the frontend adds buffering on top of the core. RetroArch's answer is Run-Ahead, and on a sufficient CPU it can make an emulator feel tighter than the console it imitates. This is the feature that converts skeptics.

What Run-Ahead does

Run-Ahead works by running the core forward several frames internally each visible frame, rolling the state back, and replaying with your real input, so that the lag inherent in both the original game and the emulation stack is hidden. The result is fewer frames of perceived input latency. You reach it at Quick Menu > Latency > Run-Ahead, and the full explanation lives in the official Run-Ahead guide, which is worth reading once because the trade-offs are genuine.

Enabling it safely

The catch: Run-Ahead requires the core to support save states, because that is the rollback mechanism, and it costs CPU — especially in single-instance mode, where the core literally re-simulates frames. The "second instance" option runs a second copy of the core to do the prediction, which is heavier on RAM but smoother. Start at one frame of run-ahead and increase only if input still feels mushy; more frames is not better, it is just more cost and, past the game's real internal lag, audible audio glitches.

# Append to retroarch.cfg or a per-core override
run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"
run_ahead_hide_warnings = "false"

Preemptive Frames, the lighter alternative

Newer RetroArch builds add Preemptive Frames, which achieves a similar latency reduction without spinning up a full second instance, by re-running only when input changes. On CPU-constrained devices it is often the better trade: most of the latency win, a fraction of the cost. If Run-Ahead with a second instance drops your frame rate, switch to Preemptive Frames before you give up on low latency entirely. Leave the warnings visible until you trust your setup — they tell you when a core cannot support the feature you just enabled.

Five Pitfalls That Eat Your Afternoon

Every one of these has cost real people real hours. None of them is your fault; all of them are avoidable once named.

Content and BIOS pitfalls

Pitfall 1: the wrong-checksum BIOS. A file named scph5501.bin that is the wrong dump fails exactly like a missing file, with an equally unhelpful error. Fix: verify your BIOS against the checksums the core's info file or the libretro docs list; a correctly-named bad dump is the most common false lead in PlayStation and Saturn setups. Pitfall 2: BIOS still inside a zip. Cores want the BIOS as a loose file in the system directory, not compressed and not in a subfolder. Fix: extract it, put it directly in system/, match the case exactly on Linux and macOS.

Performance and core-choice pitfalls

Pitfall 3: running an accuracy core on weak hardware. Loading bsnes on a low-power handheld and then blaming RetroArch for stutter is a rite of passage. Fix: match the core to the silicon — Snes9x, not bsnes, on anything ARM and cheap; Beetle PSX in software mode, not the upscaling hardware renderer, on an integrated GPU. Pitfall 4: cranking internal resolution past your GPU. The 8x upscale slider is right there and it is a trap on modest hardware. Fix: step internal resolution up one multiplier at a time and stop at the first hint of frame drops; native or 2x looks correct and runs.

Config and update pitfalls

Pitfall 5: the architecture mismatch. A 32-bit core dropped next to a 64-bit frontend, or an x86 core on an ARM device, simply will not appear in Load Core, and the silence is maddening. Fix: download the core that matches your frontend's exact architecture, every time — this is the manual-install gotcha and the reason the in-app updater is safer for beginners. Bonus pitfall: the config that never saved. If "Save Configuration On Exit" is off and you never ran Save Current Configuration, none of your tuning survives a restart. Fix: save explicitly after setup, then decide whether to enable auto-save.

Troubleshooting Table

When a core misbehaves, stop guessing and read the log. RetroArch will tell you precisely what went wrong if you let it speak.

Reading the verbose log

Enable verbose logging in Settings > Logging, or launch from a terminal with the verbose flag. The log names the exact core path it tried, the system directory it looked in, and the specific file it failed to find. Ninety percent of "it won't work" reduces to one line in this output. Here is what a missing-BIOS failure looks like; your version string will differ.

$ retroarch --verbose
[INFO] RetroArch 1.20.0 (your build may differ)
[INFO] [Core]: Loading dynamic libretro core from: "cores/beetle_psx_hw_libretro.so"
[INFO] [Environ]: SYSTEM_DIRECTORY: "~/.config/retroarch/system".
[INFO] [Core]: Version of libretro API: 1
[ERROR] [Content]: Failed to open file: "~/.config/retroarch/system/scph5501.bin"
[ERROR] [Core]: Failed to load content.

The table

When to nuke the config

Occasionally the config is so tangled that surgery costs more than a reset. Rename retroarch.cfg to retroarch.cfg.bak and relaunch; RetroArch regenerates a clean default. Your cores, ROMs, saves, and BIOS are untouched — only the settings reset. This is a five-minute fix that people avoid for hours out of a misplaced fear of losing data. You will not lose data. The full configuration documentation is in the libretro docs if you want to understand a key before you keep it.

Advanced Tips

Once the basics work, the depth of RetroArch reveals itself. These are the things worth doing after the system is stable, not before.

Per-core shader chains

Shaders are post-processing pipelines — CRT masks, scanlines, NTSC signal simulation, LCD grids for handheld cores. The trick most people miss is that you can save a shader preset as a core override or a per-game override, so your SNES library gets a CRT mask and your Game Boy library gets a dot-matrix LCD effect automatically. Load a shader via Quick Menu > Shaders, tune it, then Save Preset scoped to the core. Shaders cost GPU, so on handhelds pick one cheap CRT preset and stop.

Vulkan, ParaLLEl GS, and LLE

The frontend has been moving toward Vulkan as the default high-performance video driver, and recent work brought a Vulkan-powered low-level-emulation renderer, ParaLLEl GS, into the picture — low-level emulation reproduces the original GPU's behavior far more faithfully than the high-level shortcuts, at a real performance cost. If your hardware supports Vulkan, it is generally the better driver for the demanding cores; switch it in Settings > Drivers > Video and test per core, because a few older cores still prefer OpenGL. This is exactly the kind of feature where a strong desktop GPU pays off, the sort of thing worth knowing before an x86 build like RetroPie on a PC.

Netplay and pinning core versions

Netplay synchronizes two RetroArch instances frame-by-frame, and it is unforgiving about cores: both sides must run the same core, ideally the exact same build, or the simulation desyncs. The advanced move is to pin core versions deliberately — keep a known-good core binary backed up, note its build date, and do not let a blanket "Update Cores" silently replace it before a netplay session. The same discipline protects you from regressions like the early-2025 mupen64plus-next issue: the source and release history for any core live in its libretro GitHub repository, so you can always retrieve a specific build.

A Complete Working Configuration

Here is a sane base to build from. It is not a magic file — paths and drivers depend on your platform — but it encodes the decisions this article argued for: Vulkan video, threaded rendering off for accuracy cores, explicit save-on-exit, and conservative audio latency.

The retroarch.cfg base

# ~/.config/retroarch/retroarch.cfg (excerpt)
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/cores"
system_directory = "~/.config/retroarch/system"
video_driver = "vulkan"
video_vsync = "true"
video_scale_integer = "true"
video_smooth = "false"
audio_latency = "64"
input_max_users = "4"
savestate_auto_save = "true"
savestate_auto_load = "false"
config_save_on_exit = "true"
menu_show_advanced_settings = "true"

A bsnes accuracy override

And the per-core override that makes the SNES library pixel-correct on a desktop that can afford it. Note it sets only what differs from the base — integer scaling and no smoothing are inherited from global, run-ahead is added here.

# config/bsnes/bsnes.cfg
aspect_ratio_index = "21"
run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"
video_shader_enable = "true"

The final word

RetroArch rewards the patient and punishes the impatient with exactly the same toolset. The frontend is empty by design, the cores are the substance, and the difference between a frustrating evening and a console-quality library is entirely in the choices documented above: current frontend, the right core per system, your own BIOS, scoped overrides, and a config you actually saved. Read the official documentation when a setting confuses you, keep the troubleshooting table within reach, and the two-hundred-core machine becomes the most flexible emulation platform that exists. Now go dump your own BIOS files.