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

RetroArch advertises over 200 cores. That figure is true the way a warehouse "has" 200 products: it describes the catalogue on the buildbot, not what is sitting on your device after you press Download. Depending on your platform the real count collapses hard — the webOS Homebrew channel, for instance, listed roughly 170-plus armv7 cores as of December 2025, and a locked-down console port might expose a few dozen. The catalogue is the promise. The core you actually load is the product.

This guide is about closing the gap between the two. In about forty minutes and twelve steps you will install RetroArch, populate it with the correct cores for the systems you care about, understand why the buildbot cheerfully hands you emulators your CPU cannot run, and set up an override hierarchy so one badly-behaved game does not impose its settings on your entire library. We are using RetroArch 1.22.2, released November 20, 2025 and the current stable build as of mid-2026; the 1.22.0 release had a shader-related black-screen bug that was fixed in 1.22.1 and 1.22.2, and the previous milestone line, 1.21.0, shipped April 29, 2025 with the Apple Vulkan, CoreMIDI, and 3DS fixes. Version numbers matter here more than they usually do, because a core's info file and the frontend that reads it must agree, and the single most common self-inflicted wound in this hobby is updating one without the other.

The Machine's promise: no "just download everything" advice, no pretending a fifty-dollar handheld runs PlayStation 2, and a working configuration file at the end you can paste and forget.

What a Core Actually Is

The libretro API in one paragraph

RetroArch is not an emulator. It is a frontend — a shell that handles video output, audio, input, save states, shaders, netplay, and menus — and it talks to emulators through a stable C API called libretro. A core is a single dynamic library (a .dll on Windows, .so on Linux and Android, .dylib on macOS) that implements that API. Inside that library is an actual emulator — Snes9x, mGBA, Genesis Plus GX, whatever — recompiled so that instead of drawing its own window and reading its own controller, it hands frames and audio to RetroArch and receives input back. The libretro API is the contract. The core is one party to it. RetroArch is the other, and the project ships under GPLv3 with a codebase that has passed thirteen thousand GitHub stars.

This separation is the entire point. It means the same save-state code, the same shader pipeline, the same netplay implementation, and the same latency-reduction tricks work across every system, because none of that lives in the emulator anymore. It also means a bug in the frontend affects every core at once, and a mismatched core-info file can make a perfectly good emulator refuse to appear in the menu. When you internalize that RetroArch is plumbing and the cores are the appliances, the whole system stops being mysterious.

Emulator, core, frontend: the three-body problem

Keep three words straight and ninety percent of the confusion evaporates. The emulator is the upstream project — say, mGBA, written by Vicki "endrift" Pfau. The core is that emulator wrapped in libretro (mgba_libretro.dll). The frontend is RetroArch. When someone says "the mGBA core is more accurate than the gpSP core," they are comparing two upstream emulators that both happen to be available as cores. When someone says "my core won't load," they almost never have an emulator problem — they have a frontend, path, or BIOS problem. Ninety percent of "broken core" threads are one of those three, and none of them are the emulator's fault.

Why 200-plus is a marketing number

The buildbot compiles cores for many platforms, and the 200-plus figure is the union of everything it has ever built, including game engines (the Doom-running PrBoom, the point-and-click ScummVM), multimedia players, and a handful of chess engines. It is not 200 useful emulators, and it is certainly not 200 cores available for your device. If you want the real, filtered catalogue, read it at the official RetroArch cores page and cross-reference the per-core documentation on the libretro core list. Hardware purists will point out that none of this is emulation-free: if you would rather reimplement the console in logic gates than approximate it in software, an FPGA platform like the MiSTer Multisystem 2 takes a completely different road, and we will return to that trade-off in the pitfalls.

Prerequisites: Versions and Hardware

Software versions that have to agree

Install RetroArch 1.22.2 before you touch a single core. The download lives on the official site and, for the truly release-note-curious, every tag is archived on the RetroArch GitHub releases page. Use your platform's package manager where you can, because it keeps the frontend and the buildbot in step:

REM Windows (winget)
winget install Libretro.RetroArch
winget upgrade Libretro.RetroArch

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

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

# Confirm the version string BEFORE downloading cores
retroarch --version
# RetroArch 1.22.2 (Git ...) 

The reason this is step zero and not step three: core info files, which describe every core's name, supported extensions, and required BIOS, are versioned against the frontend. Download cores built for 1.22.x against a frontend from 2023 and they will either fail to load or show as "unknown" in the list. Match the versions first, argue about cores later. On the Steam Deck and most desktop Linux the Flatpak is the path of least resistance; if you insist on a distro package, remember the buildbot builds are usually fresher than what your repo ships.

Hardware reality check

Most cores are trivially light — an NES or Game Boy core will run on a potato. The heavy tail is where people get hurt. The bsnes accuracy profile is cycle-accurate and wants roughly a 4 GHz single-thread CPU to hold full speed; on a handheld it will chug, which is why Snes9x exists. The LRPS2 PlayStation 2 core is a hard fork of PCSX2 and is x86_64 only — it builds for Windows, Linux, and macOS under Rosetta, and there is no Android, iOS, or ARM-Linux binary. Saturn accuracy (Beetle Saturn), Dreamcast (Flycast), and PSP (the PPSSPP core) all sit in the moderately-heavy band and want a real GPU and a modern CPU to feel good. If you are on an ARM handheld like the Retroid Pocket 6, PS2-in-RetroArch simply does not exist, and no amount of Update Cores will conjure it — you fall back to the light, ARM-tuned cores instead. Budget accordingly: 4 GB of RAM is a floor, 8 GB is comfortable, and your storage pressure comes almost entirely from ROMs, since cores themselves are 1–30 MB each.

BIOS and ROMs: the part they do not ship

RetroArch ships the emulators. It does not ship the copyrighted firmware some of them need, and it does not ship games. PlayStation, Saturn, PS2, Dreamcast, Neo Geo, and several others will black-screen or error without the correct BIOS placed in your system/ directory, matched by exact hash and region. Where those files come from is your problem and your legal exposure — we cover the law at the end, but the short version is: dump your own. If you are hunting for the tooling to pull firmware and saves off original cartridges, that is a separate rabbit hole and a separate afternoon. Get the directory right now, because the failure mode for a misplaced BIOS is a silent black screen with no dialog, and you will waste twenty minutes blaming the core.

Installing Cores in 12 Steps

Here is the ordered procedure. Every step has a reason; skipping the ordering is how you end up with an empty Core Downloader and a forum post.

1. Verify the frontend version. Run retroarch --version and confirm 1.22.2. Rationale: everything downstream — info files, core builds, save-state compatibility — is keyed to the frontend release. Fix this first or debug it forever.
2. Set your directories. Settings → Directory. Point system/ (BIOS), saves/, and states/ somewhere stable and writable. Rationale: BIOS lookups fail silently when the system directory is wrong, producing a black screen with no error. Set it now and never wonder.
3. Update Core Info Files — FIRST. Online Updater → Update Core Info Files. Rationale: the info files are the manifest. Without a current manifest, the Core Downloader shows an empty list, and any core you sideload reports "failed to load" or appears as an unrecognized blob. This is the number-one cause of "my cores vanished."
4. Open the Core Downloader. Online Updater → Core Downloader. If it is missing, go to Settings → User Interface → Menu Item Visibility → Show Core Downloader and switch it on. Rationale: the downloader is your filtered, per-platform, per-architecture view of the buildbot — the only list that reflects what actually exists for your device.
5. Download cores by system, not in bulk. Pick the specific cores for the consoles you own games for. Rationale: "download all" wastes space, clutters the load menu with engines you will never touch, and buries the one core you actually want under forty you do not.
6. Update Assets, Controller Profiles, and Databases. All three live under Online Updater. Rationale: the scanner matches ROMs against the databases by hash; without them, Import Content produces empty playlists. Controller profiles auto-map common pads so you skip manual input setup.
7. Place your BIOS files. Drop dumped firmware into system/ with the exact expected filenames and hashes. Rationale: region and revision matter — a Japanese PS1 BIOS will not satisfy a US game's checksum on the accuracy cores, and the failure mode is a silent black screen, not a helpful dialog.
8. Load a core manually the first time. Load Core → pick one → then Load Content. Rationale: loading the core by itself proves the library is valid and matches your architecture before you drag content or a scanning problem into the equation. Isolate variables.
9. Test one known-good ROM. Load a game you are certain is a clean dump. Rationale: if a good dump on a freshly-downloaded core fails, the problem is the core, the BIOS, or the path — not your library. Establish a baseline that works.
10. Scan your ROM folder. Import Content → Scan Directory. Rationale: the scanner hashes each file and files it under the correct system playlist automatically. Hand-building playlists is for masochists and files with no database entry.
11. Set a default core per playlist. Open a playlist → the gear / manage entry → Default Core. Rationale: without a default, every launch prompts "which core?" This picks your winner once and stops asking.
12. Configure and save core options. Launch a game → Quick Menu → Core Options → set renderer, resolution, region → then Quick Menu → Overrides → Save Core/Game Override. Rationale: unsaved options evaporate on exit. Saving them as an override (next section) persists the change without contaminating your global config.

Expected output when step 8 succeeds — RetroArch's log (Settings → Logging → set to INFO, or run from a terminal) should read something like this:

[INFO] [Core]: Using content: /roms/snes/Chrono Trigger.sfc
[INFO] [Core]: Loading core: snes9x_libretro.dll
[INFO] [Core]: Version of libretro API: 1
[INFO] [Core]: Compiled against API: 1
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
[INFO] [Audio]: Set audio input rate to: 32040.00 Hz.
[INFO] [Video]: Set video size to: 512x448.

If the API versions on those two lines disagree, you have a core built against a different frontend — go back to step 1. The Online Updater tree you are living in for steps 3 through 6 looks like this:

Main Menu
 └ Online Updater
    ├ Update Core Info Files      <- run this FIRST
    ├ Core Downloader             <- pick individual cores here
    ├ Update Installed Cores      <- refresh everything in one pass
    ├ Update Assets
    ├ Update Controller Profiles
    └ Update Databases

On Debian and Ubuntu you can also pull cores from the packaging system with sudo apt-get install libretro-<core>, though the buildbot is fresher. Full menu-by-menu screenshots live in the libretro download-cores guide if you want to follow along visually.

The Right Core for Each System

The buildbot will offer you three cores per system and tell you nothing about which one to pick. Here is the opinionated map, current for 2026. Where a core has upstream documentation, it is linked.

Nintendo: NES to N64

NES: use Mesen. It is PPU-accurate, handles the obscure mappers, and ships a debugger; FCEUmm and Nestopia are lighter fallbacks for weak hardware. SNES: use bsnes if your CPU can hold 4 GHz — it is the cycle-accurate reference — and Snes9x everywhere else, which is the practical handheld pick and misses almost nothing. Game Boy / Color: Gambatte or mGBA. GBA: mGBA, full stop; it is accurate, fast, and the same author's work across the whole Game Boy line. DS: melonDS is the accurate modern pick, with DeSmuME as the older fallback.

N64 is the landmine. The mainline core is mupen64plus-next, which bundles GLideN64 for HLE rendering plus the angrylion and ParaLLEl-RDP/RSP plugins, and the official docs still list it as the recommended default. But it regressed in early 2025: specific titles such as Stunt Racer 64 and World Driver Championship stopped loading, and the community's workaround was to pin a January 2025 build. If you hit that wall, either grab the pinned build or switch that one game to the accuracy-focused Parallel N64 core (Vulkan low-level emulation), understanding that Parallel N64 has narrower overall compatibility — it is a scalpel, not a default. If precision matters more than convenience and you would rather sidestep software emulation entirely, dedicated N64 hardware like the Analogue 3D renders the plugin wars moot.

Sony and Sega

PS1 has three sane choices along a power curve. Beetle PSX HW (a Mednafen derivative with a hardware renderer) is the most accurate and the heaviest — the desktop pick. SwanStation is the DuckStation libretro port, a strong middle ground. PCSX ReARMed is the lightest, ARM-optimized, and the engine quietly powering budget handhelds and distros like muOS, OnionOS, and ROCKNIX — the same class of device covered in our Miyoo Mini Plus breakdown. On a phone or handheld, ReARMed; on a desktop, Beetle PSX HW.

PS2 is LRPS2 and only LRPS2 — the PCSX2 hard fork with the new ParaLLEl-GS renderer written by Themaister (Vulkan, GL, and D3D11/12 compute paths plus a software-accuracy mode). It needs a real BIOS, ships its GameIndex data embedded in the core, and landed in the downloader with the 1.22 line in November 2025. Reread the hardware note: it is x86_64 only. The full technical write-up is on the libretro LRPS2 announcement. PSP is the PPSSPP core, which is excellent but leans on your GPU.

Sega is mostly Genesis Plus GX — an ex-Wii homebrew emulator that covers Mega Drive/Genesis, Sega CD, Master System, Game Gear, SG-1000, and the Pico at essentially 100 percent. The one hole: it does not do 32X. For those handful of games, install PicoDrive, which is also the standard Genesis pick on Android where Genesis Plus GX is not always built. Saturn splits by power: Beetle Saturn is the accurate, demanding option, while Kronos and YabaSanshiro are the faster, more forgiving cores. Dreamcast is Flycast, which also handles the Naomi and Atomiswave arcade boards and wants its dc_boot.bin firmware in place.

Handhelds, arcade, and the awkward middle

3DS changed hands. The Citra core is dead — the project was taken down — and its replacement is Azahar, a merge of the prominent Citra forks including PabloMK7's and Lime3DS. Azahar shipped its first official libretro core in release 2125.0 Alpha 4 across six operating systems (Linux, Windows, macOS, Android, iOS, tvOS), and the line has since advanced toward 2126.0 as a release candidate in mid-2026. It dropped support for encrypted games and the Nintendo CDN (you point it at the Artic Setup Tool instead), and the libretro binaries are now stripped for a smaller Android footprint. Get it from the Azahar releases, not from anything still calling itself Citra. GameCube and Wii run on the Dolphin core, which was resynced to the current Dolphin stream in October 2025; expect fewer per-game knobs than standalone Dolphin, because the libretro wrapper deliberately simplifies the config surface.

Arcade is the other place people get lost. Final Burn Neo is the pragmatic default — one core spanning Neo Geo, CPS-1/2/3, and a library reaching back into the 1970s (RetroBat, for reference, bumped its bundled FBNeo cores to a build dated April 22, 2026). The MAME core is broader and pickier: it wants ROM sets matched to its exact version, so treat it as the specialist you reach for when FBNeo does not cover a title. The older 2600 lives on Stella, PC Engine/TurboGrafx on Beetle PCE, and the point in every case is the same — match the core to the ROM set and the machine you are running on, not to whichever one appeared first in the list.

Overrides: Game Beats Core Beats Global

The four-level hierarchy

RetroArch resolves settings from most-specific to least-specific, and understanding the order is what stops you from setting a 4x internal resolution for Gran Turismo 2 and accidentally applying it to every PS1 game you own. The precedence, highest wins:

1. Game override — config/<core>/<game>.cfg
2. Content-directory override — config/<core>/<dir>.cfg
3. Core override — config/<core>/<core>.cfg
4. Global — retroarch.cfg

A game override touches exactly one ROM on one core. A core override touches every game on that core. Global is the floor. You almost always want the narrowest scope that solves the problem, which for tweaks is nearly always a game override. The mechanism and every file path are documented in the libretro overrides guide.

Saving a game-specific override

Launch the game, open Quick Menu → Overrides → Save Game Override. RetroArch writes only the differences from the parent config into a tiny file, so overrides stay legible and diffable. Say a PS1 racer shimmers with polygon jitter and you want it in widescreen at four times the native resolution — you set exactly those knobs, save a game override, and every other PS1 game keeps the sane defaults. Here is what that file looks like; note that Beetle PSX HW's option keys are exactly these, not invented:

# File: config/Beetle PSX HW/Gran Turismo 2 (USA).cfg
# Applies ONLY to this ROM on this core.
video_aspect_ratio_auto = "false"
aspect_ratio_index = "22"
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 = "enabled"

Core options versus overrides

There is a second, parallel system that trips people up. Emulator-specific toggles — renderer, PGXP, internal resolution — are core options, stored globally in retroarch-core-options.cfg or, per-game, in config/<core>/<game>.opt. Frontend settings — aspect ratio, shaders, audio latency — are overrides in the .cfg files above. You create a per-game options file from Quick Menu → Core Options → Manage Core Options → Create game-options file. Input remaps are a third store again, living in config/remaps/<core>/<game>.rmp. Three stores, one mental model: options are the emulator's knobs, overrides are RetroArch's knobs, remaps are the pad. A core-wide options file looks like this:

# File: config/Parallel N64/Parallel N64.opt
# Illustrative keys - read your exact key names off
# Quick Menu -> Core Options, they vary by core build.
parallel-n64-gfxplugin = "parallel"
parallel-n64-parallel-rdp-upscaling = "2x"
parallel-n64-parallel-rdp-native-texture-lod = "enabled"
parallel-n64-cpucore = "dynarec"

Five Pitfalls That Eat Your Afternoon

Ordering and version mistakes

Pitfall 1: Update Cores before Update Core Info Files. This is the classic. Download cores against a stale manifest and they show up as unknown, fail to load, or the downloader comes up empty. Fix: always Update Core Info Files first, then Update Installed Cores. If you are already broken, run them in that order and restart. A buildbot change on May 24, 2026 replaced older core files, so installs from before that date should run Update Installed Cores once; installs after it need no manual refresh.

Pitfall 2: grabbing the accuracy core on hardware that cannot run it. People install bsnes on a handheld, watch it stutter, and conclude RetroArch is slow. Fix: match the core to the silicon — Snes9x, not bsnes, anywhere below ~4 GHz; PCSX ReARMed, not Beetle PSX HW, on ARM. Accuracy cores are a desktop luxury.

Platform and content mistakes

Pitfall 3: expecting the PS2 core on ARM. LRPS2 is x86_64 only. There is no ARM build, so on a phone or an ARM handheld you will search the downloader forever. Fix: accept it, or use standalone AetherSX2/NetherSX2 outside RetroArch, or emulate PS2 on an x86 machine. The FPGA crowd sidesteps this entire class of problem by reimplementing hardware in logic rather than software.

Pitfall 4: running the wrong Sega core. Genesis Plus GX has no 32X, so Knuckles Chaotix and Virtua Racing Deluxe silently refuse. Fix: install PicoDrive for 32X. Same story on Android, where PicoDrive is often the only Genesis core built at all.

Configuration mistakes

Pitfall 5: editing retroarch.cfg while RetroArch is running. With config_save_on_exit = "true", the frontend rewrites the file on close and stomps your hand edits. Fix: either edit the file with RetroArch closed, or make the change in-menu and Save Override so it lands in the right scoped file. And the bonus sixth, because it is 2026's most common one: downloading Citra for 3DS. Citra is gone. Fix: install Azahar (2125.0 or later) instead.

Troubleshooting Table

Symptoms map to a small set of causes. Work top to bottom; most "broken core" reports are one of the first three rows.

Advanced Tips

Run-ahead and latency

RetroArch can eliminate a frame or two of the input lag that emulation adds on top of the original hardware, using run-ahead: it runs the core an extra frame internally and rolls back, so your input registers a frame sooner. Because it lives in the frontend, every core inherits it. One frame with a secondary instance is the safe default; two frames is aggressive and only worth it on light cores, because run-ahead re-runs the emulator and the cost scales with how heavy the core is. Do not run it on bsnes or LRPS2 unless you have headroom to burn.

run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"   # halves the CPU cost of run-ahead
run_ahead_hide_warnings = "false"

Shaders, integer scaling, and netplay

Shaders are frontend-side, so a CRT shader like crt-royale or the lighter crt-guest-advanced works identically across every core — set it once as a global or scope it per-system with an override. Two rules keep it honest: leave video_smooth = "false" so bilinear blur does not fight the shader, and turn on integer scaling for pixel-accurate geometry before you reach for any shader at all. Netplay is frontend-side too, which is why it works across cores that support it — you host, your opponent joins by room, and the rollback lives in RetroArch rather than the emulator. Thumbnails are a similar story: Update Playlist Thumbnails pulls boxart, titles, and snaps from the community thumbnail server so your playlists stop looking like a directory listing.

Manual installs and the nightly buildbot

When you need a core the stable downloader does not carry, or you want to pin a specific build (that January 2025 mupen64plus-next, for instance), pull it straight from buildbot.libretro.com/nightly, unzip the .dll/.so/.dylib into your cores/ directory, and run Update Core Info Files so the frontend recognizes it. This is also how you handle platform ports the main downloader ignores — the webOS Homebrew core repository, which rebuilt to 170-plus armv7 cores in December 2025, is the reference example for a community-maintained build channel. RetroAchievements, by the way, are native to RetroArch now — no third-party plugin, just log in under Settings → Achievements. If you are running these same cores under a distro rather than bare RetroArch, note that packaged frontends move slower: our look at RetroPie sitting frozen at v4.8 is a case study in why the underlying libretro cores can be current while the wrapper around them is years stale.

A Complete Working Configuration

Paste this into a clean retroarch.cfg (with RetroArch closed), adjust the paths, and you have a sane baseline: nearest-neighbour scaling so shaders do the work, in-game saves trusted over states, run-ahead off by default, and per-content overrides free to win over everything below. The :\ prefix is RetroArch's token for its own install directory; on Linux or macOS use absolute paths.

# ---- retroarch.cfg : core-relevant baseline (RetroArch 1.22.2) ----

# Directories
system_directory = ":\system"
savefile_directory = ":\saves"
savestate_directory = ":\states"
libretro_directory = ":\cores"
libretro_info_path = ":\info"

# Drivers
video_driver = "vulkan"          # d3d11 or gl if Vulkan misbehaves
audio_driver = "wasapi"          # pipewire on modern Linux
menu_driver = "ozone"

# Image quality: let shaders and integer scale do the work
video_smooth = "false"
video_scale_integer = "true"
aspect_ratio_index = "22"        # core-provided aspect

# Latency (see Advanced Tips) - off by default, safe everywhere
run_ahead_enabled = "false"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"

# Saves: trust battery saves, distrust states across updates
rewind_enable = "false"          # costs CPU on heavy cores
savestate_auto_save = "true"
savestate_auto_load = "false"    # never auto-load on hardware you power-cycle

# Overrides + core options win over everything above
game_specific_options = "true"
auto_overrides_enable = "true"
auto_remaps_enable = "true"
config_save_on_exit = "true"

With this in place, your workflow becomes: install the right core per system from the map above, launch a game, tweak its core options, and Save Game Override. The global file stays clean and boring — which is exactly what you want it to be — while the interesting, per-game decisions live in tiny scoped files you can delete or diff at will. That is the whole discipline: a dull global config and sharp local overrides.

The Legal Footnote Nobody Reads

The emulator is legal; the contents are your problem

Emulators are lawful software, and the case law is older than most people using them. In Sony v. Connectix (2000) the Ninth Circuit held that reverse-engineering the PlayStation BIOS to build the Virtual Game Station emulator was fair use, and Sega v. Accolade (1992) had already established that intermediate copying for interoperability can be fair use. RetroArch and its cores fall squarely inside that shelter. What falls outside it is the copyrighted material you feed them: the games and the console BIOS. There is no Connectix for downloading a ROM you do not own.

BIOS, ROMs, and the dump-your-own rule

The lawful path is narrow and well-marked: own the original hardware and media, and dump your own firmware and cartridges. That is why a chunk of this hobby is soldering irons and cart readers rather than emulator menus. It is also why the BIOS never ships in the box — distributing Sony's or Sega's firmware is straightforward copyright infringement even though your use of a dump you made yourself is defensible. The frontend authors know exactly where that line is, which is why Update Cores hands you the emulator and pointedly not the firmware.

The takedown era and why forks exist

The reason your 3DS core is now named Azahar and not Citra is the sharp end of all this. When the pressure landed on the Citra and Yuzu projects, the emulators did not become illegal — but the projects folded, and the community reconstituted the code under new names and new stewardship, exactly as open-source licenses permit. The lesson for anyone maintaining a library: pin the cores that matter to you, keep the buildbot bookmarked, and read the changelogs, because in emulation the software is durable but the names are not. For the canonical background on the frontend itself, the RetroArch overview is a reasonable, sourced starting point — and everything downstream of it is documented, versioned, and, unlike the ROMs, entirely yours to keep.