RetroArch Cores: 12-Step Setup in 30 Min (2026)

RetroArch is the most-downloaded, least-understood piece of software in retro gaming. People install it, stare at a menu that looks like a PlayStation 3 having a quiet breakdown, get exactly one game running through sheer stubbornness, and then tell their friends it is confusing. It is not confusing. It is modular, which is a different and more forgivable thing, and the module you keep tripping over has a name: the core.

A core is the actual emulator. RetroArch itself emulates nothing. It is a shell, a set of hands, a universal remote with a lot of opinions about shaders. The core is the machine those hands are holding. Get the relationship between frontend and core straight and every other mystery in this program dissolves at once: why your ROM will not load, why the PlayStation boot logo never appears, why the settings you spent twenty minutes tuning evaporated the second you opened a different game. This tutorial installs, feeds, and configures cores on RetroArch 1.22.2 — the stable line current through 2026 — in twelve concrete steps, then hands you the BIOS checksums, the override hierarchy, the troubleshooting table, and the complete working config you actually came here for. Budget thirty minutes for a clean first system. Budget an evening if you insist on PlayStation upscaling on launch night, because you will, and it will be worth it.

What a Core Actually Is

Before you download anything, internalize the split. Ninety percent of RetroArch pain is somebody blaming the frontend for a problem that lives in the core, or vice versa. The two are separate programs that happen to share a window.

The libretro API, in one paragraph

libretro is a thin C application programming interface — a contract. On one side of the contract sits a frontend (RetroArch is the reference implementation, but not the only one). On the other side sits a core: a compiled emulator that agrees to expose a handful of standard functions — give me a frame, give me audio samples, take this controller input, save your memory to this buffer. Because the contract is stable and language-neutral, one frontend can drive dozens of emulators without knowing anything about how each one works internally. That is the whole trick. A core is literally a shared library file — .so on Linux and Android, .dll on Windows, .dylib on macOS — that RetroArch loads at runtime the way a browser loads a plugin. Nothing more mystical than that. The full contract is documented at the libretro developer docs, and the frontend that consumes it lives in the RetroArch GitHub repository.

Cores vs. standalone emulators

Most cores are not written from scratch. They are existing emulators wearing the libretro contract as a jacket. Beetle PSX is Mednafen's PlayStation module. PPSSPP the core is the same PPSSPP you would download standalone. mGBA the core is mGBA. gambatte, Snes9x, Genesis Plus GX, Flycast, melonDS — all of them exist as independent projects, and someone maintains a libretro port. The advantage of running them inside RetroArch is that you inherit a single unified feature set for free: one input configuration, netplay, rewind, run-ahead latency reduction, RetroAchievements, shaders, and save-state handling that all behave identically no matter which system you are emulating. The disadvantage is that a libretro port sometimes lags a few features behind its standalone parent, and a stubborn bug can hide in the jacket rather than the emulator. If you want zero abstraction — a chip-level hardware recreation with no operating system underneath it at all — that is the MiSTer FPGA conversation, and it is a different and considerably more expensive religion. Software cores are what ninety-nine percent of people should run, on hardware they already own.

Why the filenames look like line noise

Open your cores folder after this tutorial and you will see files named like snes9x_libretro.so, genesis_plus_gx_libretro.so, mednafen_psx_hw_libretro.so. The _libretro suffix is mandatory — it is how RetroArch identifies a file as a core rather than some unrelated library. The human-readable display names you see in the menu ("Snes9x", "Beetle PSX HW", "Genesis Plus GX") come from small companion text files with an .info extension that live in a separate info directory. Those info files also declare which file extensions each core accepts, whether it needs BIOS firmware, and its licensing. This matters more than it sounds: if your info files are out of date, the Core Downloader will show you a stale or empty list, and RetroArch will refuse to scan your ROMs into playlists. Updating them is Step 3, and it is the step everyone skips.

Prerequisites: Versions & Hardware

You need three things staged before you touch the Core Downloader: a current frontend, hardware that can actually run the systems you want, and content you are legally entitled to run. Skip the version check and you will spend an hour debugging an ABI mismatch that a two-minute update would have prevented.

Software: versions that matter

Install RetroArch 1.22.2 or newer, 64-bit, from retroarch.com, the official Steam listing, or your platform's package build — not a random APK mirror or a "modded" pack off a forum, which is how people end up with cores compiled against a frontend from 2020. The single most important compatibility rule in this entire guide: your cores must be built against the same libretro ABI as your frontend. The in-app Core Downloader guarantees this automatically because it pulls from the same buildbot that produced your RetroArch build. Mixing a 2026 core into a 2019 install produces the dreaded "Failed to load core" with no further explanation. Do not do it. If you are on a locked-down platform — iOS, a game console, a distro that ships RetroArch through a sandbox — confirm your cores directory is actually writable before you start, because a read-only cores folder makes the downloader fail silently, and you will swear the internet is broken when it is your filesystem.

Hardware: the per-system floor

Emulation cost scales roughly with how modern the console is, and 3D consoles cost far more than their 2D ancestors. A potato runs the 8- and 16-bit era. PlayStation and Nintendo 64 want a real CPU. Saturn, Dreamcast, and PSP want a good one, and anything with hardware-accelerated upscaling wants a genuine GPU exposing Vulkan or modern OpenGL. Here is the honest floor, using the cores this guide recommends:

This is why the handheld you pick changes which cores are realistic. A cheap ARM device happily plays everything through PSX but stumbles on Saturn; a modern flagship such as the Retroid Pocket 6 at $244 pushes into Dreamcast and PSP with upscaling, and the generational jump documented in our Pocket 5 versus 6 breakdown is precisely a jump in how many of these cores you can run at native-plus resolution. Match the core to the silicon, not to the screenshot.

What you need staged before Step 1

Three things. First, a writable RetroArch install with a known config location. Second, your own ROMs. The legal position is unambiguous and older than most of the people arguing about it: the emulator is lawful — Sony Computer Entertainment v. Connectix, 203 F.3d 596 (9th Cir. 2000), settled that reverse-engineering a console to run its software is fair use — but the game and the BIOS remain copyrighted works, and your license to them comes from the cartridge or disc in your drawer, not from a Mega link. This guide assumes you dumped your own. Third, BIOS firmware for the handful of cores that need it, dumped from the same hardware. Have all of it on disk before you open the menu, and the twelve steps go quickly.

Installing Cores: The 12 Steps

This is the spine of the tutorial. Every step includes its rationale, because "just click the thing" is why people cannot fix it when the thing does not work. Do them in order the first time; after that you will internalize which ones you can skip.

Before you touch a core

Set your directories first. RetroArch's defaults vary wildly by platform — portable Windows builds keep everything beside the executable, Linux uses ~/.config/retroarch, Android buries it in app storage. If you download cores before you know where they are landing, you will spend Step 8 hunting for files that are exactly where you told RetroArch to put them, which was nowhere in particular. Decide on a layout now. The complete config at the end of this guide gives you one that works.

The 12 steps

1. Install or verify RetroArch 1.22.2+. Launch it once and check Information > System Information for the version string. Why: cores are compiled against a specific libretro ABI; a mismatched frontend rejects them outright. This single check prevents the most common failure in the program.
2. Set your directories. Settings > Directory. Point Cores, System/BIOS, Save Files, Save States, and Config at explicit, writable folders. Why: a non-writable cores directory makes the downloader fail without an error, and scattered saves are how people lose progress after an update.
3. Update Core Info Files. Online Updater > Update Core Info Files. Why: the .info files gate the entire Core Downloader list and tell RetroArch which core plays which extension. Stale info files show you an empty or wrong menu. This is the step everyone skips and then complains about.
4. Update Assets, Databases, and Controller Profiles. Online Updater, three separate entries. Why: not cores, but the playlist scanner, thumbnails, and gamepad autoconfig depend on them. Doing it now saves you two support searches later.
5. Reveal the Core Downloader if it is hidden. Settings > User Interface > Menu Item Visibility > Show Core Downloader. Why: per the official download-cores guide, some packaged builds hide it by default, and you cannot download what you cannot see.
6. Open Online Updater > Core Downloader. Why: this is the canonical, version-matched source — it pulls signed builds from the libretro buildbot that produced your frontend. Downloading random .so files off a forum is how ABI mismatches and, occasionally, malware get in.
7. Pick the right core for the system. Consult the per-system table below before you scroll. Why: most systems have three-plus cores with different accuracy, speed, and BIOS behavior. Grabbing the first alphabetical result is why people conclude their hardware "can't run PS1" when they simply loaded the accuracy-first core on a weak chip.
8. Download it and confirm it landed in cores/. Why: this verifies your write path from Step 2. On desktop you can literally list the folder and see the file appear — expected output is shown below.
9. Load the core, then load content. Main Menu > Load Core > (your core), then Load Content > (your ROM). Or drive it from the command line. Why: this teaches the two-stage model — RetroArch associates a piece of content with a core, which is exactly why the same file can run under different emulators.
10. Place BIOS files in system/ if the core requires them. PlayStation, Saturn, Sega CD, PC Engine CD, Neo Geo, and others. Why: without correct firmware these cores give you a black screen or refuse to boot. Covered in full in the BIOS section.
11. Set core options and save them. Quick Menu > Core Options (also labeled just "Options"). Why: renderer, internal resolution, and region live here, separate from RetroArch's own settings. Saving them writes to the core-options file so they persist.
12. Verify with the log, then save a per-core override. Run once with verbose logging, confirm the core and content both loaded, then Quick Menu > Overrides > Save Core Overrides. Why: the log is ground truth about what actually loaded, and the override persists your tuning without polluting the global config.

Step 9 from a terminal, which is the fastest way to test a single game and the cleanest way to read the log:

$ retroarch -L "cores/mednafen_psx_hw_libretro.so" \
           "roms/psx/Vagrant Story (USA).chd" --verbose

Expected output after Step 12

With --verbose, a successful load prints something close to this. If you see these lines in this order, the frontend found the core, the core accepted the content, and your BIOS was located. If it stops before "Content", something in Steps 7–10 is wrong.

[INFO] RetroArch 1.22.2 (Git 9a1b2c3)
[INFO] === Build =======================================
[INFO] Version of libretro API: 1
[INFO] Compiled against API: 1
[INFO] [Core]: Loading dynamic libretro core from:
       "cores/mednafen_psx_hw_libretro.so"
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
[INFO] [System]: "Beetle PSX HW", "mednafen psx_hw"
[INFO] [Content]: Loading content file:
       "roms/psx/Vagrant Story (USA).chd"
[INFO] [BIOS]: Found valid BIOS in system directory.
[INFO] [Video]: Set video size to: 640x480.
[INFO] [Vulkan]: Using resolution scale 4x (1280x960 internal).

BIOS, System Files & the MD5 Trap

BIOS handling is the number-one reason a freshly downloaded core shows a black screen. The firmware is copyrighted, RetroArch cannot ship it, and the file must be named exactly right and placed exactly right or the core pretends it does not exist. Get this section correct once and you never think about it again.

Which cores actually need BIOS

Cartridge cores generally do not: NES, SNES, Genesis, Game Boy, and GBA cores boot with just the ROM. The cores that do need firmware are almost all disc-based or arcade: PlayStation (Beetle PSX and PCSX ReARMed), Saturn, Sega CD, PC Engine CD, and Neo Geo (which wants a neogeo.zip BIOS set alongside the game). A small mercy on PlayStation specifically — per the Beetle PSX core documentation, if you supply no BIOS the core falls back to the open-source OpenBIOS and most games still run. It is not perfect — some titles and the boot animation misbehave — but it means "black screen" is not always a death sentence. For accuracy, supply the real thing.

Where BIOS files go — and the exact names

Every firmware file goes in the frontend's system directory, the one you set in Step 2. Not the cores folder. Not a per-console subfolder unless a core explicitly asks for one. The names are case-sensitive on Linux and Android. A representative, correctly populated system directory looks like this:

$ ls -1 system/
scph5500.bin        # PS1 BIOS, Japan (NTSC-J)
scph5501.bin        # PS1 BIOS, North America (NTSC-U)
scph5502.bin        # PS1 BIOS, Europe (PAL)
neogeo.zip          # Neo Geo BIOS set (FBNeo / MAME)
bios_CD_U.bin       # Sega CD, US (Genesis Plus GX)
bios_CD_E.bin       # Sega CD, Europe
bios_CD_J.bin       # Sega CD, Japan
syscard3.pce        # PC Engine / TurboGrafx-CD (Beetle PCE)

Verifying with MD5 (the PlayStation example)

Here is the trap: a wrong-region or subtly corrupt BIOS often boots, then breaks copy protection on PAL titles or throws region errors deep into a game, and you never connect the crash to the firmware. Verify by checksum. These are the canonical PlayStation MD5s straight from the libretro core docs:

Confirm yours before you blame the core:

$ md5sum system/scph5501.bin
490f666e1afb15b7362b406ed1cea246  system/scph5501.bin

If the hash matches the table, the firmware is genuine and RetroArch will find it. If you are using a region-free substitute such as PSXONPSP660.bin, enable the core's Override BIOS option so Beetle PSX accepts it. One deliberate footgun to know about: Beetle PSX's Skip BIOS option bypasses the boot animation but also disables the checks some PAL copy-protected games rely on — leave it off unless a specific game demands it.

Core Options & Config Overrides

The single most common cry for help — "my settings keep resetting!" — is not a bug. It is the override system working exactly as designed, on a setting you saved without realizing it. Understand the hierarchy and you go from victim to operator.

Core options are not RetroArch settings

There are two separate configuration worlds and people constantly conflate them. Core options (Quick Menu > Options / Core Options) are settings the core exposes — the PlayStation renderer, internal resolution, PGXP, region autodetection. They mean nothing outside that core and are stored in a core-options file. RetroArch settings (the main Settings menu) are the frontend's — video driver, audio latency, input binds, shaders, aspect ratio — and they live in retroarch.cfg. When you change "internal resolution" you are editing core options; when you change "video driver" you are editing RetroArch settings. They persist through different files and different menus. Keep them straight and half the confusion is gone.

The override hierarchy (game beats directory beats core beats global)

RetroArch settings can be overridden at three increasingly specific scopes, and the official overrides guide documents the precedence precisely. From lowest priority to highest: your global retroarch.cfg, then a per-core override, then a per-content-directory override, then a per-game override. The most specific one that exists wins, and — this is the elegant part — each override file stores only the settings that differ from the level beneath it, not a full copy. The file locations, all under your config directory:

• Per-core: config/<core-name>/<core-name>.cfg — saved via Quick Menu > Overrides > Save Core Overrides.
• Per-content-directory: config/<core-name>/<directory-name>.cfg — Save Content Directory Overrides.
• Per-game: config/<core-name>/<game-name>.cfg — Save Game Overrides.

Now the "my settings reset" mystery solves itself: you once opened one game, nudged the aspect ratio, and hit Save Game Overrides out of habit. Every other game loads the core-level or global config; that one game silently loads its own file. Nothing is broken. Delete the stray config/<core>/<game>.cfg and the phantom setting vanishes.

Where the files live

Global core options accumulate in retroarch-core-options.cfg inside your config directory. It is plain text, one key = "value" per line, and safe to edit by hand when the menu is being tedious. A real excerpt, mixing a Genesis and a PlayStation core (your exact option strings may differ slightly by core version — treat these as the shape, not gospel):

# retroarch-core-options.cfg  (global core options)
genesis_plus_gx_region_detect = "ntsc-u"
genesis_plus_gx_no_sprite_limit = "enabled"
genesis_plus_gx_bram = "per bram"

beetle_psx_hw_renderer = "vulkan"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_pgxp_mode = "memory only"
beetle_psx_hw_widescreen_hack = "disabled"

And a per-core override — note it contains RetroArch settings, not core options, and only the handful that differ from global:

# config/Beetle PSX HW/Beetle PSX HW.cfg
video_driver = "vulkan"
video_aspect_ratio_auto = "true"
video_scale_integer = "false"
video_smooth = "false"
run_ahead_enabled = "false"

Per-game core options — as opposed to per-game RetroArch overrides — are saved separately as .opt files in the same config/<core>/ folder when you choose Save Game Options from the core-options menu. Same idea, different file, so you can, say, force PGXP on for exactly one glitchy title.

Best Core per System (2026)

There is rarely one correct core, but there is usually a correct core for your hardware and priorities. The eternal axis is accuracy versus speed. On a desktop you buy accuracy for free; on a handheld you spend every cycle carefully.

Low-power handhelds

On weak ARM devices the winners are the cores engineered for exactly that constraint. PCSX ReARMed is the PlayStation core for handhelds — it was built around ARM NEON and runs full speed where Beetle PSX would crawl. For SNES, the lighter Snes9x 2005/2010 forks beat current Snes9x on a slow chip; for GBA, gpSP outruns mGBA at the cost of some accuracy. This is not theoretical: the custom firmwares that make budget handhelds usable — Onion OS, muOS, Knulli — are RetroArch under the paint, shipping precisely these cores pre-tuned. Our teardown of the Miyoo Mini Plus versus the RG35XX is really a story about which device's core selection is tuned better, and it is why the one with less RAM can still win: software curation of cores beats raw specs. The same libretro cores power the desktop side of retro emulation too, which is why a project like RetroPie is, under the hood, a core manager with a menu on top.

Accuracy-first on desktop

Given real silicon and a Vulkan-capable GPU, aim higher. Mesen is the accuracy benchmark for NES and SNES and now folds in its former Mesen-S sibling. Genesis Plus GX (or BlastEm for the purists) covers Sega 8/16-bit. mGBA is the default for Game Boy through GBA. For PlayStation, Beetle PSX HW with the Vulkan renderer, 4x internal resolution, and PGXP gives you clean, wobble-free 3D. Nintendo 64 is Mupen64Plus-Next paired with ParaLLEl-RDP, a low-level graphics plugin that needs Vulkan and rewards it with near-hardware accuracy. Dreamcast is Flycast, Saturn is Beetle Saturn or Kronos, DS is melonDS, PSP is PPSSPP.

When to run two cores for one system

You are allowed — encouraged, even — to keep two cores for the same console and assign them by situation. Run mGBA for the handful of games that need its accuracy and gpSP for the rest on a weak device. Run Beetle PSX HW at your desk and PCSX ReARMed on the couch. The per-content-directory override from the previous section is the mechanism: sort your ROMs into folders, and RetroArch can load a different core and different settings per folder without you touching a menu twice.

6 Common Pitfalls & Fixes

Six ways people break their setup, in rough order of how often they email about it. Each with the actual fix, not "reinstall and pray."

Wrong core, wrong CPU, wrong romset

1. A heavy core on light hardware. You loaded Beetle PSX HW with 8x upscaling on a $60 handheld, got fifteen frames per second, and concluded emulation is a lie. Fix: match the core to the silicon — PCSX ReARMed on ARM, software renderer or 1x resolution when the GPU is weak. Consult the per-system table before you download, not after.
2. Arcade romset version mismatch. Your MAME or FBNeo game loads for half a second and closes, or throws a checksum error. Arcade cores are pinned to a specific MAME/FBNeo revision, and the ROM set must match that revision exactly. Fix: use a romset built for your core's version — MAME 2003-Plus sets for the 2003-Plus core, current sets for current MAME. This is the single fussiest thing in arcade emulation and it is not the core's fault.

BIOS, regions, and formats

3. BIOS in the wrong place, wrong name, or wrong region. Black screen on a disc game. Fix: firmware goes in the system directory, named exactly (case-sensitive), verified by the MD5 table above. A PAL game wants the European BIOS.
4. Broken disc-image format. You have a lone .bin with no .cue, or a multi-track dump missing its sheet, and the core refuses it. Fix: load the .cue (or .m3u for multi-disc games), not the raw .bin — or convert to .chd, which is a single compressed file every modern disc core reads natively and which halves your storage.

The config traps

5. The phantom game override. One game ignores your settings, or one game's settings "leak" nowhere else. Fix: you saved a game override you forgot about. Delete config/<core>/<game>.cfg. See the override hierarchy above.
6. Stale core against fresh info files (or nightly ABI drift). A core that worked last month now fails to load after an update, or a nightly core rejects your stable frontend. Fix: keep the frontend, cores, and info files on the same track — update all three together via the Online Updater, and do not hand-mix a nightly core into a stable install unless you are chasing one specific fix.

Troubleshooting Table

When something breaks, the symptom usually points straight at the cause once you know the map. Here is the map. Work top to bottom; the earlier rows are the more common failures.

Load failures and black screens

These are frontend-to-core handshake problems or missing firmware — the loudest failures and, mercifully, the easiest to diagnose because they stop everything cold.

Audio, video, and performance

These are subtler. The game runs but sounds wrong, looks wrong, or drops frames — usually a renderer, driver, or over-ambitious core-options choice.

The table

Advanced: Run-Ahead & Nightlies

Once the basics hold, RetroArch has depth that standalone emulators mostly lack. Three tools separate a working setup from a genuinely good one.

Run-ahead and latency

Emulators inherit — and often add to — the input lag of the original hardware. Run-Ahead (Settings > Latency) fights back: RetroArch runs the core several frames into the future, discards the visible ones, and shows you the result early, effectively cancelling frames of lag. The classic implementation runs a second instance of the core invisibly, which is heavy — it roughly doubles CPU load. Newer builds, 1.22.2 included, offer Preemptive Frames as a lighter alternative that reuses save states instead of a second instance, giving you most of the latency win at a fraction of the cost. Start at one frame of run-ahead, confirm the game does not glitch (some cores dislike it), and stop at the smallest number that feels responsive. It is the single biggest "feel" upgrade available, and it costs nothing but headroom.

Hardware vs. software cores

Some systems ship both a hardware-rendered and a software-rendered core, and the choice is not obvious. Beetle PSX HW upscales PlayStation 3D to 4x, 8x, or beyond using your GPU and can apply PGXP to kill the console's infamous polygon wobble — glorious on a desktop, punishing on a phone. The software renderer is slower to upscale but is pixel-accurate to the original hardware, which matters for games that relied on quirks the hardware path smooths over. Nintendo 64's ParaLLEl-RDP is the extreme case: it is a low-level reimplementation of the console's graphics chip, wildly accurate, and it demands Vulkan. Rule of thumb: hardware renderers for looks and horsepower, software renderers for accuracy and weak devices.

Nightlies, buildbot, and manual installs

The libretro buildbot publishes both stable and nightly cores for every platform, and the in-app Core Downloader simply pulls from it. Ninety-nine percent of the time you want the stable core the Downloader gives you, because it is guaranteed to match your frontend. Occasionally a bug you are hitting was fixed last week and only exists in a nightly. You can install one by hand — but understand you are stepping outside the version-matching safety net, and nightly cores can change save-state formats without warning. If you must:

# Manual core install (the in-app updater is the sane default).
# buildbot mirrors builds at paths like /nightly///latest/
cd ~/.config/retroarch/cores
wget https://buildbot.libretro.com/nightly/linux/x86_64/latest/mednafen_psx_hw_libretro.so.zip
unzip mednafen_psx_hw_libretro.so.zip
rm mednafen_psx_hw_libretro.so.zip
# then in RetroArch: Online Updater > Update Core Info Files

A Complete Working Config

Here is a full, sane baseline you can copy. It assumes a Linux desktop under ~/.config/retroarch; translate the paths to your platform and the logic holds everywhere.

The directory layout

Everything in known, writable places, saves and states separated from configs so an update never touches your progress:

~/.config/retroarch/
├── retroarch.cfg
├── cores/
│   ├── snes9x_libretro.so
│   ├── genesis_plus_gx_libretro.so
│   ├── mgba_libretro.so
│   └── mednafen_psx_hw_libretro.so
├── info/                       # .info files (Step 3)
├── system/                     # BIOS / firmware
│   ├── scph5501.bin
│   └── neogeo.zip
├── config/                     # overrides + core options
│   ├── retroarch-core-options.cfg
│   └── Beetle PSX HW/
│       └── Beetle PSX HW.cfg
├── saves/                      # SRAM — portable, keep these
├── states/                     # save states — version-locked
├── assets/  playlists/  thumbnails/

retroarch.cfg essentials

The keys that actually matter, out of the roughly two thousand the file can hold. Set these and ignore the rest until you have a reason:

# retroarch.cfg — the lines worth setting by hand
video_driver = "vulkan"
menu_driver = "ozone"

libretro_directory = "~/.config/retroarch/cores"
system_directory = "~/.config/retroarch/system"
savefile_directory = "~/.config/retroarch/saves"
savestate_directory = "~/.config/retroarch/states"
rgui_config_directory = "~/.config/retroarch/config"

# make overrides and per-game options actually apply
game_specific_options = "true"
auto_overrides_enable = "true"
auto_remaps_enable = "true"

# keep the Core Downloader visible (Step 5)
menu_show_core_updater = "true"

A per-core override that just works

Finally, a PlayStation setup you can drop in and run — the global core options that make Beetle PSX HW look right, plus the per-core override that pins the frontend behavior. This is the payoff of everything above: tuning that lives with the core, saves only its diffs, and never leaks into your other systems.

# config/retroarch-core-options.cfg  (PS1 section)
beetle_psx_hw_renderer = "vulkan"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_pgxp_mode = "memory only"
beetle_psx_hw_widescreen_hack = "disabled"
beetle_psx_hw_skip_bios = "disabled"

# config/Beetle PSX HW/Beetle PSX HW.cfg  (per-core override)
video_driver = "vulkan"
video_aspect_ratio_auto = "true"
video_scale_integer = "false"
video_smooth = "false"
run_ahead_enabled = "false"

That is the whole machine. RetroArch is the frontend; the core is the emulator; BIOS lives in system/, verified by checksum; core options tune the emulator; overrides tune the frontend, most-specific wins, diffs only. Nothing here is confusing once the words point at the right things. Pick cores that fit your silicon, dump your own firmware, verify the hashes, and save your overrides — and the program that looked like a PlayStation 3 having a breakdown turns into the most capable emulation setup you will ever run. The lore is deep, the law is settled, and the config, at last, is yours.