v0.8.7

PiST — an IDE for Atari ST assembly development.

What's new in 0.8.7

macOS: open the disk image and drag PiST onto the Applications folder. The
previous image also showed the ROM folder and a build-info file, and macOS
refused to launch the app — PiST is damaged and can't be opened. You should
move it to the Bin — because the bundle had been changed after it was signed.

Fixed

• The macOS disk image is a drag-install. It contains PiST and a shortcut
  to Applications. The ROM, the assembler, the linker and the notices are
  inside the app, so dragging it across is the whole install. The .tar.gz is
  that same app.
• The macOS app is signed after the bundle is finished. Deploying Qt
  rewrites the binaries, and the assembler was copied in afterwards, which
  left a signature that did not match the app. That is the failure macOS
  reports as damaged.

Opening a downloaded copy may still ask for approval under System Settings ▸
Privacy & Security. The signature lets the system see an intact app;
notarization, which would skip that prompt, needs an Apple Developer ID and
this release does not have one.

Worth knowing

An AppImage does not add itself to your application menu, and cannot: that
integration is done by AppImageLauncher or appimaged. If you want a menu
entry, install the .deb or the .rpm — that is what they are for, and both
carry the entry, the icons and the metadata a software centre reads.

Every archive contains PiST, the vasmm68k_mot assembler, the vlink linker,
and an EmuTOS ROM. The Linux AppImage and the Windows archive additionally
contain the Hatari emulator, so on Linux and Windows they run and debug with
nothing else installed.

Assembler and linker: vasm and vlink are not free software. They are
redistributed unmodified and for non-commercial use, which their licences
permit; see share/doc/pist/NOTICE. PiST never patches them.

ROM: EmuTOS 1.4 (GPLv2), a free TOS replacement. Original Atari TOS images
are copyrighted and are not included — supply your own in Project Settings if
you need one.

Emulator: the Linux AppImage and the Windows archive bundle the hrdb-main
fork of Hatari (upstream 2.6.1 plus the remote-debug listener PiST's HRDB
transport uses), built unmodified from a checksum-pinned commit tarball (PiST
never patches it and runs it as a separate process). The binary is conveyed
under GPL version 2: three of the files Hatari compiles in grant version 2
alone, so the "or later" on the rest cannot lift the combined work — which is
also why the GPLv3 GNU Readline is not linked into it and travels in no
archive. The Windows build is the same fork compiled with MSYS2 ucrt64, with
its runtime DLLs beside the exe. The macOS archive does not include an
emulator: install one with brew install hatari (2.6.1 bottled), or point PiST
at one in Project Settings. Use 2.5 or later — 2.4.1 returns truncated debugger
responses that break source-line debugging, and Ubuntu 24.04 ships exactly
that, so a distribution package is often not recent enough. See
share/doc/pist/NOTICE for the full licence details.

Linux

Nothing else to install: assemble, run and debug straight away.

The AppImage — PiST-<version>-x86_64.AppImage — is self-contained: Qt, the
assembler, the linker, the emulator and the ROM are all inside it. The shell
glob below is deliberate: these notes are published verbatim as the release
body, and a literal file name here drifted from the artifact a release actually
shipped once already.

chmod +x PiST-*-x86_64.AppImage
./PiST-*-x86_64.AppImage your-program.s

.deb and .rpm packages carry the same content for those who prefer the
package manager. They are also the route that integrates with the desktop: a
menu entry, the icons and the AppStream metadata a software centre reads the
name, author and licence from. Everything they bundle lives in a private
/usr/lib/pist/, with only pist and pist-mcp linked into /usr/bin, so
none of it can be picked up by other applications — and the bundled Hatari,
vasm and vlink cannot shadow a user's own. An AppImage does not add itself to
the application menu and cannot; that integration is AppImageLauncher's or
appimaged's job, or install a package.

Everything is built on Ubuntu 22.04, so it needs glibc 2.35 or newer (Ubuntu
22.04+, Debian 12+, Fedora 36+, and anything more recent).

Windows and macOS

Windows: the .zip or the .msi — both include the emulator, and both carry
the Visual C++ runtime beside the executable, so no redistributable install is
needed. macOS: open the .dmg and drag PiST to Applications, or unpack the
.tar.gz. Either one still needs brew install hatari.

What works

Write, assemble, run and debug: source-line and conditional breakpoints,
stepping, step-over, registers, a memory viewer, and labelled disassembly, with
the editor following the program counter. Multi-file projects assemble
separately and link with the bundled vlink (add sources in Project Settings).
Projects keep their settings — include paths, defines, target CPU, machine,
ROM, RAM and disk images — in a small JSON file beside the source.

Known limitations

• CI exercises the emulator integration on Linux and macOS (both build the
  pinned Hatari 2.6.1 and the hrdb-main fork from source and run the emulator
  suites against both transports). Windows builds and unit-tests only: the
  official Windows Hatari is a GUI-subsystem binary whose debugger never
  answers over pipes, so the bundled Windows emulator — the same fork, built
  with MSYS2 ucrt64 — is experimental; reports from real Windows machines
  are particularly welcome.
• A user-installed stock Hatari on Windows still cannot pause, change
  breakpoints while running, or swap disks at runtime — Hatari compiles its
  control channel only on POSIX systems. The bundled fork is unaffected (HRDB
  is TCP), and breakpoints and stepping work regardless. See docs/FUTURE.md
  for the upstream fix that would close this for stock Hatari.
• The interface is functional rather than polished.

Run pist --diagnose to see which assembler, linker, emulator and ROMs PiST
can find, and the paths it searched.

Full Changelog: v0.8.6...v0.8.7

v0.8.6

PiST — an IDE for Atari ST assembly development.

What's new in 0.8.6

Windows: the emulator's display can now run inside the IDE, and a clean Windows
install can run PiST at all — the previous archive and MSI were missing the
Visual C++ runtime and installed no Start Menu entry.

Added

• The emulator's display embeds on Windows. View ▸ Embed emulator display
  now works there as well as on Linux/X11: PiST finds the emulator's window and
  moves it into the Emulator panel, letterboxed to the video's aspect, and keeps
  it fitted across resolution changes and dock moves. Hatari's own reparenting
  handshake is compiled in only for X11, so on Windows PiST performs the
  reparenting itself; should the window never be adoptable, the emulator keeps
  its separate window and the panel says so instead of showing black. Each
  outcome is one [embed] line in the Build & debug console.
• The Visual C++ runtime ships with the Windows archive and the MSI.
  windeployqt deploys Qt but not the runtime Qt was compiled against, so on a
  machine without the redistributable installed PiST stopped at
  MSVCP140.dll was not found. The runtime family now travels beside the
  executable; there is nothing extra to install.
• The MSI creates a Start Menu entry — Start Menu ▸ PiST ▸ PiST — where
  before it installed every file and nothing that launches them.

Fixed

• The Settings dialog fits the screen it opens on. Its layout demanded
  611 px of height whatever size was asked for, so on a scaled laptop display
  the OK and Cancel buttons fell below the window's bottom edge, and every
  relayout — changing the machine, switching tabs — moved the window. The pages
  scroll now, the dialog is exactly the size it requests, clamped to the
  screen's available geometry, and the buttons are always reachable.
• An empty Emulator panel explains itself rather than presenting a black
  rectangle that reads as a broken emulator.

Worth knowing

An AppImage does not add itself to your application menu, and cannot: that
integration is done by AppImageLauncher or appimaged. If you want a menu
entry, install the .deb or the .rpm — that is what they are for, and both
carry the entry, the icons and the metadata a software centre reads.

Every archive contains PiST, the vasmm68k_mot assembler, the vlink linker,
and an EmuTOS ROM. The Linux AppImage and the Windows archive additionally
contain the Hatari emulator, so on Linux and Windows they run and debug with
nothing else installed.

Assembler and linker: vasm and vlink are not free software. They are
redistributed unmodified and for non-commercial use, which their licences
permit; see share/doc/pist/NOTICE. PiST never patches them.

ROM: EmuTOS 1.4 (GPLv2), a free TOS replacement. Original Atari TOS images
are copyrighted and are not included — supply your own in Project Settings if
you need one.

Emulator: the Linux AppImage and the Windows archive bundle the hrdb-main
fork of Hatari (upstream 2.6.1 plus the remote-debug listener PiST's HRDB
transport uses), built unmodified from a checksum-pinned commit tarball (PiST
never patches it and runs it as a separate process). The binary is conveyed
under GPL version 2: three of the files Hatari compiles in grant version 2
alone, so the "or later" on the rest cannot lift the combined work — which is
also why the GPLv3 GNU Readline is not linked into it and travels in no
archive. The Windows build is the same fork compiled with MSYS2 ucrt64, with
its runtime DLLs beside the exe. The macOS archive does not include an
emulator: install one with brew install hatari (2.6.1 bottled), or point PiST
at one in Project Settings. Use 2.5 or later — 2.4.1 returns truncated debugger
responses that break source-line debugging, and Ubuntu 24.04 ships exactly
that, so a distribution package is often not recent enough. See
share/doc/pist/NOTICE for the full licence details.

Linux

Nothing else to install: assemble, run and debug straight away.

The AppImage — PiST-<version>-x86_64.AppImage — is self-contained: Qt, the
assembler, the linker, the emulator and the ROM are all inside it. The shell
glob below is deliberate: these notes are published verbatim as the release
body, and a literal file name here drifted from the artifact a release actually
shipped once already.

chmod +x PiST-*-x86_64.AppImage
./PiST-*-x86_64.AppImage your-program.s

.deb and .rpm packages carry the same content for those who prefer the
package manager. They are also the route that integrates with the desktop: a
menu entry, the icons and the AppStream metadata a software centre reads the
name, author and licence from. Everything they bundle lives in a private
/usr/lib/pist/, with only pist and pist-mcp linked into /usr/bin, so
none of it can be picked up by other applications — and the bundled Hatari,
vasm and vlink cannot shadow a user's own. An AppImage does not add itself to
the application menu and cannot; that integration is AppImageLauncher's or
appimaged's job, or install a package.

Everything is built on Ubuntu 22.04, so it needs glibc 2.35 or newer (Ubuntu
22.04+, Debian 12+, Fedora 36+, and anything more recent).

Windows and macOS

Windows: the .zip or the .msi — both include the emulator, and both carry
the Visual C++ runtime beside the executable, so no redistributable install is
needed. macOS: the .dmg or the .tar.gz, plus brew install hatari.

What works

Write, assemble, run and debug: source-line and conditional breakpoints,
stepping, step-over, registers, a memory viewer, and labelled disassembly, with
the editor following the program counter. Multi-file projects assemble
separately and link with the bundled vlink (add sources in Project Settings).
Projects keep their settings — include paths, defines, target CPU, machine,
ROM, RAM and disk images — in a small JSON file beside the source.

Known limitations

• CI exercises the emulator integration on Linux and macOS (both build the
  pinned Hatari 2.6.1 and the hrdb-main fork from source and run the emulator
  suites against both transports). Windows builds and unit-tests only: the
  official Windows Hatari is a GUI-subsystem binary whose debugger never
  answers over pipes, so the bundled Windows emulator — the same fork, built
  with MSYS2 ucrt64 — is experimental; reports from real Windows machines
  are particularly welcome.
• A user-installed stock Hatari on Windows still cannot pause, change
  breakpoints while running, or swap disks at runtime — Hatari compiles its
  control channel only on POSIX systems. The bundled fork is unaffected (HRDB
  is TCP), and breakpoints and stepping work regardless. See docs/FUTURE.md
  for the upstream fix that would close this for stock Hatari.
• The interface is functional rather than polished.

Run pist --diagnose to see which assembler, linker, emulator and ROMs PiST
can find, and the paths it searched.

Full Changelog: v0.8.5...v0.8.6

v0.8.5

PiST — an IDE for Atari ST assembly development.

What's new in 0.8.5

A correction to 0.8.4's packaging. The packages installed and ran, but a
software centre still could not show what they were — and if you are on 0.8.3
or earlier, the older problems below still apply to you.

If you are on 0.8.3: its .deb aborted dpkg -i with trying to overwrite
/usr/share/doc/libglib2.0-0/copyright, which is also in package
libglib2.0-0, and both of its packages installed their Qt, glib and D-Bus into
/usr/lib, where ldconfig — which scans that directory before the multiarch
one — would have handed them to every other application on the machine. Update.

Fixed

• Software centres show PiST's icon, name and author. The metainfo file 0.8.4
  added carried no <icon> element, and a component without one has no icon at
  all: Ubuntu's App Center listed the installed package with a blank space
  beside its name. It now declares the themed icon —
  <icon type="stock">pist</icon>, exactly what appstream-generator records
  from a desktop entry's Icon key — and the <categories> that mirror the
  entry's own. The categories also matter mechanically: appstreamcli validate
  only checks for them once a component qualifies as store-visible, i.e. once it
  has an icon, so the file validated clean while carrying neither.
• A stale menu icon after installing is expected once, not a defect. The
  icon-theme cache and the desktop database are rebuilt by dpkg triggers that run
  after the install returns, and a shell session that looked the icon up in
  that window keeps the miss cached. If an entry or its icon looks wrong right
  after an install, log out and back in (or restart the shell) before reporting
  it.

Worth knowing

An AppImage does not add itself to your application menu, and cannot: that
integration is done by AppImageLauncher or appimaged. If you want a menu
entry, install the .deb or the .rpm — that is what they are for, and both
carry the entry, the icons and the metadata a software centre reads.

Every archive contains PiST, the vasmm68k_mot assembler, the vlink linker,
and an EmuTOS ROM. The Linux AppImage and the Windows archive additionally
contain the Hatari emulator, so on Linux and Windows they run and debug with
nothing else installed.

Assembler and linker: vasm and vlink are not free software. They are
redistributed unmodified and for non-commercial use, which their licences
permit; see share/doc/pist/NOTICE. PiST never patches them.

ROM: EmuTOS 1.4 (GPLv2), a free TOS replacement. Original Atari TOS images
are copyrighted and are not included — supply your own in Project Settings if
you need one.

Emulator: the Linux AppImage and the Windows archive bundle the hrdb-main
fork of Hatari (upstream 2.6.1 plus the remote-debug listener PiST's HRDB
transport uses), built unmodified from a checksum-pinned commit tarball (PiST
never patches it and runs it as a separate process). The binary is conveyed
under GPL version 2: three of the files Hatari compiles in grant version 2
alone, so the "or later" on the rest cannot lift the combined work — which is
also why the GPLv3 GNU Readline is not linked into it and travels in no
archive. The Windows build is the same fork compiled with MSYS2 ucrt64, with
its runtime DLLs beside the exe. The macOS archive does not include an
emulator: install one with brew install hatari (2.6.1 bottled), or point PiST
at one in Project Settings. Use 2.5 or later — 2.4.1 returns truncated debugger
responses that break source-line debugging, and Ubuntu 24.04 ships exactly
that, so a distribution package is often not recent enough. See
share/doc/pist/NOTICE for the full licence details.

Linux

Nothing else to install: assemble, run and debug straight away.

The AppImage — PiST-<version>-x86_64.AppImage — is self-contained: Qt, the
assembler, the linker, the emulator and the ROM are all inside it. The shell
glob below is deliberate: these notes are published verbatim as the release
body, and a literal file name here drifted from the artifact a release actually
shipped once already.

chmod +x PiST-*-x86_64.AppImage
./PiST-*-x86_64.AppImage your-program.s

.deb and .rpm packages carry the same content for those who prefer the
package manager. They are also the route that integrates with the desktop: a
menu entry, the icons and the AppStream metadata a software centre reads the
name, author and licence from. Everything they bundle lives in a private
/usr/lib/pist/, with only pist and pist-mcp linked into /usr/bin, so
none of it can be picked up by other applications — and the bundled Hatari,
vasm and vlink cannot shadow a user's own. An AppImage does not add itself to
the application menu and cannot; that integration is AppImageLauncher's or
appimaged's job, or install a package.

Everything is built on Ubuntu 22.04, so it needs glibc 2.35 or newer (Ubuntu
22.04+, Debian 12+, Fedora 36+, and anything more recent).

Windows and macOS

Windows: the .zip or the .msi — both include the emulator. macOS: the
.dmg or the .tar.gz, plus brew install hatari.

What works

Write, assemble, run and debug: source-line and conditional breakpoints,
stepping, step-over, registers, a memory viewer, and labelled disassembly, with
the editor following the program counter. Multi-file projects assemble
separately and link with the bundled vlink (add sources in Project Settings).
Projects keep their settings — include paths, defines, target CPU, machine,
ROM, RAM and disk images — in a small JSON file beside the source.

Known limitations

• CI exercises the emulator integration on Linux and macOS (both build the
  pinned Hatari 2.6.1 and the hrdb-main fork from source and run the emulator
  suites against both transports). Windows builds and unit-tests only: the
  official Windows Hatari is a GUI-subsystem binary whose debugger never
  answers over pipes, so the bundled Windows emulator — the same fork, built
  with MSYS2 ucrt64 — is experimental; reports from real Windows machines
  are particularly welcome.
• A user-installed stock Hatari on Windows still cannot pause, change
  breakpoints while running, or swap disks at runtime — Hatari compiles its
  control channel only on POSIX systems. The bundled fork is unaffected (HRDB
  is TCP), and breakpoints and stepping work regardless. See docs/FUTURE.md
  for the upstream fix that would close this for stock Hatari.
• The interface is functional rather than polished.

Run pist --diagnose to see which assembler, linker, emulator and ROMs PiST
can find, and the paths it searched.

Full Changelog: v0.8.4...v0.8.5

v0.8.4

PiST — an IDE for Atari ST assembly development.

What's new in 0.8.4

A packaging release. The IDE itself is unchanged apart from how it presents
itself to the desktop; what changed is that the packages a release publishes are
now correct — and the 0.8.3 deb, it turns out, could not be installed at all.

If you downloaded the 0.8.3 .deb, it was broken: dpkg -i aborted with
trying to overwrite /usr/share/doc/libglib2.0-0/copyright, which is also in
package libglib2.0-0. Use this one. The 0.8.3 AppImage runs fine; only the
packages were affected.

Fixed

• The deb installs. It was staged straight from the AppImage's AppDir, so it
  carried the build host's copyright file for every library the bundle links —
  libglib2.0-0, libpulse0, libxcb-* and fifty more — into paths dpkg knows
  belong to packages already installed, and dpkg will not take a file away from
  another package. Those texts now live under
  /usr/share/doc/pist/licenses/distro/, where they still travel with the
  binaries they cover, and the AppImage plumbing that was being installed into
  / (AppRun, .DirIcon, apprun-hooks/) stays out of the package. The
  release workflow now installs the deb on the runner and removes it again, which
  is the check that would have caught this.
• The packages no longer hand their libraries to the rest of the system. The
  bundle's Qt, glib, D-Bus and X libraries were installed into /usr/lib, which
  ldconfig scans before the multiarch directory — so the package made itself
  the system-wide provider of libQt6Core.so.6 and friends, for every other
  application on the machine. Everything now lives in the private prefix
  /usr/lib/pist/, with only pist and pist-mcp linked into /usr/bin, so
  the bundled Hatari, vasm and vlink cannot shadow your own either.
• The name, author and licence a software centre shows. PiST shipped no
  AppStream metadata at all, so GNOME Software and Discover reported the deb's
  file name and "Unknown Author", with no licence anywhere. PiST, Koala
  Software and GPL-2.0-or-later now come from a metainfo file, a DEP-5
  /usr/share/doc/pist/copyright, and the installer licence resource — which was
  still CMake's generic placeholder, so the MSI and self-extracting installers
  quoted no licence either. The RPM's vendor was the literal string unknown.
• Asset and package naming. Every artifact is now
  PiST-<version>-<platform>. The tag's v was being interpolated verbatim,
  which is how the deb came to be called pist-v0.8.3-linux-amd64.deb — and how
  a software centre came to show it as "pist-v0". The AppImage carries its
  version too (PiST-0.8.4-x86_64.AppImage rather than PiST-x86_64.AppImage),
  and the icons are installed at 128, 256 and 512 px instead of leaving the
  hicolor directories the deployer creates empty. The Debian and RPM package
  names stay lowercase pist, as both require.
• The deb's description was mangled. It was assembled from several quoted
  arguments, which CMake joins into a list, so the control file carried a literal
  "; " at the head of every line after the first.
• On Wayland the window now belongs to its menu entry. The app states its
  desktop-file name, which is what Wayland uses as the app_id; it was being
  derived from the application name and matched nothing, so the taskbar icon did
  not group with the launcher. It is stated only where an entry is actually
  installed — claiming one that does not exist makes the desktop portal fail to
  register the app ID on every start — and the entry itself now declares
  StartupWMClass=pist, which is what X11 was already reporting.
• The macOS bundle had an empty CFBundleIdentifier, and presented itself as
  "pist" rather than "PiST" in Finder and the menu bar.

Worth knowing

An AppImage does not add itself to your application menu, and cannot: that
integration is done by AppImageLauncher or appimaged. If you want a menu entry,
install the .deb or the .rpm — that is what they are for, and both now carry
the entry, the icons and the metadata a software centre reads.

Every archive contains PiST, the vasmm68k_mot assembler, the vlink linker,
and an EmuTOS ROM. The Linux AppImage and the Windows archive additionally
contain the Hatari emulator, so on Linux and Windows they run and debug with
nothing else installed.

Assembler and linker: vasm and vlink are not free software. They are
redistributed unmodified and for non-commercial use, which their licences
permit; see share/doc/pist/NOTICE. PiST never patches them.

ROM: EmuTOS 1.4 (GPLv2), a free TOS replacement. Original Atari TOS images
are copyrighted and are not included — supply your own in Project Settings if
you need one.

Emulator: the Linux AppImage and the Windows archive bundle the hrdb-main
fork of Hatari (upstream 2.6.1 plus the remote-debug listener PiST's HRDB
transport uses), built unmodified from a checksum-pinned commit tarball (PiST
never patches it and runs it as a separate process). The binary is conveyed
under GPL version 2: three of the files Hatari compiles in grant version 2
alone, so the "or later" on the rest cannot lift the combined work — which is
also why the GPLv3 GNU Readline is not linked into it and travels in no
archive. The Windows build is the same fork compiled with MSYS2 ucrt64, with
its runtime DLLs beside the exe. The macOS archive does not include an
emulator: install one with brew install hatari (2.6.1 bottled), or point PiST
at one in Project Settings. Use 2.5 or later — 2.4.1 returns truncated debugger
responses that break source-line debugging, and Ubuntu 24.04 ships exactly
that, so a distribution package is often not recent enough. See
share/doc/pist/NOTICE for the full licence details.

Linux

Nothing else to install: assemble, run and debug straight away.

The AppImage — PiST-<version>-x86_64.AppImage — is self-contained: Qt, the
assembler, the linker, the emulator and the ROM are all inside it. The shell
glob below is deliberate: these notes are published verbatim as the release
body, and a literal file name here drifted from the artifact a release actually
shipped once already.

chmod +x PiST-*-x86_64.AppImage
./PiST-*-x86_64.AppImage your-program.s

.deb and .rpm packages carry the same content for those who prefer the
package manager. They are also the route that integrates with the desktop: a
menu entry, the icons and the AppStream metadata a software centre reads the
name, author and licence from. Everything they bundle lives in a private
/usr/lib/pist/, with only pist and pist-mcp linked into /usr/bin, so
none of it can be picked up by other applications — and the bundled Hatari,
vasm and vlink cannot shadow a user's own. An AppImage does not add itself to
the application menu and cannot; that integration is AppImageLauncher's or
appimaged's job, or install a package.

Everything is built on Ubuntu 22.04, so it needs glibc 2.35 or newer (Ubuntu
22.04+, Debian 12+, Fedora 36+, and anything more recent).

Windows and macOS

Windows: the .zip or the .msi — both include the emulator. macOS: the
.dmg or the .tar.gz, plus brew install hatari.

What works

Write, assemble, run and debug: source-line and conditional breakpoints,
stepping, step-over, registers, a memory viewer, and labelled disassembly, with
the editor following the program counter. Multi-file projects assemble
separately and link with the bundled vlink (add sources in Project Settings).
Projects keep their settings — include paths, defines, target CPU, machine,
ROM, RAM and disk images — in a small JSON file beside the source.

Known limitations

• CI exercises the emulator integration on Linux and macOS (both build the
  pinned Hatari 2.6.1 and the hrdb-main fork from source and run the emulator
  suites against both transports). Windows builds and unit-tests only: the
  official Windows Hatari is a GUI-subsystem binary whose debugger never
  answers over pipes, so the bundled Windows emulator — the same fork, built
  with MSYS2 ucrt64 — is experimental; reports from real Windows machines
  are particularly welcome.
• A user-installed stock Hatari on Windows still cannot pause, change
  breakpoints while running, or swap disks at runtime — Hatari compiles its
  control channel only on POSIX systems. The bundled fork is unaffected (HRDB
  is TCP), and breakpoints and stepping work regardless. See docs/FUTURE.md
  for the upstream fix that would close this for stock Hatari.
• The interface is functional rather than polished.

Run pist --diagnose to see which assembler, linker, emulator and ROMs PiST
can find, and the paths it searched.

Full Changelog: v0.8.3...v0.8.4

v0.8.3

PiST — an IDE for Atari ST assembly development.

What's new in 0.8.3

A correction release, published shortly after 0.8.2 and superseding it: CI found
two defects in what 0.8.2 shipped, both are fixed here, and the release workflow
now refuses to publish a commit CI has not passed, so a red build cannot reach
the releases page again. 0.8.2 keeps its own page and changelog — the large
maintenance release this one corrects.

If you downloaded 0.8.2, update: its archives carry the first bug below.

Fixed

• A failed save no longer destroys the file you were saving. Every path that
  replaces a file you already had — your source, the sprite document, an ST or
  bitplane export, a floppy image, the project — opened its destination with
  Truncate and checked the byte count afterwards, which reports the failure
  honestly and still leaves the file empty. On a full disk, a quota or an I/O
  error, that meant losing it. All of them now go through one rule: a temporary
  file in the same directory, an explicit flush and a device-error check, and
  only then the replace — so whatever was already there survives, and no
  half-written temporary is left beside it. (The files PiST generates for a
  session — the debugger's bootstrap script, the remote-control discovery file,
  the AUTO-folder image it boots pre-1.04 TOS with — are not user data and keep
  their plain write.)
  The project file had already moved to QSaveFile and was still vulnerable,
  because Qt 6.8.1's commit() — the Qt every archive bundles — does not notice
  the flush inside it failing: it renames the truncated temporary file over the
  destination and returns true. Qt 6.10 checks the device error there, which is
  why a development machine on a newer Qt never saw it. The rule checks the
  flush itself now and cancels the temporary file, so it holds on both.
• A timed-out debugger command's tail can no longer leak into the next
  command's response. When the transport gives up on a command after 10 s it
  swallows the prompt that command still owes it, and drains stderr first so the
  dead command's last output is not attributed to whatever runs next. That drain
  waited 20 ms — enough for a tail already sitting in the pipe, not for one a
  slower machine had not written yet, which is how it surfaced on macOS. The
  owed-prompt path now waits 200 ms, and nothing user-visible is held up by it:
  the command was reported failed ten seconds earlier. The completion path every
  step, continue and register read goes through keeps the short window.

Tests, packaging and docs

• The release workflow will not publish what CI has not passed. Tagging a
  commit whose CI run was red — or, as happened here, still in flight — used to
  publish anyway. A release now blocks until the CI workflow has finished that
  same commit successfully on all three platforms, and a tag on a commit that
  never reached master is refused outright rather than packaged untested.
• Three Windows-only test defects fixed. The fake git the discovery test plants
  recorded its working directory with a separator its own checker parses
  differently: cmd.exe needs ^| and was writing &, so every invocation looked
  like it ran outside the project. The gutter-repaint check asserted a glyph on a
  runner with no fonts installed at all, and now asserts the font-independent
  breakpoint dot there, skipping the glyph check with the reason named. And a
  Latin-1 file name in the floppy test was spelled as a raw 0xE9 byte inside
  QStringLiteral, whose meaning in that position is compiler-defined; it is now
  QString::fromLatin1, the same decode the product applies to the field.
• The generated third-party notices state the GPLv2 cap on the bundled emulator
  instead of upstream's "or later", and the install text names the AppImage a
  release actually ships (PiST-x86_64.AppImage).

Every archive contains PiST, the vasmm68k_mot assembler, the vlink linker,
and an EmuTOS ROM. The Linux AppImage and the Windows archive additionally
contain the Hatari emulator, so on Linux and Windows they run and debug with
nothing else installed.

Assembler and linker: vasm and vlink are not free software. They are
redistributed unmodified and for non-commercial use, which their licences
permit; see share/doc/pist/NOTICE. PiST never patches them.

ROM: EmuTOS 1.4 (GPLv2), a free TOS replacement. Original Atari TOS images
are copyrighted and are not included — supply your own in Project Settings if
you need one.

Emulator: the Linux AppImage and the Windows archive bundle the hrdb-main
fork of Hatari (upstream 2.6.1 plus the remote-debug listener PiST's HRDB
transport uses), built unmodified from a checksum-pinned commit tarball (PiST
never patches it and runs it as a separate process). The binary is conveyed
under GPL version 2: three of the files Hatari compiles in grant version 2
alone, so the "or later" on the rest cannot lift the combined work — which is
also why the GPLv3 GNU Readline is not linked into it and travels in no
archive. The Windows build is the same fork compiled with MSYS2 ucrt64, with
its runtime DLLs beside the exe. The macOS archive does not include an
emulator: install one with brew install hatari (2.6.1 bottled), or point PiST
at one in Project Settings. Use 2.5 or later — 2.4.1 returns truncated debugger
responses that break source-line debugging, and Ubuntu 24.04 ships exactly
that, so a distribution package is often not recent enough. See
share/doc/pist/NOTICE for the full licence details.

Linux

Nothing else to install: assemble, run and debug straight away.

PiST-x86_64.AppImage is self-contained — Qt, the assembler, the
linker, the emulator and the ROM are all inside it:

chmod +x PiST-x86_64.AppImage
./PiST-x86_64.AppImage your-program.s

.deb and .rpm packages carry the same content for those who prefer the
package manager. Everything is built on Ubuntu 22.04, so it needs glibc 2.35 or
newer (Ubuntu 22.04+, Debian 12+, Fedora 36+, and anything more recent).

Windows and macOS

Windows: the .zip or the .msi — both include the emulator. macOS: the
.dmg or the .tar.gz, plus brew install hatari.

What works

Write, assemble, run and debug: source-line and conditional breakpoints,
stepping, step-over, registers, a memory viewer, and labelled disassembly, with
the editor following the program counter. Multi-file projects assemble
separately and link with the bundled vlink (add sources in Project Settings).
Projects keep their settings — include paths, defines, target CPU, machine,
ROM, RAM and disk images — in a small JSON file beside the source.

Known limitations

• CI exercises the emulator integration on Linux and macOS (both build the
  pinned Hatari 2.6.1 and the hrdb-main fork from source and run the emulator
  suites against both transports). Windows builds and unit-tests only: the
  official Windows Hatari is a GUI-subsystem binary whose debugger never
  answers over pipes, so the bundled Windows emulator — the same fork, built
  with MSYS2 ucrt64 — is experimental; reports from real Windows machines
  are particularly welcome.
• A user-installed stock Hatari on Windows still cannot pause, change
  breakpoints while running, or swap disks at runtime — Hatari compiles its
  control channel only on POSIX systems. The bundled fork is unaffected (HRDB
  is TCP), and breakpoints and stepping work regardless. See docs/FUTURE.md
  for the upstream fix that would close this for stock Hatari.
• The interface is functional rather than polished.

Run pist --diagnose to see which assembler, linker, emulator and ROMs PiST
can find, and the paths it searched.

Full Changelog: v0.8.2...v0.8.3

v0.8.2

Superseded by v0.8.3 — update.
A failed save in this build can leave the file you were saving truncated to zero
bytes: every write path opened its destination with Truncate and only then
checked the byte count, so a full disk or a quota destroyed your source, sprite
document, export, floppy image or project. The project file's QSaveFile did not
cover it either — on the bundled Qt 6.8.1 a flush that fails inside commit()
still renames the truncated temporary file over the destination and reports
success. 0.8.3 routes every one of those saves through a staged, flushed,
error-checked replace.

PiST — an IDE for Atari ST assembly development.

What's new in 0.8.2

A maintenance release, and a big one: no new features, 149 files touched —
19,781 insertions against 5,060 deletions. A full code-quality review of the IDE
was run to ground and every finding it produced is fixed here — the correctness
bugs you could hit, the structure that let them happen, and the tidying that
makes the next change cheap.

Fixed

• Saving a source no longer rewrites it. The editor records the file's own
  line-ending style and encoding on load and writes them back: a CRLF file stays
  CRLF, a Latin-1 file stays Latin-1 (promoted to UTF-8 only if you type a
  character Latin-1 cannot hold), and a byte-order mark survives. Loading and
  saving an unedited file is byte-identical, so a source copied out of a floppy
  image stops changing shape on save. A save also creates missing parent
  directories, which is what extracting a file to a new folder needs.
• Git acts on the project you opened. The repository root is discovered with
  git rev-parse --show-toplevel from the project directory instead of being
  assumed to be PiST's own working directory — the stray index.lock that could
  turn up in a PiST checkout was that bug.
• A commit is the index, and PiST never rewrites it. The ticked rows are
  staged and the index is then committed with no pathspec, so a path already
  staged but left unchecked — or a conflicted path — is refused by name (include
  it, unstage it, or resolve it) rather than swept in or committed with its
  conflict markers still in it.
• A damaged floppy image fails instead of quietly truncating. A FAT12 cluster
  chain that loops back on itself, links to a cluster outside the image, or ends
  short of the size its directory entry declares is now reported. A short read
  used to be indistinguishable from a short file, so writing the image back
  carried the truncation into the replacement and renamed that over your own —
  destroying the orphaned clusters a repair would need. Listing a disk stays
  best-effort: a damaged folder is shown unexpanded rather than blanking the
  panel.
• The debugger can no longer answer a command with the previous command's
  output. On the native transport a timed-out command leaves a prompt owed;
  that prompt is now swallowed and its response tail drained before the next
  command goes out, and a fresh session starts from clean framing state instead
  of inheriting the last one's counters. On HRDB the queue is held while a reply
  is owed, so a reply that never arrives cannot shift every later answer by one.
  Both backends also point their stderr drain at the stderr channel — it was
  inspecting the always-empty stdout buffer and burning its full 20 ms timeout on
  every response, which was latency you could feel while stepping.
• Disassembly of a hex-looking mnemonic is whole again. dbcc, dbf and
  abcd were absorbed into the byte column of a disassembly line, so the pane
  rendered the instruction without its mnemonic and step-over had no mnemonic to
  read.
• Two same-named objects in a multi-file project no longer share one address.
  dir1/util.o and dir2/util.o were a single module to the line map, which put
  both at one address and could arm a breakpoint in the wrong file. An ambiguous
  base name now resolves nothing and says so in the build log, naming both paths.
• Find's hit counter admits its cap: past 2000 matches it reads
  "N of more than 2000" instead of counting on.
• info video reports only what Hatari printed — the hardware summary no
  longer invents a resolution or a palette the transcript never mentioned.

Project files

.pistproject is read strictly, and every refusal names the entry at fault:

• a wrong-typed entry fails the load ('build.includePaths' must be a list of strings) instead of silently becoming an empty -I on the assembler command
  line;
• relative include paths and additional sources resolve against the project
  file's own directory, so a project builds the same wherever PiST was started
  from;
• a file written by a newer PiST is refused rather than loaded and saved back
  with the fields this build does not understand dropped from it;
• saving goes through a temporary file renamed into place, so a failed write —
  full disk, crash, power cut — leaves the project you had instead of a truncated
  one that the next load reports as invalid.

The format version is still 1: project files from earlier releases load as
before.

Remote control

The localhost protocol changed shape, so a pist and a pist-mcp from different
releases refuse each other instead of half-working:

• PiST publishes a protocol version in its discovery file, and the shim checks it
  before dialling — a mismatch is refused naming both versions, rather than
  connecting and then failing verb by verb once an agent tries something the
  other half does not have;
• a block reply carries an explicit status line (ok, or error for a failed
  query) ahead of its body;
• a body line that begins with . is sent dot-stuffed with one extra ., so a
  body that legitimately contains a lone . cannot end the block early.

The vocabulary is now one table that drives help, the block framing and the
shim's tool list together, so the four places a verb used to be spelled cannot
disagree. A script written against 0.8.1 needs the small reader update shown in
the README's remote-control section.

Under the hood

• pist_core is split into module libraries — model, image, build, debug, emu,
  project, toolchain, git, editor, ui, control, mcp — with an acyclic dependency
  graph. Modules that need to cross a boundary speak through Host interfaces
  and ControlHost instead of reaching into a sibling.
• The logic came out of the widgets: debug session, session launch, profiler,
  bitplane export, sheet slicing, animation preview, the breakpoint/watchpoint
  model and floppy transfer are units of their own (MainWindow.cpp 4,737 →
  4,414 lines, ImageEditor.cpp 2,593 → 2,295).
• The editor's colours are an injected theme value rather than a global, so an
  editor can be exercised without a palette behind it.
• A tr() sweep brought 102 user-facing strings into translation, and the dead
  code found along the way went out.
• -Wall -Wextra (/W4 on MSVC) is now the build baseline and the tree is
  warning-free; CMake presets cover asan and ubsan builds.
• Every fix above landed with its regression test written against the failure
  first. All 15 suites are green, and the emulator framing cases run without an
  emulator present.

Licence

• The bundled Hatari is built without GNU Readline, and no archive ships it.
  Three of the files Hatari compiles into every binary grant GPL version 2 alone,
  so the emulator PiST conveys is capped at GPLv2 and a GPLv3 library cannot join
  it. Nothing is lost: without readline the debugger takes its fgets fallback
  and writes the prompt to stderr instead of stdout, and PiST frames a command on
  the > prompt on either stream. NOTICE and docs/PLAN.md §10 carry the
  audit of those three files and the include chains that reach them.

Every archive contains PiST, the vasmm68k_mot assembler, the vlink linker,
and an EmuTOS ROM. The Linux AppImage and the Windows archive additionally
contain the Hatari emulator, so on Linux and Windows they run and debug with
nothing else installed.

Assembler and linker: vasm and vlink are not free software. They are
redistributed unmodified and for non-commercial use, which their licences
permit; see share/doc/pist/NOTICE. PiST never patches them.

ROM: EmuTOS 1.4 (GPLv2), a free TOS replacement. Original Atari TOS images
are copyrighted and are not included — supply your own in Project Settings if
you need one.

Emulator: the Linux AppImage and the Windows archive bundle the hrdb-main
fork of Hatari (upstream 2.6.1 plus the remote-debug listener PiST's HRDB
transport uses), built unmodified from a checksum-pinned commit tarball (PiST
never patches it and runs it as a separate process). The binary is conveyed
under GPL version 2: three of the files Hatari compiles in grant version 2
alone, so the "or later" on the rest cannot lift the combined work — which is
also why the GPLv3 GNU Readline is not linked into it and travels in no
archive. The Windows build is the same fork compiled with MSYS2 ucrt64, with
its runtime DLLs beside the exe. The macOS archive does not include an
emulator: install one with `brew ins...

v0.8.1

PiST — an IDE for Atari ST assembly development.

What's new in 0.8.1

On Windows, Run finds the program you just built.

• The project folder is the hard drive. Hatari on Windows only recognises a path written with backslashes. PiST was handing it a Qt path (C:/proj/hello.prg), so the emulator mounted the wrong directory and TOS could not open the program. The project directory is now the GEMDOS drive, and the program starts from it.

Every archive contains PiST, the vasmm68k_mot assembler, the vlink linker,
and an EmuTOS ROM. The Linux AppImage and the Windows archive additionally
contain the Hatari emulator, so on Linux and Windows they run and debug with
nothing else installed.

Assembler and linker: vasm and vlink are not free software. They are
redistributed unmodified and for non-commercial use, which their licences
permit; see share/doc/pist/NOTICE. PiST never patches them.

ROM: EmuTOS 1.4 (GPLv2), a free TOS replacement. Original Atari TOS images
are copyrighted and are not included — supply your own in Project Settings if
you need one.

Emulator: the Linux AppImage and the Windows archive bundle the hrdb-main
fork of Hatari (upstream 2.6.1 plus the remote-debug listener PiST's HRDB
transport uses), GPL-2.0-or-later, built unmodified from a checksum-pinned
commit tarball (PiST never patches it and runs it as a separate process). The
Windows build is the same fork compiled with MSYS2 ucrt64, with its runtime
DLLs beside the exe. The macOS archive does not include an emulator:
install one with brew install hatari (2.6.1 bottled), or point PiST at one in
Project Settings. Use 2.5 or later — 2.4.1 returns truncated debugger responses
that break source-line debugging, and Ubuntu 24.04 ships exactly that, so a
distribution package is often not recent enough. See share/doc/pist/NOTICE
for the full licence details, including the GNU Readline that the bundled Linux
build links.

Linux

Nothing else to install: assemble, run and debug straight away.

pist-*-linux-x86_64.AppImage is self-contained — Qt, the assembler, the
linker, the emulator and the ROM are all inside it:

chmod +x pist-*-linux-x86_64.AppImage
./pist-*-linux-x86_64.AppImage your-program.s

.deb and .rpm packages carry the same content for those who prefer the
package manager. Everything is built on Ubuntu 22.04, so it needs glibc 2.35 or
newer (Ubuntu 22.04+, Debian 12+, Fedora 36+, and anything more recent).

Windows and macOS

Windows: the .zip or the .msi — both include the emulator. macOS: the
.dmg or the .tar.gz, plus brew install hatari.

What works

Write, assemble, run and debug: source-line and conditional breakpoints,
stepping, step-over, registers, a memory viewer, and labelled disassembly, with
the editor following the program counter. Multi-file projects assemble
separately and link with the bundled vlink (add sources in Project Settings).
Projects keep their settings — include paths, defines, target CPU, machine,
ROM, RAM and disk images — in a small JSON file beside the source.

Known limitations

• CI exercises the emulator integration on Linux and macOS (both build the
  pinned Hatari 2.6.1 and the hrdb-main fork from source and run the emulator
  suites against both transports). Windows builds and unit-tests only: the
  official Windows Hatari is a GUI-subsystem binary whose debugger never
  answers over pipes, so the bundled Windows emulator — the same fork, built
  with MSYS2 ucrt64 — is experimental; reports from real Windows machines
  are particularly welcome.
• A user-installed stock Hatari on Windows still cannot pause, change
  breakpoints while running, or swap disks at runtime — Hatari compiles its
  control channel only on POSIX systems. The bundled fork is unaffected (HRDB
  is TCP), and breakpoints and stepping work regardless. See docs/FUTURE.md
  for the upstream fix that would close this for stock Hatari.
• The interface is functional rather than polished.

Run pist --diagnose to see which assembler, linker, emulator and ROMs PiST
can find, and the paths it searched.

Full Changelog: v0.8.0...v0.8.1

v0.8.0

PiST — an IDE for Atari ST assembly development.

What's new in 0.8.0

Git lives in the IDE. You can see what changed, commit it, switch branch, and
look back — without leaving the file you were assembling.

• A Git panel, tabbed with Project files. Staged, changed and untracked
  files sit in a list; check the ones that belong in the next commit, write a
  message, and commit. Hooks run. Pull and Push are the ordinary commands, and
  git's own text is what you see when they fail.
• Switch and create branches under the commit message. The selector
  switches; New… asks for a name. A switch that would overwrite local edits is
  refused — git's error, not a discard prompt.
• A diff of the file you pick. Select a row and the patch appears under the
  list: staged rows show what is already in the index, other rows the worktree,
  untracked files as new. Deselect and the pane goes away.
• History. Newest first, up to 200 commits. Select one to see its message
  and patch in that same view.
• Blame in the gutter. View → Git blame puts the author beside the line
  numbers. A dirty line reads as uncommitted, and a click in that lane does not
  toggle a breakpoint.
• Sprite editor and profiler, packed. Onion-skin sits with the frame
  buttons, play sits above a 96-pixel preview that no longer grows when you
  hit play, and phase placement only appears in spritesheet mode. The layers
  list and the profiler icons no longer stretch to fill leftover space.

What's new in 0.7.2

The window spends its space on the work in front of you.

• A first run is for writing. Debug docks stay on the View menu until a session needs them. The editor takes the centre, project files sit on the left, and Problems and the console are a short strip along the bottom.
• Three layouts. View → Layout offers Editing, Debugging and Sprite, and Restore my layout puts back the arrangement they replaced. The first time a session stops, and the first time an image opens, the status bar offers the matching layout. The embed checkbox still owns the emulator dock.
• The View menu lists every dock, including a memory pane opened later, and Reset layout returns to that first-run arrangement.
• Status bar. Session (Not running / Running / Stopped, with the source line), a build result that stays put, and the caret. Hatari's capability probe moves to the session chip's tooltip.
• The instruction under the caret. A one-line strip under the editor names the mnemonic or the TOS call. Clicking it opens the reference. While stopped, flag chips and a one-line register strip sit under that; the full registers table is still there.
• Go to line is Ctrl+G. Return in the editor copies the indent of the line you just left.
• F8 toggles a breakpoint. The PiST keys are otherwise unchanged: F5 run, F9 continue, F10 step into, F11 step over. Settings → Appearance can switch to the common IDE scheme (F9 toggles a breakpoint, F10 steps over, F11 steps into, and F5 continues while stopped).
• Navigation opens the file. A problem, a breakpoint or a symbol in another source opens that file. A disassembly row opens its source line when the program map knows it, and does nothing when it does not. A PC-history address opens the source line, or memory.
• Problems mark warnings. Errors and warnings both carry a coloured square, and a warning tints the message amber.
• Hardware, in one line. The video subject leads with the screen address, refresh rate and overscan Hatari's info video actually prints, and each chip name has a tooltip.
• Build has its own menu. Build and the F4 diagnostic walk live there; Run is run, step and breakpoints. Set up tools and ROMs… is a button at the bottom of Project Settings.
• File → New File, with the image exports gathered under File → Export. An empty floppy is one line ("A: no disk"), and the project pane is titled with the directory. Export to a floppy image stays on the hard-drive's context menu.
• Sprite editor. Palette swatches are numbered, frames run in a filmstrip under the canvas, phases are a combo, and flip, rotate and shift live in a Transform menu.
• Appearance. The dialog shows a sample line in the editor face you picked, and the splitter handles are wide enough to grab. Comments, gutter numerals and zero bytes in the dark theme clear ordinary reading contrast.
• Profiler icons, redrawn so Start, Stop and To cursor read as one tool: a play mark over the sample count, the count on a baseline, and that count beside the caret.

What's new in 0.7.1

The OS-call reference completes its round trip, and the profiler becomes
usable:

• Insert a call's binding from the reference dock. Pick a GEMDOS, BIOS
  or XBIOS call and "Insert binding into editor" (button or right-click)
  drops its assembler binding in above the cursor — argument pushes with the
  parameter names as placeholders, the trap, and the exact stack cleanup.
  The odd shapes are right too: Pexec's fixed layout, Mshrink/Frename's
  reserved word, Dbmsg's literal 5.
• The profiler, discoverable at last. Its controls live in the profiler
  dock as icon buttons (they used to hide, greyed, in the Run menu), the
  empty dock teaches the flow, and every click — success or refusal — says
  what happened in the dock's own status line.
• Profile to cursor line. The whole ritual in one gesture: cursor where
  measuring should end, and PiST arms a one-shot there, collects, and shows
  the results when the run stops.
• Results worth reading. Hot spots as a routines tree (nearest label,
  hot lines underneath) in counts and cycles, with milliseconds and frames
  in the status line, a noise floor for the long tail, and the operating
  system's share as a TOS/ROM row instead of silently discarded.
• The profile actions follow the mode: Start is disabled while collecting,
  Stop when nothing collects, and every disabled button's tooltip says why.

What's new in 0.7.0

The instruction reference dock learned the operating system. It was always
good at telling you what addq.l does; now it tells you what your program
is doing:

• TOS system-call reference. Cursor on a trap #1, trap #13 or
  trap #14 line — or on any of the pushes feeding one — and the dock names
  the GEMDOS, BIOS or XBIOS call being made: 111 entries covering the whole
  TOS 1.x/2.x set, each with its C prototype, what d0 returns, the TOS
  version it needs, and the stack layout.
• It reads the idiom, not just the word. The dock resolves the function
  number from the push above the trap (move.w #9,-(sp), #$0b,
  #Cconws, clr.w) and shows what the call is being made with —
  "Calling with: #msg". A register-pushed number still shows the generic
  TRAP entry.
• Everything joins the one searchable list, CPU families first, so the
  filter covers instructions and calls alike.

The demo sources get a correction out of the bargain: function 7 is Crawcin,
not Cnecin as their comments claimed — exactly the mix-up this feature
exists to catch.

What's new in 0.6.3.2

The rest of the agent surface, in one point release:

• Tool annotations. Read-only tools declare readOnlyHint, and the ones
  that end or rewrite live state (pist_stop, pist_setreg, pist_setmem)
  declare destructiveHint — an MCP client can now ask your confirmation
  for exactly the right calls.
• MCP resources and prompts. pist://console, pist://state and
  pist://document as readable resources (pist://state subscribable, with
  updates pushed on every stop/resume), and two ready-made prompts:
  diagnose-build and find-hot-loop.
• The document surface, completed. pist_tabs lists every open document
  (path, modified, current) and pist_save saves the current one.
• Build failures answer with their diagnostics. A failed pist_build
  now includes the Problems pane in structuredContent — file, line,
  severity, message — instead of a bare error build failed.
• Also: 27 tools in total, the symbols verb restored to the README's
  protocol table, and the quit decision recorded (it stays off the tool
  list deliberately).

What's new in 0.6.3.1

A point release for one security-relevant fix: a connection refused by the
remote-control token check could have bytes it sent during the
(asynchronous) disconnect window executed without a token. The client now
stays refused until the socket is gone. Everything below from 0.6.3 is
unchanged.

What's new in 0.6.3

This release is about driving PiST from another program — an AI agent, a
script, or a test harness. The remote-control socket and the pist-mcp MCP
server grew a real feature set, and pist-mcp now ships in every
archive, including the Windows and macOS ones.

• 25 MCP tools. Beyond build/run/step: open and read back the document
  the IDE is showing (pist_open, pist_read), the Problems pane with
  severities (pist_problems), the build's symbols (pist_symbols), memory
  reads and disassembly (pist_readmem, pist_disasm), and the profiler
  (pist_profile_start / pist_profile_stop / pist_profile_results).
• Structured results. State, problems, symbols, memory, disassembly and
  profile results answer as JSON — in structuredContent as well as text —
  so an agent consumes fields instead of parsing console output.
• Breakpoints by label. pist_breakpoint accepts a symbol name and
  resolves it to the first code line at or after its definition (a label on
  its own line has no code to break on), replying with the file:line and
  address it ...

v0.7.2

PiST — an IDE for Atari ST assembly development.

What's new in 0.7.2

The window spends its space on the work in front of you.

• A first run is for writing. Debug docks stay on the View menu until a session needs them. The editor takes the centre, project files sit on the left, and Problems and the console are a short strip along the bottom.
• Three layouts. View → Layout offers Editing, Debugging and Sprite, and Restore my layout puts back the arrangement they replaced. The first time a session stops, and the first time an image opens, the status bar offers the matching layout. The embed checkbox still owns the emulator dock.
• The View menu lists every dock, including a memory pane opened later, and Reset layout returns to that first-run arrangement.
• Status bar. Session (Not running / Running / Stopped, with the source line), a build result that stays put, and the caret. Hatari's capability probe moves to the session chip's tooltip.
• The instruction under the caret. A one-line strip under the editor names the mnemonic or the TOS call. Clicking it opens the reference. While stopped, flag chips and a one-line register strip sit under that; the full registers table is still there.
• Go to line is Ctrl+G. Return in the editor copies the indent of the line you just left.
• F8 toggles a breakpoint. The PiST keys are otherwise unchanged: F5 run, F9 continue, F10 step into, F11 step over. Settings → Appearance can switch to the common IDE scheme (F9 toggles a breakpoint, F10 steps over, F11 steps into, and F5 continues while stopped).
• Navigation opens the file. A problem, a breakpoint or a symbol in another source opens that file. A disassembly row opens its source line when the program map knows it, and does nothing when it does not. A PC-history address opens the source line, or memory.
• Problems mark warnings. Errors and warnings both carry a coloured square, and a warning tints the message amber.
• Hardware, in one line. The video subject leads with the screen address, refresh rate and overscan Hatari's info video actually prints, and each chip name has a tooltip.
• Build has its own menu. Build and the F4 diagnostic walk live there; Run is run, step and breakpoints. Set up tools and ROMs… is a button at the bottom of Project Settings.
• File → New File, with the image exports gathered under File → Export. An empty floppy is one line ("A: no disk"), and the project pane is titled with the directory. Export to a floppy image stays on the hard-drive's context menu.
• Sprite editor. Palette swatches are numbered, frames run in a filmstrip under the canvas, phases are a combo, and flip, rotate and shift live in a Transform menu.
• Appearance. The dialog shows a sample line in the editor face you picked, and the splitter handles are wide enough to grab. Comments, gutter numerals and zero bytes in the dark theme clear ordinary reading contrast.
• Profiler icons, redrawn so Start, Stop and To cursor read as one tool: a play mark over the sample count, the count on a baseline, and that count beside the caret.

What's new in 0.7.1

The OS-call reference completes its round trip, and the profiler becomes
usable:

• Insert a call's binding from the reference dock. Pick a GEMDOS, BIOS
  or XBIOS call and "Insert binding into editor" (button or right-click)
  drops its assembler binding in above the cursor — argument pushes with the
  parameter names as placeholders, the trap, and the exact stack cleanup.
  The odd shapes are right too: Pexec's fixed layout, Mshrink/Frename's
  reserved word, Dbmsg's literal 5.
• The profiler, discoverable at last. Its controls live in the profiler
  dock as icon buttons (they used to hide, greyed, in the Run menu), the
  empty dock teaches the flow, and every click — success or refusal — says
  what happened in the dock's own status line.
• Profile to cursor line. The whole ritual in one gesture: cursor where
  measuring should end, and PiST arms a one-shot there, collects, and shows
  the results when the run stops.
• Results worth reading. Hot spots as a routines tree (nearest label,
  hot lines underneath) in counts and cycles, with milliseconds and frames
  in the status line, a noise floor for the long tail, and the operating
  system's share as a TOS/ROM row instead of silently discarded.
• The profile actions follow the mode: Start is disabled while collecting,
  Stop when nothing collects, and every disabled button's tooltip says why.

What's new in 0.7.0

The instruction reference dock learned the operating system. It was always
good at telling you what addq.l does; now it tells you what your program
is doing:

• TOS system-call reference. Cursor on a trap #1, trap #13 or
  trap #14 line — or on any of the pushes feeding one — and the dock names
  the GEMDOS, BIOS or XBIOS call being made: 111 entries covering the whole
  TOS 1.x/2.x set, each with its C prototype, what d0 returns, the TOS
  version it needs, and the stack layout.
• It reads the idiom, not just the word. The dock resolves the function
  number from the push above the trap (move.w #9,-(sp), #$0b,
  #Cconws, clr.w) and shows what the call is being made with —
  "Calling with: #msg". A register-pushed number still shows the generic
  TRAP entry.
• Everything joins the one searchable list, CPU families first, so the
  filter covers instructions and calls alike.

The demo sources get a correction out of the bargain: function 7 is Crawcin,
not Cnecin as their comments claimed — exactly the mix-up this feature
exists to catch.

What's new in 0.6.3.2

The rest of the agent surface, in one point release:

• Tool annotations. Read-only tools declare readOnlyHint, and the ones
  that end or rewrite live state (pist_stop, pist_setreg, pist_setmem)
  declare destructiveHint — an MCP client can now ask your confirmation
  for exactly the right calls.
• MCP resources and prompts. pist://console, pist://state and
  pist://document as readable resources (pist://state subscribable, with
  updates pushed on every stop/resume), and two ready-made prompts:
  diagnose-build and find-hot-loop.
• The document surface, completed. pist_tabs lists every open document
  (path, modified, current) and pist_save saves the current one.
• Build failures answer with their diagnostics. A failed pist_build
  now includes the Problems pane in structuredContent — file, line,
  severity, message — instead of a bare error build failed.
• Also: 27 tools in total, the symbols verb restored to the README's
  protocol table, and the quit decision recorded (it stays off the tool
  list deliberately).

What's new in 0.6.3.1

A point release for one security-relevant fix: a connection refused by the
remote-control token check could have bytes it sent during the
(asynchronous) disconnect window executed without a token. The client now
stays refused until the socket is gone. Everything below from 0.6.3 is
unchanged.

What's new in 0.6.3

This release is about driving PiST from another program — an AI agent, a
script, or a test harness. The remote-control socket and the pist-mcp MCP
server grew a real feature set, and pist-mcp now ships in every
archive, including the Windows and macOS ones.

• 25 MCP tools. Beyond build/run/step: open and read back the document
  the IDE is showing (pist_open, pist_read), the Problems pane with
  severities (pist_problems), the build's symbols (pist_symbols), memory
  reads and disassembly (pist_readmem, pist_disasm), and the profiler
  (pist_profile_start / pist_profile_stop / pist_profile_results).
• Structured results. State, problems, symbols, memory, disassembly and
  profile results answer as JSON — in structuredContent as well as text —
  so an agent consumes fields instead of parsing console output.
• Breakpoints by label. pist_breakpoint accepts a symbol name and
  resolves it to the first code line at or after its definition (a label on
  its own line has no code to break on), replying with the file:line and
  address it actually armed at.
• Session token and zero configuration. A listening IDE now requires a
  per-session token (auth <token> is the first line on a connection — on a
  shared machine, "localhost only" still means every local user) and
  publishes it with the port in an owner-only discovery file. pist-mcp
  finds both there, so against a locally started IDE it needs no flags at
  all. Note for existing raw-protocol clients: send auth first — see the
  README.
• Push events. Watchers are told when the debugger stops (with the real
  program counter) and resumes, as socket events and as MCP log
  notifications — no polling for a breakpoint hit.
• Blocking semantics. run, build and now profile stop answer only
  when the work is genuinely done, and block-typed queries return errors in
  the same framing, so a reader never hangs waiting for a terminator.
• Correctness throughout the agent surface, much of it found by driving
  the tools end-to-end: the shim no longer introduces itself with the wrong
  version, watch subscriptions can't hang against an unreachable IDE,
  breakpoints on non-code lines say so instead of promising a stop that
  never comes, open errors on a path that never opened instead of
  reporting success, and the shim's protocol suite...

v0.7.1

PiST — an IDE for Atari ST assembly development.

What's new in 0.7.1

The OS-call reference completes its round trip, and the profiler becomes
usable:

• Insert a call's binding from the reference dock. Pick a GEMDOS, BIOS
  or XBIOS call and "Insert binding into editor" (button or right-click)
  drops its assembler binding in above the cursor — argument pushes with the
  parameter names as placeholders, the trap, and the exact stack cleanup.
  The odd shapes are right too: Pexec's fixed layout, Mshrink/Frename's
  reserved word, Dbmsg's literal 5.
• The profiler, discoverable at last. Its controls live in the profiler
  dock as icon buttons (they used to hide, greyed, in the Run menu), the
  empty dock teaches the flow, and every click — success or refusal — says
  what happened in the dock's own status line.
• Profile to cursor line. The whole ritual in one gesture: cursor where
  measuring should end, and PiST arms a one-shot there, collects, and shows
  the results when the run stops.
• Results worth reading. Hot spots as a routines tree (nearest label,
  hot lines underneath) in counts and cycles, with milliseconds and frames
  in the status line, a noise floor for the long tail, and the operating
  system's share as a TOS/ROM row instead of silently discarded.
• The profile actions follow the mode: Start is disabled while collecting,
  Stop when nothing collects, and every disabled button's tooltip says why.

What's new in 0.7.0

The instruction reference dock learned the operating system. It was always
good at telling you what addq.l does; now it tells you what your program
is doing:

• TOS system-call reference. Cursor on a trap #1, trap #13 or
  trap #14 line — or on any of the pushes feeding one — and the dock names
  the GEMDOS, BIOS or XBIOS call being made: 111 entries covering the whole
  TOS 1.x/2.x set, each with its C prototype, what d0 returns, the TOS
  version it needs, and the stack layout.
• It reads the idiom, not just the word. The dock resolves the function
  number from the push above the trap (move.w #9,-(sp), #$0b,
  #Cconws, clr.w) and shows what the call is being made with —
  "Calling with: #msg". A register-pushed number still shows the generic
  TRAP entry.
• Everything joins the one searchable list, CPU families first, so the
  filter covers instructions and calls alike.

The demo sources get a correction out of the bargain: function 7 is Crawcin,
not Cnecin as their comments claimed — exactly the mix-up this feature
exists to catch.

What's new in 0.6.3.2

The rest of the agent surface, in one point release:

• Tool annotations. Read-only tools declare readOnlyHint, and the ones
  that end or rewrite live state (pist_stop, pist_setreg, pist_setmem)
  declare destructiveHint — an MCP client can now ask your confirmation
  for exactly the right calls.
• MCP resources and prompts. pist://console, pist://state and
  pist://document as readable resources (pist://state subscribable, with
  updates pushed on every stop/resume), and two ready-made prompts:
  diagnose-build and find-hot-loop.
• The document surface, completed. pist_tabs lists every open document
  (path, modified, current) and pist_save saves the current one.
• Build failures answer with their diagnostics. A failed pist_build
  now includes the Problems pane in structuredContent — file, line,
  severity, message — instead of a bare error build failed.
• Also: 27 tools in total, the symbols verb restored to the README's
  protocol table, and the quit decision recorded (it stays off the tool
  list deliberately).

What's new in 0.6.3.1

A point release for one security-relevant fix: a connection refused by the
remote-control token check could have bytes it sent during the
(asynchronous) disconnect window executed without a token. The client now
stays refused until the socket is gone. Everything below from 0.6.3 is
unchanged.

What's new in 0.6.3

This release is about driving PiST from another program — an AI agent, a
script, or a test harness. The remote-control socket and the pist-mcp MCP
server grew a real feature set, and pist-mcp now ships in every
archive, including the Windows and macOS ones.

• 25 MCP tools. Beyond build/run/step: open and read back the document
  the IDE is showing (pist_open, pist_read), the Problems pane with
  severities (pist_problems), the build's symbols (pist_symbols), memory
  reads and disassembly (pist_readmem, pist_disasm), and the profiler
  (pist_profile_start / pist_profile_stop / pist_profile_results).
• Structured results. State, problems, symbols, memory, disassembly and
  profile results answer as JSON — in structuredContent as well as text —
  so an agent consumes fields instead of parsing console output.
• Breakpoints by label. pist_breakpoint accepts a symbol name and
  resolves it to the first code line at or after its definition (a label on
  its own line has no code to break on), replying with the file:line and
  address it actually armed at.
• Session token and zero configuration. A listening IDE now requires a
  per-session token (auth <token> is the first line on a connection — on a
  shared machine, "localhost only" still means every local user) and
  publishes it with the port in an owner-only discovery file. pist-mcp
  finds both there, so against a locally started IDE it needs no flags at
  all. Note for existing raw-protocol clients: send auth first — see the
  README.
• Push events. Watchers are told when the debugger stops (with the real
  program counter) and resumes, as socket events and as MCP log
  notifications — no polling for a breakpoint hit.
• Blocking semantics. run, build and now profile stop answer only
  when the work is genuinely done, and block-typed queries return errors in
  the same framing, so a reader never hangs waiting for a terminator.
• Correctness throughout the agent surface, much of it found by driving
  the tools end-to-end: the shim no longer introduces itself with the wrong
  version, watch subscriptions can't hang against an unreachable IDE,
  breakpoints on non-code lines say so instead of promising a stop that
  never comes, open errors on a path that never opened instead of
  reporting success, and the shim's protocol suite runs in CI on all three
  platforms (the Linux and macOS archives also assert pist-mcp resolves
  its bundled Qt).

Every archive contains PiST, the vasmm68k_mot assembler, the vlink linker,
and an EmuTOS ROM. The Linux AppImage and the Windows archive additionally
contain the Hatari emulator, so on Linux and Windows they run and debug with
nothing else installed.

Assembler and linker: vasm and vlink are not free software. They are
redistributed unmodified and for non-commercial use, which their licences
permit; see share/doc/pist/NOTICE. PiST never patches them.

ROM: EmuTOS 1.4 (GPLv2), a free TOS replacement. Original Atari TOS images
are copyrighted and are not included — supply your own in Project Settings if
you need one.

Emulator: the Linux AppImage and the Windows archive bundle the hrdb-main
fork of Hatari (upstream 2.6.1 plus the remote-debug listener PiST's HRDB
transport uses), GPL-2.0-or-later, built unmodified from a checksum-pinned
commit tarball (PiST never patches it and runs it as a separate process). The
Windows build is the same fork compiled with MSYS2 ucrt64, with its runtime
DLLs beside the exe. The macOS archive does not include an emulator:
install one with brew install hatari (2.6.1 bottled), or point PiST at one in
Project Settings. Use 2.5 or later — 2.4.1 returns truncated debugger responses
that break source-line debugging, and Ubuntu 24.04 ships exactly that, so a
distribution package is often not recent enough. See share/doc/pist/NOTICE
for the full licence details, including the GNU Readline that the bundled Linux
build links.

Linux

Nothing else to install: assemble, run and debug straight away.

pist-*-linux-x86_64.AppImage is self-contained — Qt, the assembler, the
linker, the emulator and the ROM are all inside it:

chmod +x pist-*-linux-x86_64.AppImage
./pist-*-linux-x86_64.AppImage your-program.s

.deb and .rpm packages carry the same content for those who prefer the
package manager. Everything is built on Ubuntu 22.04, so it needs glibc 2.35 or
newer (Ubuntu 22.04+, Debian 12+, Fedora 36+, and anything more recent).

Windows and macOS

Windows: the .zip or the .msi — both include the emulator. macOS: the
.dmg or the .tar.gz, plus brew install hatari.

What works

Write, assemble, run and debug: source-line and conditional breakpoints,
stepping, step-over, registers, a memory viewer, and labelled disassembly, with
the editor following the program counter. Multi-file projects assemble
separately and link with the bundled vlink (add sources in Project Settings).
Projects keep their settings — include paths, defines, target CPU, machine,
ROM, RAM and disk images — in a small JSON file beside the source.

Known limitations

• CI exercises the emulator integration on Linux and macOS (both build the
  pinned Hatari 2.6.1 and the hrdb-main fork from source and run the emulator
  suites against both transports). Windows builds and unit-tests only: the
  official Windows Hata...