Step 4: Install Booster (Atari ST)

Step 4 · Atari ST

Install Booster.

Booster is the bootloader that owns the board and runs microfirmwares. Until it is flashed, nothing on the device knows how to load your app, so this has to happen before your first build rather than after it. The upstream getting started guide covers this same setup for ordinary users, in more detail than here.

What Booster actually does for you

It is easy to read "bootloader" and assume it is a formality. It is not. Booster provides most of the infrastructure your microfirmware would otherwise have to implement itself:

Wi-Fi and networking, so your app does not have to bring up a network stack.
A web interface for managing the device from a browser on your phone or laptop.
microSD access, with installed apps living in an /apps folder.
App management: downloading, installing, updating and launching microfirmwares, including yours.
Over-the-air updates of itself.

It also means your app does not own the whole device. It is one of several that can be installed, and the user chooses which is active.

Flash it onto the Pico W

Get the current release from the rp2-booster-bootloader repository or from the SidecarTridge downloads page . There are three ways to install it, all documented upstream. Use whichever you find easiest, they do the same thing.

Browser installer

The route the upstream documentation recommends, and the one to try first. A browser-based installer flashes the board over USB with no tools installed at all. Follow option 1 in the getting started guide .

It needs a browser with WebUSB support. If yours refuses, fall back to one of the other two routes.

Drag and drop

Hold the BOOTSEL button on the Pico W while you connect it over USB. It appears as a mass-storage device called RPI-RP2. Drag the full image onto it:

file to copy

rp-booster-<version>-full.uf2

The Pico W reboots by itself once the copy finishes. No tools required beyond a file manager. This is option 2 upstream , and Raspberry Pi's Pico-series documentation explains what BOOTSEL mode is doing.

picotool

If you already installed picotool in step 3, use it. It is faster and it verifies what it wrote:

Terminal

picotool load -xv /path/to/rp-booster-<version>.uf2

This is option 3 upstream , and the same command shape you will use for your own builds in step 6, so getting comfortable with it now pays off.

Two different files.

The drag-and-drop route uses the -full image. Match the route to the file. Grabbing the wrong one is the most common stumble here.

Bring it up

Put the Pico W on the board, the board in the Atari's cartridge port, and power on. Booster starts, and you configure Wi-Fi and reach its web interface from a browser. The initial factory configuration section walks through it, including a headless option that reads Wi-Fi credentials from a file on the card. Day-to-day use of the web interface is covered in the user guide , and every setting is listed in parameters .

On the Atari side you will see a terminal-driven selector. Two keys are worth remembering straight away:

Press ESC to enter the app selector.
Hold either SHIFT key while booting to skip it and boot straight from GEMDOS.

That second one is your escape hatch. If you later flash a microfirmware that hangs the machine, holding SHIFT gets you back to a usable computer. If the board does not come up at all, work through troubleshooting before assuming it is broken.

Install something from the catalogue before you write anything.

Pick any app from Booster's list and install it. It proves the board, the microSD card, Wi-Fi and the catalogue connection all work. When your own app misbehaves in step 6, you will already know the platform underneath it is fine.

Where your app will live

Worth knowing now, because it explains some limits you will meet later. The Pico W's flash is 2 MB, and Booster divides it up:

Region	Size	What it holds
Active app	1152 KB	The microfirmware currently running, which will be yours once you flash it.
Per-app settings	4 KB each	Each installed app gets its own isolated configuration sector.
Global settings	4 KB	Booster's own configuration.
Lookup table	4 KB	Maps app UUIDs to their settings sectors. Lives at `0x101FE000`.

Up to thirty apps can be installed at once. The 1152 KB figure is the one to remember. It is a lot of room for C code, and it is why the C half is where your logic belongs.

Choose a catalogue channel

Booster downloads its list of installable apps from a catalogue on the network. As of v2.3.0 that catalogue is served by this site, and the Config page is the single place that chooses which one:

Config page option	What it fetches
`Stable - Tested release (default)`	`md-store.sidecartridge.com/atari-st/apps.json`
`Testing - unstable releases`	`.../apps-test.json`
`Development - Local development only`	`.../apps-dev.json`
`Custom apps catalog URL`	Anything you type. Never rewritten by an upgrade.

The Stable and Beta chips on the Apps page are a filter over whatever the Config page selected. They used to switch catalogue and quietly rewrite the saved setting, and as of v2.3.0 they no longer do.

For this guide you want Development, and the next section explains why it is a requirement rather than a preference.

Upgrading from an older Booster.

Devices already on one of the standard channels are moved to the new store automatically. If you had set a custom catalogue URL, it is left exactly as it was.

Turn on developer mode

Development is not optional for this track.

Everything you build from step 6 onward uses the development UUID, 44444444-4444-4444-8444-444444444444. That UUID is the DEV APP slot, and it only exists on the Development channel. On Stable or Testing there is nothing for your build to land in.

So set the channel now and leave it there for the whole of the rest of this guide. You switch away at the end, in step 10, once your app has a real UUID of its own.

Open Config and set the catalogue to Development - Local development only.
Go to Apps and install the DEV APP from that catalogue. This is the slot your builds get pushed into.
Stay on the Development channel. Changing catalogue or deleting the DEV APP closes the gate immediately.

A red DEVELOPMENT MODE banner appears when it is active. That banner is how you know the deploy API in step 6 will answer.

The deploy API has no authentication.

Anyone who can reach your device on the network can push code to it and run that code on the attached Atari. That is why it is off by default, why it needs two deliberate actions to enable, and why it shuts off the moment you change catalogue or delete the DEV APP.

Use it on a network you trust. Turn it off when you are done developing. The full contract is in DEPLOY-API.md .