Atari TOS
Atari TOS, short for "The Operating System," is a single-tasking graphical operating system developed by Digital Research for Atari Corporation's ST series of 16/32-bit personal computers, first released in 1985 alongside the Atari 520ST and 1040ST models.[1] It combines a command-line disk operating system (GEMDOS, derived from CP/M) with a graphical user interface (GEM, or Graphics Environment Manager), enabling users to interact via windows, icons, menus, and mouse-driven folders.[2][3] Stored primarily in ROM (initially targeting 128 KB but implemented as 192 KB) for quick booting, TOS powered the Atari ST's competitive edge in the mid-1980s home computer market by providing a Macintosh-like GUI at a lower cost, supporting resolutions up to 640x400 in monochrome or 320x200 in color, and facilitating applications in desktop publishing, music production, and gaming.[2] The development of TOS began in 1984 under Atari's new leadership following Jack Tramiel's acquisition of the company, with the goal of creating an affordable computer to rival the IBM PC and Apple Macintosh; Digital Research was contracted to adapt their existing CP/M and GEM technologies into a unified OS supporting 256 KB of RAM.[1] Initial version 1.0, known as RAM TOS, was distributed on floppy disk due to incomplete ROM integration and contained bugs, but it was quickly superseded by ROM-based updates like TOS 1.02 (1987) for the Mega ST, which added blitter hardware acceleration support.[3][1] Subsequent versions evolved to address hardware advancements: TOS 1.04 (1989) optimized memory usage and hard disk partitioning (up to 512 MB via BigDOS); TOS 1.06 supported the enhanced Atari STE's sound and graphics; TOS 2.06 (1991) introduced a more customizable desktop and 68010 CPU compatibility for the Mega STE; TOS 3.06 (1991) targeted the 32-bit Atari TT with improved multitasking for accessories; and TOS 4.04 (1993) for the Atari Falcon added 3D-accelerated windows and DSP support.[3][1][4] Key technical components of TOS include the BIOS for low-level hardware access (with optional XBIOS extensions), GEMDOS for file management and console I/O, the Virtual Device Interface (VDI) for graphics drivers, and the Application Environment Services (AES) for window management, collectively enabling cooperative multitasking for up to six desk accessories alongside a primary application while using minimal memory (leaving about 3.7 MB of transient program area on a 4 MB system).[3][2] Despite its limitations—such as no preemptive multitasking, short 8.3 filenames, and manual power-off without a shutdown procedure—TOS's stability, speed, and intuitive interface contributed to the ST series selling over two million units (estimates up to 3 million worldwide) by the early 1990s, influencing software ecosystems in creative industries before Atari shifted focus away from hardware in 1993.[5]Overview and History
Introduction
Atari TOS, or The Operating System, served as the foundational operating system for the Atari ST series of personal computers. It integrated GEMDOS, a text-mode kernel resembling MS-DOS for handling file operations and device management, with GEM, a graphical user interface developed by Digital Research that provided windows, menus, icons, and mouse support.[6][7] This combination enabled a unified environment for both command-line and visual interactions on Motorola 68000-based hardware.[8] Key characteristics of TOS included its design as a single-user, single-tasking system, optimized for efficient execution directly from read-only memory (ROM) chips totaling 192 KB, though initial releases in 1985 required booting the full TOS from floppy disk. It was actively developed through the late 1980s and discontinued in the 1990s as Atari shifted focus from personal computing.[6][9] The system featured a flat memory model, allowing straightforward access to the 68000's linear address space up to 16 MB, and included built-in support for peripherals such as MIDI interfaces for music production and joystick ports for gaming.[6] Historically, TOS powered some of the earliest affordable color graphical user interface computers, making advanced desktop paradigms accessible to home users and hobbyists at a fraction of the cost of contemporaries like the Apple Macintosh.[6] Its ROM-based execution and direct hardware access via components like the BIOS and extended XBIOS promoted rapid boot times and programming flexibility, influencing the evolution of personal computing interfaces in the 1980s.[6][7]Development and Release
Atari TOS originated from efforts by Atari Corporation to develop an affordable 16-bit personal computer in 1984, following Jack Tramiel's acquisition of the company in July of that year. Under Tramiel's leadership, the focus shifted to rapid production of a system featuring a graphical user interface (GUI) and built-in BASIC, targeting both home and business markets. To achieve this, Atari collaborated with Digital Research, licensing their GEM (Graphics Environment Manager) for the GUI and adapting GEMDOS—a DOS-like subsystem based on CP/M-68K—for core operating system functions. This partnership addressed Atari's need for a mature yet customizable OS, though Digital Research's limited experience with GUIs and the Motorola 68000 processor presented integration hurdles.[1][4][10] Development accelerated in late 1984 and early 1985, with the Atari ST line conceptualized as a direct competitor to the Apple Macintosh and emerging systems like the Commodore Amiga, emphasizing low cost and user-friendly features such as MIDI ports for music production. The first machines, including the Atari 520ST, were announced at the Winter Consumer Electronics Show in January 1985, with initial market release in June 1985, but TOS was incomplete; initial units shipped with only a minimal BIOS in 16 KB ROM, requiring users to load the full TOS (version 1.0, approximately 206 KB) from a floppy disk due to delays in ROM chip production and size miscalculations—Atari had underestimated needs at 192 KB. Tramiel's push for speed resulted in a rushed rollout, positioning the ST at $799 for monochrome models to undercut rivals while promising ease of use through the GEM interface.[1][11][12] Early TOS 1.0 suffered from significant bugs, including unreliable file handling and lack of hard disk support, which frustrated users and prompted quick patches; by late 1985, a more stable version with Line-F optimizations was completed, and by 1986, TOS transitioned to full 192 KB ROM integration across ST models, eliminating the floppy boot process. This rapid iteration reflected the collaborative pressures between Atari's hardware team and Digital Research, incorporating hardware-specific elements like MIDI port drivers to appeal to creative professionals. Despite these challenges, the affordable ST and TOS combination captured a strong European market share, establishing Atari as a viable alternative to pricier Macintosh systems and the Amiga's advanced graphics.[1][4][13]System Architecture
Core Components
Atari TOS, the operating system for the Atari ST series of computers, is built upon a set of core software components that provide essential functionality for process management, hardware abstraction, and graphics rendering. These components operate in a unified, single-tasking environment where applications have direct access to system resources without memory protection, enabling efficient but unprotected execution on the Motorola 68000 processor. The primary elements include GEMDOS, BIOS, XBIOS, and the graphics interfaces Line-A and VDI, which together form the foundational layer of TOS, independent of the higher-level GEM graphical user interface.[14][6] GEMDOS serves as the text-mode kernel of TOS, functioning as the primary interface for system-level operations and drawing inspiration from the CP/M operating system while incorporating extensions compatible with MS-DOS conventions. It manages process execution through functions like Pexec(), which loads and runs programs in modes such as load-and-execute or create-basepage, utilizing a basepage structure to track process memory (e.g., low and high TPA boundaries) and environment details. I/O redirection is handled via handles for standard devices (e.g., CON: for console, AUX: for auxiliary), with calls like Fdup() and Fforce() allowing reassignment, while environment variables are passed as null-terminated strings during process creation. Accessed via TRAP #1 with stack-based parameters, GEMDOS also oversees memory allocation through Malloc() and Mshrink(), ensuring a structured yet extensible foundation for file and process handling.[15][16][14] The BIOS, or Basic Input/Output System, provides low-level abstraction for essential hardware interactions, shielding higher-level code from device-specific details. It supports operations on floppy disks, hard disks, and serial ports through functions like Rwabs() for absolute sector read/write on disks and Bconin()/Bconout() for serial and console I/O, returning results in register D0. Invoked via TRAP #13 and designed to be reentrant up to three levels deep, BIOS ensures reliable data flow between the system and peripherals without exposing underlying hardware protocols.[6][14] XBIOS extends the BIOS with advanced capabilities tailored to the Atari ST's features, including graphics, sound, and specialized I/O such as the ACSI bus for hard drives. Called via TRAP #14, it includes functions like Setscreen() for configuring display modes, Dosound() for audio output, and Floprd()/Flopfmt() for floppy operations, as well as Giaccess() for interrupt handling and Rsconf() for resolution settings. This component enables direct manipulation of hardware accelerators like the YM2149 sound chip and video shifter, preserving registers D3-D7 and A3-A7 during calls to maintain application state.[6][17][14] Line-A and VDI constitute the graphics subsystem, offering primitives for efficient drawing and device-independent rendering that integrate seamlessly with the GEM environment. Line-A provides low-level, high-speed graphics calls accessed via exception opcode 1010 or TRAP #2, including operations like Put Pixel (A001) for point plotting, Arbitrary Line (A003) for vector drawing, and BitBlt ($A007) for block transfers, utilizing parameter arrays such as CONTRL and PTSIN for coordinates and control. VDI, the Virtual Device Interface, builds upon Line-A as a higher-level abstraction for portability, handling font management through structures like font headers and supporting text output with built-in bitmapped fonts (e.g., 6x6, 8x8, 8x16). Together, they enable applications to perform raster and vector graphics without direct hardware dependency.[6][14][18] TOS employs a single-tasking model, where only one user program executes at a time in an unprotected memory space, allowing direct hardware access via interrupts and exceptions for pseudo-multitasking behaviors like AES event handling. Without memory protection mechanisms, applications can interact freely with system resources, relying on cooperative scheduling and supervisor/user modes to maintain stability, though this design prioritizes performance over isolation.[14][6]Hardware and Memory Management
Atari TOS employs a flat memory model based on the Motorola 68000 processor's 24-bit external address bus, enabling direct access to up to 16 megabytes of physical RAM without virtual memory support.[14][19] The operating system itself resides in ROM at address $FC0000, occupying 192 to 512 kilobytes depending on the version and machine, while low RAM (from $000000) holds system variables, the exception vector table, and the OS footprint, typically around 8-16 kilobytes depending on the TOS version.[14] The Transient Program Area (TPA), where applications execute, begins immediately after the low RAM OS area (pointed to by the __membot system variable) and extends into upper memory up to the hardware-detected RAM top, allowing programs to allocate contiguous blocks via BIOS calls like Getmpb for initialization.[6] This linear, non-segmented approach simplifies programming but limits multitasking to cooperative schemes without memory protection between processes.[14] TOS interfaces directly with core Atari ST hardware peripherals through dedicated controllers and BIOS/XBIOS routines. The MIDI interface, managed by a Motorola 6850 ACIA chip at FFFC00, operates at 31.25 kbaud and supports two ports (IN and OUT/THRU) for up to 16 channels, enabling low-latency music sequencing via interrupts vectored at $114.[](https://www.synacktiv.com/ressources/Atari-ST-Internals.pdf)[](http://www.bitsavers.org/pdf/atari/ST/Atari_ST_GEM_Programming_1986/GEM_0904.pdf) Joystick and mouse inputs route through the 6301-based IKBD microprocessor, which handles polling or interrupt-driven events across two 9-pin ports, with vectors like $118 for key events.[](https://www.synacktiv.com/ressources/Atari-ST-Internals.pdf) Audio output relies on the Yamaha YM2149 programmable sound generator (PSG), featuring three tone channels, a noise generator, and envelope control across 16 registers accessed at FFFF8800, clocked at 2 MHz for frequencies from 30 Hz to 125 kHz.[14][19] For enhanced models like the Atari STE, TOS version 1.06 introduces support for the hardware blitter coprocessor, which accelerates bit-block transfers for graphics, and DMA-driven 8-bit stereo sound playback at up to 50 kHz, expanding beyond the base ST's mono PSG capabilities.[14] Peripheral buses under TOS control include the Atari Computer System Interface (ACSI), a custom 8-bit bidirectional variant of SCSI for hard drives, supporting up to eight devices at transfer rates up to 1 MB/s via a dedicated DMA channel at $FF8600.[14][20] ACSI commands are issued through BIOS functions like Hread/Hwrite, with the bus topology allowing daisy-chaining and interrupt acknowledgment for status phases.[20] The floppy disk controller, a Western Digital WD1772 chip, supports double-density (DD) formatting on 3.5-inch drives, yielding 360 KB per single-sided disk or 720 KB double-sided, with DMA transfers and track/sector access handled by BIOS calls such as Rwabs.[14] Interrupt handling in TOS leverages the 68000's exception mechanism, with a 256-entry vector table fixed at $000000-0003FF containing 32-bit pointers to handlers for CPU exceptions, traps, and peripherals.[14] The Motorola 68901 Multi-Function Peripheral (MFP) chip generates most external interrupts at IPL levels 2-6, such as timer C for vertical blank (VBL) at vector $70 (level 4) or serial receive for MIDI at $11C (level 6), while auto-vectors handle unassigned slots.[14] TOS initializes these during boot, allowing applications to hook vectors via Supexec for custom routines, though improper handling risks system crashes due to the lack of privilege modes in user space.[14] The boot process commences with a ROM-based cold boot upon power-on or reset, where the 68000 loads its initial program counter from $000004 (pointing into TOS ROM at FC0000) and supervisor stack pointer from $000000.[](https://www.synacktiv.com/ressources/Atari-ST-Internals.pdf) TOS then performs hardware initialization, including MFP setup, RAM size detection via shadow testing, and cartridge scanning at FA0000; if no cartridge, it probes the boot device (floppy A: or ACSI ID 0) for an executable AUTO folder or boot sector on track 0, sector 0.[14][19] Successful execution chains from the boot sector's 128-byte header, launching AUTO programs in sequence before entering the desktop, with the boot device identified by the _bootdev variable at $446.[14] This ROM-centric design ensures near-instantaneous startup compared to disk-loaded alternatives in early prototypes.[14]User Interface
Desktop Environment
The Atari TOS desktop environment provides an icon-driven graphical shell built on the GEM (Graphics Environment Manager) system, serving as the primary user interface for file management and application launching. The desktop functions as a virtual folder displaying icons representing applications, folders, and drives, allowing users to interact via mouse operations. To launch an application or open a folder, users double-click the corresponding icon, which triggers execution through the underlying GEMDOS file system. Single-clicking an icon selects it for further actions like dragging to copy or move files, while the interface supports basic drag-and-drop functionality for file operations starting from later AES versions.[21][22] Desktop configuration is managed through specific initialization files that store user preferences and settings. The primary file, DESKTOP.INF, is an ASCII-formatted resource used in TOS versions prior to 2.00 to define icon positions, window sizes, drive representations, and file type associations. In TOS 2.00 and later, this is supplemented or replaced by NEWDESK.INF, which extends functionality by linking icons to resource files like DESKICON.RSC for custom visuals and behaviors, enabling more flexible assignments such as associating specific icons with file extensions. These files are loaded at boot time into a shell buffer, with sizes varying by TOS version (e.g., 1024 bytes pre-2.00, up to 4096 bytes in 2.00-3.06), and can be edited or updated by installation programs with user confirmation to reflect changes in the desktop layout.[21][23] TOS recognizes distinct file types through extensions to determine icon display and launch behavior, facilitating intuitive workflow. Programs with the *.PRG extension are treated as standard GEM applications, displayed with generic executable icons and launched directly upon double-click. TOS-specific executables use the *.TOS extension, often optimized for direct hardware access and shown with system-appropriate icons. Terminal or command-line programs employ the *.TTP extension, allowing parameter passing while remaining resident in memory, and GEM-based terminal programs use *.GTP, which prompts for command-line input similar to TTP but integrates more closely with the graphical environment. These associations are defined in the configuration files to ensure consistent iconography and execution paths across the desktop.[21] Desk accessories enhance usability by providing always-available utility tools as floating, overlapping windows that remain active alongside the main desktop. TOS supports up to six such accessories simultaneously (four in TOS 1.0), loaded from the AUTO folder at startup, with standard examples including the control panel for system settings adjustments, printer installation utility, and VT-52 terminal emulator. Accessories are accessed via the right mouse button, which opens a menu listing available items under the "Desk" dropdown, allowing quick invocation without interrupting primary tasks.[21][24] Window management in the desktop emphasizes overlapping, resizable interfaces with intuitive controls for multitasking. Windows can be opened for folders or drives by double-clicking icons, featuring standard GEM elements like closer (to shut), fuller (to maximize), and sizer (to resize) gadgets in the title bar. The persistent menu bar at the top includes "File" for operations like show, open, and info; "Options" for sorting and window preferences; and "Desk" for accessory access and desktop information, all navigable via left-clicking and dragging the mouse. This setup supports basic multitasking, with windows updating dynamically through AES messages for events like drive changes.[21][25]GEM Integration and Features
Atari TOS integrates the Graphical Environment Manager (GEM) as its primary graphical user interface layer, with the Application Environment Services (AES) serving as the core component for managing user interactions. The AES provides essential functions for creating and handling menus, dialogs, alerts, and resource files in the .RSC format, enabling developers to build consistent, resource-driven applications without directly managing low-level graphics or input. Resource files store dialog trees, object definitions, strings, icons, and images, allowing for modular UI design that can be edited using tools like the GEM Resource Construction Set. This integration ensures that applications adhere to a uniform look and feel across the TOS ecosystem.[26][27] Event handling in the AES revolves around processing mouse, keyboard, and menu events through a centralized message loop, creating an illusion of multitasking via cooperative yielding among applications. Developers use functions likeevnt_multi to wait for multiple event types simultaneously, such as button clicks, key presses, or menu selections, while the system suspends the foreground application only when necessary to handle events. This cooperative model supports up to one main application and six desk accessories concurrently under TOS, without true preemptive multitasking. The desktop environment itself operates as the primary GEM application, leveraging these events to manage the overall user session.[26][27]
Graphics capabilities in TOS GEM are facilitated by the Virtual Device Interface (VDI), which offers device-independent drawing primitives for lines, shapes, text, and images, abstracting hardware differences across screens, printers, and plotters. VDI supports both monochrome modes for early ST systems and color modes, extending to a 4096-color palette (12-bit RGB) on the Atari Falcon through color lookup tables or direct pixel addressing, queryable via functions like vq_extnd. This allows applications to render high-resolution graphics uniformly, with clipping mechanisms to restrict output to specific rectangles for efficient windowed rendering. AES applications typically open virtual workstations on the VDI to perform these operations, ensuring compatibility with TOS's hardware abstraction.[26][18]
Internationalization in TOS GEM is achieved primarily through resource files, which encapsulate language-specific strings, menus, and dialogs, permitting easy localization without recompiling code—for instance, switching from English to German text by loading a different .RSC file. Font scaling is handled via VDI's text output functions, which adjust character sizes and proportions dynamically based on resolution and device capabilities, supporting scalable fonts in later extensions like GDOS. This framework enables multi-language support across TOS applications, enhancing accessibility for international users.[26][27]
Desk accessories integrate seamlessly into the GEM event loop by registering with the AES using menu_register, appearing as options in the desktop's menu bar and loading into memory at boot from designated directories like AUTO folder. Upon selection, they receive an AC_OPEN message to initialize windows or dialogs, process events in the shared loop without interrupting the main application, and respond to AC_CLOSE for cleanup, all while maintaining the single-tasking nature of TOS through cooperative suspension. This allows utilities like calculators or notepads to run alongside primary programs, with resources embedded prior to registration to mitigate memory issues in early TOS versions.[26][27]
File System and Storage
GEMDOS Structure
GEMDOS serves as the file system kernel within Atari TOS, providing logical operations for file and directory management on top of underlying storage devices. It implements a hierarchical structure with support for directories, files, and device access, enabling applications to perform input/output through standardized system calls. This kernel abstracts the physical media, handling allocation, navigation, and error conditions while maintaining compatibility with Atari-specific conventions.[15] The core of GEMDOS is built on a modified FAT12 file system for floppy disks and FAT16 for hard disks, utilizing 512-byte sectors as the fundamental unit for data storage and allocation. These modifications include Atari-specific boot sector layouts to accommodate custom initialization code, distinguishing it from standard MS-DOS implementations while preserving the cluster-based allocation table for tracking free space and file chains. The root directory is fixed in size, limited to 112 entries for standard floppy disks (with variability for hard disks set via the BPB), which imposes constraints on the number of top-level files or subdirectories without reformatting the volume. Filenames adhere to the 8.3 convention (eight characters for the name plus three for the extension) in uppercase to ensure cross-compatibility.[28][29][30][6] Path handling in GEMDOS employs forward slashes (/) as directory separators, differing from the backslashes used in MS-DOS, with a total path length limited to 128 bytes and no inherent depth limit for system calls (though the desktop in TOS versions prior to 2.0 limits manipulation to eight levels). Paths may include device specifiers such as A: for the first floppy drive or C: for a hard disk partition, allowing direct addressing of up to 26 drives (A: to Z:). Environment strings, accessible via system variables, support definitions like PATH to specify search directories for executable files, facilitating program loading without full path specification.[31][32][6][29] Directory operations are managed through GEMDOS system calls prefixed with D, such as Dcreate for establishing a new directory at a specified path and Ddelete for removing an empty one, ensuring atomic updates to the directory entry table. File handling relies on calls like Fcreate, which opens a new or truncated file and returns a handle, and Fopen, which accesses an existing file in read or write mode, both supporting mode flags for access control. These calls operate on file descriptors, which are non-negative integers representing open resources.[33][15][30] Volume labels are stored as special directory entries in the root with attribute byte 0x08, limited to 11 characters, providing a human-readable identifier for the disk. Boot sectors include a BIOS Parameter Block (BPB) detailing sector count, cluster size, and FAT location, alongside space for custom Atari boot code to load drivers or initialize hardware without built-in formatting utilities, which must be provided by external tools.[28][29] Error handling in GEMDOS returns negative integer codes for failures, with common values including -37 (EBADF) for an invalid file descriptor and -33 (ENOENT) for non-existent paths or files, allowing applications to diagnose issues like permission denials or resource exhaustion. These codes promote robust programming by providing precise feedback on operations such as file opens or directory creations.[34][15]Disk Formats and Device Support
Atari TOS supported double-sided double-density (DD) 3.5-inch floppy disks as the primary removable storage medium, utilizing a standard format of 80 tracks per side, 9 sectors per track, and 512 bytes per sector, resulting in a 720 KB capacity per disk.[6] Custom formats extended this by increasing sectors to 10 per track or tracks to 80 on both sides, achieving up to 800 KB, though these required specialized utilities or hardware for reliable access.[6] Beginning with TOS 2.0, support for high-density (HD) 1.44 MB floppies was introduced, allowing double-sided 80-track disks with 18 sectors per track, though DD 720 KB remained the default for compatibility with standard Atari drives.[6] Hard disk storage relied on the Atari Computer System Interface (ACSI), a parallel bus similar to SCSI but limited to 8 devices, with TOS managing access through the AHDI (Atari Hard Disk Interface) driver.[29] Partitioning used a root sector structure akin to the MS-DOS Master Boot Record (MBR), defining up to four primary partitions (GEM for ≤32 MB, BGM for larger) or extended partitions (XGM) for additional logical units, with a maximum of 14 partitions per drive.[29] TOS employed a FAT16-like file allocation table with CHS (Cylinder-Head-Sector) addressing and no native Logical Block Addressing (LBA) support, restricting early implementations to 256 MB per partition in TOS versions prior to 1.04 and 512 MB thereafter.[29] Beyond fixed media, TOS accommodated RAM disks via third-party drivers, treating portions of system RAM as high-speed, volatile block devices for temporary storage, with capacities up to several megabytes depending on available memory.[35] Cartridge ROMs, inserted via the dedicated port, provided read-only storage primarily for TOS upgrades or application code, functioning as non-volatile extensions without file system overhead.[36] While MIDI interfaces were supported as peripherals for audio devices, they did not serve storage functions. Formatting operations for floppies were handled by the XBIOSFlopfmt function, which supported sector interleaving to enhance sequential access performance; early TOS used a simple interleave of 1, while later versions enabled skewing (e.g., non-sequential sector ordering like 8,9,1,2,3,4,5,6,7 per track) via a skew table for up to 20% faster reads.[6] Hard disk partitioning and formatting invoked GEMDOS calls through utilities, initializing the boot sector, FAT, and root directory while marking bad sectors.[29]
Cross-compatibility with MS-DOS emerged in TOS 1.04 through adoption of FAT12/16 structures for floppies and FAT16 for hard disks, permitting disks formatted on Atari systems to be readable on PCs with minimal extensions for larger clusters and Atari-specific boot parameters.[29] This enabled shared media but required compatible drivers for Atari extensions like Big-DOS partitions exceeding 32 MB.[29]
| Floppy Format | Tracks/Side | Sectors/Track | Capacity | Notes |
|---|---|---|---|---|
| DD Standard (TOS 1.x+) | 80 | 9 | 720 KB | Double-sided, 512 bytes/sector; default for Atari drives.[6] |
| DD Custom | 80 | 10 | 800 KB | Extended sectors; utility-dependent.[6] |
| HD (TOS 2.0+) | 80 | 18 | 1.44 MB | High-density media; optional for upgraded drives.[6] |
| Hard Disk Partition Limits (by TOS Version) | Max Size per Partition | Interface | Addressing |
|---|---|---|---|
| TOS <1.04 | 256 MB | ACSI | CHS only.[29] |
| TOS 1.04–3.x | 512 MB | ACSI | CHS only.[29] |
| TOS 4.x | 2 GB | ACSI | CHS only; extended drivers for larger.[29] |