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

A fresh RetroArch install is a chassis with no engine. You can open it, admire the menus, tweak the shaders, and load precisely nothing, because the front-end and the emulators are two different things. The emulators are cores, and on desktop they do not ship inside the installer — you fetch them afterward. This is the single fact that trips up every first-timer, and every year a new crop of setup videos rediscovers it as if it were breaking news.

RetroArch's own documentation is blunt about the architecture: it is a modular program that runs emulators and games within its framework as if they were "plugins", and the catalogue has over 200 cores, and the list keeps expanding over time. That is the good news and the trap in one sentence. Two hundred cores is a lot of rope. This tutorial is about installing the fifteen you will actually use, in the correct order, without hanging yourself on the other one hundred and eighty-five. Budget thirty minutes. Most of that is deciding what you want; the mechanical part takes ten.

What a Core Actually Is

The plugin model

RetroArch is a front-end. It draws the menus, handles input, runs the video and audio pipeline, manages save states and shaders and netplay. It does not emulate anything. The emulation lives in a core: a self-contained dynamic library that implements the libretro API — one standardized set of function calls RetroArch uses to feed a core input and content and pull back frames and sound. On a desktop that library is a file: snes9x_libretro.so on Linux, snes9x_libretro.dll on Windows, snes9x_libretro.dylib on macOS. Swap the library, swap the machine you are emulating. Nothing else about RetroArch changes.

Because the boundary is a stable API, cores update independently of the app. RetroArch's official core page makes the selling point explicit: you don't need to download a new version of RetroArch in order to be able to run new or updated cores. That is why a 2019 RetroArch build can still load a 2026 core, and why the correct maintenance habit is to update cores far more often than you update the front-end itself.

The exception is platforms without dynamic loading. On game consoles and certain locked-down mobile targets — a static homebrew build, the iOS app — cores are compiled directly into the binary and you cannot download more. On those, "installing a core" means installing a different build of RetroArch. Desktop, Android, and most Linux handhelds get the buildbot and the downloader.

Not just emulators

The word "core" gets used as a synonym for "emulator," and that is mostly right but not entirely. The RetroArch project lists the full set: cores include game engines, games, multimedia programs and emulators. The libretro API does not care whether the thing behind it is a Super Nintendo or a Doom source port. So the same Load Core list that offers Snes9x also offers PrBoom (Doom), TyrQuake (Quake), DOSBox-Pure (an entire PC-DOS environment), ScummVM (point-and-click adventures), a native port of Cave Story, and toys like 2048. This matters for a practical reason: not every core needs a ROM. When you are debugging a "core won't load content" problem, remember that some cores are the content.

The 200-plus number, in context

"Over 200 cores" is a catalogue figure, not a per-device promise. The buildbot compiles cores for many platforms, and no single platform gets all of them. An x86_64 Windows or Linux box sees essentially the whole list. An ARM handheld running a community build might see a curated 170-ish — the webosbrew ARMv7 rebuild in December 2025 shipped around that number — because some cores have no ARM target, some are too heavy to be worth shipping, and some are x86-only by design. So when a guide breathlessly says "200-plus cores," read it as "the library is enormous; your device sees a large subset of it." The correct response to a large subset is not to install all of it, which we will get to.

Prerequisites: Versions and Hardware

Software

Install the current stable RetroArch. As of mid-2026 that is 1.22.2, released 20 November 2025; the 1.22 line also shipped 1.22.0 and 1.22.1 earlier that month (1.22.0 had a shader black-screen bug fixed in the point releases). The prior milestone, 1.21.0, landed 29 April 2025. Pull it from the official releases page or your platform's channel — and get it from a channel that leaves the Core Downloader enabled. On Windows, winget install Libretro.RetroArch or the Chocolatey and itch.io builds are fine. On Linux and the Steam Deck, the Flatpak keeps the downloader; the Ubuntu PPA deliberately disables it (see Pitfalls). Do not mix a nightly RetroArch with stable cores or vice versa; keep the app and the cores on the same buildbot channel.

You will also want a little disk headroom. Cores are small individually — a few hundred kilobytes to a few megabytes each — but the info-file bundle, the asset pack, and the system database add up, and disc-based systems want room for BIOS files and (compressed) games. A gigabyte of free space is comfortable for the front-end, cores, and metadata before you add any content.

Hardware, honestly

Cores are not equal in appetite. 8-bit and 16-bit systems run on anything made this decade, including a Raspberry Pi and every ARM handheld. The cliff edges are specific and worth memorizing: cycle-accurate SNES via bsnes wants roughly a 4 GHz core to hold full speed; PlayStation 2 emulation through the libretro LRPS2 core is desktop x86_64 only, with no serious ARM story; Sega Saturn's accurate cores are heavy; and even "light" systems get expensive once you stack internal-resolution upscaling and run-ahead. If you are shopping for a handheld to run these, that is its own argument — our Retroid Pocket 5 vs 6 breakdown maps where the ARM ceiling actually sits for PS1, DS, PSP, and the low end of PS2.

A rough tier list: NES, SNES, Genesis, GB, GBA, PS1, N64 are comfortable on any modern x86 laptop or a mid-range ARM handheld. Saturn, Dreamcast, PSP, DS, 3DS want a real CPU and, for the 3D systems, a GPU with a current driver. PS2, GameCube, Wii are desktop-class asks; the libretro cores exist, but this is where a dedicated standalone emulator sometimes still wins.

BIOS and content you're allowed to run

RetroArch ships no games and no BIOS images, for the obvious legal reasons. Emulators themselves are settled law — clean-room reimplementation is protected, as Sony v. Connectix and Sega v. Accolade established — but the copyrighted BIOS and the ROMs are yours to source legitimately, which in practice means dumping hardware you own. PlayStation, Saturn, Neo Geo, and the NAOMI/Atomiswave arcade sets will not boot without their firmware in the system/ directory, hashed correctly. For the sanctioned cartridge route, our Retrode cartridge-dumping walkthrough shows how to pull your own SNES and Genesis carts to files a core will accept. Keep BIOS files in system/; each core's info file declares exactly which ones it wants.

How RetroArch Finds and Loads Cores

The cores directory and the info directory

Two directories run the whole show. The Cores directory holds the libraries themselves; the Core Info directory holds a matching .info file for each core. RetroArch reads the info directory to build the "which cores exist and what can they do" picture, and it reads the cores directory to actually load one. Point either at the wrong place, or make either read-only, and the downloader quietly fails. Here is a sane Linux layout; Windows portable installs mirror it under the RetroArch folder with a leading :\ token meaning "the folder retroarch.cfg lives in."

~/.config/retroarch/
├── retroarch.cfg          # main config
├── cores/                 # the cores themselves: *.so / *.dll / *.dylib
│   ├── snes9x_libretro.so
│   ├── mgba_libretro.so
│   └── flycast_libretro.so
├── info/                  # *.info manifests — one per core, stems must match
│   ├── snes9x_libretro.info
│   └── flycast_libretro.info
├── system/                # BIOS / firmware (scph5501.bin, dc_boot.bin, neogeo.zip)
├── playlists/             # *.lpl scanned game lists (JSON)
├── config/                # per-core and per-game overrides
├── saves/                 # battery saves (*.srm)
└── states/                # save states

The keys that point at these live in retroarch.cfg. You rarely edit them by hand — the menu writes them — but knowing they exist turns "the downloader does nothing" from a mystery into a two-line check.

# retroarch.cfg — core-relevant keys (the menu writes these for you)
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/info"
system_directory = "~/.config/retroarch/system"
core_updater_buildbot_url = "http://buildbot.libretro.com/nightly"
core_info_cache_enable = "true"
core_updater_auto_extract_archive = "true"

Core info files: the manifest that must come first

An info file is a small text manifest. It declares the core's display name, the file extensions it accepts, the system database it maps to, its licence, and — critically — any BIOS or firmware it requires. RetroArch reads this before a core is even downloaded, which is why the metadata has to be current first. Download a core against stale info and RetroArch may list it with no friendly name, refuse to associate it with your ROM extensions, or fail to warn you about a missing BIOS. Here is the shape of one:

# snes9x_libretro.info (excerpt)
display_name = "Nintendo - SNES / SFC (Snes9x - Current)"
authors = "Snes9x Team"
supported_extensions = "smc|sfc|swc|fig|bs|st"
categories = "Emulator"
database = "Nintendo - Super Nintendo Entertainment System"
license = "Non-commercial"
firmware_count = "0"

That firmware_count line is the difference between a game that boots and a black screen. When a core lists required firmware, RetroArch's Core Information screen shows each file and whether it found it in your system directory. This is the first place to look when content refuses to launch. The canonical set of these manifests lives in the libretro-super info repository, which is exactly what Update Core Info Files pulls.

The buildbot and the nightly-versus-stable line

Cores come from RetroArch's buildbot, an automated build server that compiles every core for every supported platform. The downloader is just a front-end to that server. It has two channels: stable, rebuilt when RetroArch tags a release, and nightly, rebuilt continuously. A stable RetroArch pulling nightly cores (or the reverse) is the classic cause of a core that downloads cleanly and then crashes on load, because the libretro API contract can drift between them. Match your channels. If you installed stable 1.22.2, take stable cores.

Installing Cores: 12 Numbered Steps

The order below is deliberate. The most common failure — a downloaded core that shows up nameless or won't touch your ROMs — is caused by doing step 7 before step 4. Follow the sequence. The libretro download-cores guide walks the same path if you want the upstream wording.

1. Update the front-end first. A core targets the front-end's libretro API version, so update the app before the cores and let the two agree. On Windows, winget upgrade Libretro.RetroArch; on a Steam Deck or Linux, flatpak update org.libretro.RetroArch; on macOS, brew upgrade --cask retroarch. Rationale: updating cores against an old front-end reintroduces the exact ABI mismatch you are trying to avoid.
2. Enable the Core Downloader if it's hidden. Go to Settings → User Interface → Menu Item Visibility and switch on Show 'Core Downloader'. Rationale: some builds hide it by default, and you cannot use a menu you cannot see.
3. Confirm your directories are writable. In Settings → Directory, check that the Cores and Core Info paths point somewhere you own. Rationale: the downloader writes files; a read-only or root-owned path makes it fail silently. This is the number-one cause of "Update Cores does nothing" on Linux.
4. Online Updater → Update Core Info Files. Do this before downloading a single core. Rationale: the info files are the manifests from the previous section; refreshing them first means every core you then download arrives named, categorized, and aware of its BIOS needs.
5. Online Updater → Update Assets and Update Databases. Rationale: assets are the menu icons and on-screen keyboard; databases are the ROM-hash lists that let RetroArch name your games during a scan. Neither is a core, but skipping them makes playlists ugly and scanning unreliable.
6. Decide your shortlist before you download anything. Rationale: with 200-plus cores available, the temptation is Select All. Resist it. A bloated Load Core list slows startup and buries the cores you use. Pick the systems you own games for; the next section is a ready-made shortlist.
7. Online Updater → Core Downloader, and pick cores one by one. Alternatively, from a content screen use Load Core → Download a Core for the same list. Rationale: the Core Downloader is the à-la-carte menu; select exactly the cores on your shortlist. If you already have cores and just want them current, use Update Installed Cores instead — it refreshes everything in one pass.
8. Verify a core actually installed. Open Load Core; your new core should appear with a human name (e.g. Nintendo - SNES / SFC (Snes9x - Current)), not a raw filename. Rationale: a friendly name confirms the matching info file is present. A filename-only entry means step 4 didn't take — repeat it and restart.
9. Import your content. Use Import Content → Scan Directory and point it at a folder of ROMs. Rationale: scanning hashes your files against the databases from step 5 and builds per-system playlists automatically, which is how per-playlist core assignment becomes possible.
10. Assign a default core to each playlist. Open a playlist, then its right-hand options, and set the default core. Rationale: this is the "which emulator runs this system" decision, made once per system instead of once per game. Per-game overrides still win where you set them.
11. Run Update Installed Cores periodically. Rationale: this is your maintenance verb. It re-pulls every core you have from the buildbot in one action — the fastest way to stay current without walking the Core Downloader again. Do it after every front-end update.
12. Save and sanity-check with a verbose launch. Load a game; if it boots, save your config via Settings → Configuration → Save Configuration on Exit, or scope it through Quick Menu → Overrides. To debug, launch from a terminal with --verbose and read the log. Rationale: the log names the exact core file it loaded and the exact content path, turning guesswork into a two-line diagnosis.

Steps 4 through 7 all live under one menu tree, which is worth seeing as a shape:

Main Menu
 └─ Online Updater
      ├─ Update Core Info Files      <- (1) run this FIRST
      ├─ Core Downloader             <- (2) pick individual cores
      ├─ Update Installed Cores      <- refresh everything you already have
      ├─ Update Assets
      └─ Update Databases

A successful download plus the verbose launch from step 12 should read roughly like this:

[INFO] [Updater]: Starting download: snes9x_libretro.so.zip
[INFO] [Updater]: Extracting to: ~/.config/retroarch/cores/snes9x_libretro.so
[INFO] [Updater]: Download complete.
[INFO] [Core]: Loading dynamic libretro core from: "cores/snes9x_libretro.so"
[INFO] [Core]: Version of libretro API: 1, Compiled against API: 1
[INFO] [Content]: Using content: "~/ROMs/SNES/Chrono Trigger.sfc"

The 2026 Core Shortlist by System

Named-core guidance is a genre unto itself, and reasonable people disagree at the margins. What follows is a defensible default for 2026: the core to install first, the alternative worth knowing, and the reason. Community mappings converge on the same short list — FinalBurn Neo for arcade and Neo Geo, Mesen for NES, Snes9x for SNES, PPSSPP for PSP — and the table below extends that across the systems most people actually run.

Nintendo

NES belongs to Mesen, which is PPU-accurate, handles the awkward mappers, and ships a debugger; FCEUmm or Nestopia UE are lighter if you're on weak silicon. SNES is a two-answer question: Snes9x is the practical, handheld-friendly pick, while bsnes (Accuracy) is cycle-accurate and wants that 4 GHz core. For N64, Mupen64Plus-Next is the mainline core — it bundles the GLideN64, angrylion, and ParaLLEl-RDP renderers so you can trade accuracy for speed per game. It had a rough patch in early 2025 where a handful of titles refused to load; the 1.22-era builds are the ones to run. Reach for ParaLLEl N64 only when you want its Vulkan low-level renderer on a specific title and can live with narrower compatibility and no GLideN64. Game Boy and GBC go to SameBoy (accuracy plus proper link-cable) or Gambatte; GBA to mGBA; DS to melonDS; and 3DS to Azahar, the community continuation that picked up the pieces after Citra was pulled in 2024.

Sega and arcade

Genesis Plus GX covers Mega Drive/Genesis, Sega CD, Master System, Game Gear, SG-1000, and Pico — but not 32X. For 32X you install PicoDrive, which is also the go-to Genesis core on weaker Android hardware. Dreamcast, NAOMI, Atomiswave, and System SP all run on Flycast, flyinghead's actively-maintained fork of the old reicast — the reicast cores are deprecated and gone, and the arcade sets want MAME-format BIOS archives in system/. For coin-op proper, FinalBurn Neo handles CPS1/2/3, Neo Geo, Cave, and a deep 1970s-onward library, with current MAME as the catch-all for anything FBNeo doesn't cover.

Sony and the heavy end

PS1 is a three-way call. Beetle PSX HW is the accuracy king with a hardware renderer and internal-resolution upscaling; SwanStation (a DuckStation-derived core) is the great all-rounder; and PCSX ReARMed is the lightweight that powers budget handhelds, muOS, OnionOS, and ROCKNIX. PSP is a single strong answer: PPSSPP. PS2 runs on LRPS2, a hard fork of PCSX2 with Themaister's new ParaLLEl-GS renderer — it is desktop x86_64 only, needs a real BIOS, and only reached the downloader with the 1.22 line in late 2025. Saturn splits between Beetle Saturn (accurate, heavy) and Kronos (x86_64, faster). At this end, the honest advice is that a standalone emulator sometimes still edges the core — but for a single unified front-end, these are the picks.

Per-Game and Per-Playlist Assignment

The playlist default core

Once you scan content, RetroArch stores each system as a playlist — a .lpl file, which since the 1.x format is human-readable JSON. Setting a playlist's default core is the once-per-system decision from step 10. It writes two keys at the top of the file:

{
  "version": "1.5",
  "default_core_path": "~/.config/retroarch/cores/snes9x_libretro.so",
  "default_core_name": "Nintendo - SNES / SFC (Snes9x - Current)",
  "scan_content_dir": "~/ROMs/SNES",
  "items": [
    {
      "path": "~/ROMs/SNES/Chrono Trigger.sfc",
      "label": "Chrono Trigger",
      "core_path": "DETECT",
      "core_name": "DETECT",
      "db_name": "Nintendo - Super Nintendo Entertainment System.lpl"
    }
  ]
}

default_core_path and default_core_name apply to every game in the list unless an individual item overrides them. Each item's core_path and core_name set to DETECT means "use the playlist default." This is why importing a folder of SNES games and setting Snes9x once just works.

Pinning a core to a single game

Sometimes one game misbehaves on the system default — a homebrew that only runs on bsnes, a PAL oddity that wants a different renderer. Load that game, open Quick Menu → Set Core Association, and RetroArch rewrites just that item's core_path to the specific core. The rest of the playlist keeps the default. This is the per-game selection those 2026 setup videos demonstrate after import: the same system can show multiple cores, and you choose per title.

DETECT, and why a system shows multiple cores

The libretro docs note that many consoles have multiple cores, and the front-end leans into it. When you launch content with the core set to DETECT and no default, RetroArch offers every installed core whose info file claims your file extension. That is a feature — it lets you A/B two emulators on the same ROM — but it is also why a tidy setup pins defaults. An unassigned library forces the picker on every single launch.

Run-Ahead and Latency Tuning

Run-Ahead

Run-Ahead is the closest thing emulation has to a cheat code for input lag. It runs the core one or more frames into the future each display frame, using the rewind machinery, so the frame you see already reflects your input — cancelling out the buffered latency that emulation and modern displays add. Enable it under Settings → Latency. Start at 1 frame and stay within 1–3 for most systems; going higher trades away more CPU and eventually causes visual glitches.

# Settings > Latency (written to retroarch.cfg)
run_ahead_enabled = "true"
run_ahead_frames = "1"                 # start at 1; stay within 1-3
run_ahead_secondary_instance = "true"  # accurate, but ~doubles CPU
preempt_frames_enable = "false"        # lighter alternative — never enable both
video_frame_delay = "0"                # 0 = auto
video_max_swapchain_images = "2"       # lower = less buffered latency

There is a cost. Classic run-ahead in second-instance mode loads the core twice and runs both, so your CPU budget roughly doubles. On a strong desktop that is nothing; on a handheld it can push a borderline system over the edge. Which is the whole reason for the next setting.

Preemptive Frames, the lighter path

Preemptive Frames is the newer, cheaper alternative to second-instance run-ahead. Instead of running a whole second copy of the core, it saves a state and re-runs the last few frames within the single instance when your input changes. For cores with fast, small save states it delivers most of run-ahead's latency win at a fraction of the CPU cost. If second-instance run-ahead is too heavy on your device, disable it and enable Preemptive Frames instead — never both at once.

The rest of the latency stack

Run-ahead is the big lever; a few smaller ones finish the job. Frame Delay (set to 0 for auto) pushes emulation later in the frame to shave display latency, backing off automatically if it can't keep up. Max Swapchain Images at 2 reduces buffered frames versus the default 3. On a variable-refresh display, enabling Sync to Exact Content Framerate with VRR keeps everything locked without the latency of plain V-Sync. None of these touch which core you run, but they decide how the core feels.

Cores Under Batocera, RetroPie, LaunchBox

Turnkey distros bundle the cores for you

If you are running a dedicated emulation box, you may never see the Core Downloader, because the distro pre-loads a curated set of libretro cores and hides the plumbing. Batocera ships a vetted core list per architecture and updates them with the OS image rather than à la carte, which is why its N64 or PS1 default might differ from what you'd pick on a desktop RetroArch. RetroPie exposes cores through its own script manager (install or update per core), and its release cadence lags upstream — worth knowing when a core you want is newer than the RetroPie build offers. In both cases the cores are the same libretro binaries; only the delivery mechanism differs.

Handhelds and the architecture caveat

On ARM handhelds the rule is: never hand-copy a core across devices. A core built for x86_64 will not load on an ARM CPU, and a core from a different ARM build can still mismatch the front-end's API. Update from inside that device's RetroArch so you get the right binary. The curated firmwares — OnionOS on the Miyoo Mini Plus, or the stock Android RetroArch on a Retroid — handle this for you, which is exactly why they are curated: fewer cores, all guaranteed to run.

LaunchBox and the command line

Front-ends that aren't RetroArch — LaunchBox/BigBox, Playnite, ES-DE — launch RetroArch from the command line and pass the core with the -L flag. That is the seam where core migrations happen. The textbook case: moving a Sega NAOMI or Sammy Atomiswave platform off the dead reicast_libretro core and onto flycast_libretro. In LaunchBox you edit the emulator's associated platform to point at the new core file; on the command line it's a one-word change:

:: External front-ends pass the core to RetroArch with -L
:: Load one SNES game with Snes9x:
retroarch.exe -L "cores\snes9x_libretro.dll" "C:\ROMs\SNES\Chrono Trigger.sfc"

:: Migrate a Naomi / Atomiswave platform off the dead reicast core:
::   OLD:  -L "cores\reicast_libretro.dll"
::   NEW:  -L "cores\flycast_libretro.dll"
retroarch.exe -L "cores\flycast_libretro.dll" "C:\ROMs\Atomiswave\game.zip"

The lesson generalizes. Any external front-end stores the core as a named *_libretro file path, so a rename or deprecation (reicast → flycast, Citra → Azahar) means updating that string wherever the front-end recorded it, not just inside RetroArch.

Common Pitfalls and Fixes

Every one of these has generated its own forum thread a thousand times over. Here is the short version, with the fix.

1. You downloaded a core and it shows up nameless, or won't touch your ROMs. You skipped Update Core Info Files. The core is fine; RetroArch just has no manifest for it. Run Online Updater → Update Core Info Files, restart, and it will populate the name and extensions.
2. The core loads but the game is a black screen or won't boot. Missing or wrong-hash BIOS. PS1, Saturn, Neo Geo, and NAOMI/Atomiswave need firmware in system/. Open the core's Information screen; it lists each required file and whether it was found. Supply the correct-hash file, don't guess.
3. Update Cores does nothing on Linux. Either you installed via the Ubuntu PPA (which disables the downloader on purpose) or your Cores directory isn't writable. For the PPA, install cores with the package manager instead — sudo apt-get install libretro-CORENAME. Otherwise point the Cores directory at a folder you own.
4. "Failed to open libretro core." Architecture or bitness mismatch — an x86_64 core on ARM, or a hand-copied file from another platform. Delete it and re-download from inside that exact RetroArch build. Never copy cores between devices.
5. A core downloads cleanly, then crashes the moment it loads. Nightly-versus-stable channel drift. Your front-end and cores are from different buildbot channels. Reinstall so both are stable (or both nightly) and re-run Update Installed Cores.
6. The "wrong" core keeps launching one specific game. A leftover per-game override is pinning a core path — often one you've since removed. Delete the override under config/ (or Quick Menu → Overrides → Remove) and the game falls back to the playlist default.
7. Your Genesis and Sega CD games run, but 32X won't. Genesis Plus GX doesn't do 32X. Install PicoDrive and assign it to the 32X content. The same species of confusion applies to NAOMI on reicast — that core is gone; use Flycast.
8. Everything is slow after you installed "all" the cores. A giant cores directory bloats the Load Core list and lengthens startup while RetroArch reads every info file. Trim to your shortlist, and enable core_info_cache_enable so the metadata is read once and cached.

Troubleshooting Table

Symptom-first, because that's how you actually meet these problems.

Advanced Tips

Manual install from the buildbot

When the in-app downloader is unavailable — a locked-down device, a firewall, a platform you're side-loading anyway — you can install a core by hand. Grab the *_libretro archive for your exact platform from buildbot.libretro.com/nightly, extract the library into your Cores directory, and drop the matching .info into your Core Info directory. The two must agree by filename stem. Restart, and it's indistinguishable from a downloaded core. This is also how you pin a specific older core version that the downloader would otherwise overwrite.

Core options and the override ladder

Cores expose their own settings — renderer, internal resolution, region, controller quirks — under Quick Menu → Core Options, saved per core in config/CORE NAME/. Overrides stack in a strict priority order, most specific winning: per-game beats per-content-directory beats per-core beats global. That ladder is the single most useful thing to internalize: set a global default, relax it per core, and pin the exceptions per game. Here is a Beetle PSX HW option file that turns on the Vulkan hardware renderer and 4× upscaling for PlayStation only:

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

Save it via Quick Menu → Overrides at the scope you want, and RetroArch applies it only there.

Netplay, achievements, and renderer gotchas

Three things bite people who mix cores casually. Netplay requires both players to run the identical core and version; a minor mismatch desyncs instantly. RetroAchievements is native to RetroArch now, but its "hardcore" mode only registers on specific cores flagged compatible — the fast-but-loose core you picked for speed may not qualify. And renderer choice gates cores: ParaLLEl's Vulkan low-level path needs a Vulkan-capable driver, several hardware-accelerated cores want OpenGL or D3D11/12, and switching RetroArch's video driver can silently break a core that was working. When a core misbehaves after "nothing changed," check whether the video driver changed.

A Complete Working Configuration

The retroarch.cfg core section

Pull all of the above together and the core-relevant portion of a working retroarch.cfg looks like this. Paths are Linux; on Windows portable, replace the home paths with the :\cores token form. These are sane defaults — you rarely touch them once set.

# ==== Directories ====
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/info"
system_directory = "~/.config/retroarch/system"
playlist_directory = "~/.config/retroarch/playlists"
rgui_config_directory = "~/.config/retroarch/config"

# ==== Core updater ====
core_updater_buildbot_url = "http://buildbot.libretro.com/nightly"
core_updater_auto_extract_archive = "true"
core_info_cache_enable = "true"

# ==== Latency ====
run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"
preempt_frames_enable = "false"
video_frame_delay = "0"
video_max_swapchain_images = "2"

# ==== Content handling ====
automatically_add_content_to_playlist = "true"
scan_without_core_match = "false"
config_save_on_exit = "true"

How the layers fit together

That config, plus the one-item SNES playlist with a pinned default_core_path from the per-game section, plus the Beetle PSX .opt from the advanced section, is a complete, layered setup. Front-end config points at the directories and the buildbot; each playlist names its system's default core; and per-core option files carry the settings that only make sense for that emulator. Nothing overlaps, and each layer overrides cleanly upward — global, then core, then directory, then game. When something behaves unexpectedly, you now know exactly which of those four files to open.

A 60-second sanity checklist

Before you call it done: front-end updated; Core Downloader visible; directories writable; Update Core Info Files run before any core; shortlist installed, not the whole catalogue; each playlist has a default core; BIOS in system/ for the disc and arcade systems; run-ahead at 1 frame; and a verbose launch that boots a real game. Tick those and you have a RetroArch that loads cores the way the project intends, instead of the way the forums suffer.

The core system is why RetroArch outlived every front-end that tried to replace it, and why it will still be here when the next one tries. It is also, on day one, why it does nothing. Do these twelve steps once, and it does everything.