Batocera Download 2026: 43.1 in 12 Steps, 30 Min

Type batocera download into any search engine and it quietly assumes you want a program — an installer, a package, something you double-click and forget by lunchtime. That assumption is wrong, and the wrongness is the entire point. Batocera is not an application. It is an operating system, and what you actually download is a compressed disk image that you write onto a USB stick or SD card and then boot, replacing nothing and installing over nothing unless you explicitly tell it to.

This guide walks the whole path: what the download really is, how to choose the correct image for your hardware, how to verify it, how to flash it in twelve deliberate steps, and how to configure it into a working console. The current stable build as of this writing is Batocera 43.1 “Glasswing”, released 30 May 2026 as a bug-fix follow-up to the 43.0 major release of 8 May 2026. Budget roughly thirty minutes of hands-on time, most of it spent watching a progress bar move bytes it could have moved without your supervision.

Why “Batocera Download” Misleads

Before you download anything, understand what you are downloading. The single most common reason a first attempt ends with the machine booting straight back into Windows is the belief that Batocera behaves like an app. It does not, and internalizing that difference now will save you an evening of confusion later.

It is an operating system, not an application

Batocera is a Linux distribution. What lands in your downloads folder is a file ending in .img.gz — a gzip-compressed raw disk image. You do not run it; you write it, block for block, onto removable media, and then you point your computer's firmware at that media and boot from it. The official project describes itself plainly: a retro-gaming distribution you copy to a USB stick or SD card to turn a computer or “nano computer” into a gaming console. That phrasing is not marketing garnish. It is a literal description of the mechanism. There is no setup wizard that installs Batocera alongside your existing operating system, because Batocera is the operating system for as long as it is running.

This is why searching for a “download” is subtly misleading. You are not fetching software to install; you are fetching an OS image to boot. Once you accept that, every later step — the flashing, the two-partition layout, the read-only boot area — stops looking arbitrary and starts looking inevitable.

What Batocera actually bundles

Under the hood, Batocera is a curated stack. It ships the EmulationStation front-end as the face you see, RetroArch and its libretro cores as the emulation engine for most systems, and a fleet of standalone emulators for the systems libretro handles poorly. A 2026 setup guide counts more than 200 preconfigured emulator cores in the image, which is the entire reason people reach for Batocera instead of assembling the same thing by hand. If you have ever spent a weekend hand-installing the same libretro cores one by one, Batocera's appeal is that someone already did that, tested it, and froze it into an image. It is an appliance, not a launcher.

It also ships with exactly zero games. Batocera is the console; the cartridges are your problem. That is a deliberate design and a legal one, which brings us to the part The Machine is contractually obligated to mention.

Free, open source, and what “free” costs you

The official project description calls Batocera a completely free distribution, and it means free in both senses — zero cost and open source. Nobody sends you an invoice, and the source is public. What is not free is your legal exposure. Batocera supplies no ROMs and no BIOS files; you provide those, and you own whatever liability comes with how you obtained them. The defensible path is dumping your own cartridges and discs. Everything else lives in a gray zone that no distribution, however free, will indemnify you against. Batocera hands you a console and a shrug. The console is excellent. The shrug is legally correct.

Prerequisites: Hardware & Software

A tutorial that skips prerequisites is a tutorial that generates support threads. Here is precisely what you need before you download a single byte, with versions, because “latest” is not a version and “should work” is not a spec.

Supported hardware

Batocera is deliberately catholic about hardware. A 2026 compatibility overview lists support for Raspberry Pi 2 through Pi 5, x86_64 PCs and mini PCs, and “dozens of ARM handhelds.” In practice that covers three broad camps: the Pi crowd, the repurposed-PC crowd, and the handheld crowd running Batocera on devices such as the Retroid Pocket 6 and its rivals. Each camp downloads a different image, which is the whole subject of the next section, but the hardware decision comes first because it determines everything downstream.

For a first build, an old x86_64 laptop or mini PC is the path of least resistance: fast storage, familiar firmware, and no architecture surprises. A Raspberry Pi 5 is the tidy dedicated-appliance choice. A handheld is the most fun and the most fiddly. If you are weighing Batocera against a purpose-built FPGA box like the MiSTer Multisystem 2, understand that you are comparing software emulation on commodity hardware against cycle-accurate logic on a dedicated board — different philosophies, different budgets, different failure modes.

The media you flash to

You need a USB stick or SD card to receive the image. The requirements are unglamorous but non-negotiable:

• Capacity: 16 GB minimum. 32 GB or larger is sensible, because after the OS claims its space the remainder becomes your ROM and save storage.
• Speed: For SD cards, an A1 or A2 application-class card. Random I/O, not sequential marketing numbers, is what determines whether menus feel responsive. For USB, a genuine USB 3.0 stick.
• Authenticity: Buy from a reputable seller. Counterfeit cards that report 256 GB while holding 8 GB are a plague, and they corrupt Batocera silently, usually the moment you finish copying a large ROM set.

Host software and versions

On the computer you will flash from, you need one flashing tool and, for the command-line route, a way to decompress gzip. Any one of these suffices:

• balenaEtcher (current release), a cross-platform GUI that reads .img.gz directly and verifies the write automatically.
• Raspberry Pi Imager 1.8 or newer, which also handles compressed images and is the friendliest option for Pi targets.
• dd plus gunzip/zcat on Linux or macOS, for people who prefer their footguns loaded manually.

You will also want the official Batocera image for your architecture — version 43.1 at time of writing — and about 3 GB of free disk space on the host to hold the download and its decompressed form. Grab Etcher from the balenaEtcher project page or the Imager from the Raspberry Pi software page if you do not already have one.

Picking the Right Image

Batocera publishes a separate image per architecture, and downloading the wrong one produces a device that either refuses to boot or boots into a black rectangle of silence. The filename tells you everything you need, once you learn to read it.

Reading the filename

A 2026 setup article gives the canonical download filename pattern, and it decomposes cleanly:

batocera-x86_64-43.1-20260530.img.gz

  batocera   -> the distribution
  x86_64     -> CPU architecture (also seen: rpi5, rpi4, h6, rk3588, ...)
  43.1       -> version number
  20260530   -> build date, 30 May 2026 (YYYYMMDD)
  .img.gz    -> a gzip-compressed raw disk image

Every field earns its place. The architecture token is the one that bites people: x86_64 is for PCs and mini PCs, while Raspberry Pi and ARM handheld builds carry their own board-specific tokens. The build date is not decoration either — it is how Batocera distinguishes an initial release image from a later respin of the same version, and it is what you quote when you file a bug so a developer knows exactly which build you ran.

Matching the build to your board

Choose the image by the hardware you decided on in the prerequisites. An x86_64 laptop or mini PC takes the x86_64 image. A Raspberry Pi 5 takes the Pi 5 image; a Pi 4 takes the Pi 4 image; they are not interchangeable, because the boot firmware and kernel differ per board. ARM handhelds each have their own image keyed to their system-on-chip, and downloading a generic ARM build for a specific handheld is a common way to brick a boot. When in doubt, the official install documentation on the Batocera wiki maintains a per-device download matrix that maps hardware to the correct file.

The x86_64-v3 gotcha

Here is the modern trap that recent-version notes bury and forum posters rediscover the hard way. Batocera's 43-series x86_64 builds raised the baseline to the x86_64-v3 microarchitecture level — roughly Intel Haswell-era and AMD Zen-era chips and newer, the generation that introduced AVX2 — and moved the desktop stack toward Wayland. If you are reviving a genuinely ancient office PC from before about 2013, the current image may simply refuse to boot on a CPU that predates the v3 feature set. This is not a defect; it is a deliberate floor. The fix is to use hardware that clears the bar, and the diagnosis — an image that flashes perfectly but never reaches EmulationStation on an old machine — is worth recognizing before you blame the SD card.

Downloading & Verifying

Downloading is the easy half. Verifying is the half everyone skips and a third of them regret. Do both.

Where to download

Get the image from the official Batocera site or the wiki's download links, and nowhere else. The project is free, which means there is zero legitimate reason for a third-party mirror to gate it behind a survey, an ad-locker, or a “download accelerator.” Torrents and random file-lockers are how tampered images spread. The two directly authoritative references are the official Batocera site and the Batocera wiki install page; if you want to see how the image itself is assembled, the build system lives in the batocera.linux GitHub repository. Everything else is a middleman you did not need.

Decompress, or let the tool do it

The download is a .img.gz. Whether you decompress it yourself depends on your flashing route. balenaEtcher and Raspberry Pi Imager read the gzip directly and expand it on the fly — you point them at the .img.gz and walk away. The command-line dd route needs the raw image, which you can either extract first or stream through zcat in a single pipe:

# Option A: decompress to a standalone .img first
gunzip -k batocera-x86_64-43.1-20260530.img.gz

# Option B (preferred): stream straight into dd, no temp file
# (shown fully in the flashing section)
zcat batocera-x86_64-43.1-20260530.img.gz | ...

The -k flag on gunzip keeps the original archive so you can re-verify or re-flash without downloading again. Option B is tidier because it never writes a multi-gigabyte temporary file to your host disk.

Verify the checksum

Before you write anything, confirm the download is intact and unaltered. Compute the image's SHA-256 hash and compare it against the digest published next to the download. A single flipped bit in a 3 GB image can produce a system that boots but corrupts saves days later, and a checksum is thirty seconds of insurance against that.

# Linux / macOS
sha256sum batocera-x86_64-43.1-20260530.img.gz

# Expected output (the digest below is illustrative —
# always compare against the value on the official download page):
# a1b2c3d4e5f6...0f1e2d3c4b5a  batocera-x86_64-43.1-20260530.img.gz

If the hashes match, proceed. If they do not, delete the file and download it again; do not “just try flashing it anyway,” which is how people spend an afternoon debugging a problem that a re-download would have erased.

Flashing in 12 Steps

This is the core of the tutorial: writing the verified image to your media. The steps are ordered so that the destructive one — identifying and targeting a disk — comes after you have removed every disk you care about from the equation. Follow them in order. Each carries its rationale, because a step without a reason is a step you will skip.

Steps 1–4: Prepare and identify the target

1. Back up anything on the target media. Flashing overwrites the entire device, partition table and all. Rationale: dd and Etcher do not merge or append; they obliterate. Whatever was on that stick is gone the instant the write starts.
2. Confirm you downloaded the correct architecture image and that its checksum matched. Rationale: an image for the wrong board wastes the entire flash and the boot attempt after it; verifying now is cheaper than debugging later.
3. Close every other program that might touch removable drives. Rationale: backup utilities and auto-mounters can grab the device mid-write and produce a corrupt, half-written image that boots erratically.
4. Insert the USB stick or SD card and identify its device node precisely. Rationale: this is the step that destroys data when done carelessly. On Linux, list block devices and read the sizes and transport types until you are certain which node is the removable one:

# Linux: list block devices with size and transport
lsblk -o NAME,SIZE,MODEL,TRAN

# Example output — the 28.9G USB stick is sdb, NOT the 931G nvme0n1:
# NAME        SIZE MODEL             TRAN
# nvme0n1   931.5G Samsung SSD 980   nvme
# sdb        28.9G SanDisk Ultra     usb

# macOS: identify the disk (look for the matching size, e.g. disk4)
diskutil list

Steps 5–8: Write the image

5. Unmount the target device's partitions — but do not physically remove it. Rationale: a mounted partition is “busy,” and dd either fails or writes around it. On Linux use umount /dev/sdb*; on macOS use diskutil unmountDisk /dev/disk4.
6. Choose your flashing tool. Rationale: all three produce a byte-identical result, so pick by comfort. GUI users should use Etcher or Raspberry Pi Imager; command-line users can use dd. There is no quality difference — only a difference in how many ways you can shoot yourself in the foot.
7. Point the tool at the image and the target device. Rationale: this is where a wrong selection becomes a catastrophe, so read the target name twice. In Etcher: select the .img.gz, select the drive, and confirm the drive size matches your stick, not your system disk. For dd, stream the decompressed image straight to the device node:

# Linux: decompress and write in a single pipe.
# Replace /dev/sdX with the node you confirmed in step 4.
zcat batocera-x86_64-43.1-20260530.img.gz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync
sync

# macOS: use the raw disk node (rdiskN) for speed, press Ctrl-T for progress.
# gunzip -k batocera-x86_64-43.1-20260530.img.gz
# sudo dd if=batocera-x86_64-43.1-20260530.img of=/dev/rdisk4 bs=4m

8. Start the write and wait. Rationale: this is the actual copy, and on typical media it takes several minutes for a 3 GB image. Interrupting it produces an unbootable half-image. Let it finish.

Steps 9–12: Verify, eject, boot

9. Let the tool verify the write. Rationale: cheap media develops silent write errors, and Etcher's automatic verification pass re-reads the card and compares it to the source. If you used dd, the conv=fsync flag forces the data to disk, but a manual re-read is still worth it on suspect cards.
10. Run sync and safely eject. Rationale: operating systems cache writes, so “100%” in the tool is not the same as “flushed to the card.” The sync command and a proper eject guarantee the buffers are empty before you pull the media.
11. Move the media to the target machine and set it as the boot device. Rationale: Batocera boots from removable media, and the target's firmware will not choose it automatically unless told. Enter the BIOS/UEFI boot menu (commonly F12, F11, Esc, or Del at power-on) and select the USB or SD device. On some UEFI systems you must also disable Secure Boot.
12. Boot, and let first-run expand the data partition. Rationale: on first boot Batocera automatically grows its data partition to fill the remaining space on the card. The first boot is therefore slower than every subsequent one; this is expected, not a hang.

Twelve steps, one image, one console. Keep them in order and the one destructive step — targeting the disk — never arrives before you have made every disk you care about impossible to select by accident.

First Boot & the SHARE Partition

The image is written; now the console wakes up. Understanding what happens on that first boot — and the partition layout it reveals — is what separates a user who can maintain Batocera from one who reflashes it every time something goes sideways.

What happens on first boot

Power on with the media inserted and, assuming the firmware boot order is correct, Batocera loads directly into EmulationStation, its front-end. The very first boot does two things it will never do again: it expands the data partition to fill the card, and it generates initial configuration. Expect a longer load and possibly one automatic reboot. Once EmulationStation appears — a horizontal carousel of system logos, most of them empty because you have added no games yet — the operating system is fully live and running entirely from your USB stick or SD card. Nothing was written to the target machine's internal drive. Pull the media, and the machine is exactly as it was.

The two-partition layout that matters

This is the architectural fact that makes Batocera maintainable. A 2026 guide describes the split cleanly: Batocera boots entirely from USB or SD, and updates normally touch only the read-only boot partition, while your ROMs, BIOS files, saves, and batocera.conf live on a separate SHARE partition. In other words, the operating system and your data are physically divided. The boot partition is the disposable, replaceable half; the SHARE partition is the half you actually care about.

The practical payoff is enormous. Because the OS is read-only and self-contained, an update can replace it wholesale without endangering a single save file. And because your data lives on SHARE, you can — in principle — blow away and reflash the boot partition while leaving your library untouched. It is the same design logic that lets a device like the Analogue 3D take firmware updates without wiping your save states: separate the mutable from the immutable, and updates stop being scary.

Configuring controllers and language

On first boot, connect a controller. Batocera detects most USB and Bluetooth pads automatically; if the mapping prompt does not appear, hold any button for a few seconds to trigger configuration, then follow the on-screen input walk-through. Press START to open the main menu, where language, screen resolution, network, and Bluetooth all live. Set your language, join Wi-Fi if you are not on Ethernet, and set the display resolution to match your screen. These settings are written to the SHARE partition, which means they survive every future update — you configure them once.

Adding ROMs, BIOS & Config

A console with no cartridges is a paperweight with good taste. Batocera ships empty by design, so populating the SHARE partition is the step that turns the download into a functioning machine. There are two ways in, one folder structure that matters, and one legal reality nobody escapes.

Network share versus direct transfer

The easiest way to move files is over the network. Once Batocera is on your LAN, it advertises itself as a network share reachable at the hostname batocera. From Windows, open \\BATOCERA in Explorer; from macOS or Linux, connect to smb://batocera/. You will see the share folder with its roms and bios subfolders, and you can drag files straight in over Wi-Fi or Ethernet. The alternative is to power the machine down, move the SD card or USB stick back to your host, and copy files onto the SHARE partition directly — faster for bulk transfers, but it means physically shuttling the media.

The folder structure that matters

Batocera sorts games by putting them in the right per-system folder. Drop a SNES ROM into snes, a Genesis ROM into megadrive, a PlayStation image into psx, and EmulationStation matches each folder to a system and a default emulator. The layout on the SHARE partition, mounted at /userdata when the system is running, looks like this:

/userdata            <- the SHARE partition, mounted here at runtime
  |- roms/           <- one folder per system: snes/, megadrive/, psx/, n64/ ...
  |- bios/           <- firmware files, checked against a known-hash database
  |- saves/          <- save files and save states
  |- system/         <- batocera.conf and other configuration lives here
  |- screenshots/
  |- music/

After copying games, return to EmulationStation and either restart it or trigger a games-list refresh from the menu, and the new systems appear in the carousel. If a folder stays hidden, it usually means it is empty or the files inside are in a format that system's emulator does not accept.

BIOS: the legal gray zone

Some systems — PlayStation, Sega CD, various handhelds — require original BIOS firmware to run at all, and Batocera will not, and legally cannot, provide it. You place BIOS files in the bios folder, and Batocera includes a built-in checker (under the main menu) that verifies each file against a database of known-good hashes and tells you exactly which are missing or wrong. That checker is genuinely useful and worth running before you conclude an emulator is broken. The firmware itself is copyrighted, and the defensible source is the hardware you already own. The Machine will note, as ever, that a free operating system does not make its inputs free, and move on.

Updating Without Re-Downloading

Here is the reason this tutorial is not one you repeat monthly. Once Batocera is installed, you rarely re-download the full image, because the system updates itself in place. A 2026 comparison notes that Batocera refreshes “roughly every couple of months” — the 42 “Papilio” build landed 12 October 2025, 43.0 arrived 8 May 2026, and 43.1 followed on 30 May 2026 — and re-flashing on that cadence would be absurd. You don't have to.

The in-system update path

Batocera's official Updates & Downloads menu is reachable from EmulationStation by pressing START and navigating to Updates & Downloads. This is the path most users take, because it updates the system without re-downloading and re-flashing the full image by hand. Inside, the update option — START → Updates & Downloads → Start Update — fetches the latest build for your architecture and applies it to the read-only boot partition. Because your ROMs, saves, and configuration live on the separate SHARE partition, the update replaces the operating system underneath them without touching your data. You restart when it finishes and you are on the new version, library intact.

The SSH upgrade route

For the terminal-inclined, Batocera exposes the same capability over SSH. With SSH enabled (it is, by default, on most builds; the default credentials are user root, password linux), connect from another machine and run the built-in upgrade command:

# From another computer on the same network
ssh root@batocera
# default password: linux  (change it — see the advanced section)

# Check for and apply the latest build for this architecture:
batocera-upgrade

The batocera-upgrade command does over the wire what the menu does with a controller: it pulls the current build and stages it onto the boot partition. It is the honest way to script or automate updates, and it is how you distinguish a genuine in-place upgrade from the manual image download you did once at the start.

When to re-flash instead

In-place updates are the norm, but not universal. Re-flash from a fresh image when you are jumping many versions at once and want a clean baseline, when the boot partition itself is damaged, or when release notes for a major version explicitly recommend a clean install because of a partition-layout change. In those cases you download a new .img.gz, back up your SHARE partition first, and repeat the twelve-step flash. Because your data was always separate, restoring it afterward is a copy operation, not a reconstruction.

5 Common Pitfalls

The same handful of mistakes account for the overwhelming majority of failed Batocera setups. Recognizing them in advance is faster than diagnosing them afterward, so here are five, each with the fix.

Wrong disk, dead data

Pitfall 1: flashing to the wrong device. The single most expensive mistake is pointing dd or Etcher at your system drive instead of your USB stick. There is no undo. The fix is procedural, not technical: identify the target by size and transport type (the lsblk step above), unmount it, and read the target name aloud before you confirm. Etcher mitigates this by hiding system drives from its list; dd mitigates nothing and trusts you completely.

FAT32, exFAT, and the 4 GB wall

Pitfall 2: the file-size ceiling. If your SHARE partition or an external ROM drive is formatted FAT32, single files larger than 4 GB — large disc images, some compressed sets — will refuse to copy or will silently truncate. The fix is to store oversized ROMs on an exFAT-formatted drive, or to keep them on the native SHARE partition, which Batocera formats appropriately. This is a filesystem limitation, not a Batocera bug, and no amount of retrying changes physics.

Missing BIOS, blocked boot, and bad media

Pitfall 3: missing BIOS files. An emulator that launches to a black screen or an error is usually starving for firmware. Run the built-in BIOS checker, place the exact files it names into /userdata/bios, and relaunch. Pitfall 4: firmware that won't boot the media. If the target machine ignores your stick entirely, the boot order is wrong or Secure Boot is blocking it. Enter the UEFI setup, move USB/removable media above the internal drive, and disable Secure Boot for x86_64 targets. Pitfall 5: counterfeit or dying media. Random corruption, saves that vanish, and boots that fail intermittently point at the card, not the software. Test the card's true capacity, and if it is fake or failing, replace it — you cannot software your way out of bad flash.

Troubleshooting Table

When something specific breaks, work symptom-first. The table below maps the failures Batocera users actually hit to their likeliest cause and the fix that resolves it. Start at the symptom that matches yours and stop reading when it works.

Advanced Tips

Once the console works, the difference between adequate and excellent is configuration. Batocera exposes far more than its menus suggest, and the following are the levers worth pulling.

Overclocking and performance tuning

On Raspberry Pi and many handhelds, Batocera includes tested overclock profiles in the System menu that push clock speeds beyond stock for demanding cores — Nintendo 64, PlayStation, Dreamcast — without hand-editing config files. Use them within reason and with adequate cooling; thermal throttling erases the benefit and a hot SoC ages faster. The same care applies to desktop GPUs if you are running Batocera on a PC and want to squeeze more out of higher-resolution rendering; the discipline is identical to any careful GPU overclock — small increments, stability testing, temperature ceilings. Batocera makes the emulation side easy; the physics of heat it leaves to you.

Decorations, shaders, and scraping

Three cosmetic-but-transformative features deserve attention. Bezel decorations fill the black bars on 4:3 content with artwork or fake-hardware overlays. Shaders emulate CRT scanlines and phosphor bloom — the difference between clinically sharp pixels and the softened image these games were designed against. And the scraper, reached from the main menu, downloads box art, metadata, and video snaps so your carousel looks like a storefront instead of a directory listing. The shader and core options draw on the same libretro machinery documented in the libretro documentation, so anything you learn there transfers directly.

SSH, read-only boot, and custom collections

Three power-user habits. First, change the default SSH password immediately — shipping root:linux on a networked device is an open door; set a new one from the security options or over SSH. Second, understand that the boot partition is read-only by design, so persistent changes belong on SHARE under /userdata/system; edits elsewhere evaporate on reboot, which is a feature, not a loss. Third, build custom collections — curated cross-system lists like “beaten,” “favorites,” or “couch co-op” — from the game options menu, so your library is organized by how you actually play rather than by silicon vintage. None of these are necessary to boot a game. All of them are why people who set Batocera up once rarely go back to anything else.

A Complete batocera.conf

Everything above converges on one file. The batocera.conf that lives at /userdata/system/batocera.conf is the single source of truth for system-wide and per-system behavior, and because it sits on the SHARE partition it survives every update. Below is a complete, annotated starting configuration you can adapt.

The annotated config

# /userdata/system/batocera.conf
# ---- global defaults (apply to every system unless overridden) ----
global.retroachievements=1
global.retroachievements.username=YOUR_NAME
global.retroachievements.password=YOUR_TOKEN
global.smooth=1              # bilinear smoothing on scaled output
global.shaderset=none        # set to a CRT preset for scanlines
global.rewind=1              # enable the rewind buffer
global.autosave=0            # off by default; enable per-system if wanted

# ---- system / network ----
system.hostname=batocera
wifi.enabled=0               # 1 to use Wi-Fi instead of Ethernet
audio.volume=90
audio.device=auto

# ---- per-system overrides ----
snes.core=snes9x
snes.ratio=4/3

n64.core=mupen64plus-next    # libretro N64 core; swap per game if needed
n64.ratio=4/3

psx.core=swanstation
psx.ratio=4/3

# ---- per-game override example ----
# Keys can target a single ROM by name:
# snes[Chrono Trigger (USA)].core=snes9x

Applying and reloading

Edit the file over the network share, over SSH, or by moving the card to your host. Batocera reads it at startup, so the safe way to apply changes is to save the file and restart EmulationStation (or reboot). Keys follow a strict system.option=value grammar; a typo in a key name is silently ignored rather than flagged, which is why the built-in menus — which write valid keys for you — are the safer route for anything you are unsure of. Treat hand-editing as surgery, not exploration.

Where to go next

With a verified image flashed, a populated SHARE partition, and a config that survives updates, you have a console that will outlast several of its games' original hardware. From here, the natural directions are curating your library, refining shaders to taste, and deciding whether Batocera stays your daily driver or shares a shelf with alternatives. If you are comparing distributions, it is worth reading how RetroPie has sat frozen at v4.8 while Batocera shipped three releases in a year — a release cadence that, more than any single feature, is the argument for choosing it. The download was never the hard part. Knowing what you downloaded was.