RetroArch Cores 2026: 200+ in 12 Steps, 40 Min

There is a persistent myth that RetroArch is complicated. It is not complicated. It is layered, which is a different and more forgivable sin. Underneath the intimidating menus sits one clean idea: a single frontend that loads interchangeable emulator backends called cores, each one speaking a common language called the libretro API. Learn the idea and the menus stop being a maze. Ignore it and you will spend an afternoon watching a core 'fail to load' for reasons no error message will ever explain to you.

This is a tutorial about installing those cores correctly — in the right order, on the right hardware, with the right core chosen for each system. It targets RetroArch 1.22.2, the stable line as of mid-2026, and it assumes you would rather understand the machine than memorize a sequence of button presses. By the end you will have a working install, the correct core for every major console, a per-game override that survives reboots, and a working mental model of the four-level config hierarchy that quietly governs everything. We will also tell you which of 2026's 'recommended' cores are traps, because several of them are.

What a Core Actually Is

Before you download anything, understand what you are downloading. A core is not 'an emulator you install into RetroArch.' It is a shared library — a .dll on Windows, .so on Linux and Android, .dylib on macOS — that implements a fixed set of functions defined by the libretro API. RetroArch is merely one program that knows how to call those functions. That is the whole trick, and it is why the exact same Genesis Plus GX binary can run inside RetroArch, Batocera, Lakka, or a dozen other frontends without modification. Once that clicks, half the mystery evaporates.

The libretro API in one paragraph

libretro defines a contract. The frontend hands the core a ROM, a chunk of memory, an audio buffer, and a video buffer; the core runs one frame of emulation and hands the buffers back. Everything you associate with RetroArch — shaders, save states, rewind, netplay, RetroAchievements, run-ahead latency reduction — lives in the frontend, above the API line. The core only has to emulate the console and fill the buffers. This separation is why a feature added to RetroArch instantly works across every core, and why a core written for libretro in 2012 still loads in 2026. It is the single most important architectural decision in the project, and it is the reason this tutorial is even possible. When someone tells you RetroArch is 'bloated,' they are describing the frontend's feature list, not the emulation, which is as lean as the standalone emulator it was ported from.

Why '200+ cores' is a number that lies to you

You will read everywhere that RetroArch has 'over 200 cores.' True, and misleading. That is a catalogue figure — the total number of distinct cores the libretro buildbot compiles across all platforms combined. Open the Core Downloader on your specific machine and you will see far fewer, because the list is filtered to builds compiled for your operating system and your CPU architecture. A Windows x64 desktop sees the fat catalogue. A 32-bit ARM handheld sees a much shorter one; the community-run webosbrew/retroarch-cores repository, for instance, rebuilt roughly 170+ armv7 cores in December 2025 plus a smaller experimental aarch64 set. So '200+' is accurate at the project level and irrelevant at your level. What matters is which cores exist for your hardware, which is exactly the distinction most first-timers fail to make before they start blaming the software.

The license nobody reads

RetroArch and most cores are GPLv3; a handful carry more restrictive non-commercial clauses inherited from upstream projects such as Mednafen. Practically, three things follow. First, the software is free and always will be — anyone selling you 'RetroArch Pro' is selling you a lie and, in the ROM-bundling case, a felony. Second, RetroArch ships no ROMs and no BIOS files, ever; the PlayStation, PS2, and Sega CD cores need real BIOS dumps that you provide, and the frontend will refuse to boot without them. Third, because cores are separate binaries under their own upstream licenses, some can appear and vanish from the downloader for legal rather than technical reasons — which is precisely what happened to the Citra 3DS core, and we will get to that. If you need legal content, the honest route is dumping your own cartridges; our Retrode 2 walkthrough covers that end of the hobby in detail.

Prerequisites: Versions & Hardware

Tutorials that skip prerequisites are how people end up with bsnes running at 40% speed and blaming RetroArch. Here is the honest bill of materials, with the version numbers and hardware floors that the marketing pages will never give you straight.

Software — the exact versions

Install RetroArch 1.22.2 (released November 20, 2025) or newer. Avoid 1.22.0 specifically: it shipped a shader black-screen bug that was fixed in 1.22.1 and 1.22.2 — if you are on 1.22.0 and your screen goes black the moment you enable a shader, that is the reason, not your GPU. The prior milestone, 1.21.0 (April 29, 2025), brought the Apple Vulkan, CoreMIDI, and 3DS fixes and is a reasonable floor if you are stuck on an older platform. Everything in this guide assumes the 1.22 line's menu layout. Get the binary only from an official source — the GitHub releases page, retroarch.com, your platform's app store, or Steam. There are convincing-looking 'RetroArch Setup 2026' domains in search results that are not affiliated with the project and exist to serve you adware; do not download from them.

Hardware — the honest per-system floor

RetroArch itself is featherweight. The cores are not, and their appetites vary by three orders of magnitude. Table stakes, roughest to gentlest:

• 8-bit and 16-bit (NES, SNES via Snes9x, Genesis, Game Boy, GBA): any device made in the last decade. A Raspberry Pi, a phone, a fifty-dollar handheld.
• SNES cycle-accurate (bsnes Accuracy): a desktop CPU with strong single-thread performance — figure on the order of a 4 GHz core. This is not a 'modern PC struggles' situation; it is a 'bsnes deliberately simulates the console at the cycle level' situation, and it is doing that on purpose.
• PS1 (Beetle PSX HW with the hardware renderer and upscaling): a real GPU. The software path runs on anything; the pretty path does not.
• N64, Saturn, Dreamcast: a mid-range desktop or a strong recent ARM handheld.
• PS2 (LRPS2) and 3DS (Azahar): a modern x86_64 desktop with a discrete or strong integrated GPU. LRPS2 in particular is x86_64-only — there is no ARM build, so no Android, no ARM Linux, no iOS.

If you are shopping for a handheld to run the heavier systems, read our breakdown of the 2026 Retroid Pocket lineup before you assume PS2 is on the menu; on most ARM handhelds, it simply is not, and no spec sheet will warn you.

BIOS and ROMs you must supply

RetroArch ships neither. The disc-based systems are the ones that will bite you: PS1 wants a matching BIOS (for example, scph5501.bin for the US region), PS2 wants a real BIOS dump, Sega CD wants its regional BIOS. These go in your system/ folder, and region matters — a Japanese BIOS will not cleanly boot a US disc image. For ROMs, dump your own; a cartridge dumper makes it legal and painless. If all of this sounds like more maintenance than you signed up for, a pre-built distribution hides it entirely, which we come back to at the end of the core-selection section.

Install & the Update Order

Ninety percent of 'my cores will not load' threads trace back to one mistake: updating things in the wrong order. RetroArch's Online Updater has several entries and they are not interchangeable. Here is the order that never fails, and why each step comes where it does.

Update the application, then the metadata

First, update RetroArch the application, because a core built against a newer libretro API can refuse to load in an older frontend. Use your package manager rather than fighting the in-app updater on desktop:

# Windows (winget)
winget upgrade Libretro.RetroArch

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

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

# Ubuntu / Debian — pull a core straight from the official PPA
sudo apt-get install libretro-mupen64plus-next

On the reference platforms that is winget upgrade Libretro.RetroArch on Windows, flatpak update org.libretro.RetroArch on Linux and the Steam Deck, and brew upgrade --cask retroarch on macOS. Update the app first, then everything below.

Update Core Info Files FIRST — this is the whole ballgame

Open Online Updater and resist the urge to click 'Core Downloader.' Click Update Core Info Files first. The info files are the manifest — they tell RetroArch which cores exist, what systems they emulate, what file extensions they accept, and what BIOS they need. If that manifest is stale or missing, three things happen and every one of them looks like a bug: the Core Downloader appears empty, freshly downloaded cores 'fail to load,' and installed cores show up as 'unrecognized.' None of that is a bug. It is a manifest you forgot to update. Do this before anything else, every single time. The official guidance in the libretro download-cores documentation says the same thing, and it remains the most common source of wasted evenings in the entire hobby.

Package managers, the PPA, and where the Downloader hides

If your Core Downloader menu is missing entirely, it is hidden, not broken: Settings, then User Interface, then Menu Item Visibility, then Show Core Downloader. On Ubuntu and Debian you can bypass the in-app downloader altogether and pull cores from the official PPA with sudo apt-get install libretro-mupen64plus-next and its siblings, which is handy for scripted or headless installs. Bleeding-edge users can grab nightlies straight from the libretro buildbot, though a nightly is exactly as stable as the word implies. Whichever route you take, finish with Online Updater, then Update Installed Cores, so every binary and its info file agree with each other.

Installing a Core: 12 Steps

With the plumbing understood, here is the full sequence from a cold install to a configured, override-protected core. Each step carries its rationale, because a step you understand is a step you will not skip next time.

The twelve steps, in order

1. Update RetroArch itself. A core compiled against a newer libretro API will not load in an older frontend. Rationale: you are eliminating version skew before it can masquerade as a broken core.
2. Open Online Updater, then Update Core Info Files. This refreshes the manifest. Rationale: without a current manifest the downloader is empty and new cores report as unrecognized — this one step prevents the most common failure in the whole process.
3. Update Assets, Databases, and (optionally) Cheats. Assets are menu icons and fonts; databases power playlist scanning and game-name matching. Rationale: a core loads without these, but content scanning and thumbnails will silently break and you will blame the core.
4. Confirm the Core Downloader is visible. Settings, User Interface, Menu Item Visibility, Show Core Downloader. Rationale: if it was hidden you would conclude, wrongly, that your build cannot download cores at all.
5. Open Load Core, then Download a Core. This is the Core Downloader proper. Rationale: this list is already filtered to your OS and CPU architecture, which is precisely why it is shorter than the mythical '200+' and why picking blindly here is safe.
6. Pick the core by system AND architecture. For SNES on a desktop, Snes9x or bsnes; on a weak handheld, Snes9x only. Rationale: choosing bsnes on a sub-4 GHz device is the difference between full speed and a slideshow, and nothing in the menu warns you.
7. Download it and wait for the confirmation toast. RetroArch places the binary in cores/ and pairs it with its info file. Rationale: that pairing is what makes a core 'recognized'; if step 2 was skipped, the pairing fails silently and the core will not appear.
8. Verify via Information, then Core Information. This screen shows the core's name, supported extensions, required BIOS, and license. Rationale: reading 'Required BIOS: scph5501.bin' now saves you a cryptic black screen twenty minutes later.
9. Load content with the core. Load Content, pick your ROM, select the core you just installed. Rationale: this is the first moment the core actually executes, and the log will tell you immediately if a BIOS or renderer is missing.
10. Open Quick Menu, then Core Options, and set the important ones. Renderer, internal resolution, accuracy toggles. Rationale: defaults are conservative on purpose; the good stuff — hardware renderer, upscaling, PGXP — is opt-in.
11. Save an override at the right level. Quick Menu, Overrides, then Save Core Override (applies to every game on that core) or Save Game Override (this game only). Rationale: choosing the wrong level is how one game's widescreen hack ends up mangling your entire library.
12. Run Update Installed Cores periodically. Online Updater, then Update Installed Cores, refreshes every installed core in one pass. Rationale: cores are patched constantly; a mysterious new bug is often a fix that landed upstream that you simply have not pulled yet. A May 24, 2026 buildbot change swapped out older core files for installs predating it — if yours is older than that, one pass brings you current.

Expected output: what success looks like

Turn up Settings, Logging, Logging Verbosity, and loading a PS1 game through Beetle PSX HW produces something like the following. Read it top to bottom; every line is a checkpoint.

[INFO] [Core]: Using content: 'Final Fantasy VII (USA) (Disc 1).chd'.
[INFO] [Core]: Loading dynamic library 'cores/mednafen_psx_hw_libretro.dll'.
[INFO] [Core]: Version of libretro API: 1, Compiled against: 1.
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
[INFO] [Video]: Requested renderer: Vulkan.
[INFO] [Content]: Content loading succeeded.

The two lines that matter are 'Loading dynamic library' (the core binary was found) and 'Content loading succeeded' (the ROM and any BIOS were accepted). If you see the first but not the second, the failure is content or BIOS, not the core — go check your system/ folder before you touch anything else.

Verifying without launching a game

You do not need a ROM to confirm a core installed correctly. Information, then Core Information, lists the core's display name, version, supported file extensions, required and optional BIOS with their expected filenames, and the upstream license. If a core does not appear here at all after downloading, you skipped Update Core Info Files — return to step 2. This screen is also the fastest way to learn exactly what a disc-based core wants before you waste time hunting the cause of a black screen.

The Right Core Per System

This is the section people actually come for, and the one where 2026 will punish you for following a 2021 guide. The right core is not always the newest or the most accurate; it is the one that matches your silicon. Here is the cheat sheet, then the arguments behind the tricky rows.

Nintendo: Mesen, the SNES politics, and the N64 regression

For NES, use Mesen. It is PPU-accurate, handles the exotic mappers, and ships a genuine debugger; there is no reason to run anything older in 2026. For SNES the choice is faintly political. bsnes Accuracy — the descendant of byuu's higan — is cycle-accurate and gorgeous and wants roughly a 4 GHz core to hold full speed with audio intact. Snes9x is the pragmatic pick: a rounding error less accurate, runs on a potato, and is what you should install on any handheld. Run bsnes on a desktop, Snes9x everywhere else, and do not let anyone shame you for the latter.

N64 is where a 2026 guide has to actively warn you. The mainline core, mupen64plus-next, bundles GLideN64 (HLE), angrylion (accurate software), and the ParaLLEl-RDP/RSP plugins, and it is the correct default — the official library documentation still recommends it. But it regressed in early 2025: certain titles, Stunt Racer 64 and World Driver Championship among them, stopped loading entirely, and the community's workaround was to pin the January 2025 build until the fix propagated. If one specific N64 game refuses to boot while others run fine, that regression is your first suspect. The accuracy-first alternative is Parallel N64 (Vulkan, low-level RDP/RSP), which trades broad compatibility for correctness on the games it does support.

Sony: the PS1 three-way and the PS2 core that skips your handheld

PS1 has three defensible cores and the right answer depends entirely on your hardware. Beetle PSX HW, a Mednafen derivative, has the hardware renderer, internal upscaling, and PGXP geometry correction; it is the most accurate and the heaviest, and it is what you run on a desktop with a real GPU. SwanStation, a libretro port of DuckStation, sits in the middle. PCSX ReARMed is the lightweight ARM specialist that powers the budget handheld world — it is the PS1 core quietly doing the work inside muOS, OnionOS, and ROCKNIX on devices like the ones in our Miyoo Mini Plus versus RG35XX comparison. Match the core to the silicon and PS1 is a solved problem.

PS2 is the blunt one. The core is LRPS2, a hard fork of PCSX2 that landed in the downloader with the 1.22 line in November 2025, carrying a brand-new low-level renderer called ParaLLEl-GS (by Themaister, with Vulkan, GL, and D3D11/12 compute paths plus a software fallback for accuracy). It embeds the GameIndex and needs a real PS2 BIOS. The catch that trips people constantly: LRPS2 is x86_64-only. Windows, Linux, and macOS via Rosetta — that is the entire list. There is no Android build, no ARM Linux build, no iOS build. If your device is ARM, PS2 through RetroArch is simply unavailable, and no amount of updating will summon a core that was never compiled. The libretro announcement spells the renderer story out if you want the deep version.

Sega, arcade, and the 3DS core that replaced Citra

Genesis Plus GX is your Sega workhorse — 100% of Mega Drive/Genesis, Sega CD, Master System, Game Gear, and SG-1000, all from one core with a pedigree tracing back to Wii homebrew. The one thing it does not do is 32X; for that you switch to PicoDrive, which is also the sensible Genesis pick on Android, where it is a Core Downloader entry. Arcade is Final Burn Neo, whose library reaches back into the 1970s and which downstream projects like RetroBat were still bumping as recently as an April 22, 2026 build.

The 3DS story is the one with lawyers in it. Citra is gone — pulled in the wake of Nintendo's legal campaign against its sibling emulators — and the successor is Azahar, a merge of the strongest surviving Citra forks, PabloMK7's and Lime3DS among them. Azahar shipped its first official libretro core in the 2125.0 Alpha 4 build (April 1, 2026), covering six operating systems — Linux, Windows, macOS, Android, iOS, and tvOS — and the line has since advanced toward 2126.0. It drops support for encrypted titles and the old Nintendo CDN, and its libretro binaries are now stripped for a smaller Android footprint. If you are chasing 3DS in RetroArch, Azahar is the only correct answer in 2026; anything telling you to install 'the Citra core' is out of date. You can track releases on the Azahar GitHub.

And if maintaining any of this by hand sounds tedious, that is a legitimate position. Pre-built distributions make these decisions for you: Batocera 43.1 is essentially this entire tutorial's choices made in advance and burned to an SD card. The purist alternative is to leave software emulation behind entirely for FPGA hardware — the MiSTer Multisystem 2 reproduces these consoles at the gate level rather than the instruction level, which is a different tradeoff with its own devoted religion.

Core Options & Overrides

This is the part RetroArch never explains and the part that separates a working install from a haunted one. RetroArch runs two parallel settings systems and a four-level precedence order, and once you internalize both, nothing about your configuration will ever surprise you again.

Two systems: configs and core options

There are configuration overrides — frontend settings such as aspect ratio, shaders, integer scaling, and input — and there are core options — settings the core itself exposes, such as renderer, internal resolution, and accuracy hacks. They are stored differently and saved through different menus, and conflating them is why people 'save settings' and then watch those settings fail to apply. Frontend settings live in .cfg override files; core settings live in retroarch-core-options.cfg globally, or in per-game .opt files. When a setting will not stick, the first question is always: is this a frontend setting or a core option? They travel on different rails.

The four-level precedence order

Both systems resolve in the same priority, most specific winning:

1. Game override — this one ROM only.
2. Content directory override — every ROM in that folder (handy for 'all my GBA games get this shader').
3. Core override — every game run on that core.
4. Global — retroarch.cfg, the fallback for everything.

A game override beats a content-directory override beats a core override beats global. This is exactly why a widescreen hack saved at the core level bleeds into games that should be 4:3, and why the fix is to save it at the game level instead. The overrides documentation is worth the five-minute read; it is the closest thing this software has to a Rosetta Stone, and internalizing the ladder above will resolve most 'settings do not save' confusion on its own.

Where the files actually live

Overrides land under config/[Core Name]/. A core override is config/Beetle PSX HW/Beetle PSX HW.cfg; a content-directory override is config/Beetle PSX HW/[dirname].cfg; a game override is config/Beetle PSX HW/[Game Name].cfg. Input remaps get their own tree under config/remaps/[Core Name]/ as .rmp files. Per-game core options are config/[Core Name]/[Game Name].opt. Here is a real config subtree so the abstraction has a shape:

RetroArch/
├── retroarch.cfg                       # global config (fallback for everything)
└── config/
    ├── Beetle PSX HW/
    │   ├── Beetle PSX HW.cfg           # CORE override  -> every PS1 game
    │   └── Gran Turismo 2 (USA).cfg    # GAME override  -> this game only
    ├── Snes9x/
    │   └── Snes9x.cfg                  # CORE override  -> every SNES game
    └── remaps/
        └── Beetle PSX HW/
            └── Gran Turismo 2 (USA).rmp  # per-game input remap

To create these from the menu rather than by hand: Quick Menu, Overrides, then Save Game Override for the frontend side, and Quick Menu, Core Options, Manage Core Options, then Save Game Options for the core side. The keys that make automatic loading work — auto_overrides_enable, auto_remaps_enable, game_specific_options, and the ever-dangerous config_save_on_exit — live in your global config, and we set them explicitly in the complete configuration at the end of this guide.

Five Pitfalls to Avoid

These are the failure modes you will actually hit, in roughly descending order of how much time they waste. Each is paired with the fix, because a pitfall without a fix is just a complaint.

The manifest and the mismatch

Pitfall 1 — skipping Update Core Info Files. Symptom: an empty downloader, 'failed to load,' cores marked unrecognized. Fix: Online Updater, then Update Core Info Files, then reopen the downloader. This is the same lesson as step 2, and it is worth repeating precisely because it is responsible for more collective wasted time than every other item on this list combined.

Pitfall 2 — the architecture mismatch. Symptom: a core downloads but crashes on load, or an obvious core is simply not in your list. Cause: you assumed a core exists for your CPU when it does not. Retroid Pocket 3+ owners have hit this with cores such as ColecoVision that were not built for their architecture; LRPS2 users hit it on every ARM device because there is no ARM LRPS2. Fix: confirm the core exists for your platform in the downloader, or in the ARM core repository, before you troubleshoot a 'bug' that is actually an absence.

The wrong core for the job

Pitfall 3 — bsnes on weak hardware. Symptom: SNES audio crackle and sub-full-speed play. Cause: bsnes Accuracy is cycle-accurate and wants roughly a 4 GHz core. Fix: switch to Snes9x; the accuracy difference is imperceptible across the vast majority of the library, and full speed is not.

Pitfall 4 — the N64 regression and the missing 32X. Symptom: a specific N64 game (classically Stunt Racer 64) will not load, or your 32X games are nowhere to be found. Causes and fixes: the early-2025 mupen64plus-next regression — pin the January 2025 build or use Parallel N64; and 32X is not in Genesis Plus GX — use PicoDrive. Both are the same lesson in disguise: the core is doing exactly what it was built to do, which is not what you assumed it did.

The self-inflicted config wound

Pitfall 5 — the wrong override level. Symptom: one game's setting (a widescreen hack, a shader, a control remap) contaminates your whole library. Cause: you saved a Core Override when you meant a Game Override. Fix: delete the offending config/[Core]/[Core].cfg and re-save the change at the game level instead.

Pitfall 6 — config_save_on_exit eating your changes. Symptom: settings you changed in a session silently revert, or settings you did not mean to keep get baked into the global config. Cause: config_save_on_exit = true writes the entire live config on close, quietly overwriting careful manual edits. Fix: either make changes through the override menus (which write to the correct scoped file) or turn config_save_on_exit off and save deliberately. The wrong-region-BIOS variant of this — a black screen because a Japanese PS1 BIOS met a US disc — belongs in the same family: match BIOS region to content, every time.

Troubleshooting Table

Bookmark this. It maps the symptoms you will actually see to their causes and fixes, in the order you should try them. Work top to bottom; the earlier rows are both more common and cheaper to check.

Reading the log like a mechanic

Setting Settings, Logging, Logging Verbosity to a higher level turns RetroArch from cryptic to chatty. The two milestones to watch for are 'Loading dynamic library' (the core binary loaded — if this is missing, the problem is the core file or its info file) and 'Content loading succeeded' (ROM and BIOS accepted — if this is missing but the library loaded, the problem is your content or BIOS, not the core). Roughly ninety percent of diagnosis is just knowing which of those two lines failed to appear.

The clean-config reset

When an install is genuinely haunted — settings that will not stick, cores that will not behave, no obvious cause — the nuclear option is to rename retroarch.cfg and relaunch; RetroArch regenerates a clean default. Back up your config/ overrides first if you want to keep them, then reintroduce them one at a time until the problem reappears. It is faster than bisecting a config file you edited three months ago and no longer remember touching.

Advanced Tips

Once the basics hold, these are the levers worth pulling. None are required; all are the difference between a working install and one you actually enjoy.

Nightlies, pinning, and the ARM repositories

The stable downloader lags upstream by design. When you need a fix that landed last week — or, in the N64 case, an older build that had not yet regressed — go to buildbot.libretro.com/nightly, find your platform and architecture, and drop the core binary straight into cores/ (then Update Core Info Files so the manifest matches). Pinning a known-good build by keeping its binary and simply not updating that one core is an entirely legitimate strategy; the mupen64plus-next January-2025 workaround is exactly this move. ARM handheld owners should bookmark the webosbrew armv7/aarch64 repository, which fills gaps the official ARM downloader leaves open.

Remaps, subsystems, and softpatching

Input remaps (Quick Menu, Controls, Manage Remap Files) are stored separately from overrides, per core, as .rmp files, so you can rebind a whole system without touching any per-game config. Multi-disc and special-hardware titles use subsystems — the reason you load, say, a Super Game Boy or a specific multi-cart combination through a dedicated 'Load Subsystem' path rather than plain Load Content. And RetroArch applies soft patches (IPS, BPS, UPS) automatically if the patch file sits next to the ROM with a matching name; this is how translation patches and ROM hacks 'just work' without permanently modifying your original dump. None of these are advertised in the main menu, which is why most users never discover them.

RetroAchievements and shader caches

RetroAchievements is native in RetroArch — no third-party plugin, no browser extension. Settings, Achievements, log in, done. It is one of the genuinely modern reasons to prefer RetroArch over a pile of standalone emulators. On the performance side, GPU-heavy cores (Azahar among them, with its 2125.0 disk shader cache writing .vkch files) build a shader cache on first run so the stutter you feel the first time through a level does not repeat on the second. Do not delete these caches to 'save space' — you are only buying yourself the stutter back, at a worse exchange rate.

Complete Working Config

Here is a coherent, copy-pasteable configuration that puts the whole tutorial into practice: a global config that turns on scoped auto-loading, a per-game core-options file for a demanding PS1 title, and the directory tree they produce. Adjust filenames to your own library.

The global settings that make overrides behave

These lines belong in your global retroarch.cfg. They are the difference between a config that respects your per-game work and one that stomps it.

config_save_on_exit = "true"
auto_overrides_enable = "true"
auto_remaps_enable = "true"
game_specific_options = "true"
core_updater_auto_extract = "true"
menu_show_core_updater = "true"

auto_overrides_enable and auto_remaps_enable load your scoped files automatically; game_specific_options makes the per-game .opt files apply; menu_show_core_updater guarantees the downloader is visible; and leaving config_save_on_exit true is safe only because everything specific is scoped to override files that outrank the global one.

A per-game core-options file (Beetle PSX HW)

Saved as config/Beetle PSX HW/Final Fantasy VII (USA).opt, this turns on the hardware Vulkan renderer, 4x internal resolution, and PGXP geometry correction for one game without touching the rest of your PS1 library:

beetle_psx_hw_renderer = "hardware_vk"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_pgxp_mode = "memory only"
beetle_psx_hw_dither_mode = "internal resolution"
beetle_psx_hw_widescreen_hack = "disabled"

Those are the real core-option keys — beetle_psx_hw_renderer, beetle_psx_hw_internal_resolution, beetle_psx_hw_pgxp_mode, beetle_psx_hw_dither_mode, beetle_psx_hw_widescreen_hack — not invented ones. Set renderer to software instead and this same file becomes your accuracy profile for a game that dislikes the hardware path.

The tree it all produces

Put the three pieces together and a healthy install looks like this — cores paired with info files, BIOS in system/, and overrides scoped exactly as narrowly as they should be:

RetroArch/
├── retroarch.cfg
├── cores/
│   ├── mednafen_psx_hw_libretro.dll        # Beetle PSX HW
│   ├── snes9x_libretro.dll
│   ├── mupen64plus_next_libretro.dll
│   └── genesis_plus_gx_libretro.dll
├── info/
│   ├── mednafen_psx_hw_libretro.info       # the manifest -- update FIRST
│   ├── snes9x_libretro.info
│   └── ...
├── config/
│   └── Beetle PSX HW/
│       └── Final Fantasy VII (USA).opt     # per-game core options
└── system/
    └── scph5501.bin                        # US PS1 BIOS you supply

Nothing global that should be per-game, nothing per-game that should be global. If you can read that tree and predict what will load for a given ROM, you understand RetroArch better than most of the people currently answering questions about it on forums.

That is the entire discipline: update the manifest before the cores, pick the core that matches your silicon rather than your ambition, and scope every setting to the narrowest level that makes sense. Do those three things and RetroArch stops being layered and starts being simple. Do none of them and you will be back in a 2019 forum thread reading a reply from someone as lost as you were — which is precisely the fate this tutorial exists to spare you.