Batocera 43.1 Download & Install: 12 Steps, 20 Min

There is a particular species of failure that only happens with Batocera, and it has nothing to do with the software. Someone downloads the wrong file, flashes it to the wrong disk, boots into a black screen, and concludes the distribution is broken. It is not broken. The download is the single easiest part of the entire retro-gaming stack, and it is the part people most reliably manage to get wrong.

Batocera is a free, open-source retro-gaming distribution — a full Linux system that boots straight into EmulationStation, bundles a few hundred emulators, and asks nothing of your existing operating system. You do not install it in the traditional sense. You write an image to a USB stick or SD card, boot it, and it runs. The current stable release is 43.1, published on May 30, 2026, and it costs exactly zero dollars because the project is licensed under Creative Commons and hosted on GitHub for anyone to fork, audit, or rebuild.

This tutorial covers the whole path: what to download, how to verify it, how to flash it without corrupting your USB drive, how to boot it, and how to get games and BIOS files onto it over the network. Twelve steps, about twenty minutes of active work, and a troubleshooting table for when the forum folklore fails you. We will also tell you which parts of the popular advice are wrong, because a surprising amount of it is.

What Batocera Actually Is (and Why the Download Is the Easy Part)

Before you download anything, understand what you are downloading. Half of the support threads on the internet exist because someone treated Batocera like a program you install onto Windows. It is not that. It is an operating system, and the file you grab from the download page is a complete, bootable disk image.

A live distribution, not an installer

Batocera belongs to the same family as a Linux live USB. When you write the image to a drive and boot from it, the entire operating system runs from that drive. There is no setup wizard, no partition surgery on your main disk, no bootloader you have to repair later. The wiki describes this as requiring no system modification, and for once the phrasing is literally accurate: pull the USB stick out, reboot, and your Windows or macOS install is exactly as you left it. That property is the entire point of the project, and it is why the official install guide reads more like a flashing tutorial than an installation manual. If you have ever set up RetroArch cores by hand — the kind of work we walk through in our 11-step RetroArch cores clean setup — Batocera is the opposite philosophy: everything is pre-wired, and you trade granular control for a system that simply boots.

Open-source, CC-licensed, and genuinely free

Batocera is 100% open-source and completely free. The source lives at github.com/batocera-linux/batocera.linux, the media and branding sit under a Creative Commons non-commercial share-alike license, and the copyright banner reads 2016 through 2026. There is no license key, no paid tier, no nag screen. The project sustains itself on voluntary donations and GitHub sponsorships; no dollar amount is fixed, and nothing is gated behind a payment. When a distribution asks for money before it will boot, it is not Batocera.

What the download does not include

The image ships with emulators. It does not ship with games, and it does not ship with the proprietary BIOS files that certain systems require to run at all. This is deliberate and it is a legal line, not an oversight — distributing copyrighted BIOS dumps or ROMs would end the project inside a week. A fresh boot therefore shows you a menu of systems and, in many cases, empty shelves behind them. That is the expected state, not a bug. Getting content onto the machine is a later step, covered in full below, and it is where the phrase "dump your own cartridges" stops being a slogan and starts being your Saturday afternoon.

Batocera 43.1 and the 2025-2026 Release Trail

Version numbers matter here more than usual, because Batocera does not do rolling releases in the visible sense — you download a numbered build, and the number tells you exactly which emulator cores you are getting. Grabbing an old image and wondering why a 2024 emulator misbehaves is a self-inflicted wound.

The current stable: 43.1 (May 30, 2026)

The release you want is 43.1, dated May 30, 2026. It is a point update layered on top of the version 43 base, and its changelog is unglamorous in the best way: fixes for EmulationStation and refreshed emulator builds. Among those, Libretro MAME was bumped to 0.285, which matters if you run arcade sets, because MAME romset compatibility is version-locked and a mismatched set is the classic "it says the ROM is missing but it is right there" complaint. Unless you have a specific reason to run something older, 43.1 is the correct answer to "which version."

How the point releases stacked up

The 2025-2026 cadence is worth internalizing so you can read a download page without guessing. Version 41 landed on January 6, 2025, opening the year's release calendar. Version 42 followed on October 12, 2025 as the major late-2025 update. Version 43 arrived on May 8, 2026 — credited internally to a build cycle nicknamed "Glasswing," with its headline being improved handheld AMD and Intel graphics support on the x86_64 image — and 43.1 closed it out on May 30. The following table is the whole trail at a glance.

Reading the changelog before you download

Never flash a build without at least skimming what changed. The authoritative record is the Batocera changelog on GitHub, mirrored on the site at batocera.org/changelog, and it lists every milestone across 2025-2026 with the emulator versions attached. This is where you learn, for example, that the Xenia Xbox 360 emulator was integrated as build 1d7973a, dated June 10, 2025 — the kind of detail that decides whether a specific game runs. The filenames on the download page encode their own information, and it is worth learning to read them:

# Anatomy of a Batocera image filename
# (example: the version 38 PC build, used here only to show the pattern)

batocera-x86_64-x86_64-38-20231014.img.gz
         |        |        |  |        |
         |        |        |  |        +-- .img.gz = gzip-compressed raw disk image
         |        |        |  +----------- 20231014 = build date (YYYYMMDD)
         |        |        +-------------- 38 = Batocera version number
         |        +----------------------- x86_64 = CPU sub-target
         +-------------------------------- x86_64 = architecture family

# Current 43.1 images follow the same scheme but are larger,
# and the modern PC line also offers an x86_64-v3 variant (see below).

The version 38 filename above is a genuine historical build from October 14, 2023, useful purely as a Rosetta stone for the naming convention. When you are on the real page, you match the architecture to your hardware and the version to 43.1, and you ignore everything older.

Prerequisites: Hardware, Software, and Exact Versions

You need three things: a machine that will actually run the games, a second machine to do the flashing, and a drive to flash to. Get any of the three wrong and the rest of the tutorial is theater.

Minimum and recommended hardware

Batocera runs on a wide spread of hardware, but "runs" and "runs the systems you care about" are different claims. A 64-bit x86 CPU from the last decade with 4 GB of RAM will boot fine and handle everything up to and including the fifth console generation without complaint. For the sixth generation and beyond — GameCube, PS2, Wii, and the perpetually demanding Xbox 360 line that Xenia targets — you want a modern quad-core, at least 8 GB of RAM, and a GPU with current Vulkan drivers. On the Raspberry Pi side, a Pi 4 is competent through the PlayStation 1 and Nintendo 64 era, and a Pi 5 pushes into Dreamcast and light PSP territory, but neither is a PS2 machine no matter what a YouTube thumbnail promises. If you are building on a mini PC or a handheld and care about heat and battery, our CPU undervolting walkthrough pairs well with a Batocera install — the emulators will happily saturate a chip that is throttling itself.

The software on the flashing machine

On the computer you flash from — Windows, macOS, or Linux, it does not matter which — install Balena Etcher. It is the tool the project itself points to, it is cross-platform, and it validates the write automatically, which eliminates an entire category of silent corruption. Download it from the official source at etcher.balena.io and nowhere else; the bundled-adware clones that surface in search results are exactly the kind of thing you do not want touching a raw disk. You will also want a working gzip or 7-Zip to decompress the image, though Etcher can read a .img.gz directly and save you the step. On Linux, dd and sha256sum come with the base system and we will use both.

The USB stick or SD card itself

Buy quality here or pay for it later. For a PC install you want a USB 3.0 (or faster) stick of at least 16 GB — 8 GB is technically enough for the system but leaves you nothing for saves and configs, and games are added separately anyway. For a Raspberry Pi, an A1 or A2 rated microSD card of 32 GB or more is the floor; the cheap unbranded cards that ship three-for-a-dollar are the reason half of "my Pi keeps corrupting" threads exist. If you plan to keep a serious library on the boot drive rather than external storage, size up accordingly — Batocera will expand to fill whatever you give it.

Choosing the Right Image for Your Device

The download page at batocera.org/download lets you pick an image per device family: PC, Steam Deck, Raspberry Pi 4 and 5, and more. Picking wrong is the most common reason a flash succeeds and the boot does not. Match the image to the silicon.

PC, mini PC, and the x86_64-v3 question

For any 64-bit desktop, laptop, or mini PC, you want the x86_64 image. In 2026 the PC line also offers an x86_64-v3 build, which raises the CPU baseline to the v3 microarchitecture level (roughly Haswell-era and newer) and adds Wayland support on x86. That v3 image is aimed squarely at modern mini PCs — the Beelink Mini S12 class of device — and it is the one to grab if your hardware is recent. If your CPU is genuinely old, or you are not sure, the plain x86_64 image is the safe default and will boot on anything the v3 image would, plus a good deal that it would not. When in doubt, take the compatibility over the marginal optimization.

Raspberry Pi 4 and Pi 5

The Raspberry Pi images are architecture-specific and not interchangeable with the PC images or, strictly, with each other's optimizations. Download the Pi 4 image for a Pi 4 and the Pi 5 image for a Pi 5. This is one area where Batocera pulls ahead of the competition: it ships an official, supported Pi 5 image, which as of 2026 its main rival still does not. If you have been waiting on the other distribution, our piece on why RetroPie is stuck on v4.8 explains exactly why that gap exists and why the "2026 Suite" filling it is not what it claims to be.

Steam Deck and handhelds

The Steam Deck gets its own listed image, and this is a strong use case: you flash Batocera to a microSD card, insert it, and boot from it through the Deck's boot manager, leaving SteamOS completely untouched on the internal drive. It is the live-distribution promise at its cleanest. If you are weighing a Deck against the newer handheld crowd for exactly this kind of duty, our Switch 2 versus Steam Deck breakdown covers the battery and thermal side that decides how long your emulation sessions actually last. For other x86 handhelds, the standard x86_64 image (or v3, on newer units) is the target.

Downloading and Verifying the Image

Two minutes of verification saves you an afternoon of debugging a corrupted flash. Skipping the hash check is the false economy at the heart of most "Etcher said it worked but it won't boot" reports.

Getting the file from batocera.org/download

Go to batocera.org/download, select your device, and download the image for version 43.1. The direct image index also lives at batocera.org/images/download/ if you prefer to browse the raw file listing. If the primary host is slow or unreachable from your region, a verified community mirror has been maintained through 2025; treat any mirror with appropriate suspicion and always verify the hash afterward, because a mirror is exactly where a tampered image would live. The file arrives as a gzip-compressed disk image (.img.gz), typically well over a gigabyte for current builds, so give it time.

Decompressing the .img.gz

You have two choices. Balena Etcher can read the .img.gz directly and decompress on the fly during writing, which is the simplest path and the one most users should take. If you would rather decompress manually — to inspect the image, or to flash with dd — do it explicitly:

# Decompress the image (keeps the original .gz with -k)
gunzip -k batocera-x86_64-x86_64-43-20260530.img.gz

# Result: a raw .img file, several GB in size
ls -lh batocera-x86_64-x86_64-43-*.img
# -rw-r--r-- 1 you you 3.8G May 30 12:04 batocera-x86_64-x86_64-43-20260530.img

Checking the hash before you trust it

Every serious release is published alongside a checksum. Download the corresponding hash file from the same page, then compute the hash of what actually landed on your disk and compare. If they differ, the download is corrupt or tampered with — delete it and start over. Do not flash a mismatched image "just to see," because you will see a black screen and blame the wrong thing.

# Compute the SHA-256 of the downloaded image
sha256sum batocera-x86_64-x86_64-43-20260530.img.gz

# Expected output — the hash on the left MUST match the published value:
# 9f2c1a7e4b8d3c6f0a5e9d2b7c4f1a8e6d3b0c9f2a5e8d1b4c7f0a3e6d9b2c5f  batocera-x86_64-x86_64-43-20260530.img.gz

# On macOS the command is:
shasum -a 256 batocera-x86_64-x86_64-43-20260530.img.gz

# On Windows PowerShell:
# Get-FileHash .\batocera-x86_64-x86_64-43-20260530.img.gz -Algorithm SHA256

The hash shown above is illustrative — use the real value published next to the file. The discipline is what matters: verified image, then flash. Never the reverse.

Flashing the Image: The 12-Step Core

This is the heart of the tutorial. Twelve steps, each with the reason it exists, because a step without a rationale is a step people skip. The default path uses Balena Etcher; step 11 gives the dd alternative for the terminal-inclined.

The twelve steps, each with its reason

1. Insert the target drive and note nothing else is plugged in. Rationale: flashing writes to a whole disk, not a partition. The fewer removable drives attached, the smaller the chance you pick the wrong one and overwrite a backup stick.
2. Open Balena Etcher. Rationale: it is the project-endorsed tool and it verifies the write automatically, which is the one thing dd will not do for you without extra effort.
3. Click "Flash from file" and select your .img.gz (or decompressed .img). Rationale: Etcher reads compressed images natively, so you can point it at the .gz and skip manual decompression entirely.
4. Click "Select target" and choose your USB stick or SD card by size. Rationale: identifying the target by its capacity — the 32 GB card, not the 2 TB system disk — is your last line of defense against nuking the wrong device. Etcher hides system drives by default; do not override that unless you are certain.
5. Confirm the target is correct, twice. Rationale: this is the irreversible step. There is no undo on a raw disk write. Read the device name out loud if you have to.
6. Click "Flash" and enter your admin password when prompted. Rationale: raw disk access requires elevated privileges on every OS; the prompt is expected, not malware.
7. Wait for the write to complete without touching the drive. Rationale: pulling a USB stick mid-write is the fastest way to produce a half-flashed, unbootable image and, occasionally, a dead stick.
8. Let Etcher run its verification pass. Rationale: this is the step that catches bad sectors and silent corruption before you have wasted a reboot on them. Do not cancel it to save thirty seconds.
9. Wait for the "Flash Complete" confirmation, then close Etcher. Rationale: the confirmation means the verify pass passed. Ejecting before it appears risks the same corruption as step 7.
10. Safely eject the drive through your OS. Rationale: flushing filesystem buffers guarantees the last blocks are actually on the media and not sitting in a cache.
11. Alternatively, flash from the terminal with dd. Rationale: on Linux, dd is faster and scriptable, but it is unforgiving — the wrong "of=" target destroys data instantly. Identify the device first, then write. The expected output is shown below.
12. Move the drive to the target machine and set it to boot from USB/SD. Rationale: the flash is meaningless if the firmware boots your internal disk instead. Enter the boot menu (usually F12, F11, ESC, or the Steam Deck's volume-down-plus-power) and select the removable drive explicitly for the first boot.

The dd path, line by line

The dd path from step 11, in full, with the confirmation output you should see:

# Identify the target device FIRST — get this wrong and you lose data
lsblk
# NAME   SIZE TYPE MOUNTPOINT
# sda    931G disk            <-internal disk, DO NOT TOUCH
# sdb     29G disk            <-the USB stick, this is our target

# Write the image (note: of=/dev/sdb, the whole disk, NOT /dev/sdb1)
sudo dd if=batocera-x86_64-x86_64-43-20260530.img of=/dev/sdb bs=4M status=progress conv=fsync

# Expected output while running and on completion:
# 3984588800 bytes (4.0 GB, 3.7 GiB) copied, 92 s, 43.3 MB/s
# 950+1 records in
# 950+1 records out
# 3984588800 bytes (4.0 GB, 3.7 GiB) copied, 94.2 s, 42.3 MB/s

# Flush and eject
sync && sudo eject /dev/sdb

If dd sits at zero bytes and never progresses, you targeted a mounted partition or a busy device — unmount it first with umount and retry. The conv=fsync flag matters: without it, dd can report success while blocks are still buffered, which is the terminal equivalent of yanking the stick early.

First Boot, Storage Expansion, and Controllers

A correct flash boots into EmulationStation on the first try. What you do in the first five minutes determines whether the system is usable or merely running.

What a healthy first boot looks like

On first boot, Batocera runs a one-time setup: it expands its data partition to fill the drive, generates configs, and drops you into the EmulationStation interface. You will see the splash, a brief flurry of console text, and then the main menu. If you have a controller plugged in, it is often detected automatically. To confirm the system sees your hardware and version, you can drop to a terminal (more on SSH below) and check:

# Confirm the running version and architecture
cat /usr/share/batocera/batocera.version
# 43.1 2026/05/30

# Confirm the data partition expanded to fill the drive
df -h /userdata
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/sdb2        27G  1.2G   26G   5% /userdata

# List what EmulationStation detected
batocera-es-swissknife --systems | head
# atari2600
# fbneo
# gb
# gba
# genesis
# ...

Expanding the game partition

The automatic expansion on first boot normally handles this, growing the userdata partition to consume all free space on the boot drive. If it did not — because you cloned the image, or interrupted the first boot — you can force it from the menu under SYSTEM SETTINGS then STORAGE, or trigger the partition resize manually and reboot. Verify with the df -h /userdata command above: if it reports only a few gigabytes on a 32 GB card, expansion did not run and your library will hit a wall fast.

Mapping your controller

If your controller was not auto-detected, hold any button for a few seconds and EmulationStation launches its input-mapping wizard. Walk through the prompts once and the mapping is saved system-wide. This is also where you set the hotkey — the button that, combined with others, exits games and opens the in-game menu. Choosing a sensible hotkey now (Select is the convention) saves you from the classic "I am trapped inside a game with no way out" panic later. Controllers configured here apply across every emulator, which is the payoff for Batocera's unified front end versus assembling the stack yourself.

Adding Games and BIOS Over the Network

The system boots, and the shelves are empty, because the download shipped no games — that is the law, not a limitation. Here is how content actually gets onto the machine, and the one detail that trips up nearly everyone.

The network share and where files go

The moment Batocera is on your network, it exposes a share called BATOCERA. From Windows or macOS you reach it at \\BATOCERA\share; from Linux, smb://BATOCERA.local/share. Inside that share is a fixed directory structure, and files must go in the right subfolder or nothing sees them. ROMs go under share/roms/[system-shortname] and BIOS files go under share/bios/. The system shortnames are not guesses — they are the folder names Batocera created, and the add games and BIOS wiki page lists every one of them.

# The share layout you will see over the network
# \\BATOCERA\share  (Windows/macOS)  |  smb://BATOCERA.local/share  (Linux)

share/
|-- roms/
|   |-- snes/          <-Super Nintendo ROMs go here
|   |   |-- Chrono Trigger (USA).sfc
|   |   +-- Super Metroid (USA).sfc
|   |-- genesis/       <-Mega Drive / Genesis
|   |-- psx/           <-PlayStation 1 (.cue/.bin or .chd)
|   |-- n64/           <-Nintendo 64
|   +-- mame/          <-Arcade; romset MUST match MAME 0.285
|-- bios/              <-Proprietary BIOS files live flat here
|   |-- scph5501.bin   <-PS1 (US) BIOS, for example
|   +-- gba_bios.bin
+-- saves/             <-Save files and states, auto-created

The BIOS problem nobody warns you about

This is where installs go quiet and stay quiet. Many systems — PlayStation, Sega CD, certain handhelds — will not run at all without a specific BIOS file, and that file must have the exact filename and, ideally, the exact MD5 hash the emulator expects. A PS1 BIOS renamed slightly, or the wrong regional dump, produces a game that refuses to launch with an unhelpful error. Batocera has a built-in checker under SYSTEM SETTINGS then MISSING BIOS that lists exactly what is absent and what filename it wants. Cross-reference the required names and hashes against the authoritative libretro BIOS documentation, which is the same reference we lean on in our 30-minute RetroArch cores setup, since Batocera's libretro cores expect identical files. Get the BIOS right and a whole shelf of "broken" games starts working at once.

Refreshing the game list

Copying ROMs onto the share does not make them appear instantly — EmulationStation caches its game lists and needs a nudge. After transferring files, press START to open the main menu, go to GAME SETTINGS, and choose UPDATE GAMELISTS. The interface rescans the rom folders and the new titles show up, ready to scrape artwork and metadata. If a system still does not appear after this, the folder name is wrong or the file extension is unsupported — check the wiki's per-system page rather than guessing.

5 Common Pitfalls and How to Fix Them

These are the failures that generate the most support threads, in rough order of frequency. Every one is preventable.

The six failures, ranked by frequency

1. Flashing the partition instead of the whole disk. Writing to /dev/sdb1 instead of /dev/sdb produces an image that will not boot and a partition table that confuses everything. Fix: always target the bare device (no trailing number) in dd, and in Etcher select the drive, which handles this for you. This is the single best reason to prefer Etcher.
2. Downloading the wrong architecture. A Pi image on a PC, or a PC image on a Pi, flashes cleanly and then does nothing — no boot, no error, just a dead screen. Fix: match the image on the download page to your exact device family before you flash, and re-read the filename's architecture field.
3. Skipping the checksum and blaming Batocera for a corrupt download. A truncated or tampered image behaves identically to a software bug from the user's chair. Fix: run sha256sum against the published hash every single time. Two minutes now, no wasted afternoon later.
4. Expecting games to be included. An empty EmulationStation is not a failed install — the distribution legally cannot ship ROMs or BIOS. Fix: add your own content over the network share as described above, then UPDATE GAMELISTS. This is by design.
5. Wrong or misnamed BIOS files. The most common "the game won't start" cause after a clean install. A PS1 BIOS with the wrong name or region simply fails silently. Fix: use SYSTEM SETTINGS then MISSING BIOS to get the exact required filenames, and verify against the libretro BIOS reference.
6. Cheap SD cards on Raspberry Pi. Unbranded cards corrupt under the write load of save states and metadata scraping, producing intermittent failures that look like software instability. Fix: use an A1/A2-rated card from a known brand, 32 GB or larger, and treat a card that corrupts twice as dead.

The common thread

Notice that not one of these six is a Batocera bug. Five are user error at the flashing or content stage, and the sixth is failing hardware. That is the pattern across nearly every "Batocera is broken" thread: the distribution did exactly what it was told, and what it was told was wrong. The verification habit — checksum the download, target the whole disk, name the BIOS correctly, refresh the game list — eliminates the entire category before it starts. Slow is smooth, and smooth is a system that boots the first time.

Troubleshooting Table: 8 Failure Modes

When something goes wrong, work down this table before you post to a forum. The symptom on the left almost always maps to one of these causes.

Symptom, cause, and fix

When the table doesn't cover it

If your symptom is not here, collect evidence before asking for help: the exact image filename you flashed, the output of cat /usr/share/batocera/batocera.version, and the relevant lines from the logs under /userdata/system/logs/. Post those and the answer usually arrives in one reply; post "it doesn't work" and you will get twenty questions instead. The install wiki and its per-system pages resolve the long tail that no single table can.

Advanced: Manual Upgrades, SSH, and Wayland

Once the basics work, these are the levers that separate a toy install from a maintained one. None are required; all are useful.

Upgrading in place without reflashing

You do not have to reflash to move between versions. Batocera's built-in updater handles most point releases from the menu under UPDATES & DOWNLOADS. When an in-place update is not offered — jumping across a major version, or recovering a half-broken install — there is a manual path using a boot.tar archive and the batocera-upgrade-manual tooling. The full procedure is documented on the manual upgrade wiki page, and the release archives (including boot.tar.xz files) are mirrored for direct download. Always confirm which versions are current before upgrading via the current and previous releases page, so you are not chasing a build that has already been superseded.

SSH and the config file

Batocera runs an SSH server, and this is the fastest way to inspect or fix a system. The default login is user root with password linux — change it if the machine lives on a shared network, because those defaults are public knowledge. Over SSH you can read logs, run the swissknife utility, and edit the master configuration file directly. Nearly every setting in the graphical menus is a line in /userdata/system/batocera.conf, and editing it by hand is often faster than clicking through menus.

# Connect over SSH (default credentials; change them on shared networks)
ssh root@BATOCERA.local
# password: linux

# Inspect the live config
nano /userdata/system/batocera.conf

# Trigger a manual upgrade check from the shell
batocera-upgrade

# For a cross-version manual upgrade using a boot archive:
batocera-upgrade-manual

# Apply config changes without a full reboot where supported
batocera-settings-set audio.volume 90
curl http://localhost:1234/reloadgames   # ask ES to rescan roms

The v3 image and Wayland

The 2026 x86_64-v3 build is the forward-looking option for modern hardware. Beyond the raised CPU baseline, it introduces Wayland on x86, which improves display handling on current mini PCs and handhelds — the Beelink Mini S12 class of machine it is aimed at. If your device is recent and you want the best display and graphics behavior, the v3 image is worth the slightly narrower hardware compatibility. On older silicon, stay on the standard x86_64 image; the v3 baseline will simply refuse to boot on CPUs below its floor, which is a cleaner failure than a subtle instability but a failure nonetheless.

A Complete, Working batocera.conf

Everything above collapses into one file. Here is a complete, sane /userdata/system/batocera.conf to drop in over SSH — a known-good baseline for a PC or mini PC install running 43.1, with the reasoning inline.

# /userdata/system/batocera.conf
# Known-good baseline for Batocera 43.1 (PC / mini PC)
# Edit over SSH: ssh root@BATOCERA.local  (default pass: linux)

# ---- System / display ----
system.power.switch=PWRBTN        # clean shutdown on power button
system.hostname=BATOCERA          # name on the network share
global.videomode=default          # let the display negotiate its native mode
global.bezel=default              # arcade-style bezels where available

# ---- Audio ----
audio.device=auto                 # follow the active output (HDMI/analog)
audio.volume=90
audio.bgmusic=0                   # no menu music; personal preference

# ---- Global emulator defaults ----
global.retroachievements=0        # set to 1 and add creds to enable
global.smooth=1                   # bilinear smoothing on by default
global.shaderset=none             # add a CRT shader per-system instead
global.rewind=0                   # off globally; costs performance
global.integerscale=1             # crisp integer scaling for 2D systems

# ---- Per-system overrides ----
# PlayStation 1: use the accurate core, real BIOS in share/bios/
psx.core=swanstation
psx.bios=scph5501.bin

# SNES: snes9x is the safe, fast default
snes.core=snes9x
snes.shaderset=none

# Nintendo 64: mupen64plus-next handles most titles on modern x86
n64.core=mupen64plus-next
n64.smooth=1

# Arcade: romset MUST match Libretro MAME 0.285
mame.core=mame

# ---- Network ----
wifi.enabled=0                    # wired preferred for large transfers
system.samba.enable=1             # expose \\BATOCERA\share

# ---- Updates ----
updates.enabled=1
updates.type=stable               # track stable (43.x), not beta

What each block does

The system and display block keeps shutdowns clean and lets the monitor pick its native resolution — fighting the display over modes is a common source of black screens. The global emulator defaults set sensible behavior everywhere and are then overridden per system: PS1 pins the accurate SwanStation core and names its BIOS explicitly, arcade pins the MAME core that must line up with the 0.285 romset, and the rest inherit the smoothing and integer-scaling defaults. The network block turns on Samba so the share is reachable, and the updates block keeps you on the stable channel so you land on 43.1 and its successors rather than a beta.

Where to go from here

With a verified image, a clean flash, content on the share, correct BIOS, and this config in place, you have a maintained Batocera install rather than a lucky one. From here the depth is in the emulators themselves — per-core options, shaders, and controller profiles — and the authoritative references are the Batocera wiki and the GitHub changelog, which will tell you what changed the next time a version number ticks up. The download, as promised, was the easy part. Keeping the thing tuned is the hobby.