Update All MiSTer: one script for cores, firmware and ROMs

A wrapper that expands the MiSTer Downloader

Update All MiSTer is described as an all-in-one script for keeping up to date with the MiSTer ecosystem. The README explains the relationship precisely: this script runs the MiSTer Downloader under the hood, and expands it by selecting additional downloader databases.

That inheritance is the key architectural fact. The tool is not a reimplementation of downloading and installing files on an FPGA board; it drives an existing, official downloader and changes which databases that downloader is pointed at. The official MiSTer Downloader is what actually moves files onto the SD card, and Update All is the layer that decides what the board ends up containing.

The practical result is that one script covers a set of things that otherwise need separate tools: the main distribution with cores and firmware, unofficial cores from community collections, tools and scripts such as the Arcade Organizer, and extra content such as ROMs, BIOS files and wallpapers.

The repository layout backs this up. There is an `update_all.sh` entry point at the top level, a `src/` directory holding the Python source, a `setups/` directory containing the setup scripts referenced by the settings screen, a `docs/` directory with per-feature documentation such as `docs/arcade_organizer.md`, a `latest.id` file, and `CHANGELOG.md` and `DEVELOPMENT.md` files for users and contributors respectively.

The Settings screen decides which databases are used

Configuration happens on the device, not in a file you edit on a PC. Update All has a Settings Screen, and the README says it appears if you press UP on your controller or keyboard during the countdown that shows right after starting `update_all.sh` on the MiSTer. It also warns you to select SAVE to keep the changes you make before leaving.

The menu groups the choices into a fixed set of categories. Main Distribution downloads the essential files including cores and firmware, and lets you pick between distribution variants. JTCORES for MiSTer covers cores made by the Jotego Team and is on by default, with an option to additionally enable patreon-only cores. Other Cores lists curated databases of unofficial cores, including the Coin-Op Collection, which is enabled by default and can optionally pull in beta cores or both alpha and beta cores, plus Arcade Offset and the LLAPI Forks Folder, which are disabled by default. Other Tools and Scripts adds the Arcade Organizer, which creates a folder structure under `_Arcade/_Organized` for easier navigation of MRA files, and a complete names.txt file for better core names in the menus. Extra Content covers ROMs, BIOS files and wallpapers. Analogue Pocket provides tools for connecting a MiSTer to an Analogue Pocket, and the Patron Menu offers exclusive contents for Patreon community members.

The defaults are chosen conservatively in some places and generously in others, so reading the list before you press UP is worth the minute it takes.

Four distribution variants, including a pinned Linux image

The Main Distribution choice is where the real decisions live, because the four options are not interchangeable.

The default is the MiSTer-devel Distribution, a republication of the official MiSTer Distribution that is identical except for Linux, which is held at a stable release. The second option is the MiSTer-devel (Edge Linux) Distribution, the official distribution in the MiSTer-devel organization with the newest Linux image. The third is the DB9 Fork MiSTer Distribution, which adds Extended Native Controller Compatibility for Genesis and NeoGeo/Supergun controllers and requires an SNAC8 compatible adapter. The fourth is the Aitor Gomez fork, which the README describes as the same as the official MiSTer Distribution but including his custom firmware.

The reasoning behind the default is worth understanding, because it is the kind of detail that bites later. A MiSTer runs its user interface on a Linux image, and the newest image can change behaviour in ways that break other things. Holding Linux at a stable release while still updating cores and firmware is a conservative choice, and the Edge Linux option is there for people who specifically want the newest image and accept the churn.

The DB9 fork exists for a physical reason. Extended Native Controller Compatibility for those controller families needs the SNAC8 adapter, so choosing that distribution on a board without the adapter buys nothing.

Installing it means one file in the Scripts folder

The installation is unusually simple, and the reason is that the tool updates itself.

You download the ZIP file from the releases page, extract `update_all.sh`, and place it in the `/Scripts` folder on your primary SD card, creating that folder if it does not exist. The README states that you only need to perform this operation once, since the tool self-updates. Then you turn on the MiSTer, go to the Scripts menu, and run the script from there.

What you should expect on the first run is time. The README says it will take around 15 minutes the first time you run it, and that later runs should take much less. That first run is when the databases are fetched and the files are written, so the long duration is expected rather than a symptom of something wrong.

There is no package manager, no dependency tree to resolve and no Python environment to prepare. The script is self-contained on the SD card, and the SD card is where MiSTer software conventionally lives, which is why the `/Scripts` folder is the natural home for it.

One detail from the README worth carrying into a decision: the tool writes into the `downloader.ini` file at the root of the SD card every time you change something in the Settings screen. That file is shared with the official downloader, and it is the bridge between your choices and what actually gets fetched.

The downloader.ini route and the remote code question

There is a second installation route, and the README prefers it. The alternative method installs the same files, and the README notes that it is a bit safer.

The mechanism is to edit the `downloader.ini` file at the root of the SD card, creating it if it does not exist, and add these lines:

[update_all_mister]
db_url = https://raw.githubusercontent.com/theypsilon/Update_All_MiSTer/db/update_all_db.json

With that entry in place, you turn on the MiSTer, go to the Scripts menu, and run `update` or `downloader`, which the README says are both equivalent. Update All and the other files are installed, and you then go back to the Scripts menu and run it.

The reason for the preference is the third route, which is about trust rather than convenience. The README includes a section titled how to avoid executing remote code altogether, and explains that if you are concerned about executing a build that the launcher fetches from the web, you can install the Downloader build manually first, then follow the alternative installation. If that manual step is skipped, the launcher installs the Update All and Downloader builds automatically during its first run, and that auto-installation occurs only once.

That is a design decision with real consequences. On a device that is permanently connected to the internet and physically attached to a television, a self-updating script that fetches and runs code is a meaningful trust decision, and the documentation at least lets you make it deliberately.

The PC launcher covers the offline case

Not every MiSTer owner can or wants to put the board online. The README points to the MiSTer Downloader's PC Launcher for downloading all MiSTer files on your PC, and describes it as useful if you cannot connect your MiSTer to the internet.

The bridge between the two is the same `downloader.ini` file. The README states that to install the same files that you get with Update All, you use the same `downloader.ini` file that you have on your MiSTer at the root of the SD card, and reminds you that Update All writes into that file every time you change something in the Settings screen.

So the workflow is: configure on the device or copy a configuration across, then run the downloader from a PC, then move the SD card. The settings you chose in Update All travel as configuration rather than as a second tool.

This path also sidesteps the self-update question entirely, since the PC side is not fetching and executing a build on the device. For someone who keeps the MiSTer on a USB stick and swaps it between machines, the file based approach is more practical than a device that expects to reach the network.

GPL-3.0, frequent releases, and a project with a following

The licence field on the repository says GPL-3.0, which is the right licence for a script of this kind: anyone redistributing a modified copy has to keep it open, and anyone running it as-is is unaffected by that obligation.

The release history shows a very active project. The tagged releases are named after the moment they were built, with UpdateAll_2026-10-09_21.17.33 dated 2026-10-09, UpdateAll_2026-10-05_21.19.42 on 2026-10-05 and UpdateAll_2026-10-04_17.09.39 on 2026-10-04, and the last push was on 2026-10-20. These are timestamped snapshots rather than semantic versions, which suits a tool that updates itself and that tracks a changing set of upstream databases.

Two repository files support the maintenance story. The `CHANGELOG.md` gives you the history of what changed, and `DEVELOPMENT.md` is there for contributors. There are also two small scripts, `dont_download.sh` and `dont_download2.sh`, whose names suggest exclusion lists for content you do not want fetched, though the README excerpt does not describe them in detail.

One more piece of the structure points at how the project runs. There is a `db/` branch referenced by the `db_url` in the ini file, which holds the database definitions separately from the code, so the set of databases can change without a new release of the script itself.

Editorial conclusion

Adopt Update All MiSTer if you own a MiSTer and want cores, firmware and curated extras kept current from one place, and you are comfortable with a script that downloads and runs other builds. Skip it if you want a minimal, locally controlled setup, because the documentation itself describes the way to avoid executing remotely fetched code. Verify first that the distribution you pick on the Settings screen matches your hardware, in particular whether the default pinned Linux image suits you, and that the `downloader.ini` entry has been written correctly before running `update` from the Scripts menu. The licence field on the repository says GPL-3.0, and the last push was on 2026-10-20.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. theypsilon/Update_All_MiSTer on GitHub