GEM was the graphical desktop environment that shipped on the Atari ST from 1985. It gave the ST a consistent, window-based interface at a time when most home computers were still command-line machines — and for a decade, an enormous catalogue of serious software was built on top of it: music tools, DTP applications, graphics programs, professional utilities. The ecosystem was real and deep.

Then the hardware died, and most of that software went with it. The community kept things alive — FreeMiNT brought preemptive multitasking to the ST kernel, XaAES brought a modern AES implementation, EmuTOS replaced the proprietary ROM — but these were always fighting the constraints of the original platform. Squeezing modern capabilities out of a 1985 machine, or out of emulators of it. nocrew’s OSIS project asked an earlier version of BGD’s question — what if TOS applications ran on Linux directly? — but the infrastructure of the late 1990s made the display side of the problem intractable. BGD is fortunate to be solving the same problem with Wayland available.

BGD takes a different approach. Rather than extending the original platform, it asks: what if GEM’s desktop model — the global menu bar, the spatial file manager, the consistent window chrome, the VDI drawing interface — were reimplemented from scratch on modern foundations, with full backwards compatibility for existing applications?

The three pieces

BGD is built from three components that fit together cleanly.

ParaTos is a compatibility layer that runs existing TOS and GEM applications on Linux. Each application runs as an ordinary Linux process. ParaTos intercepts the application’s system calls — TRAP #1 for GEMDOS file I/O and memory management, TRAP #2 for VDI graphics and AES window calls — and translates them: GEMDOS calls become Linux syscalls, VDI and AES calls are redirected to the modern BGD implementation. On x86-64 and ARM64 hardware, the Musashi 68k emulator runs the application’s 68k code. On native m68k hardware — an Atari TT030 with a modern Linux kernel, for example — the application runs at native hardware speed, with Linux signals catching the TRAP instructions instead.

The result is that a TOS application from 1991 runs on a Raspberry Pi 600, opens windows on a Wayland compositor, renders text through HarfBuzz and FreeType, and exchanges clipboard data with a modern web browser — without any modification to the original binary.

The BGD compositor is a Wayland compositor built on wlroots, extended with a custom GEM protocol that adds first-class support for GEM window management semantics. GEM’s global menu bar — where the foreground application’s menus occupy the top of the screen, managed by the compositor rather than individual windows — is implemented as a proper Wayland protocol object. Window stacking, rectangle list delivery for efficient redraws, and inter-application messaging are all handled correctly, in ways that standard Wayland protocols cannot express. Standard Wayland applications — GTK apps, Qt apps, a terminal emulator, a browser — run alongside GEM applications in the same session.

libvdi is a new VDI implementation backed by Pixman for raster operations, FreeType and HarfBuzz for text rendering. Every VDI drawing call — lines, filled polygons, blits, text — renders directly into a shared memory buffer that the compositor composites without needing to know anything about the individual operations that produced it. Legacy TOS applications using the classic 256-character Atari charset are handled transparently; native BGD applications work in UTF-8 throughout.

Why bother

The honest answer is that the GEM desktop model is genuinely good and genuinely underexplored. The global menu bar is not nostalgia — it is a considered design that separates application menus from application windows in a way that makes sense on small screens and large ones alike. The spatial file manager, where windows remember their positions and the desktop is a place rather than a launcher, is a coherent philosophy that Thing (the BGD default shell, originally written by Arno Welzel in 1994 and still actively maintained) has refined for thirty years.

There is also the application catalogue. Decades of Atari software — MIDI sequencers, image editors, word processors, games — sits in archives, technically preserved but practically inaccessible. BGD makes it runnable on modern hardware, without emulating the hardware itself, and without giving up the modern stack underneath.

And there is a personal thread running through this. The GAMECART register article on this blog came from digging through Atari ASIC schematics. The BLiTTER article came from figuring out what the hardware could actually do. The chiptune version of Sad Disco was made on an Atari ST. BGD is where those threads converge into something more deliberate — a project that takes the platform seriously as a lineage worth continuing, rather than a curiosity worth preserving.

Where things stand

This is currently a design project, with the thinking documented privately until the architecture is stable enough to publish.

The one working piece is ParaTos, which already runs text-based TOS console applications on Linux. The rest — the compositor, libvdi, the GEM Wayland protocol extension — exists as careful design waiting to become code.

Future posts will go deeper into each component as the work progresses.