RetroArch Cores 2026: Install 200+ in 12 Steps

Most people who install RetroArch for the first time spend twenty minutes looking for the part where they pick a console, get confused, and quietly assume the software is broken. It is not broken. They are simply looking for a feature that does not exist, because RetroArch does not contain a single emulator. It contains a slot where emulators go. The thing you put in that slot is called a core, and until you understand the distinction, every guide you read will feel like it skipped a chapter.

This article is that chapter. We are going to cover what a core is, where it comes from, how to install one without nuking your existing setup, which core to pick for each system when accuracy actually matters, how to keep the whole pile updated, and how to wring lower latency out of your hardware with core-specific overrides. By the end you will have a working configuration you can copy verbatim. We will be precise about versions, honest about the failure modes, and we will not pretend any of this is as friendly as the marketing implies.

What a Core Actually Is (and Isn't)

The single most useful sentence in this entire article: RetroArch is a frontend, not an emulator. Internalize that and ninety percent of the confusion evaporates.

The frontend is a container, the core is the engine

RetroArch's official documentation frames cores as dynamically loadable programs backed by the Libretro API. The frontend handles the boring-but-critical scaffolding — video output, audio sync, input mapping, save states, shaders, netplay, rewind, the user interface — and the core handles the actual emulation of a Super Nintendo, a PlayStation, an arcade board, or in some cases a non-emulator game engine entirely. When you read in the official core library documentation that you load a core through Load Core and then pair it with a ROM through Load Content, that two-step dance is the architecture. The frontend is not the emulator. It is the box the emulator ships in.

This is why RetroArch can claim, on its own site, over 200 cores spanning emulators, game engines, multimedia programs, and other content types. No single emulator author wrote two hundred of anything. Instead, dozens of independent emulator projects were ported to a shared API, and RetroArch exposes all of them through one consistent interface. You learn one set of menus, one save-state hotkey, one shader pipeline, and it works across every system you can find a core for.

Why the Libretro API matters beyond RetroArch

Here is the part the casual user never notices and the power user never forgets: a core is not bound to RetroArch. The official site is explicit that cores are reusable by any frontend implementing Libretro. The same snes9x_libretro.so file that runs inside RetroArch on your desktop can be loaded by a completely different frontend on a handheld, a TV box, or a custom build. The core is simultaneously a distribution unit and a compatibility layer: emulator developers target one API instead of reinventing video and input plumbing for every platform, and frontends get instant access to a huge library without writing emulation code. That is the editorial significance of the whole model. The core is the product. RetroArch is one of several stores that sell it.

Cores are not all emulators

A common misreading is that "core" is just RetroArch's word for "emulator." Close, but not exact. Many cores are emulators — Snes9x, Beetle PSX, Genesis Plus GX. But others are native game engine reimplementations (think open-source engine ports that play original game data without emulating any console at all) and a handful are multimedia or utility cores. The distinction matters when you go hunting in the Core Downloader and find entries that don't correspond to any console you've ever owned. They aren't bugs. They are the long tail of a two-hundred-plus library that grew far past its 16-bit origins. If you are coming from a single-system handheld like the ones we cover in the Miyoo Mini Plus game list breakdown, this breadth is exactly the trade-off: more flexibility, more rope to hang yourself with.

Prerequisites: Versions and Hardware

You cannot tune what you cannot run, and you cannot run cores that your hardware cannot feed. Before step one, get the boring inventory right.

Software you need installed

You want a current stable build of RetroArch. As of mid-2026 that means the 1.21.x stable line or newer from the official channel — do not run a three-year-old package out of a distro repository and then file complaints when the Online Updater hands you cores built against a newer API. On desktop, install from the official site or, on Windows, the Steam build (which keeps cores in a slightly different folder, noted below). On Linux, the Flatpak from Flathub is the path of least resistance and keeps the core directory sandboxed and predictable.

Critically, the platform must support dynamic module loading. This is the feature that lets the official documentation promise that new or updated cores do not require a full RetroArch reinstall. Desktop Windows, macOS, Linux, Android, and most handheld Linux distributions support it. A few locked-down console ports do not, and on those platforms cores are baked into the build and the Online Updater is either absent or cosmetic. Know which camp you are in before you start.

Hardware reality check

An 8-bit or 16-bit core will run on a potato. A Nintendo NES core sips cycles. The hardware question only becomes interesting once you climb the ladder. Accuracy-focused cores like Mesen for NES or BSNES for SNES cost noticeably more CPU than their fast counterparts, because cycle-accurate emulation is, by definition, doing more work per frame. And the modern PlayStation 2 core, LRPS2, which the official site describes as using a brand-new Vulkan-powered LLE renderer called ParaLLEl GS, will simply not start on a machine without a working Vulkan driver. "LLE" — low-level emulation — means it is emulating the GS graphics synthesizer at a low level rather than translating its calls to your GPU at a high level, and that fidelity is not free. If you are running this on a handheld, cross-reference the silicon; our Retroid Pocket 6 review covers the kind of SoC that handles Vulkan cores without crying.

The directory layout you must understand

RetroArch stores cores in a specific directory, and you will eventually need to find it. The location is configurable under Settings → Directory → Cores, but the defaults are worth memorizing.

# Default core directory by platform

Windows (standalone):  C:\RetroArch-Win64\cores\
Windows (Steam):       %APPDATA%\..\..\steamapps\common\RetroArch\cores\
Linux (Flatpak):       ~/.var/app/org.libretro.RetroArch/config/retroarch/cores/
Linux (native):        ~/.config/retroarch/cores/
macOS:                 ~/Library/Application Support/RetroArch/cores/
Android:               /data/data/com.retroarch/cores/   (or app-specific dir)

# Cores are platform-specific shared objects:
#   .dll  on Windows
#   .so   on Linux / Android
#   .dylib on macOS
# A Windows .dll will NEVER load on Linux. There is no cross-platform core binary.

That last comment is not decoration. The number one support thread in every RetroArch community is someone who copied a .dll onto a Linux handheld and cannot understand why nothing loads. Cores are compiled native code. The right binary for the wrong platform is just a paperweight.

Installing Your First Cores: 12 Steps

This is the spine of the article. Twelve numbered steps, each with the reasoning attached, because a step you don't understand is a step you can't debug. This sequence mirrors the workflow documented in Retro Game Corps' starter guide, which remains the canonical onboarding path in 2026 precisely because the order has not changed.

1. Launch RetroArch and confirm your version. Go to Main Menu → Information → System Information and read the build version. Rationale: every later step assumes your core info files will match this build. If you skip this and later download cores that refuse to load, this is the number you'll be asked for.
2. Update the core info files first. Main Menu → Online Updater → Update Core Info Files. Rationale: info files are the metadata that tells RetroArch what each core is, what systems it supports, what BIOS it needs, and whether it's compatible with your build. Updating these before downloading cores means the Core Downloader shows you accurate, current entries instead of stale ones.
3. Update assets. Online Updater → Update Assets. Rationale: assets are the menu icons, fonts, and UI graphics. Skipping this won't stop emulation, but you'll stare at a menu full of missing-image placeholders and wonder if the install failed. It didn't. You just skipped the wallpaper.
4. Update controller profiles (autoconfig). Online Updater → Update Controller Profiles. Rationale: this downloads the autoconfiguration profiles so your gamepad maps correctly the moment you plug it in. Get this in place before you start testing cores, or you'll misdiagnose a mapping problem as a core problem.
5. Update databases. Online Updater → Update Databases. Rationale: the databases power scanning — RetroArch matches your ROM files against known checksums to build clean playlists. Without current databases, the scanner will leave legitimate games unmatched and you'll assume your ROMs are bad.
6. Update cheats. Online Updater → Update Cheats. Rationale: optional, but cheap and one-time. The cheat database is keyed per-game and per-core; grabbing it now means it's there later when you want it, with no second trip.
7. Update overlays and shaders. Online Updater → Update Overlays, then Update GLSL/Slang Shaders. Rationale: shaders are how you get CRT scanlines and the assorted filters that make pixel art look intentional. Slang shaders require Vulkan or a modern GL driver; GLSL is the more portable fallback. Download the set that matches your video driver.
8. Open the Core Downloader. Main Menu → Online Updater → Core Downloader. Rationale: this is the storefront. Every one of the 200-plus cores lives here, listed by system and core name. You will install cores one by one — there is deliberately no "install everything" button, because installing everything is a waste of space and a recipe for the wrong-core-loaded confusion we'll cover in pitfalls.
9. Download one core for one system you actually own ROMs for. Start with something forgiving — Nintendo - SNES (Snes9x) or Sega - Mega Drive/Genesis (Genesis Plus GX). Rationale: proving the pipeline end-to-end with one easy system tells you the install path works before you fight with a finicky PS2 core. Debug the simple case first.
10. Load the core manually once. Main Menu → Load Core, select the core you just downloaded. Rationale: doing this by hand, separate from loading content, makes the two-step Load Core / Load Content model concrete. You will see exactly what "the frontend loaded an engine" means before automation hides it from you.
11. Load content and verify a game boots. Main Menu → Load Content, browse to a ROM, select it. Rationale: this is the moment of truth. If the game runs, your core, your assets, and your input config are all correct. If it doesn't, you now have exactly one variable to investigate instead of twelve.
12. Scan your ROM directory to build playlists. Main Menu → Import Content → Scan Directory, point it at your ROM folder. Rationale: once the databases (step 5) are current, scanning produces tidy per-system playlists with proper game names and boxart. From now on you launch games from playlists, RetroArch auto-selects the associated core, and you never touch Load Core manually again — unless you're deliberately switching cores, which we'll get to.

Expected output: a successful core load

When step 11 goes right, RetroArch's log (visible if you launch from a terminal, or via Settings → Logging → Frontend Logging Level set to verbose) prints something close to this:

[INFO] [Core]: Using core: "Nintendo - SNES / Snes9x".
[INFO] [Core]: Loading dynamic libretro core from: "~/.config/retroarch/cores/snes9x_libretro.so"
[INFO] [Core]: Version of libretro API: 1, Compiled against API: 1
[INFO] [Content]: Content loading skipped. Implementation will load it on its own.
[INFO] [Core]: Content ran for a total of: 00 hours, 00 minutes, 03 seconds.
[INFO] [Audio]: Set audio input rate to: 31950.00 Hz.
[INFO] [Video]: Set video size to: 1280x896.
[INFO] [SRAM]: SRAM will be saved to "~/.config/retroarch/saves/game.srm".

The two lines that matter: Loading dynamic libretro core from confirms dynamic module loading is working (no reinstall needed for future cores), and Version of libretro API: 1, Compiled against API: 1 confirms the core and frontend agree on the API. A mismatch here is the single most common reason a downloaded core refuses to start.

Choosing the Right Core Per System

In 2024 the question was "is there a core for this?" In 2026 the question is "which core, and what am I optimizing for?" Core selection has graduated from a works/doesn't-work binary into a genuine quality and accuracy decision. Most systems offer two or three cores: a fast one, an accurate one, and sometimes a feature-rich one.

Accuracy-first picks

XDA Developers' accuracy-focused breakdown lays out the cores that prioritize fidelity over speed, and the list is worth following if your hardware can afford it. For NES, Mesen is the accuracy benchmark. For Super Nintendo, BSNES (and its higan lineage) emulates the hardware closely enough to expose bugs that faster cores paper over. For Sega systems — Master System, Genesis/Mega Drive, Game Gear — Genesis Plus GX is the accurate workhorse. For arcade, MAME-based cores reproduce the original boards rather than approximating them. The cost is CPU: cycle-accurate emulation does more work per frame, full stop. On a desktop you'll never notice. On a budget handheld you might.

Speed and feature picks

When the accurate core is too heavy, the system-by-system optimization that modern tutorials emphasize comes into play. For PlayStation, you choose between Beetle PSX (accurate, with an HW variant that supports internal upscaling and PGXP geometry correction) and a lighter alternative when the hardware is tight. For Sega Genesis on weak silicon, PicoDrive trades some accuracy for speed and even covers Sega CD and 32X. The pattern is consistent: a heavyweight accurate core and a lightweight fast core per family, and you pick per platform based on what you're running on. This is the same logic that drives distro choices on dedicated boxes — see how it plays out on a full build in our Batocera v43.1 flashing walkthrough, where core defaults are tuned per system out of the box.

The modern frontier: LRPS2 and PS2

The PlayStation 2 is the line in the sand for 2026. The LRPS2 core brings PCSX2-class PS2 emulation into RetroArch, and the official site's description of its Vulkan-powered LLE renderer called ParaLLEl GS is the headline technical detail. ParaLLEl GS emulates the Graphics Synthesizer at a low level, which is what makes it accurate and what makes it demanding. If your platform lacks a Vulkan driver, LRPS2 is a non-starter — not a configuration problem, a hard requirement. This is the clearest illustration of how core selection now intersects with rendering architecture: picking a PS2 core is also picking a renderer, a GPU API, and a hardware floor. There is no "just works" path; there is the path your silicon can actually walk.

Keeping Cores Updated Without Reinstalling

The best architectural decision RetroArch ever made was decoupling core updates from frontend updates. You update the engine without reinstalling the car.

The two update paths

The official documentation describes the primary route plainly: Main Menu → Online Updater → Update Cores. On any platform with dynamic module loading, this pulls fresh core binaries straight from the buildbot, and — this is the part worth repeating — it does not require a full RetroArch reinstall. The frontend stays put; only the .so / .dll / .dylib files get swapped.

There's a second, more convenient route that the Retro Game Corps guide highlights: Update Installed Cores. Instead of re-downloading every core in the library, this updates only the cores you already have. In practice this is the button you actually use, because core maintenance is an ongoing process, not a one-time install. Emulator authors push fixes constantly; a core you installed in January is meaningfully different by June.

# What "Update Installed Cores" does, conceptually:
#
# 1. Enumerate every core present in your cores/ directory
# 2. Query the buildbot for each one's current build timestamp
# 3. Download + replace only cores with a newer build available
# 4. Leave the frontend, your configs, and your saves untouched
#
# Equivalent on a CLI-driven / scripted setup (Linux, conceptual):

cd ~/.config/retroarch/cores/
for core in *.so; do
    echo "Installed: $core"   # cross-reference against buildbot listing
done
# In practice: just use Online Updater -> Update Installed Cores.
# Manual buildbot fetching is for headless / locked-down platforms only.

Why third-party builds still exist

The official buildbot is not the only source of cores, and that's healthy. A December 2025 rebuild of the webosbrew/retroarch-cores project reported over 170 cores built for WebOS on armv7 — i.e., LG smart TVs. That number tells you something: third-party packaging of RetroArch cores remains active well outside the main RetroArch ecosystem, because the Libretro API is open and any community can compile cores for any platform the official buildbot ignores. If you're on an unusual target, the relevant GitHub repo is often where your cores actually come from. This is the same open-build energy that keeps projects like the ones in our RetroPie for PC status report alive years past their supposed expiry dates.

How often to update

Resist the urge to update before every session. Cores can regress — a build that fixes one game can break another, and the buildbot ships the latest commit, not the most stable one. A sane cadence: update info files and run Update Installed Cores roughly monthly, or when you hit a specific bug and want to check whether it's already fixed upstream. Before a big update, back up your cores/ directory so you can roll back a single binary if a new build misbehaves. We'll put that backup step into the final configuration.

Core Overrides and Run-Ahead Latency Tuning

This is where cores stop being a compatibility concern and start being a tuning surface. RetroArch lets you save settings at three scopes: global, per-core, and per-game. The per-core scope — the core override — is the one that earns its keep.

What an override actually is

By default, every setting you change applies globally. A core override is a saved snapshot of settings that applies only when a specific core is loaded. Want bilinear filtering off for your pixel-accurate SNES core but on for a 3D PlayStation core? Override per core. Want run-ahead on for a fighting game core but off for a CPU-heavy one? Override per core. The settings live in a small config file next to your main config, and they layer on top of the global config when the matching core loads. Save one via the in-game menu: Quick Menu → Overrides → Save Core Overrides.

Run-ahead: the latency feature worth understanding

The Retro Game Corps guide specifically recommends Run-Ahead to Reduce Latency for certain cores, and saving those settings as core overrides — a concrete, real example of cores affecting not just compatibility but feel. Run-ahead works by running the emulator's internal logic one or more frames into the future, then displaying the result immediately, effectively cancelling out the input lag that the original hardware (and the emulation pipeline) introduces. The cost is CPU: the core runs the frame more than once. That's exactly why you scope it per core — you enable it where the latency win matters and the CPU headroom exists, and you leave it off everywhere else.

# Quick Menu -> Latency -> Run-Ahead settings to set, then
# Quick Menu -> Overrides -> Save Core Overrides to persist.
#
# The resulting file (example for Snes9x on Linux):
#   ~/.config/retroarch/config/Snes9x/Snes9x.cfg

# --- Snes9x.cfg (core override) ---
run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"
run_ahead_hide_warnings = "true"
video_smooth = "false"
video_shader_enable = "true"
# Everything not listed here falls through to the global retroarch.cfg.

Start with run_ahead_frames = "1". One frame of run-ahead removes roughly one frame of latency and is affordable on most hardware. Two frames is greedy; only push it if your CPU laughs at the core and you can actually perceive the difference. The secondary_instance option runs a second copy of the core to do the look-ahead, which is smoother but doubles the CPU cost — a trade you make per core, on purpose. None of this is worth doing on a high-latency display or a laggy wireless pad; fix those first, the same way you'd minimize the chain before tuning a streaming setup like in our PS Remote Play latency guide.

Per-game overrides for the stubborn cases

Below core overrides sit game overrides (Save Game Overrides), which apply to a single ROM. Use these sparingly — for the one game in a system that needs a specific aspect ratio, a per-title cheat, or a control remap that would be wrong everywhere else. The precedence is global, then core override on top, then game override on top of that. Most users never need the game layer. When you do, it's the surgical tool.

Common Pitfalls and How to Fix Them

Every one of these has burned thousands of people. None of them is exotic. Read this section before you ask anyone for help.

Pitfall 1: Wrong-platform core binary

You downloaded a .dll on Windows, copied it to a Linux handheld, and it won't load. Cores are compiled native code. A Windows DLL cannot run on Linux or Android, and there is no universal binary. Fix: only ever use the Core Downloader on the device itself, or grab the binary built for that exact platform and architecture (armv7 vs aarch64 vs x86_64 — they're different builds too).

Pitfall 2: Core info files out of sync

You downloaded a fresh core, but it doesn't appear in playlists or won't associate with content, or it loads but reports a libretro API mismatch. This is almost always stale core info files. Fix: run Online Updater → Update Core Info Files, then restart RetroArch. Always update info files before cores, not after. This is step 2 of the install sequence for a reason.

Pitfall 3: Missing BIOS files

The core installs fine and then games refuse to boot, or boot to a black screen. Many systems — PlayStation, PS2, Sega CD, Neo Geo — require original BIOS/firmware files that RetroArch cannot legally distribute and does not ship. Fix: place the correctly-named, correct-checksum BIOS files in Settings → Directory → System/BIOS. Then check Information → Core Information, which lists exactly which BIOS files the loaded core wants and whether each was found. Don't guess; read the list.

Pitfall 4: Vulkan-required core on a non-Vulkan setup

LRPS2 (or any Vulkan-only core) crashes on launch or refuses to start. The renderer — ParaLLEl GS for LRPS2 — needs a working Vulkan driver, and your platform doesn't have one. Fix: set Settings → Drivers → Video to vulkan and confirm your GPU drivers actually expose it. If your hardware genuinely can't do Vulkan, that core is simply not available to you. This is a hardware floor, not a setting you can wish away.

Pitfall 5: Arcade ROM set version mismatch

Your MAME or FBNeo core loads but throws checksum errors or refuses individual games. Arcade cores are pinned to a specific ROM set version (e.g., a particular MAME romset revision). Mixing a romset from one MAME version with a core built for another produces exactly these errors. Fix: match your arcade ROM set version to the core's expected version. Check the core's info/documentation for the target romset, and don't assume "arcade is arcade." It isn't.

Pitfall 6: Override saved at the wrong scope

You tuned run-ahead beautifully, saved it, and now it's applying to every system or to none. You saved a game override when you meant a core override, or vice versa. Fix: delete the stray override file from ~/.config/retroarch/config/<CoreName>/ (or the game-specific one), reload the correct core, set your options, and use Quick Menu → Overrides → Save Core Overrides deliberately. Watch the on-screen confirmation message — it tells you which scope you just wrote.

Troubleshooting Table

When something breaks mid-session, scan this table before you panic. Each row is a symptom mapped to its most likely cause and the fix that resolves it most of the time.

Reading the verbose log

When the table doesn't solve it, the log will. Set Settings → Logging → Frontend Logging Level to 0 (Debug) and Log to File on, then reproduce the problem. The log names the exact core path it tried to load, the API versions, the BIOS files it searched for, and the precise point of failure. Ninety percent of "unsolvable" core problems are solved by one line in a verbose log that the user never bothered to read.

When to roll back a core

If a previously-working game broke right after an update, the new core build regressed. Don't assume your data is corrupt. Restore the previous core binary from your backup (you made one, per the update section), or use the buildbot's archive to fetch an older build of that single core. The fact that you can swap one .so file without touching anything else is the entire point of the architecture — use it.

Advanced Tips for Core Power Users

Once the basics are solid, these are the moves that separate a working setup from a tuned one.

Lock cores you've dialed in

RetroArch lets you lock an installed core so that Update Installed Cores skips it. If you've spent an evening getting a specific arcade core and its matching romset working perfectly, lock the core (Quick Menu → Manage Core → Lock Installed Core) so a future bulk update can't silently swap it for a build that breaks your romset. Locking is the quiet feature that prevents the most frustrating regression: the one you didn't ask for.

Pin renderers and resolution per core

Combine core overrides with per-core video settings. A 2D core wants integer scaling, no bilinear filtering, and a CRT shader. A 3D core like Beetle PSX HW wants internal upscaling (2x–4x), PGXP for geometry, and possibly a different shader. Save each as a core override and RetroArch flips the entire video pipeline automatically when you switch systems. You stop fiddling and start playing.

# Example: Beetle PSX HW core override
# ~/.config/retroarch/config/Beetle PSX HW/Beetle PSX HW.cfg

video_driver = "vulkan"
# Core-specific options live in a separate .opt file:
# ~/.config/retroarch/config/Beetle PSX HW/Beetle PSX HW.opt
beetle_psx_hw_renderer = "vulkan"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_pgxp_mode = "memory only"
beetle_psx_hw_pgxp_texture = "enabled"
beetle_psx_hw_widescreen_hack = "disabled"

Use core options files directly

Every core exposes its own options — internal resolution, region, audio interpolation, accuracy toggles — through Quick Menu → Core Options. These persist in a .opt file. For repeatable, scriptable setups (multiple handhelds, a shared family build, a documented configuration you can version-control), editing the .opt files directly is faster than clicking through menus on each device. The format is the same key/value pairs you see above. Treat your config directory like infrastructure, because on a multi-device setup, it is. This is the same discipline that makes flashing a fresh image painless on dedicated hardware — the kind of repeatability we lean on in the Batocera flashing guide.

A Complete Working Configuration

Here is a configuration you can adapt verbatim. It assumes a Linux desktop or capable handheld with Vulkan; adjust paths for your platform using the directory table from the prerequisites section. This is the global config plus the override structure that ties everything together.

The global retroarch.cfg essentials

# ~/.config/retroarch/retroarch.cfg  (essentials only — RetroArch writes the rest)

# --- Directories ---
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/cores"
system_directory = "~/.config/retroarch/system"   # BIOS files go here
savefile_directory = "~/.config/retroarch/saves"
savestate_directory = "~/.config/retroarch/states"
video_shader_dir = "~/.config/retroarch/shaders"

# --- Video ---
video_driver = "vulkan"
video_fullscreen = "true"
video_vsync = "true"
video_smooth = "false"            # off globally; 3D cores re-enable via override

# --- Audio ---
audio_driver = "alsathread"
audio_sync = "true"

# --- Latency (global baseline; run-ahead set per-core) ---
run_ahead_enabled = "false"

# --- Overrides + logging ---
core_specific_config = "false"     # use the modern per-core override system instead
log_verbosity = "false"            # flip to true only when troubleshooting
log_to_file = "false"

The per-core overrides

# A 2D accuracy/latency profile — ~/.config/retroarch/config/Snes9x/Snes9x.cfg
run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"
video_smooth = "false"
video_shader_enable = "true"

# A 3D upscaling profile — ~/.config/retroarch/config/Beetle PSX HW/Beetle PSX HW.cfg
video_driver = "vulkan"
video_smooth = "true"
run_ahead_enabled = "false"        # too heavy to run-ahead on most hardware

# A lightweight fast profile for weak silicon — PicoDrive.cfg
video_smooth = "false"
run_ahead_enabled = "false"

The maintenance routine

# A sane monthly maintenance routine (do these in order):
#
# 1. Online Updater -> Update Core Info Files     (metadata first, always)
# 2. Back up the cores directory before touching binaries:
cp -r ~/.config/retroarch/cores ~/.config/retroarch/cores.bak
# 3. Online Updater -> Update Installed Cores      (only what you have)
# 4. Online Updater -> Update Databases            (keeps scans clean)
# 5. Launch one game per system to confirm nothing regressed
# 6. If a core regressed, restore the single binary:
cp ~/.config/retroarch/cores.bak/<corename>_libretro.so \
   ~/.config/retroarch/cores/
# 7. Lock any core you've perfectly tuned so step 3 skips it next time.

That's the whole system. Frontend stays put. Cores update independently. Per-core overrides flip your entire video and latency pipeline when you switch systems. Backups make every update reversible at the granularity of a single binary. None of it requires reinstalling RetroArch, because the architecture was designed — deliberately, and unusually well — to never make you do that.

The closing argument

The reason any of this is worth learning is the same reason the core model is the defining feature of RetroArch in 2026: you are not betting on one emulator. You are buying into an interface that two hundred-plus engines plug into, maintained by people who will never all quit at once, packaged for platforms the original authors never imagined — LG TVs included. The frontend is the part that lasts. The cores are the part that improves. Learn the seam between them and you'll still be playing on this setup long after whatever single-purpose emulator you'd have chosen instead has gone unmaintained. For more on dedicated hardware that bakes this philosophy in, the RetroPie for PC writeup covers the same decoupling at the OS level. The lesson generalizes: own the container, rent the contents.