Batocera 43.1 Download 2026: 12 Steps, 25 Min

Batocera is the retro-gaming distribution that asks nothing of you except a spare drive and the willingness to read exactly one configuration file. It is free — not freemium, not "free with a launcher," not free-until-the-trial-ends. It is genuinely $0 to download, install, and run, released under Creative Commons and mirrored in full on GitHub. You fetch an image, you write it to a USB stick or SD card, you boot it, and the machine you already own becomes a console. No dual-boot, no shrinking your Windows partition, no product key. That is the entire pitch, and after ten years of continuous development it is a pitch the project actually keeps.

This is the long version of the download-and-flash process, written for the release that is current as of mid-2026: Batocera 43.1, the maintenance point release riding on top of version 43, codenamed "Glasswing," which shipped on May 8, 2026. It is also written for the people that release quietly broke. Anyone holding a Nintendo DS save, a 3DS library, or a folder of encrypted .cia files is about to have a bad afternoon, and I would rather you have it before you overwrite anything. We will cover choosing the right image, verifying it, flashing it, surviving the first boot, feeding it games without getting sued, and the specific v43 landmines that nobody reads the changelog for until it is too late. Budget about 25 minutes of active work; most of the wall-clock is the download and the partition expansion, and you can go make coffee for both.

What 43.1 Is — and What v43 Broke

Before you download anything, understand what you are downloading. Batocera is not a launcher you install on top of an existing OS; it is the OS. It boots straight into EmulationStation, mounts a data partition it calls userdata, and runs emulators — mostly libretro cores through RetroArch, plus standalone emulators where a core does not exist. Version 43 is the most disruptive release in years, and the disruption is the interesting part.

The Glasswing line in one breath

Batocera 43 landed on May 8, 2026 under the codename "Glasswing." Its headline change is not a new menu skin — it is a brand-new x86_64-v3 image aimed squarely at modern handhelds with AMD and Intel graphics, running on Wayland with the LabWC compositor instead of the older X11 stack. In plain terms: the ROG-Ally-class and Steam-Deck-adjacent hardware finally gets a build that matches its microarchitecture and its GPU drivers, while everyone on ancient desktop hardware keeps the plain x86_64 image. The 43.1 point release that followed a few weeks later folds in the bug fixes that always trail a major version. When this guide says "43.1," assume the underlying feature set is Glasswing's — the version number on the box changed, the substance did not.

The license nobody reads

Batocera has been in continuous development since 2016 and is licensed CC-BY-NC-SA — Creative Commons Attribution-NonCommercial-ShareAlike. Read that as: you may use it, copy it, and remix it freely; you must credit the project; you may not sell it; and anything you build on top inherits the same terms. This is also the precise reason DraStic left the building in v43. A closed-source, commercially-licensed emulator does not fit inside a non-commercial, share-alike, source-available distribution, and the maintainers finally stopped pretending it did. Every part of the project — the image build scripts included — lives at the official GitHub repository, and the changelog is a public file you can read before you upgrade instead of after you file a forum post.

Why Batocera and not RetroPie or a MiSTer

If you are choosing a camp, choose with your eyes open. RetroPie is the venerable Raspberry-Pi-first option, but as we covered when RetroPie sat frozen at v4.8 while the Pi 5 shipped, its release cadence has gone glacial; Batocera, by contrast, ships dated builds constantly and treats x86 as a first-class target. At the other extreme sits FPGA hardware — the purist's answer — and if cycle-accurate silicon is your religion, the story of the MiSTer MultiSystem 2 and its 17,000 orders is the one to read. Batocera is the middle path: software emulation, enormous hardware breadth, and a spare mini-PC instead of a $400 dev board. Pick it because it runs on what you have.

Prerequisites: Hardware and Software

Downloading the wrong image, or flashing it with a tool that lies to you, is how most first attempts die. Get the prerequisites right and the rest is mechanical.

The honest hardware floor

The official position, echoed on the wiki's hardware guidance, is forgiving: any 64-bit x86 machine from roughly 2010 onward will run Batocera. RAM minimum is 1 GB, but 2 GB or more is the realistic floor — anything that can boot Windows 10 or 11 is comfortably over the bar. Storage is where people underspend: 16 GB is the hard minimum, 32 GB is recommended, and there is a concrete penalty for cheaping out — you cannot auto-download system updates on a 16 GB device, because there is not enough free space to stage the new image. If you intend to keep more than one console's worth of ROMs, treat 64 GB as the practical starting line and 128 GB as "I want a real library." A sub-$200 mini-PC such as the Beelink Mini S12 is the canonical cheap host; you do not need a gaming rig, because emulating a Super Nintendo is not a GPU workout.

Software and versions you need

The toolchain is short. You need (1) a way to write a raw disk image: Raspberry Pi Imager or balenaEtcher if you want a GUI, or dd if you live in a terminal; (2) a way to decompress a .img.gz if your flasher does not do it inline — most modern ones do; (3) an SSH client, which is built into Windows 10/11, macOS, and every Linux; and (4) a card reader or USB port for the target media. That is the whole list. There is no "Batocera installer" to download, no dependency hell, no package manager to fight — the image is the install.

What "x86_64-v3" actually demands

Glasswing's v3 image is not a marketing suffix; it is a real CPU requirement. The x86_64-v3 microarchitecture level requires AVX2, BMI2, FMA, and friends — in practice, an Intel Haswell (2013) or AMD Excavator-era chip or newer. Feed the v3 image to a 2011 Sandy Bridge box and it will not boot; you will get a black screen and assume the flash failed. If your CPU predates ~2013, or you are not sure, take the plain x86_64 image, which targets the older baseline and runs everywhere. The v3 build exists to squeeze modern handhelds, not to gatekeep your old Dell.

Choosing the Right Image

The official download portal is the only place you should get an image. Not a torrent, not a "preloaded 512 GB SD card" from a marketplace, not a random Mega link. The portal asks two questions: what hardware are you on, and — for x86 — which microarchitecture. Answer them correctly and you never think about it again.

PC vs SBC vs Steam Deck

The portal splits builds into three families. PC / x86_64 covers desktops, laptops, and mini-PCs — this is the plain image and the v3 image described above. Single Board Computers (SBCs) covers the Raspberry Pi line, Odroid, the various RK3588 boards, and a long tail of ARM devices; each board has its own image because ARM has no universal boot standard, so a Pi 5 image will not boot on an Odroid and vice versa. Steam Deck gets its own dedicated build tuned for Valve's hardware. Choose the family that matches your box exactly. When in doubt on an SBC, the wiki's per-device pages tell you the precise filename to grab.

v3 vs plain x86_64 — the microarchitecture trap

This is the single most common first-timer mistake in the Glasswing era, so it earns its own subsection. The v3 image will give you a black screen on any CPU older than roughly 2013, and a black screen looks identical to a corrupt download. If you flashed carefully, verified your checksum, and still get nothing on boot, the odds are you grabbed v3 for a machine that wants plain. Downgrade the image, not your expectations.

Reading the filename

Batocera filenames encode everything you need to sanity-check a download. Here is a real historical example — the version 38 PC build from October 2023, as documented in installation threads — annotated so the anatomy is obvious:

batocera-x86_64-x86_64-38-20231014.img.gz
         │      │       │  │        └── .img.gz  = gzip-compressed raw disk image
         │      │       │  └────────── 20231014  = build date, YYYYMMDD
         │      │       └───────────── 38        = major version number
         │      └───────────────────── x86_64    = CPU architecture
         └──────────────────────────── x86_64    = platform family

# A current Glasswing v3 PC build follows the same shape, e.g.:
#   batocera-x86_64_v3-43-20260508.img.gz   (your exact date/suffix will differ)

Two takeaways. First, the extension is .img.gz — a gzip-compressed raw image, not an ISO you burn and not a ZIP you extract into files. Second, the version and date are right there in the name; if the number does not say 43, you did not download Glasswing.

Download, Verify, Flash: 12 Steps

This is the spine of the whole operation: twelve numbered steps from empty drive to a booting console, each with the reasoning attached so you know why, not just what. Do them in order. The deeper sections that follow — first boot, ROMs, migration — expand on the steps that deserve more than a sentence. If you want the condensed version to keep in another tab, our 20-minute 43.1 install run-through is the short companion to this long one.

Before you click download

Two-minute pre-flight. Confirm your target media is one you are willing to completely erase — flashing is destructive and total. Confirm you know your CPU generation, per the v3 trap above. And if you are upgrading an existing Batocera box rather than building fresh, read the migration section first and back up your saves before you touch anything, because v43 removes emulators, and a removed emulator does not migrate its saves for you.

The numbered walk-through

1. Confirm your target hardware and back up existing data. Why: v43 preserves the userdata partition on an in-place update, but a fresh flash does not, and a botched flash preserves nothing. If you are migrating, your DraStic saves are about to be orphaned — copy them off now.
2. Choose the correct image — plain x86_64, x86_64-v3, your specific SBC, or Steam Deck. Why: the v3 image will not boot on pre-2013 CPUs, and an SBC image is board-specific; the wrong choice produces a black screen that mimics a dead download.
3. Download only from batocera.org/download. Why: "preloaded" images and torrents are the classic vector for both malware and someone else's copyrighted ROMs, which turns your free hobby into a legal liability you did not sign up for.
4. Verify the download with a checksum. Why: a truncated or corrupted .img.gz flashes a brick, and you will not find out until it fails to boot. Ninety seconds now saves an hour of guessing later.
5. Identify your target disk precisely with lsblk (or the flasher's device list). Why: dd and Etcher overwrite whatever you point them at — including your OS drive. This is the step people cry about on forums; do not become a statistic.
6. Flash the image with Raspberry Pi Imager, balenaEtcher, or dd. Why: writing the raw image byte-for-byte is the entire installation. There is no setup wizard; the disk becomes bootable the moment the write completes.
7. Optionally verify the flash — Etcher does this automatically; dd users can re-read and compare. Why: cheap USB sticks and counterfeit SD cards silently drop or misreport bytes, and a bad write is invisible until boot.
8. First boot: let it expand the userdata partition. Why: out of the box the image only claims a couple of gigabytes; expansion reclaims the rest of the disk for ROMs and saves. Do not power off mid-expand — that is how you corrupt the partition table.
9. Configure your controller. Why: nothing else in EmulationStation works until an input device is mapped, and if you migrated from an older version, your previous pad mapping may not have survived.
10. Connect to the network and confirm the share/SSH is reachable. Why: this is how you will actually move gigabytes of ROMs and edit batocera.conf — copying files onto the SD card by hand does not scale past one system.
11. Add ROMs and BIOS to the correct folders, then update the gamelists. Why: EmulationStation only shows systems that contain at least one recognized ROM, and BIOS-dependent cores fail silently when the BIOS is missing or the wrong revision.
12. Test one game per core, then set your update channel. Why: verifying a single known-good ROM per system isolates BIOS and core problems before you dump 500 GB onto the box and try to debug forty consoles at once.

What a good verify and flash look like

Step 4, the checksum, is one command. Compute the hash of the file you downloaded and compare it against the value published beside the image on the portal:

$ sha256sum batocera-x86_64_v3-43-20260508.img.gz
3f9a1c8e...9b2d71e0c4a7  batocera-x86_64_v3-43-20260508.img.gz

# Compare the left-hand hash to the one on the download page.
# Identical = good. Different = re-download; do not flash it.

Step 5, identifying the disk, is where careers end. On Linux, list your block devices and find the target by size, not by guessing a letter:

$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME        SIZE TYPE MOUNTPOINT
sda         931G disk
├─sda1      512M part /boot/efi
└─sda2      930G part /
sdb          58G disk               <-- 58 GB USB stick = the target, UNMOUNTED
└─sdb1       58G part

Here sda is a 931 GB internal drive with your OS on it, and sdb is the 58 GB stick you are about to erase. Point the flasher at sdb, never sda. Step 6 with dd, decompressing on the fly, looks like this — and the triple-check comment is not decorative:

# Decompress and write raw to the target disk in one pipe.
# TRIPLE-CHECK /dev/sdX. This OVERWRITES everything on that device.
gunzip -c batocera-x86_64_v3-43-20260508.img.gz | sudo dd of=/dev/sdb bs=4M status=progress conv=fsync

# Expected tail of output:
7623195648 bytes (7.6 GB, 7.1 GiB) copied, 214 s, 35.6 MB/s
1817+1 records in
1817+1 records out

A note on tooling politics: the official wiki nudges you toward Raspberry Pi Imager and USBImager and explicitly says dd is not recommended — not because dd is broken, but because dd will cheerfully obliterate your root filesystem if you fat-finger the device name and it never asks "are you sure." If you are not fluent, use the GUI. If you are fluent, you already read the man page. Either way, the official install page is the canonical reference.

First Boot, SSH, and the Share

The flash is done and the drive is in the target machine. The first boot is where Batocera turns a raw image into a usable system, and there are two things you must let it finish and two things you must set up before ROMs make any sense.

Partition expansion and the first reboot

On first boot Batocera automatically grows the userdata partition to fill the drive, then reboots itself once. The wiki's phrasing is worth internalizing: it "could take a few seconds or a few minutes, depending on your drive size and speed, it will reboot again once done." Do not interrupt this. Pulling power during expansion is the single most reliable way to corrupt a fresh install. Once it settles, confirm the partition actually claimed the disk — over SSH, df -h should show tens of gigabytes free, not a few hundred megabytes:

$ ssh root@batocera.local          # default password: linux (nothing echoes while typing)
batocera:~# df -h /userdata
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb2        56G  1.2G   52G   3% /userdata

That 56G total on a 58 GB stick is what a successful expansion looks like. If instead you see a 2 GB partition that is 95% full, expansion did not finish — reboot and let it complete, or expand it manually from the system menu.

SSH and the default credentials

Batocera ships SSH enabled with fixed default credentials: username root, password linux. When you type the password nothing appears on screen — no asterisks, no dots — which trips up people who assume the keyboard is dead. It is not; just type linux and press Enter. Reach the box at root@batocera.local or root@batocera from any machine on the same network. The full command set lives on the wiki's SSH reference page. If this box is exposed to anything beyond your LAN — and it should not be — change that password immediately, because root/linux is not a secret, it is a convention.

The network share is how you move games

Copying ROMs onto the SD card by physically shuttling it between machines gets old at the second console. Batocera exposes its userdata partition as a network share (Samba), and the userdata partition and "the share" are the same thing under two names. From another computer, browse straight to it:

# Windows (File Explorer address bar):
\\BATOCERA\share          or      \\batocera.local\share

# macOS (Finder -> Go -> Connect to Server):
smb://batocera.local/share

# Linux (file manager address bar):
smb://batocera.local/share

Inside the share you will find roms/, bios/, saves/, and the rest of userdata, writable over the wire. This is the workflow: drag a folder of games into roms/snes/ from your desktop, tell EmulationStation to rescan, done.

Adding ROMs, BIOS, and the Law

Batocera ships with zero games. That is deliberate and it is the reason the project is legal to distribute. The emulators are legal; the content is your problem, and it is worth being precise about what "your problem" means.

The folder map

Everything lives under /userdata/, which is the same tree you see over the network share. ROMs go into a per-system subfolder using Batocera's short system name; BIOS files go in one flat folder; the single config file that governs the whole machine sits in system/:

/userdata/
├── roms/
│   ├── snes/     Chrono Trigger (USA).sfc
│   ├── nes/      Super Mario Bros. (World).nes
│   ├── n64/      Legend of Zelda, The - Ocarina of Time (USA).z64
│   ├── psx/      Final Fantasy VII (USA) (Disc 1).chd
│   └── 3ds/      your DECRYPTED .3ds files go here
├── bios/         SCPH5501.bin, gba_bios.bin, ...
├── saves/        per-system save and save-state files
└── system/
    └── batocera.conf     <-- the one config file that matters

If a system does not appear in EmulationStation, it is almost always because its roms/ subfolder is empty or the file extension is one the core does not recognize. The exact per-system folder names and accepted extensions are enumerated on the wiki's add games and BIOS page — bookmark it, because "which folder does the TurboGrafx-16 use" is a question you will ask more than once.

The BIOS problem

Many cores need a BIOS dump to run — PlayStation, Sega CD, Game Boy Advance, and others — and Batocera cannot ship those, because a console BIOS is copyrighted firmware owned by Sony, Sega, or Nintendo. Drop them into /userdata/bios/ with the exact filenames and, ideally, the exact MD5 hashes the cores expect; the libretro BIOS reference lists the canonical names and checksums. Batocera has a built-in BIOS checker (in the system menu) that flags missing or mismatched files — use it, because a wrong-revision BIOS produces the same silent black screen as a missing one, and you will blame the ROM.

The law, briefly

Here is the part The Machine knows cold. Emulators are legal. That is settled U.S. case law — Sony v. Connectix (9th Cir. 2000) and the Bleem litigation established that writing an emulator, and the intermediate copying required to reverse-engineer a console, can be fair use. What is not legal is distributing or downloading copyrighted ROMs and BIOS images you do not own, and "abandonware" is a community norm, not a legal defense — there is no expiration date on copyright that flips a 1994 cartridge into public domain. The clean path, the one that does not depend on a rights-holder's indifference, is dumping media you physically own. If you want the defensible route from cartridge to file, our 12-step cartridge-dumping walkthrough with the Retrode3 is exactly that. Batocera hands you a legal machine; what you put in roms/ is on you.

Migrating to 43: DraStic & 3DS Traps

If you are coming from version 42 or earlier, v43 is not a routine bump. It removes an emulator, changes how another one ingests files, and tightens the boot partition. The good news, corroborated in coverage of open-source gaming OSes, is that Batocera does not delete your data on update — it rewrites only the system and boot partitions and leaves userdata (ROMs, saves, BIOS, config) intact. The bad news is that "your data survives" and "your emulators survive" are different promises.

DraStic is gone — save your saves first

The DraStic Nintendo DS emulator was removed in v43 because it is closed-source and no longer compatible with the core OS, and there is no drop-in replacement that inherits its save format. Your DS saves still sit in userdata after the update, but nothing is reading them anymore. Before you upgrade, pull them off the box and be prepared to reconfigure controllers, because the emulator that owned that mapping is leaving:

# BEFORE upgrading to 43: pull your DS saves off the machine.
# Over SSH from your PC:
scp -r root@batocera.local:/userdata/saves/nds ./nds-saves-backup

# After upgrading, DS runs on melonDS. Save formats do not always
# transfer 1:1 -- keep the backup until you confirm each game loads.

3DS: Azahar, decryption, and .3ds

Nintendo 3DS support was reworked. Azahar Plus was replaced by upstream Azahar — the maintainers moved to the source project for cleaner integration. The .3ds extension is supported again in v43, but hardware shaders are disabled by default to favor compatibility over speed; if a game renders wrong, that toggle is the first thing to flip. The sharp edge: encrypted CIA and CCI files are no longer supported. You must decrypt your 3DS dumps to .3ds or .cxi on a machine you own before they will load. Encrypted-in, black-screen-out — this is the second most common v43 support thread after the v3 boot issue.

TheXTech assets, the /boot check, and Xenia

Three smaller traps round out the release. TheXTech (the open-source Super Mario Bros. X engine) now requires a minimum of 1.3.7 assets — update your asset pack or it throws errors on launch. Because the v43 image is larger than previous versions, verify your /boot partition has room before an in-place upgrade; a cramped boot partition is why some updates fail halfway. And Xenia (Xbox 360) got a build bump — the build tracked in our research was 1d7973a, dated June 10, 2025 — chiefly to keep pace with newer host hardware. If Xbox 360 emulation misbehaved on your old install, v43 is the version to retest on.

Common Pitfalls and Fixes

These are the failure modes that generate the most forum noise. Read them once and you will recognize the symptom instantly instead of assuming your hardware is broken.

The five that get everyone

• Black screen on first boot after a clean flash. Nine times out of ten this is the v3 image on a pre-2013 CPU, not a bad write. Re-flash the plain x86_64 image and it boots. The other one time out of ten is a genuinely corrupt download — which is exactly why step 4 exists.
• "No games found" for a system you clearly loaded. The ROMs are in the wrong folder, use an extension the core rejects, or you never told EmulationStation to rescan. Move them into /userdata/roms/<system>/, confirm the extension against the wiki, and run UPDATE GAMELISTS from the game settings menu.
• An emulator loads, then instantly black-screens or crashes. Missing or wrong-revision BIOS, almost always. Drop the correct file in /userdata/bios/ and run the built-in BIOS checker to confirm the MD5 matches what the core wants.
• 3DS games refuse to launch after upgrading to 43. Your files are still encrypted CIA/CCI, which v43 dropped. Decrypt to .3ds. If they launch but render garbage, re-enable hardware shaders, which ship off by default now.
• Updates are greyed out or fail partway. You are on 16 GB media (no room to stage the update) or your /boot partition is too small for the larger v43 image. Use 32 GB or more, and check boot capacity before upgrading in place.

The subtle one: silent SD card failure

A counterfeit or dying SD card will flash "successfully," boot once, and then corrupt saves at random. If a machine that worked yesterday starts losing progress or throwing filesystem errors, stop debugging software and re-flash to a known-good card from a reputable brand. Batocera cannot fix hardware that lies about how many bytes it stored.

Troubleshooting Table

The quick-reference version. Symptom on the left, the actual cause in the middle, the fix on the right.

Advanced Tips

Once the box boots and plays a game, the difference between "it works" and "it is mine" is a handful of habits. None of these are required; all of them pay off.

Update channels and safe upgrades

Batocera exposes two update tracks: stable, which is the tested release line, and a bleeding-edge track for people who enjoy pain. For a machine you actually play on, stay on stable and update deliberately, not reflexively — read the changelog first, because a v43-style release can remove an emulator you depend on. The safest upgrade path is to keep 32 GB+ of headroom so the built-in updater can stage the new image, and to back up /userdata/saves/ before any major version jump. Data survives updates by design, but "by design" and "every single time on every card" are not the same guarantee.

Achievements, shaders, and bezels

Three quality-of-life systems are worth turning on. RetroAchievements bolts an achievement layer onto games that never had one — set your credentials in batocera.conf and it just works across supported cores. Shaders (CRT filters, LCD grids, scanlines) make a 240p game look like the display it was designed for instead of a raw upscale; start with a light CRT shader and back off if it costs you frames. Bezels and decorations fill the pillarboxing on a 16:9 screen with artwork instead of black bars. All three are global toggles you can override per-system when one console wants different treatment.

SSH-driven config and per-game overrides

The real power move is editing /userdata/system/batocera.conf directly over SSH, because it supports a clean override hierarchy: global defaults, then per-system, then per-game. That is how you run one N64 title on a different core than the rest, or force a single game into a specific resolution:

# /userdata/system/batocera.conf -- override hierarchy in action
n64.core=mupen64plus_next
n64.video_threaded=1
snes.core=snes9x
snes[Chrono Trigger (USA)].core=snes9x_next   # this ONE game uses a different core

Because Batocera runs on RetroArch and libretro cores underneath, the same knobs the wider libretro ecosystem documents are available to you here — if you want to understand what a "core" actually is and how to pick between them, our 11-step clean RetroArch cores setup maps the territory that Batocera abstracts away. The official libretro documentation is the deeper reference when a specific core misbehaves.

A Complete Working batocera.conf

Here is a complete, commented batocera.conf you can adapt — Wi-Fi, timezone, global video and rewind, RetroAchievements, and a few per-system choices, ending with a single per-game override so the pattern is unmistakable. Drop it at /userdata/system/batocera.conf, edit the obvious placeholders, and reboot. This is the whole point of Batocera: one legible text file that governs the entire machine.

# /userdata/system/batocera.conf
# ---- Network ---------------------------------------------------
wifi.enabled=1
wifi.ssid=YourNetworkName
wifi.key=YourNetworkPassword

# ---- System ----------------------------------------------------
system.hostname=BATOCERA
system.timezone=America/New_York
system.language=en_US
system.kblayout=us
system.power.switch=PC

# ---- Updates ---------------------------------------------------
updates.enabled=1
updates.type=stable

# ---- Global emulator defaults ----------------------------------
global.videomode=default
global.ratio=auto
global.smooth=0
global.rewind=1
global.autosave=1
global.integerscale=1
global.shaders=none
global.bezel=default

# ---- RetroAchievements -----------------------------------------
global.retroachievements=1
global.retroachievements.username=YourRAName
global.retroachievements.password=YourRAPassword
global.retroachievements.hardcore=0

# ---- Per-system overrides --------------------------------------
snes.core=snes9x
snes.shaders=/usr/share/batocera/shaders/crt/crt-guest-advanced.glslp
nes.core=fceumm
n64.core=mupen64plus_next
n64.video_threaded=1
psx.core=swanstation
psx.ratio=4/3

# 3DS in v43: Azahar core, hardware shaders left OFF for compatibility
3ds.emulator=azahar
3ds.hardware_shaders=0

# ---- Per-game override (highest priority) ----------------------
snes[Chrono Trigger (USA)].core=snes9x_next

That is Batocera end to end: a free, open-source operating system you download from one URL, verify with one command, flash to a stick, and govern with one file. Version 43.1 asks a little more of you than its predecessors — decrypt your 3DS games, mourn DraStic, mind the v3 microarchitecture — but the trade is the same one the project has offered since 2016. You bring the hardware and the games you legally own; it brings everything else, and it charges you nothing. Read the changelog before you upgrade, keep a save backup, and it will outlast the console it is emulating.