Microfirmware Store

Give it a real UUID

Everything so far used the shared development UUID. That has to change before anything leaves your desk. Two published apps with the same UUID fight over the same settings sector, and the catalogue cannot tell them apart.

Generate a UUIDv4 and keep it. It identifies this app for the rest of its life.

uuidgen
# or, if you would rather not care which tools are installed:
python3 -c "import uuid; print(uuid.uuid4())"

[guid]::NewGuid().ToString()

Make a release build

./build.sh pico_w release <YOUR UUID4 HERE>

Note both changes from step 6: release instead of debug, and your own UUID instead of the development one. You get the same three files in dist/, now named after your UUID:

• <uuid>-<version>.uf2, the firmware people download and install.
• <uuid>.json, your app's descriptor, filled in and ready to publish.
• rp.uf2.md5sum, the checksum, already copied into the descriptor.

Flash this build and test it once more. A release build is not identical to a debug build, and "it worked in debug" has surprised people before.

Describe your app in desc/app.json

That <uuid>.json in dist/ is not written by hand. It is generated from desc/app.json in your repository, and if you have not edited that file yet then what you just built still describes itself as the template.

The template ships two files in its desc/ folder . app.json.template is the blank form. app.json is the working copy that build.sh actually reads, and the one you edit.

The binary URL is templated too

The built firmware is named <uuid>-<version>.uf2, so the URL that points at it has to carry the version. Write the placeholders and let the build fill them, and the URL stays correct across every release without you touching it:

{
  "uuid": "<APP_UUID>",
  "name": "My Microfirmware",
  "description": "What it does, in one sentence.",
  "image": "https://example.com/my-app-256.png",
  "tags": [
    "Utility"
  ],
  "devices": [
    "ST",
    "STE",
    "MegaST",
    "MegaSTE"
  ],
  "binary": "https://example.com/downloads/<APP_UUID>-<APP_VERSION>.uf2",
  "md5": "<BINARY_MD5_HASH>",
  "version": "<APP_VERSION>"
}

Bump version.txt, rebuild, and both the filename and the URL follow.

From one descriptor to a catalogue

Your apps.json is a list of descriptors under an apps key. One app, one entry, exactly as build.sh produced it:

{
  "apps": [
    { ... the contents of dist/<uuid>.json ... }
  ]
}

Publish more than one app and they sit side by side in that array. The store adds the creator attribution when it folds your listing into the public catalogue, so leave that out of your own file.

Host it

Publishing is two separate things, and keeping them apart in your head helps:

1. You host your own files. The .uf2 and an apps.json listing it live somewhere you control: a GitHub release, a web host, anywhere reachable. You keep ownership of your own listing, and you update it without asking anyone.
2. This store points at them. One pull request adds your origin to the registry, and from then on a build job folds whatever is at your URL into the catalogue every device downloads. That is step 11.

Two rules on the hosting itself. Keep the URL stable and update the file in place, because the registry stores that URL and nothing else. And while the apps.json URL may be HTTP or HTTPS, the image and binary URLs inside it must be HTTPS, since a visitor's browser loads those directly.

Pick a channel to publish to

Both this store and Booster have three channels, and since Booster v2.3.0 they are the same three files on this site. What you publish here is what the Config page on somebody's device fetches.

The loop closes

Since v2.3.0, Booster fetches its catalogue from https://md-store.sidecartridge.com/atari-st/apps.json. That is not a copy of this site or a mirror of it. It is this site, the same file behind the listing you can browse right now, built from the registry your pull request edits.

So the thing you publish is the thing the device downloads. Somebody with a SidecarTridge , an Atari ST and no idea who you are opens Booster, sees your app in the list, installs it.