RetroArch Cores 2026: Full Setup, 12 Steps, 20 Min

RetroArch is not an emulator. That sentence trips people up for a week, then it clicks, and afterward nothing about the software confuses them again. RetroArch is a frontend: a shell that handles menus, input remapping, save states, rewind, shaders, achievements, and netplay, then hands the actual job of pretending to be a Super Nintendo to a separate plug-in. That plug-in is a core. The core is the emulator. RetroArch is the building it rents an office in.

Internalize that division of labor and the rest of this tutorial is bookkeeping. Miss it, and you will lose an afternoon convinced RetroArch "can't run" a game when in truth you never installed the module that can. This guide is about the cores: what they are, where they come from, which ones to install in 2026, how to update them without reinstalling anything, and how to stop the frontend from silently loading the wrong one and blaming you for it.

We are writing against RetroArch 1.22.2, published on 20 November 2025, with a backward glance at 1.21.0 (29 April 2025) — the release that shipped the new PlayStation 2 core and sat comfortably past the point where the libretro catalogue was described as holding over 200 cores spanning emulators, game engines, standalone games, and multimedia programs. RetroArch itself is GPLv3 and open source, with north of 13,000 stars on GitHub. If you are running something older than the 1.22 line, update before you do anything else; a depressing share of the "my core keeps crashing" reports online are a 2023 binary trying to read a 2026 save format.

What a RetroArch Core Actually Is

Before you download a single module, understand what you are downloading. A core is not a game, not a BIOS, and not a settings profile. It is a self-contained emulator compiled to a specification, and everything downstream — which systems you can play, how accurate they are, how much CPU they eat — is decided at this layer, not in the RetroArch menus.

The libretro API in one paragraph

A core is a shared library — a .dll on Windows, a .dylib on macOS, a .so on Linux and most handhelds — that implements the libretro API. That API is a small, deliberately boring contract. The core promises to expose a handful of functions: "give me one frame of video," "give me one frame of audio," "here is the current controller state," "load this content," "reset." RetroArch calls those functions sixty times a second and paints the result on your screen. Because the contract is stable and shared, one frontend can drive a Game Boy emulator, a DOS interpreter, a Vulkan-based PlayStation renderer, and a Doom engine port without knowing a thing about their internals. That is the entire trick, and it is why the project can advertise a library of more than 200 cores without any single one of them knowing RetroArch exists.

Why "200+ cores" is a catalogue number, not a promise

Here is the caveat every breathless listicle omits: 200+ is the size of the catalogue, not the number of cores that will appear on your device. The libretro buildbot compiles each core for every platform it can, and plenty of cores never build for weak ARM chips, 32-bit targets, or Apple Silicon. On desktop x86_64 you will watch the Core Downloader list swell past 100 cores in a single alphabetical scroll. On an ARM handheld the number shrinks — a December 2025 webOS rebuild shipped roughly 170 armv7 cores, and cheaper devices see fewer still. LRPS2, the PlayStation 2 core, is x86_64-only; no amount of wishing compiles it for your Miyoo. The Steam edition tells the same story from another angle: its announcement feed logged the build reaching 60 cores when DirkSimple was added and 65 cores when Dosbox Pure landed. Different distribution, different count. When someone insists RetroArch "has" a core, the only correct response is: on which platform?

Cores versus standalone emulators

Most major cores are ports of standalone emulators, and the port is rarely a perfect clone. Beetle PSX descends from Mednafen; the libretro LRPS2 core announced on 29 April 2025 is a heavily modified fork of PCSX2, rebuilt against the libretro API and shipped at launch with a brand-new Vulkan LLE renderer on Windows, macOS, and Linux. Sometimes the core leads — RetroArch's run-ahead latency reduction is a frontend feature no standalone shipped first. Sometimes the standalone leads: DuckStation's independent builds, which the RetroBat changelog logs at version 0.1.11295.0 on 10 May 2026, routinely land features months before the equivalent core does. The practical lesson is that a core is a living thing chained to an upstream project, and "which is better, the core or the standalone" has a genuinely different answer every quarter. Anyone who gives you a permanent answer is selling something.

Prerequisites, Hardware, and BIOS

Tutorials that skip this section produce the bulk of the world's "black screen, please help" posts. Three things gate whether a core will run at all: a current RetroArch, hardware that can actually keep up, and — for a surprising number of systems — a legally-dumped BIOS in the right folder with the right name.

Software versions you actually need

Get onto the 1.22 line and stay there. The point release matters: 1.22.0 shipped a shader black-screen regression that was fixed in 1.22.1 and 1.22.2, so if you grabbed the very first 1.22 build and your overlays vanished, that is a known bug, not your GPU dying. Installation and updates are one command on every desktop platform:

# Windows (winget) — installs the stable build
winget install Libretro.RetroArch

# Update later WITHOUT touching your cores, saves, or configs
winget upgrade Libretro.RetroArch

# Steam Deck / Linux (Flatpak)
flatpak update org.libretro.RetroArch

# macOS (Homebrew cask)
brew upgrade --cask retroarch

# Verify — should report 1.22.2 or newer
retroarch --version

Expected output on a healthy install:

RetroArch 1.22.2 (Git a1b2c3d)
=== Build =======================================
Capabilities:  SSE SSE2 SSE3 SSSE3 SSE4 SSE4.2 AVX AVX2
Built: Nov 20 2025

The hardware reality check

Cores are not equally hungry, and the frontend will happily let a weak CPU choke on an accurate core rather than warn you. The heavyweights are cycle-accurate emulators and the modern consoles. bsnes in its Accuracy profile is a genuine cycle-accurate SNES emulator that wants roughly a 4 GHz CPU core to hold full speed — overkill for Super Mario World, mandatory for the SA-1 and SuperFX edge cases. LRPS2 is x86_64-only and leans on its ParaLLEl-GS renderer, so it needs a real desktop GPU, not integrated graphics from 2016. Low-level N64 and Saturn cores similarly assume compute headroom you will not find on a phone. On the other end, ARM handhelds live on lightweight cores by necessity; a Retroid Pocket-class handheld runs the same libretro ecosystem as your PC but from a much smaller shelf of ARM builds, and a budget device like the Miyoo Mini Plus tops out around the PlayStation 1 era for exactly this reason. If you are building on a Raspberry Pi, note that RetroPie packages RetroArch and its cores for you, which changes the update workflow described below.

BIOS files and where they go

Many cores refuse to boot without a system BIOS: PlayStation 1, PlayStation 2, and Sega Saturn all need one; the NES and SNES do not. RetroArch looks for these in the system directory, and the filenames and checksums must match what the core expects, byte for byte. The law is simple and unromantic: those files are copyrighted, and the defensible way to obtain them is to dump them from hardware you own. Verify integrity before you ever blame a core for a bad boot:

# system/ — PlayStation 1 BIOS examples (dump from YOUR console)
scph5500.bin   # NTSC-J
scph5501.bin   # NTSC-U
scph5502.bin   # PAL

# Confirm the file is what the core expects before troubleshooting anything else
sha1sum system/scph5501.bin
# 8dd7d5296a650fac7319bce665a6a53c6efe5bd7  system/scph5501.bin

A mismatched or truncated BIOS produces exactly the same black screen as a broken core, which is why so many people misdiagnose it. Check the hash first; it takes five seconds and saves an hour.

Installing Cores From the Buildbot

You almost never install cores by hand. RetroArch supports dynamic module loading, which means the frontend can pull a fresh core off the libretro buildbot and load it at runtime — no new app version, no reinstall, no restart on most platforms. The official cores page says as much, and it is the single most under-appreciated feature in the whole project: your cores are updated independently of RetroArch itself.

Core Info Files come first — genuinely first

The most common way to arrive at an "empty downloader" or a list of cores that "fail to load" is to skip the info-file step. Core info files are the manifest — the metadata that tells RetroArch each core's display name, which systems it handles, which file extensions it accepts, and which BIOS it wants. Without a current manifest, the downloader has nothing to describe and the frontend cannot match a ROM to a core. So before you download a single module: Online Updater → Update Core Info Files. Do it first, do it again any time the downloader looks wrong.

Main Menu
  → Online Updater
      → Update Core Info Files      <-- DO THIS FIRST
      → Core Downloader             <-- then this
      → Update Installed Cores      <-- later, to refresh everything

The Core Downloader

With info files current, open Online Updater → Core Downloader and you get the alphabetical list — well over 100 cores on desktop. If the Core Downloader is missing entirely, it has been hidden: go to Settings → User Interface → Menu Item Visibility → Show Core Downloader and switch it back on. Pick the core you want, select it, and RetroArch fetches the platform-correct build, decompresses it, and drops it in your cores folder. On Debian and Ubuntu you can alternatively pull specific cores from the package manager with sudo apt-get install libretro-<core>, though the buildbot builds are fresher.

Updating without reinstalling anything

Because cores are separate modules, they drift out of date on their own schedule, and the frontend gives you a one-pass fix: Online Updater → Update Installed Cores walks every core you have downloaded and pulls the latest build from the buildbot in a single operation. This matters more than it sounds. Many users treat cores as static and never touch them again after install, then wonder why a bug fixed months ago still bites them. Note one 2026 wrinkle: a buildbot change on 24 May 2026 replaced older files for installs predating that date, so anyone on a pre-May-2026 install should run Update Installed Cores once; post-that-date installs need no manual intervention. Here is the whole cycle end to end:

# The correct update order, every time:
1. Online Updater  -> Update Core Info Files      # refresh the manifest
2. Online Updater  -> Update Installed Cores      # refresh the binaries
3. (optional) Online Updater -> Update Databases  # refresh ROM-matching DBs

# On the OS side, keep RetroArch itself current independently:
winget upgrade Libretro.RetroArch          # Windows
flatpak update org.libretro.RetroArch      # Linux / Steam Deck

Load a Core and a Game in 12 Steps

Here is the full path from a fresh install to a running game, grouped into three phases and annotated with the reasoning behind each step so you can debug your own mistakes instead of pasting them into a forum. Twelve steps, about twenty minutes the first time, ninety seconds every time after.

Phase 1: Install and place the core

1. Update Core Info Files. Online Updater → Update Core Info Files. Rationale: the manifest has to be current or the downloader is blind — it cannot name or categorize cores it has no metadata for. This is the step people skip and the reason their downloader looks broken.
2. Open the Core Downloader. Online Updater → Core Downloader. Rationale: this is dynamic loading in action — you are pulling a platform-correct binary from the buildbot, not bundling one into the app. If it is missing, unhide it under Settings → User Interface → Menu Item Visibility.
3. Pick one correct core, not all of them. Choose the core for your target system (see the verdict below). Rationale: downloading every core wastes space and buries the ones you use behind dozens you do not. Curate deliberately.
4. Download the core. Select it; RetroArch fetches, extracts, and installs it into the cores folder. Rationale: the frontend handles decompression and placement so the file lands where the loader expects it — doing this by hand is how you end up with a core RetroArch cannot see.

Phase 2: Point RetroArch at your files and boot

1. Set the System/BIOS directory. Settings → Directory → System/BIOS. Rationale: PS1, PS2, and Saturn cores read their BIOS from here; get this wrong and the symptom is identical to a broken core.
2. Load the core. Main Menu → Load Core → pick your freshly-downloaded module. Rationale: the core must be resident before content, because the core is what parses the content — RetroArch itself does not know what a .sfc file is.
3. Load content. Main Menu → Load Content → browse to your ROM or disc image. Rationale: now the loaded core receives the file and boots it. Loading content first, with no core, is the single most common beginner error.
4. Confirm it actually booted. Watch for the system's boot logo or the game itself. Rationale: a running game is proof the core-plus-BIOS-plus-ROM chain is intact; anything else is a diagnosable failure, not a mystery.

Phase 3: Tune, save, and maintain

1. Open Core Options. Quick Menu (default hotkey F1) → Core Options. Rationale: this is where the core exposes its own knobs — renderer, internal resolution, region — and these belong to the core, not to RetroArch. Changing them here changes the emulator's behavior directly.
2. Save a scoped override. Quick Menu → Overrides → Save Core Overrides (or Save Game Overrides). Rationale: this writes your tweaks to a file that loads automatically next time without polluting your global config — the difference between a tidy setup and a house of cards.
3. Update Installed Cores periodically. Online Updater → Update Installed Cores. Rationale: cores are maintained upstream on their own cadence; a monthly refresh pulls in fixes you would otherwise never see.
4. Back up your config folder. Copy the whole config/ directory and retroarch.cfg somewhere safe. Rationale: your overrides, remaps, and per-game options live here; cores re-download in seconds, but your configuration does not.

The System-by-System Core Verdict (2026)

This is the section you actually came for. RetroArch ships multiple cores per system and refuses to tell you which to use, on the reasonable grounds that the answer depends on your hardware and your priorities. Here is the 2026 shortlist, opinionated and current. Accuracy costs CPU; practicality costs accuracy; pick your poison per system.

Nintendo: NES, SNES, N64, and the handhelds

For the NES, the accuracy crown in 2026 belongs to Mesen — the most accurate NES core available, with PPU-level precision, the broadest mapper support, and a full debugger for the curious. Nothing else is close on correctness. For the SNES, bsnes in Accuracy mode is cycle-accurate and definitive, provided you feed it that ~4 GHz core; on weaker or portable hardware, Snes9x is the practical choice and is wrong about almost nothing you will notice. For the Nintendo 64, tread carefully. The mainline core, mupen64plus-next, bundles GLideN64 for high-level rendering plus angrylion and the ParaLLEl-RDP/RSP plugins, and RetroArch recommends it as the default — but it suffered a real regression in early 2025 where titles like Stunt Racer 64 and World Driver Championship stopped loading, and the community pinned an older January build to cope. When accuracy matters more than compatibility breadth, the low-level Parallel N64 core (Vulkan LLE) is the fallback. If clean N64 output is your whole reason for being here, it is worth understanding how much heavy lifting these plugins do — the same problem a dedicated device like the Analogue 3D solves in hardware with its internal upscaler. For Game Boy Advance, use mGBA; for Game Boy and Game Boy Color, mGBA or Gambatte both do the job cleanly.

Sony and Sega: PS1, PS2, Saturn, Genesis

For the PlayStation 1, the recommended core in 2026 is Beetle PSX HW — the Mednafen-derived core with a hardware renderer, the most accurate option and the one that scales cleanly to high internal resolutions on a desktop. It is heavy; that is the trade. On ARM handhelds it is impractical, and the light, fast PCSX ReARMed is what powers most budget devices and distributions like muOS, OnionOS, and ROCKNIX. SwanStation, the DuckStation libretro port, sits between them as a solid middle option. For the PlayStation 2, LRPS2 — the hard fork of PCSX2 with the ParaLLEl-GS renderer by Themaister — is the practical RetroArch choice, but remember its constraints: x86_64 only (Windows, Linux, and macOS via Rosetta; no Android, iOS, or ARM Linux), a real BIOS required, and the GameIndex.yaml compatibility data now embedded in the core itself. For the Sega Saturn — still one of the genuinely hardest systems to emulate, thanks to its dual SH-2 CPUs, the SCU DSP, and the twin VDP1/VDP2 video chips — Beetle Saturn remains the recommended core. For the Sega Genesis / Mega Drive and its family, Genesis Plus GX is superb, covering Mega Drive, Sega CD, Master System, Game Gear, SG-1000, and Pico with 100% compatibility — with the one asterisk that it does not do the 32X, for which you switch to PicoDrive.

Arcade and the awkward cases: MAME, FBNeo, 3DS

Arcade is where taxonomy fights philosophy. MAME is a documentation project first and a way to play games second; its mission is preservation-grade accuracy, and it is under constant maintenance — the Libretro forums carried a live thread titled "MAME .288 Core Update?" dated 1 July 2026, which is precisely the kind of arcade-core churn you should expect all summer. For actually playing most CPS-1, CPS-2, and Neo Geo titles, though, Final Burn Neo (FBNeo) is the preferred core — lighter, faster, and forgiving of ROM sets that MAME rejects on principle, with a library reaching back to the 1970s. The most instructive case in 2026 is the Nintendo 3DS: the long-standing Citra core is dead, taken down and removed from the ecosystem entirely. Its replacement is Azahar — a merge of the prominent Citra forks including PabloMK7's and Lime3DS — which shipped its first official libretro core in the 2125.0 Alpha 4 series across six operating systems and had advanced to a 2126.0 release candidate by mid-2026. The RetroBat changelog captured the swap plainly: it added the libretro Azahar core and removed the old citra core. If your 3DS core vanished, that is why, and Azahar is the fix. This churn is not a bug in the ecosystem; it is the ecosystem working. The "Core and Feature Requests" forum category alone stood at 880 replies and 125,441 views as of 22 June 2026 — a large, loud, actively-developing community that revises its recommendations in real time.

The Override Hierarchy Nobody Explains

Every serious RetroArch problem that is not a broken core is a configuration-scope problem. RetroArch loads settings in layers, and if you do not know the order, you will "fix" a setting in the wrong layer and watch it silently revert every time. This is the mechanism, laid bare.

Global, core, content-directory, game — in that order of authority

Settings cascade from least to most specific, and the most specific one wins. Global config (retroarch.cfg) is the base. A core override sits on top of it and applies to every game run on that core. A content-directory override is narrower still, applying to every game in a particular folder. A game override is the sharpest scalpel, applying to exactly one title. The precedence, from weakest to strongest:

global  <  core  <  content-directory  <  game

# On disk, that maps to:
retroarch.cfg                                  # global
config/<CoreName>/<CoreName>.cfg               # core override
config/<CoreName>/<DirName>.cfg                # content-dir override
config/<CoreName>/<GameName>.cfg              # game override

# Core OPTIONS (the emulator's own knobs) live separately:
config/<CoreName>/<GameName>.opt             # per-game core options
retroarch-core-options.cfg                      # global core options

# Input remaps have their own tree:
config/remaps/<CoreName>/<GameName>.rmp        # per-game controller remap

Saving an override without nuking global

The menu path is the safe way to write these files, because RetroArch computes the correct scope and diff for you. From inside a running game: Quick Menu → Overrides → Save Core Overrides or Save Game Overrides. RetroArch writes only the settings that differ from the layer beneath, so the file stays small and legible. To make per-game core options work at all, the master switch game_specific_options must be enabled; the related keys auto_overrides_enable and auto_remaps_enable control whether those files load automatically on boot. If your overrides mysteriously fail to stick, the usual villain is config_save_on_exit = "true" rewriting your global config out from under you on quit — turn it off once your base config is how you like it.

Core options versus RetroArch settings — not the same thing

This distinction trips up even experienced users. Core options belong to the emulator: internal resolution, renderer backend, region, PGXP mode. They live in .opt files and are set under Quick Menu → Core Options. RetroArch settings belong to the frontend: aspect ratio, shaders, run-ahead, audio latency. They live in .cfg files and are set under Settings. A game override (.cfg) will never change a core option, and a core-options file (.opt) will never change a shader. When a tweak refuses to apply, first ask which of the two things you are actually trying to change; half the time the setting is real but you are editing the wrong file.

Five Ways People Break Their Cores

These are the failure modes that fill support threads, each with the mechanism and the fix. None of them are exotic; all of them are self-inflicted, which is good news, because self-inflicted problems are curable.

Pitfall 1: Skipping the info files

You open the Core Downloader and it is empty, or you download a core and it "fails to load" or shows an unrecognized name. Nine times in ten you skipped Update Core Info Files. The manifest is not optional decoration; it is how RetroArch identifies and categorizes every core. Fix: Online Updater → Update Core Info Files, then retry. Make it a reflex before every download session.

Pitfall 2: Loading content before a core

You pick a ROM from Load Content and get a prompt asking for a core, or nothing happens. RetroArch does not know what a .sfc or .chd file is — the core does. Fix: Load Core first, then Load Content. Once you build playlists, RetroArch remembers the association and this disappears, but during setup it bites everyone.

Pitfall 3: The wrong core for the arch, silently

You copied a core folder from your PC to a handheld, or grabbed a build from a random link, and it will not appear or will not load. Cores are compiled per CPU architecture; an x86_64 .dll means nothing to an ARM device, and LRPS2 simply does not exist for ARM at all. Retroid Pocket owners hit this with cores like Coleco that never built for their target. Fix: only ever install through that device's own Core Downloader, which serves only builds that match its architecture. Never hand-copy cores between platforms.

Pitfall 4: BIOS that is missing, misnamed, or corrupt

A PS1, PS2, or Saturn game shows a black screen or an error, and you blame the core. The core is fine; the BIOS is absent, wrongly named, or a bad dump. Fix: place the correct file in your System directory, match the exact filename the core expects, and verify the SHA-1 hash as shown earlier. A hash check is the fastest diagnostic in the whole hobby and almost nobody runs it.

Pitfall 5: Stale saves and options after an update

You updated a core and now it crashes on load, or your carefully-tuned game looks wrong. Save states are tied to a core's exact internal layout and do not always survive an update; an old core-options file can also carry a setting the new build interprets differently. Fix: save-states break across versions by design — rely on in-game (SRAM) saves for anything you cannot afford to lose, and if a core misbehaves right after an update, reset its Core Options to default before assuming the update itself is broken. This is also the argument for backing up config/: your options are precious, your save states are disposable.

Troubleshooting: 10 Failures and Their Fixes

When a core misbehaves, resist the urge to post first and diagnose later. RetroArch will tell you what went wrong if you let it, and most failures resolve to one of ten patterns.

Read the verbose log first

Before anything else, reproduce the failure with logging turned up. Launch from a terminal with --verbose, or set Settings → Logging → Logging Verbosity to Debug and check the log. The line that matters is usually the last one before the crash — a missing BIOS, a failed renderer init, a content-load error. It is faster than guessing and far faster than waiting for a forum reply.

# Reproduce with logging so the failure explains itself
retroarch -L cores/beetle_psx_hw_libretro.dll "game.chd" --verbose

# A missing BIOS looks like this in the log — not a "broken core":
[libretro ERROR] Mednafen : Error opening BIOS file "scph5501.bin".
[ERROR] [Content]: Failed to load content.

The 10 most common failures

The nuclear option: reset to a known-good core

If a core is genuinely broken and no setting helps, delete it, delete its config/<CoreName>/ folder, run Update Core Info Files, and re-download it clean. This wipes stale options and any corrupt binary in one move. It is the emulation equivalent of turning it off and on again, and it works far more often than it has any right to.

Advanced: Run-Ahead, Subsystems, and Hard Sync

Once cores boot reliably, the frontend has features that reach into how the core behaves — latency, multi-cartridge hardware, and GPU pacing. This is where RetroArch stops being a launcher and starts being better than the standalone emulators it wraps.

Run-ahead: latency the original hardware never had

Run-ahead is RetroArch's headline latency feature: it runs the core one or more frames into the future, discards the visible frames, and re-simulates from a saved state so your input registers earlier — effectively removing the emulator's inherent input lag, sometimes below what the real console delivered. It is not free: it runs the core multiple times per displayed frame, so it demands CPU headroom, which is exactly why it pairs best with the lighter cores. Enable it under Settings → Latency, or bake it into an override:

# config/<CoreName>/<CoreName>.cfg — per-core run-ahead
run_ahead_enabled = "true"
run_ahead_frames = "1"                  # start at 1; raise only if lag persists
run_ahead_secondary_instance = "true"  # gentler on save-heavy cores, costs more CPU

Start at one frame. Most systems need no more, and every extra frame multiplies the CPU cost. If a core cannot hold full speed with run-ahead on, that is your hardware telling you to back off, not a reason to force it.

Subsystems: the cores that load two files at once

Some hardware needs more than one file: Super Game Boy wants a SNES ROM plus a Game Boy ROM; Sufami Turbo and certain multi-cart setups are similar. Cores expose these through subsystems, loaded from the command line or via specially-built playlists rather than the normal Load Content flow. On the command line the pattern is explicit:

# Load a core and content directly, with verbose logging
retroarch -L cores/beetle_psx_hw_libretro.dll \
  "roms/psx/Vagrant Story (USA).chd" --verbose

Expected verbose output when the chain is healthy:

[INFO] [Core]: Loading dynamic libretro core from: "cores/beetle_psx_hw_libretro.dll"
[INFO] [Core]: Version of libretro API: 1
[INFO] [Environ]: SYSTEM_DIRECTORY: "system".
[INFO] [Content]: Content loading skipped. Implementation will load it on its own.
[libretro INFO] Using HW renderer
[INFO] [Video]: Found GL context: "wgl"
[INFO] [Core]: Content ran for 1 frames.

Hard GPU Sync and the accuracy-versus-speed dial

Hard GPU Sync (video_hard_sync) forces the CPU to wait for the GPU to finish each frame, trimming latency at a small performance cost — the counterpart to run-ahead on the output side. Combined with the right core-option renderer, it is how you get a low-latency, high-resolution PlayStation 1 image out of Beetle PSX HW. The core option keys are real and worth knowing; for Beetle PSX HW the renderer accepts hardware, hardware_gl, hardware_vk, or software, internal resolution runs from 1x to 16x, and beetle_psx_hw_pgxp_mode takes disabled, memory only, or memory + CPU to correct the console's notorious polygon wobble. Every one of these is a documented, versioned setting — not a registry hack — which is the entire reason to prefer RetroArch's structured config over editing text files at random.

A Complete Working Configuration

Here is a coherent, annotated configuration you can adapt — the core-relevant slice of a real setup, showing the global directories, a per-core options file, and a per-core override working together. Nothing here is invented; every key is a genuine RetroArch or core option.

The global config: directories and updater

# retroarch.cfg — the core-relevant lines, annotated
# ":\" is RetroArch shorthand for "relative to the RetroArch base dir"
libretro_directory = ":\cores"
libretro_info_path = ":\info"
system_directory = ":\system"
core_updater_buildbot_cores_url = "http://buildbot.libretro.com/nightly"
core_updater_auto_extract_archive = "true"
core_info_cache_enable = "true"
menu_show_core_updater = "true"
game_specific_options = "true"   # required for per-game core options
auto_overrides_enable = "true"   # auto-load .cfg overrides on boot
auto_remaps_enable = "true"      # auto-load .rmp input remaps
config_save_on_exit = "false"    # keep RetroArch from rewriting global on quit

A per-core options file: Beetle PSX HW

# config/Beetle PSX HW/Beetle PSX HW.opt
# CORE options — these belong to the emulator, not to RetroArch.
beetle_psx_hw_renderer = "hardware_vk"           # Vulkan hardware path
beetle_psx_hw_internal_resolution = "4x"         # 1x..16x; 4x is a sane desktop default
beetle_psx_hw_pgxp_mode = "memory only"          # kills PS1 polygon wobble
beetle_psx_hw_dither_mode = "internal resolution"
beetle_psx_hw_widescreen_hack = "disabled"       # enable only for 3D-only games

A per-core override and the folder layout

# config/Beetle PSX HW/Beetle PSX HW.cfg
# RETROARCH-side override for this core: latency and aspect only.
aspect_ratio_index = "22"          # 22 = Core Provided
run_ahead_enabled = "true"
run_ahead_frames = "1"
video_hard_sync = "true"

# How the whole thing sits on disk:
RetroArch/
  cores/                          # the .dll/.so/.dylib modules
    mesen_libretro.dll
    beetle_psx_hw_libretro.dll
  info/                           # .info manifests — update these FIRST
  system/                         # BIOS (scph5501.bin, etc.)
  config/
    Beetle PSX HW/
      Beetle PSX HW.cfg           # per-core RetroArch override
      Beetle PSX HW.opt           # per-core options
  retroarch.cfg                   # global config

That is the whole model: a current frontend, cores pulled fresh from the buildbot, BIOS you dumped yourself and hash-checked, the right core chosen per system, and your tweaks written into scoped override files instead of smeared across the global config. Do it this way and RetroArch stops being a source of mysteries and becomes what it actually is — the most flexible way to run four decades of hardware from one window. For the primary sources, keep these bookmarked: the official RetroArch cores page, the libretro download-cores and overrides guides, the Libretro forums for live core-development traffic, the RetroArch releases on GitHub for exact version notes, and the per-core documentation for the option keys shown above. Cores change every quarter; the method in this guide does not.