RetroArch Cores 2026: 200+ Options, 14 Steps, 30 Min

There are, the marketing says, "over 200 cores." There are not 200 cores waiting for your specific device, you will not want most of the ones that exist, and roughly a third of the frustration in this hobby comes from people who never learned the difference between those two sentences. This is a tutorial about installing, choosing, updating, and overriding RetroArch cores in 2026 — on the desktop and on the pile of ARM handhelds that now vastly outnumber the desktops — written by someone who reads the load log so you do not have to. Fourteen steps, about thirty minutes, and a complete working configuration at the end you can steal outright.

What a Core Actually Is

Before you download anything, understand what you are downloading, because the entire mythology of RetroArch rests on a misunderstanding that costs beginners whole weekends.

RetroArch is not an emulator. A core is.

RetroArch is a frontend: a menu, an input abstraction layer, a video and audio pipeline, a save-state manager, and a rewind buffer. It emulates nothing. What it speaks is a single stable ABI called libretro. A core is a shared library — a .dll on Windows, a .so on Linux and Android, a .dylib on macOS — that implements the libretro API on one side and wraps an actual emulator on the other. Snes9x, mGBA, Mesen, PCSX2, Mupen64Plus: those are real, independent upstream projects with their own maintainers. The libretro "core" is a comparatively thin adapter that lets RetroArch drive them through one uniform interface. When you set a shader, a run-ahead value, or a controller remap, you are configuring the frontend, and it applies to whatever core is loaded. When a game runs at the wrong speed or refuses to boot, that is almost always the core (or its BIOS), not RetroArch. Keeping that boundary clear is the single most useful diagnostic instinct you can build.

Why "200+ cores" is a catalogue, not an inventory

The 200-plus figure is the total across every platform libretro has ever built for, summed. Your Core Downloader shows only the builds compiled for your operating system and your CPU architecture. A Windows x86_64 machine sees a different, longer list than an Android aarch64 phone, which sees a different list than an armv7 handheld running a locked-down distro. To make that concrete: when the community rebuilt the webosbrew/retroarch-cores repository in December 2025 for LG's webOS televisions, they shipped 170-plus armv7 cores plus an experimental aarch64 set — a substantial catalogue, but not the mythical 200, and not the same 200 a PC gets. Treat the big number as trivia. The number that matters is "how many cores exist for the exact thing in my hands," and that is a number you discover by opening the downloader, not by reading a headline.

Cores vs. standalone emulators

Not every emulator has a good libretro core, and a few of the best no longer have one at all. DuckStation left the libretro ecosystem, so its lineage survives inside RetroArch as the SwanStation core. Citra, the 3DS emulator, was taken down entirely; its successor is Azahar, which only shipped its first official libretro core in 2026 (more on that below). The rule of thumb: RetroArch is superb when a mature core exists and you want one consistent frontend across a dozen systems. For a handful of demanding, fast-moving systems — PS2, GameCube, Switch — the standalone application is often ahead of its core. This guide is about getting the most out of the cores; it is honest about where the core is the wrong tool.

Prerequisites: Versions and BIOS

Software versions you should actually be on

The current stable release is RetroArch 1.22.2, shipped 20 November 2025. It is the tail of the 1.22 line: 1.22.0 introduced a shader black-screen regression on certain content, which 1.22.1 and 1.22.2 corrected, so if you are on 1.22.0 specifically, update. The prior milestone worth naming is 1.21.0 from spring 2025, which fixed a slate of Apple Vulkan and CoreMIDI issues and 3DS build problems. RetroArch is free, GPLv3, and past 13,200 stars on GitHub; you can confirm the newest build any time on the official releases page. Why does the frontend version matter for a tutorial about cores? Because cores are compiled against a specific libretro API revision. A core built on the current buildbot can refuse to load, or load and misbehave, on a frontend that is a year stale. Update the frontend first; then update cores.

Hardware floor, by ambition

There is no single "RetroArch requirement" because a core for the Game Boy and a core for the PlayStation 2 are separated by three orders of magnitude of compute. As a working floor: 8-bit and 16-bit systems (NES, SNES, Master System, Genesis, Game Boy, GBA) run on effectively anything, including a sub-$100 handheld. Cycle-accurate cores change that math — bsnes Accuracy genuinely wants a CPU around 4 GHz to hold full speed with no frame-pacing compromises, which is why nobody sane runs it on a handheld. N64, PS1, Saturn, and Dreamcast are the middle band where a modern phone-class SoC is the real dividing line; this is exactly why the generational CPU jumps in the handheld market matter, and why a review like our Retroid Pocket 6 vs 5 breakdown, where the newer chip posts roughly 70% more CPU, is a buying-guide for emulation and not just a spec sheet. PS2 and up is desktop territory, and the core that serves it (LRPS2) is desktop-only by design.

BIOS files and the law

Many cores are useless without a system BIOS, and RetroArch does not — and legally cannot — ship one. PS1 (for accuracy), PS2, Saturn, and several others expect real BIOS images dumped from hardware you own, placed in your System/BIOS directory. LRPS2, the PS2 core, requires a real PS2 BIOS set to boot at all; it now embeds the GameIndex.yaml compatibility database internally, so that part is handled, but the BIOS is on you. The law here is simple and unforgiving: dumping a BIOS from a console you own for personal use sits in a defensible place in most jurisdictions; downloading one does not, regardless of how many forums pretend otherwise. The Machine will tell you which cores need a BIOS. The Machine will not tell you where to get one.

Installing Cores: 14 Steps

This is the spine of the tutorial. Do them in order the first time; after that you will only ever repeat steps 5–9 and 11. Every step has a reason, because a step you perform without understanding is a step you cannot debug.

The 14-step install loop

1. Confirm your build and version. On desktop, open Information → System Information and check the version reads 1.22.2 (or newer). On Windows the clean way to update is the package manager:

   winget upgrade Libretro.RetroArch
   # or, if it was never installed via winget:
   winget install Libretro.RetroArch

   Rationale: cores are ABI-matched to the frontend. Downloading a fresh core into a year-old RetroArch is the most common cause of a core that "downloads fine but won't load," and it produces no obvious error.
2. Set your directories before touching the downloader. Go to Settings → Directory and confirm sane paths for System/BIOS, Cores, and Config. Rationale: cores look for BIOS images in the System directory. If that path is wrong, every BIOS-dependent core will fail to boot content, and you will spend an hour blaming the core for a folder setting.
3. Update Core Info Files — first, before anything else. Navigate to Main Menu → Online Updater → Update Core Info Files. Rationale: the .info files are the manifest — they tell RetroArch each core's display name, the system it emulates, its BIOS requirements, and its capabilities. Without a current manifest, the Core Downloader list can come up empty, and cores you already have can show as unrecognized or "failed to load." This one menu action prevents more support-forum threads than any other. Run it first, every time you do a big update.
4. Update Assets and Databases. Still under Online Updater, run Update Assets and Update Databases. Rationale: assets are the menu icons and system logos; databases are what let RetroArch scan a folder of ROMs into clean, named playlists. Skipping this leaves you with a functional but ugly and unscannable setup.
5. Open the Core Downloader. Online Updater → Core Downloader. If the option is missing, it is hidden, not absent — enable it under Settings → User Interface → Menu Item Visibility → Show Core Downloader. Rationale: this list is compiled for your exact OS and architecture. It is the authoritative answer to "what can this device actually run," per the official download-cores guide.
6. Download one light, high-compatibility core first. Grab Nintendo - SNES / SFC (Snes9x) or Nintendo - Game Boy Advance (mGBA) before anything exotic. Rationale: you are validating the whole pipeline — downloader, info files, load path — with a core that is nearly impossible to get wrong. Debugging a simple core is quick; debugging PS2 as your first attempt is a nightmare of confounded variables.
7. Load the core. Main Menu → Load Core and select what you just downloaded. Rationale: this confirms the binary links against your frontend before content ever enters the picture. If it loads here, the core-versus-frontend question is closed and you can focus on content and BIOS.
8. Load content and confirm it boots. Load Content, point it at a ROM, and watch it run. Rationale: a core that loads but will not run content is almost never "broken." It is a BIOS the core wants and cannot find, a bad or mis-headered ROM, or a content format the core does not accept (a raw .bin where it wanted a .cue, for instance).
9. Set the core's own options. With content running, open the Quick Menu → Options. Rationale: renderer (software vs. hardware), internal resolution, region, and BIOS toggles live here, per-core, and the defaults are deliberately conservative for compatibility. This is where you turn a working core into a good-looking one.
10. Associate a default core per system. When you build playlists by scanning, RetroArch lets you set a Default Core for each playlist, and you can still override per game. Rationale: so opening any SNES title launches Snes9x automatically, and any PS1 title launches your chosen PS1 core, without a core-picker prompt every single time.
11. Update installed cores. Periodically run Online Updater → Update Installed Cores. Rationale: cores are versioned and shipped independently of the frontend. Upstream fixes — and, occasionally, upstream regressions — arrive here on their own schedule. This is a routine maintenance action, not a one-time setup step.
12. Back up a known-good core when upstream is volatile. Copy the working .dll/.so and its .info out of your Cores folder before a big update, especially for N64. Rationale: the mainline can and does regress (see the N64 section). Keeping the exact build that worked means a broken update is a thirty-second file-copy rollback, not a research project.
13. Add cores that live outside the stable downloader. Some cores are not in the stable list yet — new arrivals, nightlies, and Linux distro packages. The buildbot serves per-platform nightlies at buildbot.libretro.com/nightly; on Ubuntu-family systems where the in-app downloader is disabled, the PPA installs cores through the package manager:

    # Ubuntu / Debian PPA install (downloader disabled builds):
    sudo apt-get install libretro-nestopia
    sudo apt-get install libretro-genesisplusgx
    # general form:
    sudo apt-get install libretro-<corename>

    Rationale: not everything ships in the stable channel on day one; Azahar's 3DS core, for one, arrived outside the stable downloader before its full release.
14. Verify with the log. Turn on Settings → Logging, set Frontend Logging Level to Info (0), reproduce the failure, and read what RetroArch actually says. Rationale: the log names the exact reason a core failed — missing symbol, missing BIOS, redirected save path — and reading it converts a two-hour guessing session into a two-minute fix. Expected healthy output on a clean load looks like:

    [INFO] [Core]: Loading dynamic library "snes9x_libretro.dll"
    [INFO] [Core]: Version of libretro API: 1
    [INFO] [Content]: Loading content file: Chrono Trigger.sfc
    [INFO] [Core]: Content ran for 0 frames... now running.
    [INFO] [Overrides]: Redirecting save file to "saves/Chrono Trigger.srm".

Which steps you actually repeat

That is the loop. Steps 1–4 are hygiene you do rarely, 5–9 you do for each new system, and 11–14 are the maintenance and diagnosis you return to for the life of the install. Nobody runs all fourteen weekly; you run four of them, occasionally, and forget the rest exist until something breaks.

Let a distribution handle the hygiene

If this all feels like a lot to run per-device by hand, that is precisely the problem the turnkey distributions solve: a project like Batocera 43.1, which you flash and boot in about 30 minutes, ships a curated core set and pre-wired directories so you inherit a sane version of everything above. The steps do not vanish; someone else has simply already run them for you.

The Right Core, By System

"Which core" is the question the catalogue number cannot answer. Here is the opinionated, current shortlist. Where two cores compete, the tension is almost always accuracy versus the CPU you have.

Nintendo

NES: Mesen. It is PPU-accurate, has the broadest mapper coverage, and ships a genuine debugger; Nestopia and FCEUmm remain fine lightweight fallbacks for weak hardware. SNES: bsnes Accuracy if you have the ~4 GHz to spend and want cycle-accuracy with no hacks; Snes9x everywhere else, and it is the correct default on every handheld. Game Boy / Color: Gambatte or mGBA. GBA: mGBA, unambiguously — accurate, fast, and light enough for anything.

N64 is the system that will bite you, so read this twice. The mainline core is Mupen64Plus-Next, which bundles multiple graphics plugins (GLideN64 for HLE, angrylion, and ParaLLEl-RDP/RSP for LLE) so you can switch renderers per game; the libretro docs recommend it as the general default. The trap: an upstream regression in early 2025 broke a handful of titles — Stunt Racer 64 and World Driver Championship among them stopped loading — and the community's answer was to pin a known-good January build (see step 12, and why you keep backups). For accuracy-critical setups or any game that will not boot on Mupen64Plus-Next, the fallback is the standalone ParaLLEl N64 core with its Vulkan low-level renderer, which is more accurate on specific titles at the cost of narrower overall compatibility. 3DS: Citra is dead. Its replacement is Azahar, a merge of the prominent Citra forks, and its first official libretro core landed in Azahar 2125.0 Alpha 4 across six operating systems (Linux, Windows, macOS, Android, iOS, tvOS); the full 2125.0 stable brings it to the Core Downloader. Note what Azahar dropped: encrypted-title support and Nintendo CDN downloads, which now route through the separate Artic Setup Tool. Project home is azahar-emu.org.

Sony

PS1 is a three-way choice defined entirely by your hardware. Beetle PSX HW (Mednafen lineage, hardware renderer) is the most accurate and the heaviest — the right pick on a desktop. SwanStation (the DuckStation libretro descendant) is the balanced middle. PCSX ReARMed is ARM-optimized and the lightest by a wide margin, which is why it is the PS1 core powering budget handhelds under muOS, OnionOS, and ROCKNIX. Same system, three cores, and the correct answer is a function of the silicon in front of you.

PS2: LRPS2, a hard fork of PCSX2, with an important constraint — it is x86_64 only. It runs on Windows, Linux, and macOS (the last through Rosetta on Apple Silicon); there is no Android, no iOS, and no ARM-Linux build. Its headline feature is ParaLLEl-GS, a new renderer by Themaister written entirely as a compute program, supporting hardware paths (OpenGL, Vulkan including MoltenVK on macOS, and D3D11/12 on Windows) plus a software path for games that demand the extra accuracy, up to heavy supersampling. It needs a real PS2 BIOS to boot. The full write-up is libretro's own LRPS2 announcement from January 2025. If you are on a handheld and reading this hoping for a PS2 core: there is not one, and there will not be one soon. That is not a gap in this guide; it is the state of the world.

Sega and arcade

Sega: Genesis Plus GX is the workhorse — effectively 100% compatible across Mega Drive/Genesis, Sega CD, Master System, Game Gear, SG-1000, and the Pico, a pedigree it inherited from the Wii homebrew scene. The one thing it does not do is 32X; for that, load PicoDrive. Assuming one core covers the entire Sega 8/16-bit family is a classic beginner error that ends with a 32X ROM staring back at a black screen. Arcade: Final Burn Neo (FBNeo) is the default — a curated, well-maintained set reaching back to 1970s hardware, with romset-matching that is stricter and saner than the MAME cores. If FBNeo lacks a driver you need, the current MAME core is the fallback, with the usual caveat that its romset must match its version exactly.

Overrides and Per-Game Config

Once cores are installed, overrides are where RetroArch stops being a toy and becomes a system. The idea: set something globally, then override it for one core, one folder, or one game — without editing config by hand. The authority here is the overrides guide, and it is worth reading in full.

The hierarchy that decides everything

Overrides load in a strict precedence, most specific winning: game → content-directory → core → global. A global setting in retroarch.cfg is the baseline. A per-core override beats it for that core. A per-directory override beats that for content in that folder. A per-game override beats all of them for that one title. Internalize this order, because 90% of "my setting didn't stick" confusion is a more specific override silently outranking the change you just made globally.

Saving overrides (do not hand-edit)

You create overrides from the running game, not a text editor. With content loaded and your settings adjusted, use Quick Menu → Overrides → Save Core Overrides to bind them to that core, or Save Game Overrides to bind them to that single title. RetroArch writes the files into a predictable tree:

# Override config files:
config/<core>/<core>.cfg              # applies to every game on this core
config/<core>/<content-directory>.cfg   # applies to a whole folder
config/<core>/<game>.cfg              # applies to one game only

# Example, a per-game override for Beetle PSX HW:
config/Beetle PSX HW/Gran Turismo 2.cfg

The rule the docs are emphatic about: once an override exists, change it through the Quick Menu and re-save, rather than editing the file by hand. Manual edits and menu saves can fight each other, and the menu wins on the next save.

Core options are a different file — the .opt

Do not confuse a config override (frontend settings like video driver, shaders, aspect ratio) with a core option (the core's own settings like internal resolution or renderer). Core options live in retroarch-core-options.cfg globally, and per-game in a .opt file you create via Quick Menu → Options → Game-options file. The relevant global switches are game_specific_options and auto_overrides_enable; if per-game core options are not loading, that first key is your suspect. A worked per-game core-options file for an N64 title that wants a higher internal res looks like:

# config/Mupen64Plus-Next/Legend of Zelda, The - Ocarina of Time.opt
mupen64plus-rdp-plugin = "parallel"
mupen64plus-rsp-plugin = "parallel"
mupen64plus-EnableFBEmulation = "True"
mupen64plus-43screensize = "1440x1080"

Cores on Handhelds

The centre of gravity in this hobby has moved to ARM handhelds, and cores behave differently there in ways the desktop-centric guides gloss over. This section is the part they leave out.

The architecture trap

An armv7 (32-bit) handheld and an aarch64 (64-bit) handheld see different core lists, and a core built for one will not load on the other. This is not a bug; it is what "compiled for your architecture" means. It is why Retroid Pocket 3+ owners on Reddit hit walls where certain cores (a ColecoVision core, among others) simply would not run — an arch/build mismatch, not a broken device. When a core is present on your PC's downloader but absent or dead on your handheld, architecture is the first thing to check, not the last.

webOS, muOS, ROCKNIX and other locked-down distros

On a general-purpose Android handheld you install RetroArch like any app and the in-app downloader works normally — which is a real advantage of the Android devices covered in our Retroid Pocket 6 versus the discontinued G2 comparison. On the locked-down Linux distributions that power cheaper hardware, cores are curated for you and the downloader may be disabled entirely; you update by updating the whole firmware image. That firmware curation is frequently the entire story of a device's emulation quality — the thesis of our Miyoo Mini Plus vs RG35XX piece, where firmware beats silicon. The webOS case is the cleanest example of a community filling a gap: that December 2025 rebuild of 170-plus armv7 cores exists precisely because LG's platform is not going to hand you a Core Downloader.

Choosing lighter cores on purpose

On weak ARM you deliberately trade accuracy for playability, and knowing the swaps is the whole skill. PS1 becomes PCSX ReARMed instead of Beetle PSX HW. SNES stays on Snes9x, never bsnes. N64 leans on HLE rendering rather than the LLE Vulkan path. The same instinct applies to the frozen-in-time distributions: a project like RetroPie, still frozen at v4.8 with no x86 image in 2026, ships an older, lighter, and very stable core set precisely because chasing the newest core on constrained hardware is a losing game. Old and stable beats new and stuttering when the CPU is the constraint.

Common Pitfalls and Fixes

Six failures account for most of the wasted hours. Learn to recognize them by their symptoms.

The empty or stale Core Downloader

Symptom: the Core Downloader is blank, or a core you just installed shows as unrecognized. Cause: missing or stale Core Info Files. Fix: run Online Updater → Update Core Info Files, then reopen the downloader. This is step 3 for a reason; it is the single most common failure in the entire pipeline.

The core loads but content won't boot

Symptom: the core loads fine from Load Core, but a ROM produces a black screen or an instant kick back to menu. Cause: a missing BIOS in the System directory, or a content format the core rejects. Fix: check the log (step 14) for a BIOS-not-found line; confirm the BIOS filename and hash match what the core's .info demands; for disc systems, load the .cue or .m3u, not the raw .bin.

Assuming one core covers a whole family

Symptom: most Sega games work, but 32X titles are black screens. Cause: Genesis Plus GX does not do 32X. Fix: load PicoDrive for 32X. The general lesson: read the core's .info for exactly which subsystems it claims, and do not assume.

Downloading a core into a stale frontend

Symptom: a freshly downloaded core will not load, with a vague failure. Cause: the frontend is old enough that the core's libretro API revision is ahead of it. Fix: update RetroArch to 1.22.2 first (step 1), then re-download the core.

The N64 regression

Symptom: a specific N64 title that used to work stopped loading after an update. Cause: the early-2025 Mupen64Plus-Next regression. Fix: roll back to your backed-up known-good core (step 12), pin the community's January build, or switch that one game to ParaLLEl N64 via a per-game override.

Expecting a PS2 core on ARM

Symptom: LRPS2 does not appear in your handheld's downloader. Cause: it is x86_64-only and no ARM build exists. Fix: none — use a PC for PS2, or accept the limitation. This is the pitfall of wishful thinking, and the fix is recalibrated expectations.

Troubleshooting Table

Read the log first

Before you touch this table, enable logging: Settings → Logging → Logging Verbosity: On, Frontend Logging Level: 0 (Info). Reproduce the fault, then read the log. Every row below is faster to resolve when you already know which line the log complained about.

Symptom, cause, fix

When to abandon a core

Some fights are not worth winning. If a core needs a BIOS you cannot legally obtain, targets an architecture your device does not have, or is chasing accuracy your CPU cannot deliver, the answer is a different core or a different device — not another hour in the settings menu. The lightest core that runs the game at full speed is, on a handheld, the correct core, full stop.

Advanced Tips

Nightly cores from the buildbot

When a fix landed upstream this week but the stable downloader has not caught up, the buildbot has it. Per-platform nightlies live at buildbot.libretro.com/nightly, organized by OS and architecture; download the matching .zip, extract the core into your Cores directory, and run Update Core Info Files so the manifest recognizes it. This is also how you grab a core that is not in the stable channel yet. The tradeoff is real: nightlies are where regressions are born, so keep your step-12 backup.

Latency: run-ahead and preemptive frames

These are frontend features, so they work across cores, and they are the closest thing RetroArch has to magic. Run-Ahead (Settings → Latency) internally runs the core one or more frames into the future and displays that, hiding the input lag the original hardware had; one frame of run-ahead often removes more perceived latency than the entire rest of your setup combined. Its cost is CPU — the core runs multiple times per displayed frame — so it suits light 8/16-bit cores and punishes heavy ones. Preemptive Frames is a newer, cheaper alternative for cores that support save-states well, achieving a similar result with less overhead. Try one frame of run-ahead on an NES or SNES core and feel the difference before you decide it is snake oil.

Per-core scaling and shader presets

Because overrides are per-core, you can bind a CRT shader and integer scaling to your 2D cores while leaving your 3D cores on a clean bilinear stretch — and never think about it again. Save a shader preset, adjust aspect and integer-scale settings, then Save Core Overrides under, say, Snes9x. Every SNES game now boots into your CRT look; every N64 game does not. This is the payoff for understanding the hierarchy in the overrides section: configuration you set once and inherit forever.

A Complete Working Config

Here is a coherent, working baseline you can adapt. It assumes a desktop 1.22.2 install and a tidy directory layout. Treat it as a starting point, not scripture — the point is that every value below has a reason you now understand.

Directory layout

RetroArch/
├── retroarch.cfg                 # global settings
├── cores/                        # the .dll/.so/.dylib core binaries
├── info/                         # the .info manifest (Update Core Info Files)
├── system/                       # BIOS files live here
├── saves/                        # .srm saves, redirected
├── states/                       # save states
├── playlists/                    # scanned per-system lists
└── config/                       # overrides, per core
    ├── Snes9x/
    │   └── Snes9x.cfg            # CRT shader + integer scale, SNES-wide
    ├── Mupen64Plus-Next/
    │   └── ...opt                # per-game core options
    └── Beetle PSX HW/
        └── ...cfg                # per-game overrides

Global retroarch.cfg essentials

# --- Video ---
video_driver = "vulkan"
video_fullscreen = "true"
video_vsync = "true"
video_scale_integer = "false"     # set true per-core for 2D + CRT shaders

# --- Directories (adjust to your paths) ---
system_directory = ":/system"
savefile_directory = ":/saves"
savestate_directory = ":/states"

# --- Overrides and core options ---
auto_overrides_enable = "true"
game_specific_options = "true"     # required for per-game .opt files
core_updater_auto_extract = "true"

# --- Latency (tune per device) ---
run_ahead_enabled = "false"        # enable per light core, 1 frame
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"

# --- Logging (turn on when debugging) ---
log_verbosity = "false"
frontend_log_level = "0"

A per-game override, end to end

Say Gran Turismo 2 needs a touch more accuracy on Beetle PSX HW. Load it, raise the internal resolution and enable the PGXP perspective correction in Quick Menu → Options, then Save Game Overrides. RetroArch writes:

# config/Beetle PSX HW/Gran Turismo 2.cfg   (frontend override)
video_scale_integer = "false"
aspect_ratio_index = "22"          # core-provided aspect

# config/Beetle PSX HW/Gran Turismo 2.opt   (core options)
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_pgxp_mode = "memory only"
beetle_psx_hw_pgxp_texture = "enabled"

Now that one game runs sharper, every other PS1 game keeps the lighter global defaults, and you did not touch a single value by hand after the first save. That is the whole philosophy of cores in RetroArch: install deliberately, choose by hardware, override by exception, and read the log when it lies to you. Do that and the 200-plus catalogue stops being a slogan and starts being a toolbox — one you own, on whatever hardware you happen to be holding.