Creating the ST operating system

What “the ST operating system” means

TOS is the complete system environment associated with the ST. It includes low-level hardware support, GEMDOS file and program services, GEM graphics and application services, and the desktop. GEM is the graphical environment; GEMDOS is the operating-system layer beneath it. The names are related, but they do not identify the same software.

1. Desktop and applicationsThe desktop lets a user navigate disks and start programs. Other applications can use the graphical services or run without the desktop interface.
2. GEM AES and VDIApplication Environment Services manage windows, menus, dialogs, and events. The Virtual Device Interface supplies drawing and text functions.
3. GEMDOSNamed files, directories, program loading, memory allocation, and related process and character-I/O services.
4. BIOS and XBIOSBasic device access and Atari-specific operations, including screen, sound, disk, keyboard, and other hardware functions.
5. ST hardwareThe processor, RAM, display and disk circuitry, keyboard controller, and peripheral devices.

This is a guide to responsibilities rather than a claim that every call passes through every box. A program can call BIOS or XBIOS directly, and a graphics operation does not need to travel through GEMDOS. The local technical books document the actual interfaces. [1]

Why Atari chose Digital Research

The ST’s schedule left little room to create an entire graphical operating environment from scratch. START records Leonard Tramiel’s explanation that the new management did not yet know the capabilities of all its retained programmers. Digital Research offered an existing architecture and a graphical project already under development. John Feagans remembers seeing the earlier Crystal demonstration on an Apple Lisa. [2]

That was a starting point, not a finished ST operating system. Digital Research’s PC work and Atari’s 68000 port were proceeding together. Dyer recalls evaluating several possibilities before the agreement to port CP/M-68K and GEM. The initial contract and the eventual shipping configuration were therefore different stages of the project. [3]

The people and their responsibilities

Atari’s systems and graphics programmers

Landon Dyer places himself in a small BIOS/OS group handling bring-up and device support. He describes separate groups for graphics primitives, getting GEM to work on the 68000, managing builds and source files, and the BASIC port. The categories explain why the project could not be completed by a single “TOS author.” Each group depended on code, tools, and hardware produced by the others. [4]

Mike Schmal is identified in START as a system-software architect. Dave Staugas worked on text blitting and later NEOchrome. Jim Eisenstein appears in Dyer’s account among the graphics programmers. Their previous game-development experience was useful when compact and efficient drawing code mattered. Leonard Tramiel made key adoption decisions and coordinated the technical direction. [2] [3]

Digital Research’s GEM work

Lee Jay Lorenzen’s oral history describes the development of Crystal and GEM, including work on the Lisa and the effort to bring a graphical environment to more affordable computers. Tim Oren, a member of the original GEM team, later explained the system through his programming articles. Their accounts establish a software history that began outside Atari, even though the ST became one of GEM’s most visible homes. [5] [6]

It is useful to distinguish the original GEM designers from the Atari engineers who adapted and completed the ST implementation. Likewise, GEMDOS’s origins and subsequent Atari integration are related but separate contributions. The GEMDOS history follows that work in more detail.

The Monterey port was more than recompilation

Beginning in September 1984, Atari programmers worked near Digital Research in Monterey. Some stayed in hotels before Atari rented houses in the area. Dyer recalls working long days, returning to work after brief breaks by the beach, and dealing with tensions between people responsible for the original code and people responsible for making it ship on unfamiliar hardware.

C was intended to help portability, but that did not make assumptions about processor layout, data types, and platform behavior disappear. Some code also had to be translated from 8086 assembly. Staugas recalls receiving revised source repeatedly; Dyer describes cases that needed deeper redesign rather than a compiler fix. The team was porting software while its design was still moving. [2] [4]

Before reliable ST prototypes existed, the programmers used other 68000 computers. Dyer describes Apple Lisas for graphics work and Motorola VME/10 systems for BIOS and OS development, running CP/M-68K. Cross-development let work begin, but it could not fully validate the finished hardware interfaces. The prototype boards themselves could fail intermittently, making debugging a joint hardware-and-software exercise.

The build process was also much less formal than a modern repository-based workflow. Dyer remembers source directories and a person who knew how to build them, rather than a conventional version-control system. That recollection helps explain the practical coordination problem without implying that no one made backups or that the project lacked skilled engineers.

The system underneath GEM changed after CES

The January 1985 demonstration used GEM on CP/M-68K. After CES, Atari committed to GEMDOS, whose hierarchical directories and DOS-like file interface were better suited to the intended computer. START places the decision in the February period; Dyer remembers late January. Both support the broad sequence: demonstrate the machine first, change the underlying DOS shortly afterward, then complete the product. [2] [4]

A directory tree may seem modest compared with a graphical desktop, but it determines how useful a machine remains as storage grows. The desktop could display folders because the underlying file services supported them. This choice also made the API and disk organization more familiar to PC programmers, although it did not make PC binaries run on a 68000.

From a boot disk to ROM

The planned ROM budget grew from 128K to 192K. Dyer recalls that BASIC was originally expected to share the ROM space, but the operating system alone grew beyond it. The eventual language port was supplied separately. The decision to omit BASIC from the ROM represented a significant departure from the expectations surrounding many earlier home computers.

When the full ROM system was not ready, the team produced a small loader ROM that could start the system from floppy disk. Disk-loaded TOS used RAM that would otherwise be available to applications. Dyer connects the early increase in the machine’s planned RAM to the need to run the OS there. A disk-based release was therefore a practical way to make hardware useful while the final ROM software was being completed.

Fitting the system into 192K required a concentrated reduction effort. Dyer remembers removing duplicate routines, unnecessary code, and inefficient layers. The target was not just a neat round number: exceeding the allotted ROM space affected the physical product and its cost. The hardware memory budget directly shaped which software features users received. [3] [4]

Dyer’s opening chronology places ROM TOS shipment in May 1985. The broader release history distinguishes the first disk-based machines from later retail ROM availability. Atari’s 1986 GEMDOS reference manual labels May 29, 1985 as the first disk-based release and November 20, 1985 as the first ROM-based release. These are documented software-release dates, not a claim about every market’s retail availability. [8] His text is preserved unchanged.

GDOS is not GEMDOS

GDOS, the Graphics Device Operating System, supported parts of GEM’s device and font system and was not included in the original ST ROM configuration. Oren’s Summer 1986 article explains its absence and how a disk-loaded component could supply additional capabilities. GEMDOS, by contrast, was already part of the system’s core file services. Confusing the two names leads to the mistaken claim that the original ST had no disk operating system in ROM. [6]

An operating system continued after its launch

The first release left defects and limitations. Dyer is especially critical of file-system testing without hard disks and of fixes he considered incomplete. START’s later discussion of developer support describes efforts to improve documentation and track bugs. Together, the accounts show that shipping TOS was the beginning of a maintenance responsibility, not the end of the software project.

Later Atari releases and independent systems expanded what the platform could do. Eric Smith’s surviving MultiTOS development records document subsequent work on MiNT, AES, file locking, memory behavior, and developer documentation. They belong to a later stage of the operating-system story and should not be attributed to the 1984–1985 team’s initial deliverable. [7]

Firsthand accounts and technical documents

1. Atari ST Internals — local PDF and The First Atari ST Book — local PDF. Period explanations of the system layers and programming interfaces.
2. Jeffrey Daniels: “Three Years with the ST”, START, Summer 1988. Locally saved article. Includes the statements by Leonard Tramiel, Feagans, Staugas, and Schmal discussed above.
3. Landon Dyer: The Atari ST, Part 1. The initial agreement, Monterey, prototypes, memory, and CES.
4. Landon Dyer: The Atari ST, Part 2. Team organization, tools, GEMDOS, and the ROM reduction effort.
5. Computer History Museum: Lee Lorenzen oral history — PDF (recorded May 24, 2017). The origins of Crystal/GEM and the graphical-interface work at Digital Research.
6. Tim Oren: “Tracking the Elusive GDOS”, START, Summer 1986. An explanation by a GEM team member of the graphics services omitted from the initial ROM configuration.
7. MultiTOS development documents from Eric Smith’s hard disk. Original later engineering reports preserved in a web transcription.
8. Atari GEMDOS Reference Manual — PDF (1986, pages credited to Dyer). The Sversion entry distinguishes disk and ROM release dates, and GEMDOS version numbers from TOS version numbers. See also A Hitchhiker’s Guide to the BIOS — PDF, Atari’s original low-level ST documentation.