RetroArch Cores 2026: 200+ Systems in 14 Steps

RetroArch does not emulate anything. The sentence annoys people, so here it is again: the application you just installed emulates nothing. It draws menus, polls controllers, resamples audio, runs shaders, and keeps your save files in order. The work you actually care about — impersonating a Super Nintendo, a Neo Geo MVS board, a PlayStation — is done by a core: a separate library that RetroArch loads at runtime and can unload a moment later to become something else entirely.

This one fact dissolves most of the confusion a newcomer brings. A core is a shared library — a .so on Linux and Android, a .dll on Windows, a .dylib on macOS — that implements the libretro API. RetroArch is merely the best-known frontend that speaks that API. There are others, and any program implementing the API can host the same cores, which is why the libretro ecosystem now reaches well beyond emulation into media players and game engines.

As of June 2026 the libretro project maintains over 200 cores spanning emulators, game engines, and multimedia programs, indexed on the official cores page. None of them ship with the application. A clean RetroArch install has zero cores loaded — by design — and the first thing every guide on Earth tells you to do is go fetch some. This tutorial tells you which ones, why, and how to keep the whole arrangement from collapsing the first time a core update silently changes a save-state format under you.

One housekeeping note before the lore: RetroArch ships cores; it does not ship games or BIOS images, and neither does this article. Where a system needs a BIOS, the lawful path is to dump it from hardware you own. The same goes for ROMs. I will point at the tools and stay quiet about the rest.

What a Core Actually Is

The libretro API in one paragraph

A core is a library that exports a fixed set of functions — retro_init, retro_load_game, retro_run (called once per frame), retro_get_system_av_info, and retro_serialize / retro_unserialize for save states, plus a handful more. The frontend calls retro_run sixty-ish times a second; the core hands back a framebuffer and a slice of audio, and reads whatever input the frontend collected. Because the contract is frozen, the same compiled core runs under RetroArch on your desktop, under RetroArch on a Raspberry Pi, inside Lakka, inside Batocera, or under any other program that implements the API. The frontend is replaceable. The core is the emulator.

That generality is the point of the libretro backend story: the API is open enough that other applications have adopted it, and the catalogue has grown past pure emulation as a result. You can read the whole specification, and build a core yourself, from the RetroArch source on GitHub. When you choose Load Core in the menu you are literally telling the frontend which shared library to dynamically link; choose another and the same chassis becomes a different console.

Emulators, engines, and multimedia

Not every core is an emulator. Some are game engines recompiled against libretro — the ScummVM core runs LucasArts adventures, Cannonball runs the OutRun engine, the DOSBox cores run DOS software, and there is a core that is nothing but the number puzzle 2048. At least one core, the FFmpeg core, is a plain media player. This is why core and emulator are not synonyms, and why the count of 200-plus cores on the index includes things that never shipped on a cartridge.

The practical consequence: when you open the download list you will see dozens of names that mean nothing to you. That is fine. You do not install all of them. You install the six or eight that match the systems you actually own games for, and you ignore the rest until the day you need one.

Cores, info files, and why both matter

Each core ships with a companion .info file that describes it: the systems it claims, the file extensions its scanner recognises, whether it needs a BIOS, its licence, and whether it supports save states, netplay, and run-ahead. RetroArch reads these info files to build the 'Download a Core' list and to drive the content scanner.

Burn this into memory, because it is the single most common cause of 'it is broken' reports: if your info files are missing or stale, perfectly good cores either fail to appear in menus or refuse to recognise your ROMs when you scan. The fix is always the same — update the core info files before you blame the core. We will do exactly that in the steps below.

Prerequisites: Versions and Hardware

You need three things, in order: the right build of RetroArch, a machine that clears the floor for the cores you want, and a place to put BIOS files and ROMs. Skip any of them and the rest of this tutorial will fight you.

Software you need

Install the latest stable RetroArch — the 1.2x line shipping through 2025 and 2026 — from a source you trust: the official site, Steam, F-Droid, or your distribution's package. Avoid random APK mirrors and 'modded' builds. This is not paranoia: cores from the official buildbot are matched to the frontend's libretro API revision, and a core built against a newer API than your frontend simply refuses to load. Mismatched binaries are the number-one reason a freshly downloaded core throws 'Failed to load'.

Prefer a 64-bit operating system: Windows 10 or 11 (64-bit), a current Linux, macOS 11 or newer, or Android 9 and up. The mGBA recommendation in the research is explicitly an Android-era pick, and Android handhelds are now first-class libretro targets. Exotic architectures need matching builds — which is the whole reason the official cores listing is mirrored per platform. The webosbrew project rebuilt 170-plus cores for WebOS on armv7 in December 2025 precisely because a desktop x86-64 core will not run on a TV's ARM chip.

Finally, you need a working internet connection. The Online Updater is a network operation, full stop; Retro Game Corps' starter guide is blunt that nothing downloads while you are offline. If you intend to use the Vulkan cores or the new ParaLLEl GS renderer, your GPU driver must expose Vulkan 1.1 or later; otherwise plan to fall back to the GL or GLcore drivers.

The directory layout

RetroArch keeps everything under one configuration root. Know where yours is before you touch anything else:

# Linux / Steam:   ~/.config/retroarch   (Flatpak: ~/.var/app/org.libretro.RetroArch/config/retroarch)
# Windows (portable build): the folder you unzipped
# macOS:           ~/Library/Application Support/RetroArch

~/.config/retroarch/
├── cores/        # the .so / .dll / .dylib cores live here
├── info/         # one .info file per core — do NOT skip these
├── system/       # BIOS images go here, named exactly
├── downloads/    # Online Updater drops archives here
├── playlists/    # generated by the scanner
├── thumbnails/   # boxart, snaps, title screens
├── config/       # per-core and per-game override files
├── saves/        # battery saves (.srm)
├── states/       # save states (.state) — version-fragile
└── retroarch.cfg # the global config

Hardware floor by tier

Be honest about the spread, because 'RetroArch is slow' almost always means 'you picked an accuracy core for hardware that cannot afford it'. Three tiers:

Light. Mesen for NES, Gambatte for Game Boy, Genesis Plus GX for the Sega 8/16-bit line — these run on a potato, including the cheapest handhelds. If your device is a Miyoo-class budget unit, live here and you will never see a dropped frame; the curation in our Miyoo Mini Plus game list is built entirely around this tier.

Mid. snes9x, mGBA, FinalBurn Neo for most boards, PCSX-ReARMed for PlayStation — these want a real CPU but nothing exotic. Any phone or single-board computer from the last few years handles them.

Heavy. bsnes, Beetle PSX HW with upscaling, FlyCast at high internal resolution, anything doing N64 low-level emulation — these want desktop-class single-thread performance and a Vulkan GPU. The research is explicit that bsnes is accuracy-first and unsuitable for weak hardware. On portable silicon this is the dividing line: the difference between a device that runs bsnes and one that stutters is real money, which is the whole argument in our Retroid Pocket 6 review.

Storage, BIOS, and the system folder

Two folders carry the legally interesting payloads. The system directory holds BIOS images, which cores look up by exact filename and, for the strict cores, by hash. The content directory — your roms folder — holds the games. RetroArch ships neither, and this article points at neither. Where a BIOS or a ROM is needed, the lawful route is to dump it from hardware you own; if you want the mechanics of pulling data off your own cartridges, that is its own project, covered in our Retrode 3 cart-dumping walkthrough.

Here is what a populated system folder looks like for the disc-based systems that actually need a BIOS. Note the canonical filenames — a Beetle PSX install that cannot find scph5501.bin will boot to a black screen and nothing else:

~/.config/retroarch/system/
├── scph5500.bin   # PS1 BIOS, NTSC-J   (Beetle PSX)
├── scph5501.bin   # PS1 BIOS, NTSC-U
├── scph5502.bin   # PS1 BIOS, PAL
├── dc_boot.bin    # Dreamcast boot ROM (FlyCast)
├── dc_flash.bin   # Dreamcast flash ROM
└── gba_bios.bin   # optional — mGBA boot logo and edge-case accuracy

Installing Cores: The 14-Step Path

What follows is the order that prevents the most rework. If you want a leaner version of the same journey, our 12-step core-install walkthrough compresses it; the version here spends extra steps on the things people skip and then file bug reports about.

Foundation: steps 1 to 5

1. Confirm the hardware and OS floor. Decide which tier of core you are targeting and make sure your machine and GPU driver clear it. Doing this first stops you from installing bsnes on a device that can only run snes9x and then concluding the software is broken.
2. Install the latest stable RetroArch from a trusted source. Official site, store, or distro package — never a mystery mirror. Rationale: core binaries are tied to the frontend's libretro API version, and the official buildbot builds against the stable line, so a trusted frontend is what makes the buildbot cores loadable at all.
3. Launch RetroArch once and quit. The first launch creates the directory tree and a default retroarch.cfg. Rationale: you cannot point at folders that do not exist yet, and editing the config before it is generated just gets overwritten on next start.
4. Set your directories explicitly. In Settings > Directories — or by editing the cfg — set the cores, info, system, playlist, and ROM-browser paths. Rationale: explicit paths make the install portable and kill the 'core not found' class of error caused by RetroArch looking somewhere you did not expect.
5. Get online and check the updater URL. Confirm network access and that the buildbot URL in the config is intact. Rationale: the Online Updater does nothing offline, and a blank or hand-edited buildbot URL silently breaks every download that follows.

Fetching cores: steps 6 to 9

6. Update the core info files first. Online Updater > Update Core Info Files. Rationale: the info files are what populate the download list and tell the scanner which extensions map to which system. Out-of-date info files make new cores invisible. This is the step everyone skips and everyone regrets.
7. Update assets, databases, and (optionally) thumbnails. Still under Online Updater. Rationale: the databases are what the content scanner matches your ROMs against; without them, scanning produces empty playlists even with the correct core installed.
8. Download the cores you actually need. Use Online Updater > Update Cores for the buildbot list, or Load Core > Download a Core to grab them one at a time. Rationale: a fresh install has zero cores, and this is the supported way to add them without reinstalling the application. Pull only the cores matching your systems; you are not collecting all 200.
9. Pick the right core per system. Match each system to the recommended core from the table in the next section rather than grabbing the first search result. Rationale: the default is not always the accurate choice, and the accurate choice is not always right for your hardware.

Wiring up content: steps 10 to 14

10. Place BIOS files and verify them. Drop the correctly named BIOS images into the system folder and, for strict cores, confirm the hashes match. Rationale: PlayStation (Beetle PSX) and Dreamcast (FlyCast) will not boot without the right BIOS; a wrong-region or corrupt file produces a black screen that looks like a core bug but is not.
11. Scan your content directory. Import Content > Scan Directory, and let it scan inside archives. Rationale: scanning hashes each file and matches it against the database to build clean, named playlists; the Beetle PSX and FlyCast workflows both lean on scanning inside archives to validate files before launch.
12. Set per-core options. Load a core, open Quick Menu > Core Options, and set the renderer and internal resolution to suit your hardware. Rationale: defaults are conservative; this is where you turn on the Vulkan renderer or dial upscaling down so a heavy core stays at full speed.
13. Create overrides for the exceptions. Save core overrides or game overrides for the handful of titles that need different settings. Rationale: you want one sane global config plus narrow exceptions, not a global config bent around a single misbehaving game.
14. Verify with a known-good test and read the log. Launch one game per system you set up and, if anything misbehaves, turn on logging and read it. Rationale: the log names the failure — missing BIOS, wrong renderer, bad core — in plain language, and saves you from guessing.

After step 8, a quick directory listing is the fastest sanity check that the cores actually landed. Expected output on Linux looks like this:

$ ls -1 ~/.config/retroarch/cores | head
bsnes_libretro.so
fbneo_libretro.so
flycast_libretro.so
gambatte_libretro.so
genesis_plus_gx_libretro.so
mednafen_psx_hw_libretro.so   # = Beetle PSX HW on the buildbot
mesen_libretro.so
mgba_libretro.so
mupen64plus_next_libretro.so
snes9x_libretro.so

The Right Core for Each System

For most systems there is one core the accuracy crowd has settled on, one or two lighter alternates for weak hardware, and a pile of historical also-rans. Here are the settled picks for 2026, drawn from the libretro project's own recommendations and the accuracy rankings published by XDA.

The 8-bit and 16-bit homes

For the NES, the pick is Mesen — it balances near-reference accuracy with performance light enough to be the default rather than a luxury. For the SNES, bsnes is the accuracy king and, deliberately, a hardware hog; on anything portable, fall back to snes9x, which is faster and wrong in ways you will almost never notice. Genesis Plus GX owns the Sega side: it runs not just the Genesis / Mega Drive but Master System, Game Gear, and SG-1000 from one core, which is exactly the breadth the research highlights. Game Boy and Game Boy Color belong to Gambatte, the long-standing standard; Game Boy Advance goes to mGBA, the accuracy pick called out for Android and a fine default everywhere else.

Arcade, disc systems, and the hard cases

Arcade emulation is FinalBurn Neo's to lose, and it does not — it is ranked the most accurate arcade core while also being faster than the alternatives, a rare combination. PlayStation goes to Beetle PSX (the HW variant when you want Vulkan upscaling and PGXP), the default the research endorses. Dreamcast is FlyCast, the default core, which doubles as your NAOMI and Atomiswave board. The genuinely hard case is the Nintendo 64: Mupen64Plus-Next is the default, but it suffered a significant regression in early 2025 that broke compatibility across multiple games and made it a rough year for N64 in RetroArch — so keep ParaLLEl N64 or a pinned older build on hand. For the heavier disc systems, Saturn leans on Beetle Saturn (accurate, brutal) or Kronos (faster), and PlayStation 2 on the newer LRPS2.

Why most accurate is not best for you

Accuracy is a budget, not a virtue you can max for free. The XDA rankings correctly crown FinalBurn Neo and bsnes, and that is frequently the wrong advice for a handheld. The honest mapping is simple: take the accurate core if your hardware tier can afford it, and take the lighter alternate if it cannot. Nobody is impressed that you ran bsnes at 40 frames per second. This is also why the WebOS armv7 rebuild matters — on constrained ARM hardware the lighter alternates are not a compromise, they are the only thing that runs at full speed. Here is the whole field in one table: recommended core, the lighter fallback, whether the system needs a BIOS, and the catch.

Accuracy vs. Speed: The Real Tradeoff

Every core sits somewhere on a line between 'behaves exactly like the original chip' and 'runs fast on whatever you have'. Knowing where your core sits — and where you need it to sit — is most of the skill.

What accuracy buys

Cycle-accurate cores like bsnes, Mesen, and the Beetle family reproduce timing the hardware actually had: mid-scanline raster tricks, precise audio mixing, copy-protection checks that sloppier cores fail, and the one obscure game that breaks on everything else. When a game has a graphical glitch on snes9x and looks perfect on bsnes, this is why. You pay for it in CPU cycles, and the bill is large — which is the entire reason the lighter alternates exist.

What HLE and speed hacks cost

The other direction is high-level emulation and speed hacks: approximate the hardware's results instead of reproducing its process. PGXP cleans up PlayStation polygon wobble, frame-skipping buys headroom, CPU overclock options push past the original's own slowdown. These are wonderful until you hit the title that depended on the exact behaviour you approximated away — and then the fix is to turn the hacks off and pay full price. Treat speed hacks as per-game exceptions, not a global posture, and you will spend far less time wondering why one game in thirty looks wrong.

Run-ahead and latency, the modern reason to care

The reason accuracy and performance collide in 2026 is run-ahead. The frontend runs the core forward extra frames, shows you the later result, and rolls back using save states — which erases the input latency the original hardware actually had. It only works on a core fast enough to run several times per displayed frame, and disciplined enough to have rock-solid save states. So the latency feature you want pushes you back toward fast, deterministic cores. The minimal configuration:

run_ahead_enabled = "true"
run_ahead_frames = "1"               # raise only while it stays full speed
run_ahead_secondary_instance = "true"  # protects save data; costs extra CPU

Start at one frame. Raise it only while the core holds full speed, and only on cores whose info file advertises save-state support — run-ahead on a core without reliable serialization will corrupt state or simply refuse to engage.

Renderers, Vulkan, and ParaLLEl GS

The video driver is a global setting, but several cores care deeply about which one you picked, and a few will not initialise under the wrong one.

Picking the video driver

Your realistic choices are gl, glcore, vulkan, the Direct3D drivers on Windows, and the software fallback. Beetle PSX HW's hardware renderer wants Vulkan; the parallel cores want Vulkan; older GL-only setups should stay on glcore. Set it once globally and override per-core only where a core demands otherwise:

video_driver = "vulkan"          # "glcore" if your GPU lacks Vulkan 1.1+
video_vsync = "true"
video_threaded = "false"         # leave off for accuracy cores
video_fullscreen = "true"
menu_driver = "ozone"

ParaLLEl GS, the new LLE renderer

The headline addition for the accuracy crowd is ParaLLEl GS, a brand-new Vulkan-powered low-level-emulation renderer. Low-level emulation means it simulates the graphics hardware's behaviour at the register level rather than translating its drawing commands into your GPU's API by hand — slower, but far closer to what the original silicon did, which matters for the engines that abused hardware quirks. It is the sibling of the paraLLEl-RDP renderer that did the same job for the Nintendo 64. The broader significance ties back to the libretro backend story: the API keeps absorbing this kind of heavy graphics work as plug-in technology, so the same renderer can serve any frontend that implements the API, not just RetroArch.

Internal resolution and the upscaling tax

Internal resolution is the dial that melts GPUs. A core rendering at native 1x is cheap; at 4x it is doing sixteen times the fragment work, and at 8x, sixty-four times. Weak hardware should sit at 1x or 2x and spend its budget on accuracy instead. On PlayStation specifically, enable PGXP for geometry before you chase resolution — straight polygons at 2x beat wobbling ones at 8x every time. The relevant core options, documented in the Beetle PSX core docs, look like this:

# config/Beetle PSX HW/Beetle PSX HW.opt
beetle_psx_hw_renderer = "vulkan"
beetle_psx_hw_internal_resolution = "4x"      # drop to "1x" on weak GPUs
beetle_psx_hw_pgxp_mode = "memory only"       # kills polygon wobble
beetle_psx_hw_pgxp_texture = "enabled"
beetle_psx_hw_widescreen_hack = "disabled"    # breaks 2D layers in many games
beetle_psx_hw_skip_bios = "disabled"

Common Pitfalls and Fixes

Seven failures account for most of the grief. None of them are mysterious once you know the pattern.

Loading and discovery

Cores download but never appear, or appear and ignore your ROMs. Almost always stale core info files. Fix: Online Updater > Update Core Info Files, then restart. 'Failed to load core'. Architecture or API mismatch — an x86-64 core on ARM, a 32-bit core on a 64-bit frontend, or a buildbot core newer than your frontend. Fix: match the build to your platform and update RetroArch to the stable line. This is the exact problem the WebOS armv7 rebuild of 170-plus cores exists to solve: the right code for the right chip.

Content and BIOS

Black screen with audio, or no boot at all, on PlayStation / Dreamcast / Saturn. Missing, misnamed, or wrong-region BIOS. Fix: put the correctly named image in the system folder and verify it. Scanning adds nothing to your playlist. The ROM is not in the database, is misnamed, or is inside an archive you did not scan inside. Fix: scan inside archives and name files to the No-Intro / Redump conventions the database expects.

Performance and platform

bsnes runs below full speed. Working as designed — it is not for weak hardware. Fix: switch to snes9x. N64 games glitch or crash on 2025 builds. The Mupen64Plus-Next regression. Fix: switch to ParaLLEl N64 or pin an older core build. A Vulkan core refuses to start. Your driver does not expose Vulkan. Fix: update the GPU driver, or set the video driver to glcore and use a GL-capable core.

Troubleshooting Table

Turn on logging before you panic

Before you guess, make RetroArch tell you what happened. Turn the logging verbosity up and watch the log; it names the failure in plain language. The keys:

log_verbosity = "true"
frontend_log_level = "0"     # 0 = show everything
libretro_log_level = "0"

A failed PlayStation boot, for instance, prints something close to this — and the cause is named on line three, not left to your imagination:

[INFO] [Core]: Loading dynamic core: mednafen_psx_hw_libretro.so
[libretro INFO] Beetle PSX: content loaded.
[libretro ERROR] Beetle PSX: cannot open BIOS file "scph5501.bin".
[ERROR] [Content]: failed to load content for the current core.
[ERROR] [Core]: this core needs a BIOS placed in the system directory.

The table

Ten symptoms, their usual causes, and the fix:

Save states are not backups

One recurring 'bug' deserves its own warning: save states are tied to a core's exact serialization format, and that format can change between core versions. Update a core and your old states may load garbage or refuse entirely. Battery saves — the .srm files in your saves folder — are portable; save states are not. Keep your real progress in in-game saves, and treat states as the disposable convenience they are, which is also why the baseline config below disables state autosave.

Advanced Tips

Once the basics hold, these are the techniques that separate a working setup from a good one.

Overrides and remaps

RetroArch resolves settings in layers: global, then per-core override, then per-content-directory, then per-game. Save a core override for settings that should apply to every game on a core (renderer, default filter), and a game override for the one title that needs something special. Input remaps are separate files again, so you can give a single game a different button layout without touching anything else. The discipline is the same as good configuration anywhere — one sane base, narrow exceptions, nothing buried. A per-game override looks like this:

# config/Snes9x/Super Metroid (USA).cfg
# Overrides applied ONLY to this one game, layered on the core override.
video_smooth = "true"
rewind_enable = "true"

Run-ahead, rewind, and netplay determinism

Three features all lean on the same property: a deterministic core with solid save states. Run-ahead cuts latency, rewind lets you scrub backward, and netplay keeps two machines in lockstep — and all three break on cores that serialize sloppily. Before you enable them, check the core's info file for save-state and netplay support. RetroAchievements' hardcore mode, for its part, disables save states and rewind entirely, so decide which you care about more before you flip hardcore on. Soft-patching (drop an IPS or BPS patch next to the ROM) and shaders such as crt-guest-advanced layer on top of all of this — shaders in particular cost real GPU time, so budget for them the same way you budget internal resolution.

Pinning core versions and using the buildbot

When a core update breaks you — the 2025 N64 regression being the canonical example — you do not have to live with it. Keep a copy of the last-good core binary outside the cores folder and restore it after updates, or pull a specific build straight from the libretro buildbot. The whole pipeline is open on GitHub, and you can read each core's options in the libretro documentation rather than guessing at key names. While you are there: the same cores power the turnkey distributions, so if you would rather not hand-build any of this, a Batocera install ships the same libretro cores pre-wired.

A Complete Working Configuration

Here is a baseline that works on a desktop-class machine and degrades gracefully on weaker ones. Treat it as a starting point: the global file sets sane defaults, and the two override files show how to bend them for a specific core without polluting the global config.

Global retroarch.cfg

# =====================================================================
#  retroarch.cfg — sane 2026 baseline. Paths assume Linux; adjust per OS.
#  Everything here is overridable per-core and per-game.
# =====================================================================

# --- Directories -----------------------------------------------------
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/info"
system_directory = "~/.config/retroarch/system"
playlist_directory = "~/.config/retroarch/playlists"
savefile_directory = "~/.config/retroarch/saves"
savestate_directory = "~/.config/retroarch/states"
rgui_browser_directory = "~/roms"

# --- Video -----------------------------------------------------------
video_driver = "vulkan"
video_vsync = "true"
video_threaded = "false"
video_fullscreen = "true"
video_scale_integer = "true"
video_smooth = "false"
aspect_ratio_index = "22"          # 22 = Core Provided

# --- Audio -----------------------------------------------------------
audio_driver = "alsathread"        # wasapi on Windows, coreaudio on macOS
audio_latency = "64"
audio_sync = "true"

# --- Latency (enable per-core once you confirm full speed) -----------
run_ahead_enabled = "false"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"

# --- Online Updater --------------------------------------------------
core_updater_buildbot_url = "http://buildbot.libretro.com/nightly"
core_updater_buildbot_assets_url = "http://buildbot.libretro.com/assets/"
core_updater_auto_extract_archive = "true"

# --- Menu and quality of life ---------------------------------------
menu_driver = "ozone"
quick_menu_show_save_core_overrides = "true"
quick_menu_show_save_game_overrides = "true"
savestate_auto_save = "false"      # autosaved states corrupt across core updates

A Beetle PSX HW core-options file

Core options live in their own per-core file under the config directory. This one assumes a Vulkan GPU; drop the resolution to 1x and the renderer to software on weak hardware:

# config/Beetle PSX HW/Beetle PSX HW.opt  — assumes a Vulkan GPU
beetle_psx_hw_renderer = "vulkan"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_depth = "16bpp"
beetle_psx_hw_pgxp_mode = "memory only"
beetle_psx_hw_pgxp_texture = "enabled"
beetle_psx_hw_pgxp_vertex = "enabled"
beetle_psx_hw_widescreen_hack = "disabled"
beetle_psx_hw_skip_bios = "disabled"
beetle_psx_hw_analog_toggle = "enabled"

An SNES per-core override

And the override that forces snes9x onto the GL renderer with no smoothing, applied to every game that core runs:

# config/Snes9x/Snes9x.cfg  — applies to EVERY game run under Snes9x
video_driver = "glcore"
video_smooth = "false"
input_player1_analog_dpad_mode = "0"

That is the whole machine. RetroArch is the chassis, the cores are the engines, and the configuration above is the tuning. Keep the info files current, keep a fallback core for the day an update betrays you, dump your own BIOS, and the 200-plus library stays exactly as boring and reliable as good infrastructure is supposed to be. The frontend was never the emulator. Now you know which part is.