Batocera 43.1 Download 2026: Free, 12 Steps, 15 Min

'Batocera download' is one of those searches that sounds like a transaction and isn't. The distribution is free, the file is one click, and yet the gap between hitting download and actually playing Chrono Trigger on the couch is where everyone gets stuck. This is the 2026 map across that gap: version 43.1, roughly a dozen steps, about fifteen minutes of active work, and every pitfall we have watched people faceplant into.

What 'Batocera Download' Actually Means

Type 'batocera download' into a search bar and part of you is bracing for a checkout page. There isn't one. Batocera.linux is free — the download costs exactly $0, it has been open-source since the project was first copyrighted in 2016, and the code lives in the open on GitHub. Nobody is going to upsell you a 'Pro' tier. The only money that changes hands in this entire tutorial is whatever you paid for the SD card.

So if the price is zero and the file is a single click, why does this article run to several thousand words? Because the download is the easy fifteen seconds. The part that eats your evening is everything around it: choosing the correct image out of roughly forty architecture-specific builds, verifying it didn't corrupt on the way down, flashing it without nuking the wrong disk, and then getting a controller, a network share, and a pile of BIOS files to cooperate. Batocera ships an operating system. It does not ship your games, and — this matters legally — it ships no copyrighted BIOS either.

Batocera is an image, not an installer

Unlike a normal desktop app, Batocera is distributed as a full disk image — a byte-for-byte snapshot of a bootable drive, compressed as an .img.gz. You do not 'install' it the way you install Steam. You write the image to an SD card or USB stick, boot your device from it, and the system expands itself to fill the drive on first launch. The root filesystem is read-only (a SquashFS), which is why Batocera is famously hard to break: your settings, ROMs, and saves live on a separate writable partition called userdata, and the OS itself is immutable.

The 2026 headline: version 43.1

As of July 2026 the current stable release is Batocera 43.1, a point update rolled out in June 2026 on top of the major v43 release from May 8, 2026. That major version is the one that added support for the 'Glasswing' class of x86 handhelds with AMD and Intel graphics, and it also quietly removed, renamed, and re-enabled a handful of emulators that will bite you if you upgrade blind. We cover those breaks in detail below, because 'download the latest version' is not automatically the right advice in 2026.

What you are legally downloading

Downloading Batocera is unambiguously legal — it is free software, and you can read every line of it. What you subsequently copy onto the userdata partition is your responsibility. The clean, boring, lawful path is to dump the cartridges and discs you already own; if you want to do that properly, our walkthrough on dumping SNES and Genesis carts with a Retrode is the companion piece to this one. Batocera hands you the machine. It does not hand you someone else's software.

Prerequisites: Hardware, Software, Versions

Before you download a single byte, you need to know exactly which machine you are building for, because Batocera's images are not interchangeable. Grabbing the Raspberry Pi 5 image for an x86 mini-PC produces a card that simply does nothing when you boot it, and half the 'Batocera won't boot' posts on Reddit are exactly this mistake.

Hardware requirements

Batocera runs on three broad families of hardware: 64-bit x86 PCs (including most Intel/AMD mini-PCs and x86 handhelds), the Raspberry Pi line, and a long tail of ARM single-board computers and handheld consoles. The practical minimums:

• x86_64 PC or handheld: a 64-bit CPU, 2 GB of RAM (4 GB or more if you want PS2, GameCube, or Wii), and a GPU with working OpenGL. Note the 2026 catch below about the x86_64-v3 baseline.
• Raspberry Pi 5 / Pi 4 / Pi 400: 2 GB RAM minimum, 4 GB or more recommended; a Pi 5 with active cooling is the sweet spot for anything up to Dreamcast and light PSP.
• Storage: the project floor is 16 GB, and 32 GB is the sane recommendation (a 16 GB card is too small for in-place auto-updates). Realistically use 32–256 GB, and expect a full ROM set to want far more. A fast A2-rated microSD or, better, a USB SSD makes menus and PS2/GameCube load times dramatically less painful.
• Controller: almost any USB or Bluetooth pad. Xbox, DualShock/DualSense, and 8BitDo controllers are auto-detected.

The 2026 x86_64-v3 catch

This is the single most important prerequisite change in recent memory, and it is not on the download page in bold where it belongs. Batocera's modern x86_64 image is built against the x86_64-v3 microarchitecture level, which requires AVX2. In plain terms: your CPU needs to be roughly 2013-or-newer — Intel Haswell and later, AMD Excavator/Zen and later. Resurrecting a Core 2 Duo or a first-gen i5 from the parts bin will not work with the current image; it fails to boot with no useful error. If you are targeting genuinely ancient hardware, you are looking at an older Batocera release or a different distro entirely. The move to a Wayland display stack (with the LabWC compositor on the Glasswing builds) is part of the same modernization push.

Software you need on your main computer

You flash the image from a separate working computer. You need exactly two things: a way to verify a checksum (built into every OS) and a flashing tool. The three sane choices:

• balenaEtcher — cross-platform, dead simple, handles .img.gz without manual decompression. The default recommendation.
• Raspberry Pi Imager (or USBImager) — best on Pi hardware; can flash a custom Batocera image and is very hard to misuse.
• Rufus (Windows) or dd (Linux/macOS) — for people who want control and don't mind a command line. The wiki considers dd a last resort, so treat it as the expert path.

That is the whole shopping list: a target device, a card or stick, a host computer, and a flasher. No account, no license key, no email signup — which, in 2026, feels almost suspicious. It isn't.

Pick and Verify the 43.1 Image

Here is where the actual procedure begins. The next four steps get you from 'I have hardware' to 'I have a verified image file on my disk.' Skipping verification is the classic way to spend an hour debugging a flash that was doomed before it started, because a truncated or corrupted download will flash perfectly happily and then fail to boot.

Steps 1–2: Identify your device, then download the matching image

1. Identify your exact hardware. Rationale: the image must match the CPU architecture and, for SBCs and handhelds, often the exact board. For a PC or x86 handheld you want the x86_64 image. For a Raspberry Pi, match the model precisely — the Pi 5 image is not the Pi 4 image. Write down the answer before you touch the download page.
2. Go to the official download page and grab the 43.1 image for that hardware. The one and only canonical source is batocera.org/download. Rationale: third-party mirrors and random Google Drive links are how people end up with tampered images or last year's build. The official page hands you the current stable (43.1) plus the SHA-256 you will need in step 4. Do not download a 'loaded' or 'modpack' image from a marketplace — those are the ones stuffed with piracy and, occasionally, malware.

The file you receive is named on the pattern batocera-x86_64-43-YYYYMMDD.img.gz (the architecture and datestamp match your choice; the v43 base carries the 20260508 stamp of its May 8 release). Expect somewhere around 2–4 GB depending on architecture.

Steps 3–4: Confirm the size, then verify the checksum

1. Confirm the download finished and the file size looks right. Rationale: browsers silently truncate downloads more often than you would think, especially on flaky connections. An .img.gz that is suspiciously small — a few hundred KB — is an error page wearing a costume.
2. Verify the SHA-256 checksum against the value on the download page. Rationale: this is the one step that separates a five-minute success from an evening of confusion. The checksum proves the bytes on your disk are identical to what the Batocera team published. Every OS can do this from the command line:

# Linux
sha256sum batocera-x86_64-43-20260508.img.gz

# macOS
shasum -a 256 batocera-x86_64-43-20260508.img.gz

# Windows (PowerShell)
Get-FileHash batocera-x86_64-43-20260508.img.gz -Algorithm SHA256

Compare the output string, character for character, against the checksum listed next to the download. If your distribution ships a .sha256 file alongside the image, let the tool do the comparison and hand you a clean one-word verdict:

$ sha256sum -c batocera-x86_64-43-20260508.img.gz.sha256
batocera-x86_64-43-20260508.img.gz: OK

If it says OK, proceed. If it says FAILED, delete the file and download again — do not flash it 'just to see', because you will only be debugging the download later while blaming the SD card.

Flash the Image: Etcher, Rufus, dd

With a verified image in hand, you write it to the card or stick. This is the step where people destroy the wrong disk, so the single rule is: identify the target device by size and name before you commit, and unplug every other external drive you do not want touched. Flashing is a raw write — it does not ask about existing data, it obliterates it.

Step 5: Flash with balenaEtcher (the safe default)

1. Flash the image with balenaEtcher. Rationale: Etcher is recommended precisely because it makes the fatal mistake hard — it hides system drives by default, verifies the write automatically, and reads .img.gz directly with no manual decompression. Open Etcher, choose Flash from file and select your .img.gz, choose your SD card or USB stick as the target, and click Flash. Wait for the verify pass to finish before you pull the card. On a decent card this takes a few minutes.

Raspberry Pi users can substitute Raspberry Pi Imager here: choose Use custom under the OS menu, point it at the Batocera image, pick the card, and write. Functionally identical, equally hard to misuse.

Steps 6–7: The command-line path with dd

If you prefer the terminal — or Etcher is misbehaving — dd is the classic Unix tool for the job. It is also the classic Unix tool for erasing the wrong disk, so we go in two deliberate steps.

1. Identify the target device node. Rationale: dd writes to whatever you name, with zero confirmation. Naming the wrong device overwrites it instantly. List your disks first and find the one whose size matches your card:

# Linux: find the device (e.g. /dev/sdb, NOT a partition like /dev/sdb1)
lsblk -o NAME,SIZE,MODEL,TRAN

# macOS: find the disk (e.g. /dev/disk4)
diskutil list

Expected Linux output — here the 240 GB USB stick is sdb, and the internal system disk is the 931 GB sda you must not touch:

NAME   SIZE MODEL            TRAN
sda    931G Samsung SSD 980  nvme
sdb    240G USB SanDisk 3.2  usb
  sdb1 240G                  usb

1. Decompress and write the image in one pipe, then flush. Rationale: piping gzip -dc straight into dd avoids storing an uncompressed intermediate file, and conv=fsync guarantees the write is fully committed before the command returns — pulling the card early is another silent corruption cause. On Linux:

gzip -dc batocera-x86_64-43-20260508.img.gz \
  | sudo dd of=/dev/sdb bs=4M status=progress conv=fsync

On macOS the same idea, writing to the raw device node (rdiskN) for speed, after unmounting the disk:

diskutil unmountDisk /dev/disk4
gzip -dc batocera-x86_64-43-20260508.img.gz \
  | sudo dd of=/dev/rdisk4 bs=4m

When dd finishes it prints the number of bytes written; that is your confirmation. Windows users without WSL should just use Rufus (select the image, select the device, write) or Etcher — there is no shame in the GUI, and there is real shame in a mistyped device path.

First Boot: Storage, Network, Controllers

Move the flashed card or stick to the target device and power on. The first boot is different from every boot after it: Batocera expands its userdata partition to fill the drive, generates configs, and drops you into EmulationStation, its game-picker frontend. On a Raspberry Pi it 'just boots.' On a PC there is one BIOS chore first.

Step 8: Boot the device (and the x86 BIOS detour)

1. Boot from the Batocera media. Rationale: PCs default to booting the internal disk, so you must tell the firmware to boot your USB/SD instead. Enter the UEFI/BIOS boot menu (usually F12, F11, F8, or Esc at power-on), select the Batocera device, and — critically — disable Secure Boot, which otherwise blocks the unsigned bootloader. Batocera then expands userdata and lands on EmulationStation. First boot is slower than the rest; let it finish.

You can confirm the expansion worked from a shell later. A healthy x86 install shows a small read-only boot partition and a large userdata partition that grew to fill the disk:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       2.0G  1.4G  620M  70% /boot
overlay          50M  1.2M   49M   3% /
/dev/sda2       228G  9.8G  218G   5% /userdata

Step 9: Set up the network

1. Connect Batocera to your network. Rationale: you will move ROMs and BIOS over the network in the next section, and networking also enables scraping box art, updates, and RetroAchievements. For Ethernet, it is automatic. For Wi-Fi, open Main Menu → Network Settings, enable Wi-Fi, pick your SSID, and enter the key. Note the device's IP address shown on that same screen — you will use it in a moment. By default the machine also answers to the hostname BATOCERA.

Step 10: Pair a controller

1. Configure your controller. Rationale: EmulationStation and every emulator read the controller mapping you define here; get it right once and it propagates everywhere. Plug in a USB pad and it is detected instantly; for Bluetooth, go to Main Menu → Controller & Bluetooth Settings → Pair a Bluetooth Controller. Then run Configure a Controller and follow the on-screen prompts, holding a button to begin and mapping each input. If you ever map something wrong, hold a button to skip it and re-run the wizard — nothing here is permanent.

At this point you have a fully working retro console with zero games on it. Everything from here is about feeding it content and tuning it.

Add ROMs and BIOS Files

Batocera keeps everything you add in one predictable place: the userdata partition, exposed over the network as a share called share. ROMs go in per-system folders under /userdata/roms/, BIOS files go in /userdata/bios/, and saves land in /userdata/saves/. You can reach all of it three ways — a Windows/macOS network share, SSH/SCP, or by pulling the card and copying directly.

Step 11: Connect to the share

1. Open the Batocera network share from your main computer. Rationale: the SMB share is the least error-prone way to move large amounts of data and keeps the folder structure obvious. On Windows, open Explorer and type \\BATOCERA\share (or \\the-ip-address\share) into the address bar. On macOS or Linux, connect to smb://batocera.local/share. You will see the roms, bios, saves, and system folders.

Inside roms you will find one folder per system, already created and named by Batocera's conventions — snes, nes, megadrive, psx, n64, and dozens more. Drop each game into the folder that matches its system.

Step 12: Copy ROMs into the per-system folders

1. Copy your ROMs into the correct system folders. Rationale: EmulationStation only scans the folder that belongs to each platform, and putting an SNES ROM in the Genesis folder just makes it invisible or unplayable. If you would rather script it than drag files, SSH is enabled by default (user root, password linux). From your computer:

# Copy a folder of SNES ROMs over the network with rsync
rsync -av --progress ./my-snes-roms/ \
  root@batocera:/userdata/roms/snes/

# Or a one-off with scp (password: linux)
scp "Chrono Trigger.sfc" root@batocera:/userdata/roms/snes/

A word on formats and sizes: the userdata partition is created as a Linux filesystem, so single files larger than 4 GB — PS2 ISOs, some GameCube images — are fine. If you ever reformat userdata yourself, avoid FAT32 for exactly this reason; use exFAT or ext4. After copying, refresh the library from Main Menu → Game Settings → Update Gamelists so new titles appear.

Step 13: Drop in BIOS files and run the checker

1. Place required BIOS files in /userdata/bios and verify them. Rationale: several systems — PlayStation, Saturn, Dreamcast, Neo Geo, and others — refuse to run without the exact BIOS file, matched by name and often by checksum. Batocera ships none of these for copyright reasons, so you supply your own. After copying them into /userdata/bios/, use the built-in checker at Main Menu → Game Settings → Missing BIOS Check, which lists every expected file, whether it is present, and whether its hash matches.

The checker is the single best time-saver in Batocera. Instead of guessing why PSX games boot to a black screen, you get a definitive report: file missing, or file present-but-wrong-hash. Fix what it flags, and the black screens disappear. The full list of systems, their folder names, and their BIOS requirements is documented on the official Batocera wiki's 'add games & bios' page, and the authoritative BIOS names and hashes live in the libretro BIOS reference.

Configure batocera.conf

Almost everything in Batocera can be set from the on-screen menus, and for most people that is enough. But the menus write their choices into a single plain-text file — /userdata/system/batocera.conf — and editing that file directly is faster, scriptable, and the only way to reach a few settings the UI hides. It is the closest thing Batocera has to a control panel, and understanding it turns 'clicking around hoping' into 'I know exactly what changed.'

How the file is structured

The syntax is dead simple: key=value, one per line, with # for comments. Keys are namespaced with prefixes that scope the setting:

• system. — machine-wide settings such as language, timezone, and hostname (Wi-Fi lives under its own wifi. prefix).
• global. — defaults applied to every emulator: smoothing, rewind, shaders, RetroAchievements.
• <system>. — per-platform overrides, where the prefix is the system's folder name (snes., n64., psx.). A per-system key beats the global one.

So global.rewind=1 turns on rewind everywhere, while n64.rewind=0 switches it back off for Nintendo 64 specifically. This override model is the whole trick to per-console tuning.

Editing it safely

You can edit the file over the network share, over SSH with the built-in text editor, or — the officially sanctioned way — from the UI itself. From SSH:

# Edit the config
nano /userdata/system/batocera.conf

# Apply a change without a full reboot where supported
batocera-settings-set global.smooth 1

# Read a value back
batocera-settings-get global.smooth

The batocera-settings-set and -get helpers are safer than hand-editing because they will not duplicate a key or corrupt the formatting. After changing emulator or video settings, restart EmulationStation (or reboot) so everything re-reads the file.

The settings that matter most

A handful of keys deliver the most benefit. Choosing an emulator core per system is the big one — Batocera often ships several cores per platform, and the default is not always the best for your hardware. Under the hood these are largely the same libretro cores you would tune by hand in a bare RetroArch setup; if you want to understand what is actually running, our guide to RetroArch cores and the 200-emulator libretro stack maps the whole landscape. A representative snippet:

# --- Per-system emulator/core selection ---
snes.core=snes9x
n64.core=mupen64plus_next
psx.core=swanstation
nes.core=fceumm

# --- Global feel ---
global.smooth=1          # bilinear smoothing
global.rewind=0          # rewind off (costs performance)
global.shaderset=none    # v43 default: hardware shaders off

# --- RetroAchievements ---
global.retroachievements=1
global.retroachievements.username=YourName
global.retroachievements.hardcore=0

Note that global.shaderset=none reflects a real 2026 default change, which we unpack next.

What v43 Changed: DraStic, Azahar, Shaders

If you are coming to Batocera fresh, download 43.1 and move on. If you are upgrading from an older release, or following a two-year-old tutorial, stop and read this section, because Batocera 43 (May 8, 2026) changed several things that silently break existing setups. None of it is a bug; all of it is the project tightening its open-source licensing and modernizing emulators. It just does not announce itself at the dinner table.

DraStic is gone; DS emulation changed hands

The big one for handheld owners: the closed-source DraStic Nintendo DS emulator was removed in Batocera 43. DraStic was proprietary, and it no longer fit a distribution that wants to stay cleanly open-source, so it was dropped with the May 8, 2026 release. DS emulation continues through open cores such as melonDS, but there is no drop-in save-state replacement — if you relied on DraStic's specific save states, they do not transfer. Upgraders who never touched DS will not notice; DS mains absolutely will, so archive your old states before you upgrade.

Azahar replaces Azahar Plus for 3DS

Nintendo 3DS emulation also shifted. In v43 the project moved to Azahar, the upstream open-source 3DS emulator, replacing the previously bundled Azahar Plus variant to stay aligned with open-source standards. Two ROM-handling changes ride along with it, and both will trip people:

• Encrypted CIA and CCI files are no longer supported. You must use decrypted ROMs. If your 3DS library boots to errors after upgrading, encryption is the first thing to check.
• The .3ds extension was re-added in Batocera 43, reversing an earlier restriction. So .3ds dumps that a previous release rejected are valid again.

Hardware shaders off by default, and a TheXTech bump

Two smaller but visible changes round out the list. First, hardware shaders are disabled by default in Batocera 43 — a compatibility decision, since aggressive default shaders caused more 'why does this game look broken / run slow' reports than they were worth. This is why global.shaderset=none is the sane baseline in the previous section; if you want CRT scanlines back, you now opt in deliberately. The change was flagged in the v43 upgrade guide (build 1d7973a) that circulated ahead of release. Second, TheXTech — the open-source reimplementation of the Super Mario Bros. X engine, and no relation whatsoever to the Mega Man line, whatever a hasty spec sheet might tell you — was updated and now expects a minimum of 1.3.7 assets to run correctly; older asset packs need refreshing.

All of these changes, with the exact commit history, are tracked in public on the batocera-linux GitHub repository. When a tutorial disagrees with reality, the changelog is the referee.

Five Pitfalls That Waste Your Evening

Every one of these has generated a thousand forum threads. None is hard to fix once you know the cause; all of them are maddening if you do not. Read this section before you flash and you will skip the whole genre of self-inflicted problems.

Wrong image, dead boot, and the checksum you skipped

Pitfall 1 — Wrong architecture image. The Pi 5 image on x86, or the x86 image on a Pi, produces a card that does nothing. Fix: re-read the download page device list and match your hardware exactly before downloading. Pitfall 2 — Skipped checksum. A corrupted download flashes fine and fails to boot, sending you off to blame the SD card for an hour. Fix: run the sha256sum check from step 4 every single time; it costs ten seconds and saves the evening.

Secure Boot, and the CPU that is too old

Pitfall 3 — Secure Boot left enabled on a PC. UEFI Secure Boot blocks Batocera's bootloader, so the machine ignores your carefully flashed stick and boots Windows instead. Fix: disable Secure Boot in UEFI/BIOS, and while you are there confirm USB sits above the internal disk in the boot order. Pitfall 4 — CPU older than the x86_64-v3 baseline. As covered in prerequisites, the modern x86 image needs AVX2 (roughly 2013+). An older chip fails to boot with no meaningful message. Fix: verify your CPU generation before assuming the flash failed; genuinely old hardware needs an older release.

BIOS black screens and the FAT32 4 GB wall

Pitfall 5 — Missing or wrong-hash BIOS. PlayStation, Saturn, and friends boot to a black screen with no explanation when their BIOS is absent or subtly wrong. Fix: run Game Settings → Missing BIOS Check, which tells you exactly which file is missing or mismatched — stop guessing and read the report. Pitfall 6 (bonus) — Large files on a FAT32 share. If you reformatted userdata to FAT32, any single file over 4 GB (PS2, some GameCube) silently will not copy or will not load. Fix: keep userdata on the Linux filesystem Batocera creates, or use exFAT/ext4 if you must reformat.

Troubleshooting Table

When something breaks after install, the failure is almost always one of a dozen known patterns. This table maps symptom to likely cause to fix. Work it top to bottom: the most common causes sit near the top, and boot-level problems are worth ruling out before you go hunting for exotic ones.

Symptom-to-fix reference

How to read it

The ordering is deliberate. Boot and flash failures (top rows) mean the OS never came up, so nothing higher in the stack matters yet. Content and BIOS problems (middle rows) mean Batocera runs but a specific system will not — those are almost always a folder or a missing file, not the emulator. Fix from the bottom of the stack upward, and you will not waste time tuning cores on a machine that has not finished booting.

When nothing matches: batocera-support

If none of these fit, generate a support archive from the terminal with batocera-support, which bundles logs and system info into a single file you can attach when you ask for help on the forum or Discord. It is dramatically more useful to a would-be helper than 'it does not work', and it often reveals the cause to you before you even post it.

Advanced Tips

Once the basics work, a few power moves separate a functional Batocera from a genuinely pleasant one. None of these are required; all of them are the kind of thing you will wish you had known on day one.

Run from USB, then install to internal disk

Running Batocera from a USB stick is perfect for testing hardware compatibility with zero commitment — nothing on the internal drive is touched. Once you are happy, Batocera can install itself to the internal disk for faster load times and a tidier build. The installer lives at Main Menu → System Settings → Install Batocera on a new disk; it copies the system to the target drive and expands userdata there. Test from USB, commit to internal — the sane order.

Choose an update channel deliberately

Batocera has two update tracks: the default stable line and the bleeding-edge butterfly beta. You update in place from Main Menu → Updates & Downloads, or from the terminal. Switching to the beta channel is a one-line change in batocera.conf:

# Stay on stable (default, recommended)
updates.type=stable

# Or opt into the butterfly beta channel
# updates.type=butterfly

# Then update from a shell:
batocera-upgrade

Stay on stable unless you have a specific reason and a backup — beta builds are where new emulators and new bugs arrive together.

NVIDIA drivers, decorations, and knowing your CLI tools

On x86 machines with an NVIDIA GPU, you may need to select the proprietary driver in batocera-boot.conf on the boot partition (set nvidia-driver=true) for correct acceleration. For the cosmetic win, enable per-system bezels ('decorations') to frame 4:3 games instead of stretching them. And learn the handful of batocera-* CLI tools: batocera-info for a hardware summary, batocera-es-swissknife to restart the frontend without rebooting, and batocera-support to package logs. For anyone who wants the accuracy of real hardware instead of emulation for the systems that matter most, an FPGA route like the MiSTer Multisystem is the complementary path — Batocera for breadth, FPGA for cycle-accuracy.

A Complete Working Configuration

To close, here is a complete, sensible batocera.conf you can adapt — the kind of baseline that gets a fresh 43.1 install feeling right without over-tuning. Copy it to /userdata/system/batocera.conf, change the obvious values (Wi-Fi, timezone, username), and reboot. Comments explain each block so you know what you are turning on.

The annotated batocera.conf

# ============================================================
#  Batocera 43.1 - working baseline configuration
#  Path: /userdata/system/batocera.conf
# ============================================================

# --- System ---
system.hostname=BATOCERA
system.language=en_US
system.timezone=America/New_York
system.power.governor=performance

# --- Network / Wi-Fi (skip if you use Ethernet) ---
wifi.enabled=1
wifi.ssid=YourNetworkName
wifi.key=YourWifiPassword

# --- Updates: stay on stable ---
updates.type=stable
updates.enabled=1

# --- Global emulator defaults ---
global.smooth=1          # bilinear smoothing on
global.rewind=0          # rewind off (perf)
global.autosave=0        # no auto save-states
global.shaderset=none    # v43 default: HW shaders off
global.showFPS=0

# --- RetroAchievements (fill in to enable) ---
global.retroachievements=0
global.retroachievements.hardcore=0
# global.retroachievements.username=YourName
# global.retroachievements.password=YourToken

# --- Per-system core choices ---
nes.core=fceumm
snes.core=snes9x
megadrive.core=genesisplusgx
n64.core=mupen64plus_next
psx.core=swanstation
gba.core=mgba
nds.core=melonds

# --- Per-system tuning overrides ---
n64.rewind=0
psx.ratio=4/3
snes.bilinear_filtering=1

# ============================================================
#  End of file
# ============================================================

Where to go from here

That config plus a verified 43.1 image, a matched flash, your own legally-dumped ROMs, and the right BIOS files is a complete, self-contained retro machine that owes nobody a subscription. The download was free, the software is open, and the only limits are your storage and your patience for BIOS hashes. If you want the same $0-and-open ethos on a Raspberry Pi specifically, note that unlike RetroPie — which, as we cover in our piece on RetroPie's frozen v4.8 and missing x86 image — Batocera still ships a first-class x86 build, which is exactly why it is the pick for mini-PCs in 2026.

The last word

Batocera asks for nothing at the door: no price, no account, no telemetry upsell. What it asks for is care — pick the right image, verify it, flash the right disk, and feed it content you are entitled to use. Do that, and the machine does the rest. For the authoritative reference on every emulator and core it wraps, keep the libretro documentation and the Batocera wiki's PC install guide bookmarked; between them, every question this article did not answer has a home.