Crusty Studio is distributed as a download: a disk image or archive on macOS, an installer on Windows, and an AppImage or a package on Linux. Whichever you take, the app drives tools you install yourself — see Getting VASM and Getting NASM below, and After installing at the end.
Requirements: macOS 12.3 or later (Monterey or newer), on Apple silicon or Intel. Each architecture has its own download: arm64 for an M-series Mac and x86_64 for an Intel one. The Intel build also runs on an M-series Mac under Rosetta 2; the Apple silicon build cannot run on an Intel Mac.
| File | Use it when |
|---|---|
CrustyStudio_<version>_arm64.dmg |
You want the usual drag-to-Applications install, on an M-series Mac. |
CrustyStudio_<version>_arm64.zip |
You prefer a plain archive, or the disk image will not mount. |
CrustyStudio_<version>_x86_64.dmg |
You want the disk image on an Intel Mac. |
CrustyStudio_<version>_x86_64.zip |
You prefer the archive, or the disk image will not mount. |
SHA256SUMS.txt |
Verifying the download. |
Check the architecture before you install: About This Mac → Chip or Processor names it, and the download's file name carries the same word. Installing the wrong one is refused with a message that names the required architecture, which is clearer than a window that never opens.
.dmg. This mounts a small virtual disk that appears in Finder and under /Volumes, holding the app and a shortcut to your Applications folder.Ejecting is worth doing rather than leaving it mounted. While the image is mounted, macOS treats the copy inside it as a second installed application of the same name, so Spotlight, the Dock or a double-clicked project can open that one instead of the copy in Applications — and because the image is the version you downloaded, it can be an old one. Running the app straight from the image is worse still: it is read-only, and it stops working the moment you eject.
.zip to expand it.These builds are signed ad-hoc but not notarised, so macOS cannot check them against an Apple developer identity. A downloaded copy is marked as quarantined and macOS refuses the first launch with a warning about an unidentified developer or a damaged app. That is expected, and there are two ways past it:
Right-click the app in Applications and choose Open, then Open again in the dialog. This is the quick path, and macOS remembers the choice afterwards.
Or clear the quarantine attribute in Terminal:
xattr -dr com.apple.quarantine /Applications/CrustyStudio.app
The second command is the reliable one: on recent macOS versions the warning for a non-notarised app often reads "is damaged and can't be opened", which the right-click route does not fix.
shasum -a 256 -c SHA256SUMS.txt
Run it in the folder holding the downloaded files. The release also publishes
build-info.json, which records the commit the download was built from; the same
commit appears in the app's status bar.
Quit Crusty Studio before you replace it — press ⌘Q, and check the Dock for a window you have forgotten about. macOS keeps a running application in memory and does not swap the program underneath it, so if the old copy is still open, clicking the icon in Applications simply brings that old process forward and the window keeps showing the old interface. Replacing the app on disk while it runs looks like the update did nothing, which is confusing enough to be worth saying twice.
If a launch still looks wrong:
ps -ax | grep crusty-studio # the full path of what is actually running
The release build is about 12.8 MB in Finder and its status bar ends with the
version and commit. A copy of 34 MB or more is a debug build from a source tree
(src-tauri/target/debug/), which no download will ever replace — delete it, or
rebuild it, rather than wondering why the download changed nothing.
If two copies are installed, macOS may also open the wrong one when you double-click a project file. Remove the one you do not want and re-register the survivor:
rm -rf /Applications/CrustyStudio\ 2.app
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f /Applications/CrustyStudio.app
Requirements: 64-bit Windows 10 (April 2018 or later) or Windows 11. The app is a WebView2 host, and the runtime it needs is part of those Windows versions; the installer downloads and installs it when it is missing.
| File | Use it when |
|---|---|
CrustyStudio_<version>_x64-setup.exe |
The installer. Run it, then launch Crusty Studio from the Start menu. |
SHA256SUMS.txt |
Verifying the download. |
The installer is not signed with a code-signing certificate, so SmartScreen interrupts the first run with a warning that the publisher is unknown. That is expected:
This is the Windows counterpart of the macOS warning above, and it goes away the same way: when the release is signed with a code-signing certificate.
Get-FileHash .\CrustyStudio_<version>_x64-setup.exe -Algorithm SHA256
Compare the hash it prints against that file's line in SHA256SUMS.txt. Windows
has no shasum, so the algorithm is named explicitly and the file name is the
one you actually downloaded.
Requirements: a 64-bit (x86_64) distribution. The AppImage carries the
WebKitGTK stack it needs, so it runs without installing anything; the .deb
asks apt to install WebKitGTK and GTK instead.
| File | Use it when |
|---|---|
CrustyStudio_<version>_x86_64.AppImage |
No installation at all: make it executable and run it. |
CrustyStudio_<version>_x86_64.deb |
Debian, Ubuntu and their derivatives. |
SHA256SUMS.txt |
Verifying the download. |
chmod +x CrustyStudio-<version>_x86_64.AppImage
./CrustyStudio-<version>_x86_64.AppImage
The AppImage is the large of the two downloads, around 76 MB, because it carries the WebKitGTK stack inside it. That is what lets it run without installing anything.
If the system has no FUSE — some containers and servers do not — run it unpacked instead:
./CrustyStudio-<version>_x86_64.AppImage --appimage-extract-and-run
The AppImage carries that WebKitGTK so it runs on a machine that has none, but it prefers the machine's own copy when there is one and it is at least as new as the bundled one. The reason is the graphics driver: the bundled stack was built for the Mesa of the machine that cut the release, and on a host that has moved on from it WebKit cannot create an EGL display — the window opens empty, with no controls on it. The host's own WebKitGTK was built for the host's driver, so it is the copy that works.
The launcher can also be told which copy to use, for a host whose WebKitGTK version it cannot read:
| Setting | Effect |
|---|---|
CRUSTY_PREFER_SYSTEM_WEBKIT=1 |
Always run against the machine's WebKitGTK. |
CRUSTY_PREFER_SYSTEM_WEBKIT=0 |
Always run against the bundled WebKitGTK. |
CRUSTY_APPRUN_DEBUG=1 |
Report the choice on stderr. |
For example:
CRUSTY_APPRUN_DEBUG=1 ./CrustyStudio-<version>_x86_64.AppImage
sudo apt install ./CrustyStudio-<version>_x86_64.deb
apt, rather than dpkg -i: it resolves the two dependencies the package
declares, libwebkit2gtk-4.1-0 and libgtk-3-0. Remove it again with:
sudo apt remove crusty-studio
Installing the .deb also puts CrustyStudio in the application menu, so after
this route Super → "Crusty" finds it and there is nothing else to set up.
The AppImage is a single file, so it can be launched from anywhere, but the convenient places to put a shortcut are not all equal.
Use a launcher, not a symlink on the Desktop. A .desktop file gives you
the application menu, a Dock pin and correct window grouping; a bare symlink in
~/Desktop gives you only a clickable file, and the GNOME desktop-icons
extension renders and launches symlinks inconsistently — it may show a generic
icon, or refuse to run at all. ~/.local/share/applications/ is what the menu
and the Dock read.
If you build from source, scripts/build-linux-app.sh does this for you. It
builds the bundles and leaves release/CrustyStudio.AppImage as a symlink to
the current versioned AppImage, so a shortcut can point at one name that
survives every version bump, and --desktop writes the menu entry:
scripts/build-linux-app.sh --desktop
npm run build:desktop and npm run build:linux are the same build without the
menu entry. Point your shortcut at release/CrustyStudio.AppImage, never at a
versioned file name — that is the name that changes with every release.
Then: Super, type "CrustyStudio", right-click the result, Pin to Dash. To
see the file without writing it — to put it on the Desktop yourself, say — use
scripts/build-linux-app.sh --print-desktop.
One thing the script checks for you: an AppImage usually mounts itself through FUSE, and where there is no FUSE it has to run unpacked instead. The entry it writes accounts for that, so a shortcut made in a container still launches.
sha256sum -c SHA256SUMS.txt
Run it in the folder holding the downloaded files, as with macOS above.
crustyBASIC compiles your program and hands the assembly to VASM, which turns it into the file the emulator runs. Crusty Studio drives both and bundles neither, so VASM has to be on your machine before the first build.
VASM is one source tree that builds a separate executable per CPU, and crustyBASIC asks for a specific one by name. The 6502 build covers the Commodore, Atari, Apple II, NES and other 6502 families; the Z80 build covers the Spectrum, ZX81, Amstrad CPC, MSX, ColecoVision, Game Boy and the rest of the Z80, 8080 and Game Boy families. Download the ones your targets need.
Download the 6502 build for your computer:
| Platform | File |
|---|---|
| macOS, Apple silicon and Intel | vasm6502_oldstyle_macos-universal |
| Windows 64-bit | vasm6502_oldstyle_windows-x64.exe |
| Linux x86-64, statically linked | vasm6502_oldstyle_linux-x86_64 |
On macOS, clear the quarantine flag if it refuses to run:
xattr -d com.apple.quarantine ~/Downloads/vasm6502_oldstyle_macos-universal
On Linux, make it runnable:
chmod +x vasm6502_oldstyle_linux-x86_64
The Z80 build, for the Z80, 8080 and Game Boy targets:
| Platform | File |
|---|---|
| macOS, Apple silicon and Intel | vasmz80_oldstyle_macos-universal |
| Windows 64-bit | vasmz80_oldstyle_windows-x64.exe |
| Linux x86-64, statically linked | vasmz80_oldstyle_linux-x86_64 |
The same two commands apply, to the file each platform downloaded: xattr -d com.apple.quarantine ~/Downloads/vasmz80_oldstyle_macos-universal on macOS, or chmod +x vasmz80_oldstyle_linux-x86_64 on Linux.
The 6809 build, for the Color Computer targets:
| Platform | File |
|---|---|
| macOS, Apple silicon and Intel | vasm6809_oldstyle_macos-universal |
| Linux x86-64, statically linked | vasm6809_oldstyle_linux-x86_64 |
There is no Windows download for this one. The author publishes no Win64 archive for the 6809 build, and this site only redistributes the Windows archives he publishes, so the 6809 build is macOS and Linux here. On Windows, build it from the source archive with the command at the end of this section.
The 68000 build, for the Amiga and the Atari ST, is vasmm68k_mot. It is the Motorola-syntax module rather than one of the oldstyle CPU builds, so there is no published binary for it here and it is built from the source archive; the studio looks for it in the same VASM folder as the others, and a target picks it by name.
These are VASM 2.0f, copyright © 2002–2026 Volker Barthelmann, redistributed with his permission: each binary is compiled from the unmodified official source, with the manual and the source archive included. The macOS and Linux builds are simply make CPU=6502 SYNTAX=oldstyle, make CPU=z80 SYNTAX=oldstyle and make CPU=6809 SYNTAX=oldstyle; the Windows ones are the archives the author publishes. README.txt records what each file is, the source archive's SHA-256, and the exact commands used, and LICENSE is the author's own. The manual is also online as HTML, and the author's pages carry the release binaries: sun.hasenbraten.de/vasm and compilers.de/vasm.html.
Building it yourself still works, and is the way to get a build for a platform or CPU not listed above — including the 6809 build on Windows and the 68000 build everywhere. Change 6502 to z80 for the Z80 families or 6809 for the Color Computer, and use CPU=m68k SYNTAX=mot for the Amiga and the Atari ST:
curl -fLO http://sun.hasenbraten.de/vasm/release/vasm.tar.gz
tar -xzf vasm.tar.gz
cd vasm
make CPU=6502 SYNTAX=oldstyle
make CPU=m68k SYNTAX=mot # the Amiga and Atari ST build, vasmm68k_mot
That needs make and a C compiler: run xcode-select --install on macOS, sudo apt install build-essential on Debian and Ubuntu, or use MSYS2 or Cygwin on Windows.
Put the executables together in one folder and point the VASM folder setting at that folder — anywhere you like, including tools/assemblers/vasm/<platform>/ inside the crustyBASIC folder, whose folder names are windows-x86_64, linux-x86_64, macos-aarch64 and macos-x86_64 (the macOS download serves both of those last two). A target picks its own CPU build out of what is in the folder, so the downloads can sit side by side with no renaming: the names they arrive with carry the platform they were built for — vasm6502_oldstyle_linux-x86_64, vasm6502_oldstyle_macos-universal, vasm6502_oldstyle_windows-x64.exe — and Crusty Studio resolves those as readily as the bare vasm6502_oldstyle, vasmz80_oldstyle, vasm6809_oldstyle and vasmm68k_mot that the author's own builds and the copies bundled inside a crustyBASIC release use. An unpacked VASM release with a folder per platform works too, because the search looks a few folders deep. The Color Computer is the only 6809 target, and the Amiga and the Atari ST are the only 68000 ones, so a 6502 and Z80 setup does not need either build until you build for coco, amiga or atarist.
To confirm the version yourself, run it with no arguments: the first line begins vasm 2., and the current release reads vasm 2.0f. An older assembler is refused, because crustyBASIC emits assembly that needs a recent one.
VASM covers the 6502, 68k and Z80 families, but crustyBASIC's x86 targets — dos16, h120, pcjr, tandy1000, linux64 and win64 — hand their assembly to NASM instead. Crusty Studio drives whichever assembler the selected target names, so NASM is only needed if you build for one of those systems.
The NASM downloads page has the source and the official builds. Many systems package it too:
| Platform | Install |
|---|---|
| macOS, Homebrew | brew install nasm |
| Debian and Ubuntu | sudo apt install nasm |
| Windows | The nasm-<version>-installer-x64.exe from the downloads page. |
Put the executable where crustyBASIC looks, in tools/assemblers/nasm/<platform>/ inside the crustyBASIC folder, using the same platform folder names as VASM above: windows-x86_64, linux-x86_64, macos-aarch64 and macos-x86_64. The file is named nasm (nasm.exe on Windows).
Run nasm -v to confirm the build: the first line reads NASM version 2.16.01 compiled on …. Crusty Studio expects the 2.x line. If it is not found automatically, point NASM assembler in Tools → Settings → Toolchain at the executable.
Crusty Studio is an editor and build front end. It does not bundle crustyBASIC, VASM, NASM, emulators, ROMs, or the demo projects:
On macOS, Gatekeeper can quarantine a downloaded compiler helper as well. The tool check reports the exact file and prints the command that clears it.
The demo projects are a separate download from the same release, so you can open them in the app without installing anything else.