What a microfirmware is.
Spend five minutes here before you install anything. What you are building is not one program, and the half you will spend most of your time in is probably not the half you expect.
Your app has two halves
A microfirmware is two programs that ship as one thing. They are written in different languages and compiled by different compilers, and the processors they run on are about thirty years apart.
The C half, on the microcontroller
Ordinary C, compiled with the Raspberry Pi Pico C/C++ SDK , running on the Pico W's ARM processor. It has room to work: hundreds of kilobytes of code space, a filesystem on the microSD card, a network connection. Anything computational belongs here, and so does anything that needs memory or talks to the internet.
The 68000 half, on the Atari
A small program in 68000 assembly that the Atari executes directly. Here is the part people miss, and everything awkward about this half follows from it: your code runs in place, from the ROM cartridge address space that the board is pretending to be. It is never copied into memory first. The Atari is executing instructions straight out of the region the microcontroller is answering for.
Two consequences. It is tiny, six kilobytes, because that address space is fixed and shared. And it cannot use the Atari's normal RAM, so anything it needs to keep either lives in the address space it already has, or gets pushed across to the microcontroller. Its job is usually to collect input, ask the C half to do the work, then put the result on screen.
When you are deciding where a feature goes, the default answer is "the C half". Move work to the Atari side only when it has to happen on the Atari: drawing, reading the keyboard, responding to the machine itself.
The trick: the board pretends to be a cartridge
The Atari ST has a cartridge port that is, electrically, a direct extension of the machine's memory bus. Plug something in and the computer can read it as if it were a ROM chip. That is all the ST thinks is happening.
The SidecarTridge board is not a ROM chip. It is a microcontroller pretending to be one. When the Atari asks for the contents of an address, the Pico W notices the request and supplies a value fast enough that the machine never knows the difference. The whole Atari-side memory range is really the microcontroller answering questions.
The bus emulation is already built, and it is the most timing-sensitive code in the project. You inherit it from the template and you leave it alone. What matters to you is the consequence: a region of Atari address space is shared with the microcontroller, and that is how your two halves talk to each other.
If you want to know how the illusion works, the hardware interface documentation goes down to signal timing and the PIO state machine. It is interesting, and it is completely optional.
Booster runs your app
You are not writing a whole firmware image for the board. A bootloader called Booster owns the device, and the getting started guide walks a normal user through setting it up. It brings up Wi-Fi, serves a web interface, manages the microSD card, and installs and launches apps.
Your microfirmware is one of those apps, which is exactly why it is a microfirmware rather than a firmware. The board can hold up to thirty of them, and the user picks which one is active.
This has a consequence you need to know now, because it catches people out in step 6: Booster must already be installed on the board before your app can run. Step 4 covers that.
How it reaches other people
Booster fetches a catalogue of available apps over the network and shows them in its web interface. That catalogue is what this site publishes, the same list you can browse from the store with no device attached, and the same one documented as the apps catalogue upstream.
So the last step of this track is not "compile it". It is getting your microfirmware into that catalogue, so somebody else's board can find it. Step 10 walks through it.
If you are going to work with an AI assistant on this, and this guide assumes you will, give it this page's model up front, before it sees any code. Assistants that do not know about the two halves will happily suggest putting filesystem access in the 68000 code.
Step 8 gives you a full context block to paste. For now, just know that the split between halves is the thing it most needs to be told.