Creating GEMDOS

Three names, three scopes

GEM is the graphical environment. GEMDOS provides underlying services such as opening files, navigating directories, allocating memory, and loading programs. TOS is the ST’s overall operating-system environment, including the Atari hardware support and graphical components. Early articles sometimes use “GEMDOS” or “TOS” more broadly, so the scope intended by an author needs to be considered when reading period documentation.

A user might double-click a program in the GEM desktop; behind that action, GEMDOS finds and loads an executable, allocates its memory, and arranges its execution. Opening a document similarly crosses the boundary between the graphical file selector and the file-handling services. The desktop’s appearance is therefore only one part of the operating-system story. [1]

Origins at Digital Research

Tim Oren’s 1986 Professional GEM column, “Coping with GEMDOS,” is a particularly important firsthand source. Oren explains that GEM on the PC already had an underlying DOS. Porting the graphics to the 68000 did not automatically provide an equivalent environment. CP/M-68K was useful for getting development started, but lacked capabilities such as the hierarchical filesystem the new environment needed. [2]

A new operating-system effort proceeded alongside the graphical port. Oren identifies Jason Loveman as the first Digital Research engineer on the project. He also explains the naming confusion: “TOS” was initially a provisional way to refer to the operating system that would run on the ST, and reports of Loveman’s involvement produced references to “Jason DOS.” GEMDOS became the name for the more general system, which was intended to support GEM on other 68000 machines as well.

The work began before dependable ST hardware was available. Oren describes using Lisa and CompuPro development systems and moving tools into the new environment as it became usable. His account makes an important distinction: CP/M-68K’s presence in the development tools and old manuals does not mean that the finished ST continued to use it as its underlying DOS.

The people involved

Jason Loveman: the initial GEMDOS implementation

Loveman’s role is documented directly by Oren’s account rather than inferred from the name of the finished Atari product. That attribution establishes the project’s beginning at Digital Research. It does not erase later work needed to adapt the system to ST hardware, finish the implementation, test it, or maintain the Atari version. [2]

Tim Oren: participant and technical explainer

Oren wrote as a member of the original GEM team. His articles are useful because they address both provenance and the concrete problems application programmers encountered. A second article, on GDOS, explains a different component whose similar name has caused lasting confusion. [3]

Landon Dyer and the Atari systems team

Dyer describes working on the BIOS and OS side of the ST project, trying the new file system, writing boot support, and investigating bugs. His memoir records the practical integration effort from inside Atari. Mike Schmal, identified in START as a system-software architect, explains the benefit of offering programmers a familiar DOS-like interface. [4] [5]

Leonard Tramiel: accepting the change

The technical team could experiment with GEMDOS, but replacing the contracted CP/M-68K basis was a product decision. Dyer attributes the commitment to Leonard Tramiel. START records Leonard’s own account of weighing a mature system against an unfinished one with better file organization and performance. The decision accepted additional short-term risk in exchange for a more useful foundation. [5]

From the CES demonstration to the shipping system

The STs shown at January 1985 CES ran GEM over CP/M-68K. Dyer remembers experimenting with GEMDOS before the formal decision and places that decision in late January. START describes the choice in the February period. The difference should be retained as a source discrepancy rather than resolved by inventing a day on which all participants must have agreed. [4] [5]

The practical attraction was a filesystem with directories and subdirectories. A flat collection of names becomes awkward as storage and applications grow. A folder tree lets users organize programs, documents, and related resources, and gives the desktop meaningful structures to display. A familiar API also reduces the conceptual work required of programmers moving from PC software, even when their code must be recompiled or rewritten for the 68000.

What GEMDOS actually supplies

The interfaces above are documented in the local Atari ST Internals and Atari’s original GEMDOS Reference Manual [7]. In assembly language, GEMDOS calls use TRAP #1. BIOS and XBIOS have separate trap interfaces. The separation allows high-level file operations to be kept distinct from hardware-level operations such as reading a disk sector. [1]

Program loading is more than copying a file into memory. An executable contains information about its code, data, and uninitialized storage, and may need relocation when loaded at its assigned address. The operating environment also establishes the program’s basepage and execution context. These details explain why a graphical desktop, a command-line tool, and the disk service layer all need a shared agreement about executable files.

Classic GEMDOS also reflects the limitations of the original system. Memory allocation does not provide the isolation and protection associated with later desktop operating systems. Standard TOS ordinarily runs one main application at a time. GEM desk accessories and the event system provide useful concurrent-looking behavior, but do not turn that original environment into a protected general-purpose multitasking system.

PC-like does not mean PC binary compatibility

GEMDOS uses a FAT-style disk organization, drive letters, paths, and the familiar short filename convention. This made exchanging data with suitably formatted PC disks practical. However, disk geometry, boot-sector details, and software expectations could still affect interchange. The 68000 also does not execute the PC’s 8086 machine code. A readable document or transferable source file is a different kind of compatibility from a runnable PC program. [1]

Contemporary authors describe the relationship in different language. Oren calls the design a close PC-DOS clone while stressing its differences; START says it was modeled on MS-DOS rather than written as a clone. The useful common point is that familiar services and disk structures did not imply an identical implementation or perfectly identical behavior. [2] [5]

GEMDOS is also unrelated to the file format of Atari DOS 2 on the 8-bit machines. A file saved on an 810 or 1050 disk is not automatically a GEMDOS file merely because both computers carry an Atari badge. The 8-bit software history explains that earlier system’s independent development.

Testing, defects, and later development

Dyer remembers a significant testing limitation: the early team did not have hard disks with which to exercise GEMDOS. Floppy-based tests could establish that common operations worked without exposing the full range of problems that appeared on larger volumes. He also recalls bugs and fixes with which he remained dissatisfied. His account should be read as a participant’s criticism of the versions he worked on, not as a blanket description of every later TOS release. [4]

Oren’s articles show the application-facing side of the same situation. Programmers needed to handle errors, convert between related interfaces, and avoid assumptions that a familiar function behaved exactly like its PC counterpart. Those details are part of the creation story: a usable platform depends on programmers understanding the actual implementation, not just its marketing description.

Later software expanded the original model. Eric Smith’s MultiTOS development records describe work on MiNT, AES, GEMDOS fixes, memory allocation, and documentation. These records demonstrate a later engineering effort to extend and repair the environment. The continued use of GEMDOS-compatible interfaces made old applications and newer system facilities able to share a recognizable foundation. [6]

Chronology

1. 1984: Digital Research’s graphical work and the new underlying DOS effort proceed while Atari’s hardware is still developing.
2. Late 1984: Atari engineers experiment with the unfinished GEMDOS system.
3. January 1985: CES demonstrations still use CP/M-68K beneath GEM.
4. Early 1985: Atari formally chooses GEMDOS and completes the ST implementation.
5. 1985–1986: Disk-based and then ROM-based TOS establish the environment; technical articles explain its interfaces and problems.
6. Later years: TOS maintenance and multitasking projects retain and extend the GEMDOS interface.

Firsthand sources and technical PDFs

1. Atari ST Internals — local PDF. File handling, memory, executable formats, and system calls. Also see The First Atari ST Book — local PDF.
2. Tim Oren: Professional GEM, column 15, “Coping with GEMDOS” (1986). Original text article with sample code; the archive is served over HTTP. Oren explicitly identifies himself as a witness to the development and names Jason Loveman.
3. Tim Oren: “Tracking the Elusive GDOS”, START, Summer 1986. Read this to distinguish the graphics component GDOS from GEMDOS.
4. Landon Dyer: The Atari ST, Part 2 (2008). Firsthand recollections of the switch, debugging, and testing limitations.
5. Jeffrey Daniels: “Three Years with the ST”, START, Summer 1988; local saved copy. Includes Leonard Tramiel’s and Mike Schmal’s explanations.
6. Eric Smith’s MultiTOS development records. Later original engineering material, preserved as a web transcription.
7. Atari GEMDOS Reference Manual — PDF (1986). Original API documentation with Dyer’s name in the page footers; describes behavior, error results, known bugs, and release identifiers.