RetroArch Cores 2026: 200+ Plugins in 12 Steps

RetroArch is not an emulator. This is the single most expensive misunderstanding in the hobby, and it costs people hours before they realize the program they downloaded does not, by itself, run a single game. RetroArch is a frontend — a shell, a chrome, an input router and a video pipeline — and it does nothing until you feed it a core. The core is the part that knows how a Game Boy works, or a PlayStation, or a DOS box, or a chess engine. RetroArch's own marketing currently boasts over 200 cores, and it is at pains to tell you these are not all emulators: some are game engines, some are media players, some are standalone games. The frontend is the UI. The cores are the execution layer. Confuse the two and nothing you read below will make sense.

This is a tutorial, so it is going to be tediously literal about the things that actually break. You will get prerequisites with version numbers, twelve numbered steps with the reason each one exists, code blocks you can copy, the five mistakes everyone makes, a troubleshooting table you can scan during a meltdown, and a complete config at the end. If you want the breezy version with a smiling host, the internet has those. This is not that.

What a Core Actually Is

The libretro contract, in one paragraph

A core is a shared library — a .so on Linux and Android, a .dll on Windows, a .dylib on macOS — that implements the libretro API. That API is a contract: the core promises to expose functions like retro_run(), retro_load_game(), and retro_get_system_av_info(), and in exchange the frontend promises to hand it controller input, give it somewhere to draw, and play the audio it produces. RetroArch is the reference frontend for libretro, but it is not the only one — the same Snes9x core that runs in RetroArch runs in any libretro-compatible host. That is the entire point of the architecture: write the emulator once, and every frontend gets it for free.

Related: Batocera 43 Download: 12

This matters for a tutorial because it tells you why cores are downloaded separately, why they version independently, and why a core that worked last month can quietly stop matching your frontend. The core and the frontend are two programs with a handshake between them. When the handshake changes, the older partner gets confused.

Emulator, engine, or program

The official cores page is careful to split the catalog into three buckets, and you should internalize the split because it changes how you reason about a core's behavior. Emulator cores — Snes9x, Genesis Plus GX, Beetle PSX, mGBA — pretend to be hardware and run unmodified ROMs and disc images. Game engine cores — the Doom engines, the Quake and OpenLara ports, the ScummVM core — do not emulate a CPU at all; they reimplement a game's engine and consume the original data files. Program cores — media players, a few utilities — are along for the ride because the libretro API happens to fit them. A 2025 setup guide reduces all of this to a useful slogan for newcomers: in RetroArch, a core is essentially an emulator. That slogan is wrong about a third of the catalog, but it is the right lie to tell a beginner on day one.

Why "just download RetroArch" is bad advice

RetroArch's support documentation says, plainly, that you do not need to download a new build of RetroArch to get updated cores — you update them in place through the Online Updater. The corollary nobody mentions is that a fresh RetroArch install has no cores at all. The first run experience for thousands of people is opening the program, browsing to a ROM, hitting load, and being told there is nothing to load it with. That is not a bug. That is the architecture working exactly as designed, and the rest of this article is the workflow that fills the gap.

Prerequisites: Versions and Hardware

Software versions

Use a current stable RetroArch from the official site or, on Windows, the Steam build if you want updates handled for you. The Steam build and the standalone build keep cores in different folders, which becomes a troubleshooting item later, so write down which one you installed. On Android, install the official build from Google Play or the APK from the site — both ship empty and pull cores at runtime. On Linux, prefer the Flatpak or the distribution package; a self-built RetroArch can only load self-built cores, which is a trap for another day.

• RetroArch: latest stable. Nightly builds exist and they are genuinely useful, but a nightly frontend frequently outruns the core buildbot, so beginners should stay on stable.
• Cores: whatever the buildbot currently serves for your platform and architecture. You do not pick versions; the Online Updater does.
• Core info files: updated before you download any cores. This is step zero and the single most-skipped step in the hobby.
• BIOS files: some cores — Beetle PSX, most disc-based systems, several handhelds — refuse to run without them. RetroArch never ships BIOS files; you supply them.

Hardware requirements

The honest answer is "it depends on the core," because a core is an emulator and emulators range from trivial to brutal. An 8-bit core will run on a potato. A PlayStation core with upscaling wants a real GPU. A 2025 Android guide explicitly recommends setting the video driver to Vulkan on newer phones for better performance, which is your first hint that the frontend's video backend and the core's demands are coupled. On the desktop, Vulkan or a modern GL driver is fine; on a handheld, you take what the vendor shipped.

Storage is cheap but not free. The full core set is large, and you do not want it. Disk pressure is the least of your problems; clutter is the real cost. A device with the entire 200+ catalog installed presents you with six cores per system at load time and you will pick the wrong one. Install what you use.

Related: Retroid Pocket 5 vs

BIOS, ROMs, and the legal line

This is the law-and-lore section, so: RetroArch ships no copyrighted material. No BIOS, no ROMs, no disc images. The cores are open source; the content is your problem and your responsibility. Dumping your own cartridges is the defensible path, and if you are doing that, our Retrode 2 cartridge-dumping walkthrough covers the hardware end of it. BIOS files live in the System directory, which RetroArch shows you under Settings → Directory; put them there before you blame the core for a black screen.

Steps 1-4: The Online Updater

The order of operations nobody respects

The single most common failure mode in core management is doing things in the wrong order. RetroArch's core management workflow centers on the Online Updater, and the Online Updater has a correct sequence: refresh the metadata first, then download cores. If you download a core before updating its info file, RetroArch may not know what systems that core supports, what BIOS it needs, or what file extensions to associate with it. The core works; the frontend just can't reason about it. Here are the first four steps.

1. Update core info files. Main Menu → Online Updater → Update Core Info Files. Rationale: the info files are the metadata that tells RetroArch what each core is, what it runs, and what BIOS it expects. Refreshing them first means every core you download afterward arrives with correct metadata already in place. Skip this and you get the dreaded "missing, must be present" warnings for files you actually have.
2. Update assets. Online Updater → Update Assets. Rationale: assets are the menu's icons, fonts, and background graphics. They have nothing to do with whether a game runs, but a half-updated asset set produces a UI full of missing-icon placeholders that make every later step harder to follow. Get the UI coherent before you start making decisions in it.
3. Update databases. Online Updater → Update Databases. Rationale: the databases are how RetroArch identifies your ROMs by checksum when it builds playlists. A current database means the scanner recognizes your files; a stale one means it silently skips them and you conclude, wrongly, that your dump is bad.
4. Update controller profiles, cheats, and shaders. The remaining Online Updater entries. Rationale: these are independent of cores but live in the same menu, and doing them now means you never have to come back. Controller profiles in particular save you from manually mapping a gamepad that RetroArch already has a profile for.

Expected output

Each updater action shows a progress bar and a short confirmation. There is no dramatic success screen; RetroArch is allergic to fanfare. A healthy run looks like this in the log, which you can see by setting logging verbosity up:

[INFO] [Updater] Downloading index file: cores/.index-extended
[INFO] [Updater] Extracting: core_info.zip
[INFO] [Updater] Update complete: 218 core info entries
[INFO] [Updater] Downloading: assets.zip
[INFO] [Updater] Extracting assets to /home/user/.config/retroarch/assets/
[INFO] [Updater] Database update complete: 162 RDB files

If you see Failed to download or a stalled bar, that is a network or buildbot problem, not a you problem — note it and consult the troubleshooting table. The number of core info entries will not match the number of cores you install; it reflects the entire catalog, which is how RetroArch advertises its breadth even on a machine with three cores on disk.

Why metadata is its own download

It is reasonable to ask why RetroArch separates info files, assets, databases, and the cores themselves into four downloads instead of one. The answer is the version-independence the architecture is built on: cores update on the buildbot's schedule, info files update when a core's capabilities change, and databases update when new ROM checksums are catalogued. Bundling them would force a full re-download every time any one of them changed. Splitting them means a core update is a few megabytes, not a few hundred. It is annoying as a user and correct as engineering.

Steps 5-8: Installing and Loading

Download what you need, one at a time

Now you actually get cores. The mechanism is the Core Downloader, and the discipline — repeated in multiple 2025 setup guides — is to download only the cores you need, one at a time. Resist the urge to grab everything. A 2025 Android walkthrough demonstrates the pattern precisely: open the Core Downloader, pick a specific core such as PicoDrive for Sega Genesis, install it, and only then move on. The reason for the one-at-a-time discipline is partly to avoid transient download errors and partly to keep your load menu legible.

Related: Multisystem² 2026: FPGA Console

5. Open the Core Downloader. Main Menu → Load Core → Download a Core (or Online Updater → Core Downloader, depending on build). Rationale: this is the canonical, supported way to get cores onto the machine with matching metadata. Manually dropping a .so into the cores folder works but skips the info-file association you just set up.
6. Pick one core for the system you care about. For Genesis, that is Genesis Plus GX or PicoDrive; for SNES, Snes9x; for PS1, Beetle PSX or PCSX ReARMed on weaker hardware. Rationale: most systems have a heavy, accurate core and a light, fast core. On a phone or handheld you want the light one; on a desktop you can afford accuracy. The most-accurate-core debate is real, and the answer is hardware-dependent.
7. Verify the core loaded. Load Core → the new core appears in the list. Select it and the menu shows the core's name and version in the top bar. Rationale: this confirms the .so is architecturally compatible with your build. A core that downloaded but won't appear is almost always an architecture mismatch, which the troubleshooting table addresses.
8. Load content. With the core selected, Load Content → browse to your ROM. Rationale: this is the moment the frontend hands the file to the core. If the core launches the game, the contract worked end to end. If you get a black screen, the usual suspect is a missing BIOS in the System directory.

Expected output

A clean core load and content launch produces log lines like the following. This is the sequence you want to see, and learning to read it turns most "it doesn't work" panics into a five-second diagnosis:

[INFO] [Core] Loading dynamic library: genesis_plus_gx_libretro.so
[INFO] [Core] Version of libretro API: 1
[INFO] [Core] Geometry: 320 x 224, Aspect: 1.333
[INFO] [Content] Loading content: Sonic_The_Hedgehog.md
[INFO] [Content] CRC32: 0xafe05ece
[INFO] [Environ] SYSTEM_DIRECTORY: /home/user/.config/retroarch/system
[INFO] [Video] Using Vulkan driver
[INFO] [Core] Content loaded successfully.

The libretro API: 1 line is the handshake confirming the core speaks the version your frontend expects. The CRC32 is what the database matches against to identify the ROM. If that CRC doesn't match anything in the database, scanning won't file the game into a playlist even though it runs fine — a subtlety that trips up people whose dumps are slightly off-spec.

Cores as a library workflow, not a one-off

Once a system's core is installed and proven, the modern workflow stops being "load core, load content" and becomes a library operation. RetroArch can scan a content directory and generate playlists, matching each ROM by checksum to a database entry and associating it with the right core. After that, you launch games from the playlist and never touch the Core Downloader again until something needs updating. This is the difference between treating cores as an emulator install and treating them as the execution layer behind a managed library. If you are building a full living-room setup around this, the same principles scale up — our look at the 119GB RetroPie-on-PC image is a cautionary tale about what happens when someone ships you every core pre-installed and pre-scanned, whether you wanted that or not.

Steps 9-12: Overrides and Tuning

The override hierarchy

This is where RetroArch quietly becomes powerful, and where most users never go. Settings in RetroArch cascade: there is a global configuration, then per-core overrides, then per-content-directory overrides, then per-game overrides, each more specific layer winning over the one beneath it. The Retro Game Corps guide highlights one concrete use: Save Core Overrides to preserve settings like run-ahead for an entire emulator core. That is the lever you want. Run-ahead reduces input latency by speculatively running frames; it is expensive, and it makes sense to enable it per-core rather than globally because the cost varies wildly between an 8-bit core and a PS1 core.

9. Configure a core, then save a Core Override. With content running, Quick Menu → Overrides → Save Core Overrides. Rationale: this writes a small config that applies to every game run under that core, without polluting your global config. Change the core's internal options — say, set run-ahead to 1 frame — then save the override, and every game on that system inherits the tuning.
10. Set per-core options via the Core Options menu. Quick Menu → Core Options. Rationale: these are the emulator's own knobs — internal resolution, region, BIOS selection, accuracy versus speed toggles. They are distinct from RetroArch's settings and they are saved per-game or per-core depending on how you save them. This is where PS1 upscaling lives, for example.
11. Set the video driver to match your hardware. Settings → Drivers → Video. Rationale: the 2025 Android guidance to use Vulkan exists because some cores and some GPUs perform dramatically better on one backend than another. On the desktop, Vulkan or glcore is the safe default; some older cores still prefer GL. The frontend's video driver and the core's renderer interact, so this is a core-management concern, not just a cosmetic one.
12. Periodically run Update Installed Cores. Online Updater → Update Installed Cores. Rationale: cores receive independent updates after install, and the Retro Game Corps guide recommends running this periodically. This is the entire payoff of the architecture: you fix bugs and gain features without reinstalling RetroArch. Do it monthly, or after you hear a core got a notable fix.

Run-ahead and the latency budget

Run-ahead deserves its own paragraph because it is the most misunderstood per-core setting. It works by running one or more frames of emulation ahead of what you see, then rolling back, so that input registers a frame or two sooner than the original hardware managed. On a fast desktop with a light core it is nearly free and feels like magic. On a handheld with a heavy core it can halve your frame rate. This is precisely why you save it as a Core Override rather than globally: enable it for the NES core where it costs nothing, leave it off for the PS1 core where it costs everything. If you are chasing latency seriously, the same logic applies to your whole chain — our PS Remote Play latency walkthrough covers the network side of the same problem.

What a saved override looks like on disk

RetroArch writes overrides as plain text config files, and reading them demystifies the whole system. A core override for the Beetle PSX core lands in a predictable place and contains only the keys that differ from global. Here is a representative core override file:

Related: Retroid Pocket 6 vs

# config/Beetle PSX HW/Beetle PSX HW.cfg
# Core override — applies to every game run under this core
run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"
video_shader_enable = "false"
video_smooth = "false"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_renderer = "vulkan"

Notice it only stores deltas. That is deliberate: an override that copied the entire global config would drift out of sync the moment you changed a global setting. By storing only differences, RetroArch lets your global config evolve while your per-core tuning stays pinned to exactly the things you meant to pin.

Common Pitfalls and Fixes

The metadata-order mistakes

Most core problems are not core problems. They are sequencing and environment problems wearing a core's clothes. Here are the five that account for the overwhelming majority of "my core is broken" reports.

• Pitfall 1 — Downloading cores before updating info files. You install a core and RetroArch can't tell you what it runs, or it nags about BIOS files you actually have. Fix: run Update Core Info Files, then Update Installed Cores. The info refresh re-associates everything. This is why steps 1-4 come before steps 5-8 and not the other way around.
• Pitfall 2 — Grabbing the entire catalog. You download every core "to be safe," and now every system offers six cores at load time and you can't remember which one you tuned. Fix: delete the cores you don't use (Load Core → highlight → Delete Core) and keep one or two per system. The 200+ catalog is a menu, not a shopping list.
• Pitfall 3 — Missing BIOS in the System directory. The core loads, the game launches to a black screen or refuses outright. Fix: confirm Settings → Directory → System points where you think it does, and that the BIOS filenames match exactly what the core's info file expects, including case. The Core Options or the info file lists required BIOS by name.
• Pitfall 4 — Architecture mismatch. You manually copied a core .so from another machine and it won't appear in the list. Fix: never copy cores between architectures. A WebOS armv7 core, an Android arm64 core, and a desktop x86_64 core are not interchangeable. Use the Core Downloader, which only serves cores built for your build.
• Pitfall 5 — Stale database, bad scan. You scan a folder and half the ROMs don't show up in the playlist. Fix: run Update Databases, then re-scan. The scanner matches by checksum; an old database doesn't contain the entries for your files, so they're silently skipped. The games run fine if loaded manually — the only thing broken is the playlist matching.

The platform-specific traps

Beyond the universal five, each platform has its own characteristic failure. On Android, the default GL driver underperforms on newer chips and the fix is the Vulkan video driver, as the 2025 guidance specifies. On WebOS and other community-packaged platforms, you are not pulling from the official buildbot at all — you are pulling from a community repository, and that repository's freshness matters. One WebOS core project reported its repository was rebuilt in December 2025 with over 170 cores built for the armv7 target, which is a reminder that on non-official platforms, "update cores" depends on a volunteer's build schedule, not RetroArch's. On the desktop, the recurring trap is the Steam build versus the standalone build keeping cores in separate directories, so a core you "already installed" is invisible to the other build.

The version-drift trap

The subtlest pitfall is the one the architecture creates by design. Because cores and frontend version independently, a nightly RetroArch can outrun the core buildbot, producing a core that loads but misbehaves because the libretro API it was built against has moved. The fix is boring: stay on stable RetroArch unless you have a specific reason not to, and when you do run nightlies, run Update Installed Cores immediately after updating the frontend so both halves of the handshake advance together.

Troubleshooting Table

Symptom to cause to fix

Scan this when something breaks. It is ordered roughly by how often each problem occurs, which is to say BIOS and metadata problems are at the top because they always are.

Reading the log when the table fails

When the table doesn't cover your symptom, the verbose log will. Settings → Logging → set Frontend Logging Level to 0 (Debug) and enable Log to File. Reproduce the failure, then read the log. The lines that matter are the core-load line (does the .so name look right?), the libretro API version line (does the core's API match the frontend's?), and the SYSTEM_DIRECTORY line (is it pointing where your BIOS actually lives?). Ninety percent of unexplained failures resolve at one of those three lines.

Related: Miyoo Mini Plus vs

When the core itself is the bug

Occasionally the problem is genuinely in the core — a regression in a recent build, a game-specific incompatibility. Two moves help. First, run Update Installed Cores; the fix may already be on the buildbot. Second, check the core's own GitHub repository under the libretro organization, where issues and recent commits will tell you whether your specific game is a known problem. The cores are open source; the issue tracker is public; you are not the first person to hit most bugs.

Advanced Tips

Picking the right core for the hardware

The accuracy-versus-speed split is the advanced user's main decision, and it has no universal answer. On a desktop, accuracy cores — Beetle PSX, bsnes, Mednafen-derived cores — give you the closest thing to original hardware, including the bugs and timing quirks games depended on. On a handheld or phone, speed cores — PCSX ReARMed, PicoDrive, Snes9x's faster variants — are the difference between full speed and a slideshow. The most-accurate-core discussion is worth reading, but treat "most accurate" as a ceiling, not a requirement: you want the most accurate core your hardware can run at full speed, which on weaker devices is not the most accurate core. If you are shopping for the device first, our comparisons of the Retroid Pocket 6 and the Miyoo Mini Plus versus the RG35XX are framed around exactly this question of how much core you can afford to run.

Override stacking for power users

The override hierarchy rewards deliberate use. A sensible pattern: keep your global config minimal and conservative, save Core Overrides for system-wide tuning like run-ahead and shader choice, and reserve Game Overrides for the handful of titles with specific needs — a game that wants a different aspect ratio, one that needs a particular core option to avoid a graphical bug. Because each layer stores only deltas, you can change a global setting and have it propagate to everything that didn't explicitly override it. This is the closest RetroArch comes to a real configuration management system, and it is wasted on people who only ever touch the global config.

Shaders, RetroAchievements, and the rest of the stack

Cores are the bottom of a tall stack. Above them sit shaders — CRT filters, scanline emulation, the whole aesthetic apparatus — which run in the frontend's video pipeline and are core-independent, so a CRT shader looks the same over any core. RetroAchievements hooks into specific cores that support the integration, reading memory to award achievements on unmodified ROMs. Netplay layers on top for two-player sessions across the internet. None of this works until the core layer is solid, which is why this tutorial spent its length there. Get the cores right and the rest of the stack is configuration; get the cores wrong and nothing above them matters.

A Complete Working Config

The directory layout

Here is a known-good layout for a desktop install. Paths differ by platform — Android and Flatpak use sandboxed locations — but the structure is identical everywhere. The point is that everything cores depend on has a defined home, and when something breaks, you check these directories first.

~/.config/retroarch/
  retroarch.cfg              # global config
  cores/                     # the .so / .dll files live here
    snes9x_libretro.so
    genesis_plus_gx_libretro.so
    mgba_libretro.so
    beetle_psx_hw_libretro.so
  info/                      # core info files (metadata)
  system/                    # BIOS files go here
    scph5501.bin             # PS1 BIOS, supplied by you
    gba_bios.bin
  config/                    # per-core and per-game overrides
    Beetle PSX HW/
      Beetle PSX HW.cfg      # core override
  playlists/                 # generated by content scanning
  saves/
  states/

A minimal global retroarch.cfg

You should not hand-edit the whole config — RetroArch writes hundreds of keys — but these are the ones worth setting deliberately. Everything else can stay at its default. This is the conservative global baseline that the override layers build on top of:

# retroarch.cfg — conservative global baseline
video_driver = "vulkan"
video_fullscreen = "true"
video_vsync = "true"
menu_driver = "ozone"

# Save behavior — stop settings from resetting
config_save_on_exit = "true"
save_file_compression = "true"

# Directories — point these where your files actually live
system_directory = "~/.config/retroarch/system"
savefile_directory = "~/.config/retroarch/saves"
savestate_directory = "~/.config/retroarch/states"

# Run-ahead OFF globally — enable per-core via override
run_ahead_enabled = "false"

# Logging — bump to 0 only when debugging
log_verbosity = "false"
frontend_log_level = "1"

The one-time setup, condensed

If you internalize nothing else, internalize this sequence. It is the entire tutorial compressed into a checklist you can run on a fresh install in well under thirty minutes, and it is the order that prevents every pitfall above.

# RetroArch core setup — correct order, every time
# 1-4: metadata FIRST
Online Updater -> Update Core Info Files
Online Updater -> Update Assets
Online Updater -> Update Databases
Online Updater -> Update Controller Profiles / Cheats / Shaders

# 5-8: cores, one at a time
Load Core -> Download a Core -> [pick one per system]
Load Core -> [confirm it appears]
Load Content -> [launch a known-good ROM]
Settings -> Directory -> System  # confirm BIOS path

# 9-12: tune and maintain
Quick Menu -> Core Options        # set per-core knobs
Quick Menu -> Overrides -> Save Core Overrides
Settings -> Drivers -> Video -> Vulkan
Online Updater -> Update Installed Cores   # run monthly

That is the whole discipline. Metadata before cores. One core per system. Tune with overrides, not the global config. Update installed cores on a schedule. RetroArch advertises over 200 cores, and the temptation is to treat that number as a feature you should consume in full. It is not. It is a catalog, and the skill is selecting from it. The frontend is the UI. The cores are the execution layer. Keep the two clear in your head and the program that ran nothing on first launch becomes the only emulation tool you need — which was, deadpan as ever, the plan all along.