TRSDOS
TRSDOS, or Tandy Radio Shack Disk Operating System, was the official disk operating system developed by Tandy Corporation for its TRS-80 series of Z80-based microcomputers sold through Radio Shack stores.[1] It provided core functionality for file management, input/output operations, and program loading from floppy disks, serving as the foundational software layer that enabled disk-based computing on these early personal computers.[2] First introduced in 1978 alongside the TRS-80 Model I's disk expansion, TRSDOS evolved through multiple versions to support subsequent models, incorporating features like double-density disk formatting and extended BASIC commands while addressing the limitations of 1970s hardware such as unreliable floppy drives.[3]
The origins of TRSDOS trace back to 1978, when Tandy Corporation commissioned software engineer Randy Cook to develop a disk operating system for the TRS-80 Model I, paying him $3,000 for the project after recommendations from floppy drive manufacturer Shugart Associates.[3] Cook's initial release, TRSDOS 2.0, arrived bundled with the Model I's Expansion Interface and disk drives but suffered from significant bugs, including directory corruption issues often exacerbated by hardware flaws.[3] A revised TRSDOS 2.1 followed shortly thereafter with major fixes, introducing innovative elements like password protection, program overlays for memory efficiency, and hashed directory access for faster file retrieval—features that were advanced for the era and influenced later TRS-80 operating systems such as LDOS and NEWDOS/80.[3]
For the TRS-80 Model III, launched on July 30, 1980, Tandy developed a new iteration of TRSDOS in-house, drawing partial inspiration from the more business-oriented Model II version.[2] This Model III TRSDOS, starting with version 1.0 and culminating in 1.3 by early 1981, supported 180K double-density disks on 40-track drives, included a HELP command for user assistance, and integrated Disk BASIC with Model I compatibility, though it limited file dating to month and year only.[2] Minor updates continued until 1984, enhancing reliability but without a planned 1.4 release materializing.[2]
The most advanced variant, TRSDOS 6.x, debuted with the TRS-80 Model 4 in 1983 and was essentially a rebranded, licensed edition of Logical Systems' LDOS, optimized for all-RAM configurations on Z80 processors.[4][5] Version 6.2, the standard for the Model 4, offered hardware independence, support for hard drives, a wide array of peripherals, and commands like CONV for converting between TRSDOS formats, making it compatible with earlier systems while introducing device drivers, redirection, and filtering capabilities.[6][5] TRSDOS 6.x represented a pinnacle of TRS-80 software evolution, providing a portable and robust environment that extended the platform's viability into the mid-1980s amid competition from more advanced systems.[5]
Overview
Description
TRSDOS, or Tandy Radio Shack Disk Operating System, served as the primary disk operating system for the TRS-80 line of eight-bit microcomputers powered by the Zilog Z80 processor.[3] It was a single-user, single-tasking environment designed to manage disk-based storage and input/output operations on these machines sold through Radio Shack stores.[1] As the official operating system from Radio Shack, TRSDOS was the primary OS for disk-equipped systems in the line.[3]
Pronounced "triss-doss," TRSDOS was initially developed to enable floppy disk expansion for the TRS-80 Model I, allowing users to move beyond cassette tape storage for faster and more reliable data handling.[7] The system operated through a command-line interface with no graphical user interface or multitasking capabilities, reflecting the hardware constraints of the era.[3]
Originally closed-source proprietary software, TRSDOS achieved greater memory efficiency through an overlay architecture, where system routines loaded into a shared memory area as needed, conserving limited RAM resources.[7] In 1984, Logical Systems published the commented assembler source code for TRSDOS 6.2.0 in a three-volume set titled "The Source," making it accessible for study and modification by developers.[8]
TRSDOS was primarily designed for the TRS-80 Model I microcomputer, introduced in 1977, which served as the initial platform with its Z80 CPU running at 1.77 MHz.[9] The operating system was later adapted for the TRS-80 Model III, released in 1980, featuring an upgraded Z80 CPU at 2 MHz and integrated hardware.[10] Compatibility extended to the TRS-80 Model 4 in 1983, equipped with a faster 4 MHz Z80A CPU and enhanced expandability, while a distinct variant of TRSDOS existed separately for the business-oriented Model II and Model 12 systems.[11]
All supported platforms shared core hardware requirements centered on the Z80 processor family, enabling TRSDOS to manage disk-based operations efficiently.[12] Systems required at least one 5¼-inch single-sided double-density (SSDD) floppy disk drive, with support for up to four such drives; these drives typically featured 35 to 40 tracks per side, providing approximately 180 KB of storage capacity per side through 18 sectors of 256 bytes each.[10] Optional hard disk support was introduced in later versions, particularly TRSDOS 6.x for the Model 4, accommodating Winchester drives with up to eight partitions for expanded storage.
Memory requirements varied by version and model but started at a minimum of 16 KB RAM for basic TRSDOS functionality on the Model I, including support for Disk BASIC, though later iterations like version 2.3 mandated 32 KB.[13] The Model III supported configurations from 16 KB up to 48 KB, while the Model 4 allowed up to 128 KB, including 64 KB of extended memory that could be configured as a virtual MemDisk drive under TRSDOS 6 for rapid access akin to a RAM-based disk.[11]
Standard peripherals included a CRT monitor for display output, an integrated keyboard for input, and an RS-232 serial port for external device connectivity, all of which were built into the Model III and Model 4 chassis.[10] Earlier Model I systems relied on an external Expansion Interface for disk controllers and additional peripherals, but TRSDOS versions from 6.x onward introduced greater device independence, allowing flexible mapping of logical drives to physical hardware like printers or modems without fixed port dependencies.[14]
History
Origins
TRSDOS, the Tandy Radio Shack Disk Operating System, was developed by programmer Randy Cook under contract with Radio Shack in 1978 to serve as the first official disk operating system for the TRS-80 Model I's disk expansion interface.[3] Cook, recommended by Shugart Associates—the supplier of the TRS-80's floppy drives—for his expertise in minicomputer disk systems, was paid $3,000 for the work, which integrated closely with the system's Level II BASIC ROM and the forthcoming Disk BASIC extension.[3] The operating system was initially referred to simply as "DOS" during early development phases before being officially named TRSDOS to reflect its ties to Tandy and Radio Shack.[3]
The primary motivation behind TRSDOS's creation was to overcome the limitations of the TRS-80 Model I's original cassette tape storage, which was slow and unreliable for loading and saving programs, by enabling faster and more capacious floppy disk operations.[15] This allowed users to store and access larger BASIC programs, data files, and utilities efficiently, supporting up to four 85 KB single-sided, single-density drives per system and facilitating the growth of third-party software ecosystems.[15] Development occurred amid the rapid evolution of the TRS-80 platform, launched in August 1977, with TRSDOS ready for public release alongside the disk expansion hardware in July 1978.[16]
TRSDOS was tailored specifically to the Zilog Z80 microprocessor architecture of the TRS-80, ensuring tight integration with the system's hardware but limiting portability to other platforms.[3] Early versions faced significant challenges, including numerous bugs in the initial TRSDOS 2.0 release, which was not intended for widespread distribution and caused issues like unreliable file handling.[17] These problems prompted a quick revision to TRSDOS 2.1, which addressed major flaws but still suffered from occasional directory corruption, often exacerbated by hardware inconsistencies such as faulty floppy drive cables or power fluctuations.[3] Cook's solo authorship contributed to these initial hurdles, though the system laid the groundwork for subsequent improvements.[16]
Versions and Evolution
TRSDOS for the TRS-80 Model I began with version 2.0, released in July 1978 as the initial public version supporting granule-based disk organization.[18] This release, developed by Randy Cook, introduced core disk operations but suffered from significant bugs, such as data corruption on full disks.[18] Version 2.1 followed in September 1978, primarily addressing major bugs from 2.0 while adding essential commands and features for improved stability.[18] By 1979, TRSDOS 2.3 emerged as the final single-density iteration for the Model I, incorporating minor bug fixes and enhanced utilities to refine usability without introducing double-density support. Later versions like 2.7 and 2.8 in 1982 added double-density support via the Radio Shack Double-Density Disk Kit.[18]
The TRS-80 Model III, launched on July 30, 1980, came with TRSDOS 1.0, which Tandy developed in-house, drawing partial inspiration from the more business-oriented Model II version.[2] This version supported 180K double-density disks on 40-track drives, included a HELP command for user assistance, and integrated Disk BASIC with Model I compatibility, though it limited file dating to month and year only. Version 1.3 followed in May 1981, with optimizations for the Model III's hardware, including support for its faster processing capabilities in certain configurations and password protection inherited from earlier Model I versions.[1][2] Minor updates continued until 1984, enhancing reliability but without a planned 1.4 release materializing.[2]
For the Model 4 series, TRSDOS evolved from LDOS, originally developed by Logical Systems, Inc. TRSDOS 6.0 debuted in April 1983 alongside the Model 4, emphasizing device independence through abstract hardware interfaces that allowed flexible peripheral handling.[19] Version 6.2, released in 1984, added the MemDisk feature, enabling expanded memory to function as a high-speed virtual disk drive.[20] Logical Systems then rebranded and updated it as LS-DOS 6.3 in 1986, introducing subdirectory support to organize files hierarchically beyond flat structures.[20] The final release, LS-DOS 6.4, arrived in 1987, consolidating refinements for the aging platform.[20]
Key advancements across the 6.x series included a shift to comprehensive hardware abstraction via device control blocks and supervisor calls, facilitating easier adaptation to varied storage media.[20] In 1984, Logical Systems released the full commented source code for TRSDOS 6.2 in a three-volume set titled The Source, enabling developer customization.[20] Official support ended by 1987 as Tandy prioritized MS-DOS for its emerging PC-compatible lines.[19]
Architecture
Core Components
TRSDOS employs a monolithic kernel architecture, where the core operating system resides as a single, integrated unit in memory, augmented by an overlay system to handle functionality within the severe memory constraints of 16 to 64 KB RAM typical of TRS-80 systems.[20] In early versions for Models I and III, the kernel, often referred to as the nucleus or SYS0/SYS, includes essential services such as an overlay loader, disk input/output routines, device drivers, and system initialization code, loading initially into low memory addresses like 0x4000 to 0x4E00.[12] This design allows non-resident modules to be dynamically loaded from disk into designated overlay regions, such as 0x4E00 to 0x5200, ensuring efficient use of limited resources without requiring permanent allocation for infrequently used components.[20]
Central to the system's structure are key modules that form the resident and overlay portions. SYS0/SYS serves as the bootstrap and core nucleus, handling initial loading and basic I/O services, while in later versions, SYSRES represents the persistent resident system, encompassing file access routines, supervisor call (SVC) processing, and interrupt management, typically occupying 0.5 KB (512 bytes).[20] Device handlers, managed through tables like the device address and mnemonic tables, enable I/O redirection across peripherals such as keyboards, video displays, and printers, supporting device-independent operations via SVCs for reading, writing, and channel I/O.[12] Overlays like SYS1/SYS (command interpreter) and SYS2/SYS (file control) are loaded on demand, with libraries such as SYS6 to SYS8 providing indexed sequential access methods (ISAM) for advanced file handling.[20]
The boot process underscores the system's simplicity and lack of built-in multitasking, operating as a single-user environment without concurrent process support. During a cold boot in early versions, the ROM routine reads from track 0, sector 0 of drive 0 to load the BOOT/SYS module (1 sector) into 0x4200-0x42FF, followed by SYS0/SYS for full initialization; in TRSDOS 6, it loads 16 sectors into 0x0800-0x1FFF.[20][21] A warm boot, triggered by system reset or equivalent mechanisms like the *CLEAR command in earlier versions, reloads necessary components without a full disk access if the resident system is intact, checking for user input to proceed.[12]
Security features, including password protection for files and directories introduced in early versions like TRSDOS 2.1, evolved across versions, with later iterations like TRSDOS 6 using up to eight-character OWNER and USER passwords to enforce access levels such as READ or FULL via file control blocks (FCBs).[7][20] This protection is integrated into modules like SYS2/SYS, denying access if security criteria are unmet. TRSDOS remained closed-source software until 1984, when Logical Systems, Inc. published the commented source code for version 6.2 in "The Source".[20][22]
Memory Organization
TRSDOS organizes memory on TRS-80 systems to balance resident operating system requirements with available space for user programs and data, typically allocating low memory addresses for core components while reserving higher addresses for applications. On Models I and III, which support up to 48 KB of RAM, the system area occupies the lower portion of RAM, approximately 8 KB dedicated to buffers, device control blocks, and resident code, starting from address 0x4000 and extending upward. This leaves the user program space below 0xE000 available for BASIC interpreters, applications, and data storage, with the exact boundary adjustable based on total RAM and configuration.[7][12]
Buffer management in TRSDOS prioritizes efficient I/O handling with a fixed 2 KB directory buffer to cache disk directory tracks in RAM, enabling quick file lookups without repeated disk access. I/O operations use variable-sized buffers for logical records ranging from 1 to 256 bytes per record, configurable at file open to match application needs and minimize overhead; each buffer includes a 34-byte device control block (DCB) for metadata like file pointers and status flags. These buffers are dynamically allocated within the system area, with up to 15 supported depending on the "HOW MANY FILES?" prompt during initialization, ensuring compatibility with limited RAM while supporting concurrent file access.[7][23]
Overlay handling allows TRSDOS to maintain a minimal resident footprint of approximately 12 KB by dynamically loading non-essential modules from disk into designated overlay zones as needed, swapping them out to free space for subsequent operations. In early versions, the core nucleus, including the command interpreter and basic I/O routines, resides permanently in low memory (e.g., 0x4000 to 0x4E00 on Model I), while overlays such as file management utilities load into addresses like 0x4E00 to 0x5200, and larger utilities occupy 0x5200 upward, overwriting prior contents only when safe. This approach, referenced in kernel overlay mechanisms, optimizes performance on resource-constrained systems by reducing constant disk I/O for infrequently used code.[12][7]
In TRSDOS Version 6 for the Model 4, memory organization introduces significant enhancements, supporting up to 128 KB of total RAM through bank-switching across two 64 KB banks (64 KB base plus optional expansion), with the system area expanded to include 0.5 KB for SYSRES and 1.5 KB for system overlays and buffers in low memory (0x1300 to 0x1DFF for SYSRES; 0x1E00 to 0x23FF for SOR) alongside a 0.25 KB library overlay region (0x2400 to 0x25FF). User program space begins at 0x3000 and extends dynamically to the HIGH$ pointer, adjustable via supervisor calls for flexible allocation. A key feature is MemDisk, which repurposes unused high RAM (up to 64 KB in the extended bank) as a virtual disk for rapid file storage and retrieval, emulating disk sectors in memory to accelerate operations like program loading and data caching without physical media access.[20][11]
File and Disk Management
Disk Structure
TRSDOS organizes disks using a granule-based system, where the fundamental unit of allocation is a granule. Granule size varies by density: 1.25 KB (5 sectors of 256 bytes each) for single-density (SD) and 0.75 KB (3 sectors) for double-density (DSDD) in Model III versions.[7][24] Disks are divided into granules, with configurations yielding 70 granules for a 35-track single-density disk (~87.5 KB raw capacity) or 240 granules for a 40-track double-density disk (~184 KB raw).[24] This structure applies to 5¼-inch floppy disks formatted in single-density (SSDD) or double-density (DSDD) modes, where each track holds multiple granules depending on the density—such as 2 granules per track in SSDD (5 sectors each) or 6 granules per track in DSDD (3 sectors each for TRSDOS).[25] Hard disks, supported in later versions like TRSDOS 6, are partitioned into up to 8 logical drives to manage larger capacities, each following a similar granule layout but with configurable sector counts per granule (e.g., 8 or 16 sectors).[20]
The directory is a fixed structure allocated on track 17 for single-sided floppy disks to optimize access times (cylinders for double-sided or hard drives).[24] It supports 48 file entries for Model I TRSDOS 2.x or 80 for Model III TRSDOS 1.x, stored across multiple sectors: the first sector contains essential metadata including the disk name, password, and AUTO command, while subsequent sectors hold the file entries (e.g., 5 entries per sector, totaling the slots).[24][7] A fixed allocation bitmap, known as the Granule Allocation Table (GAT), resides in the directory's initial sector and uses a bit-per-granule mapping to track usage—typically one bit per granule across bytes representing each track, with values indicating free (e.g., 00), allocated (e.g., 11), or locked (e.g., FF for flawed tracks).[24]
During formatting, TRSDOS initializes the disk by writing the boot sectors, establishing the directory track, and populating the GAT with all granules marked as free, while verifying track integrity through read/write checks.[26] Allocation occurs via a first-fit algorithm, scanning the GAT bitmap sequentially to find and claim the lowest-numbered free granule(s) for a file's extents, without any built-in defragmentation—leading to potential scattering over time but ensuring simple, efficient space management.[27] For version-specific enhancements, such as expanded 40-track support in TRSDOS 2.3, capacities align with these granule counts while maintaining the core bitmap-driven approach.[26]
File System Operations
TRSDOS employs an 8.3 file naming convention, consisting of up to eight alphanumeric characters for the primary name followed by a three-character extension, such as PROGRAM.BAS or ARTICLE/TXT.[20] File names are case-insensitive, allowing users to reference files without regard to uppercase or lowercase letters.[7] Wildcards facilitate pattern matching in file specifications, with the asterisk (*) representing multiple characters and the question mark (?) standing for a single character, enabling operations like selecting all BASIC files via *.BAS.[20]
Files in TRSDOS support two primary access modes: sequential and random. Sequential record input/output processes data in order from the beginning of the file, with each record ranging from 1 to 256 bytes in size.[20] Random access allows direct positioning to specific records using granule (GRAN) and record (REC) parameters, where granules represent allocation units on disk, though the system lacks support for streams or other advanced data flows.[20]
Basic file operations in TRSDOS include creation, deletion, renaming, and protection. Files are created during output operations or via system calls, while deletion and renaming are handled through dedicated mechanisms that update directory entries.[7] Protection features allow setting access levels and passwords on a per-file basis, with password support—using up to eight-character strings—introduced in version 2.1 to control read, write, execute, rename, and delete permissions.[20]
The file system imposes certain limitations, including a maximum of 48 files per directory for Model I or 80 for Model III, enforced by the fixed 48-byte size of each directory entry.[20] Subdirectories are not supported in core TRSDOS versions, maintaining a flat directory structure until the introduction of this capability in LS-DOS 6.3.[20]
Command-Line Mechanics
The TRSDOS command-line interface (CLI) is a text-based system that accepts line-buffered input from the keyboard or redirected devices, processing commands entered at a prompt such as 'DOS READY' or 'TRSDOS READY', depending on the model and version. Users type commands followed by parameters, pressing Enter to execute; the interface supports up to 80 characters of lookahead buffering for efficient input. This design emphasizes simplicity, with case-insensitive parsing that converts inputs to uppercase for validation.[20][27]
Parsing begins with the command interpreter scanning the input line for the primary command keyword, ignoring optional "noise words" such as "TO" or "FROM" that enhance readability but do not affect functionality—for instance, "COPY FILEA TO FILEB" is equivalent to "COPY FILEA FILEB". The system first checks for internal (resident) commands handled directly by the DOS kernel, then searches for external commands across available drives (typically 0-3 or 0-7 depending on the version), loading them as overlays from disk files with a default .CMD extension if no extension is specified in TRSDOS 6.x. File specifications (filespecs) follow a structured format: up to 8-character name, 3-character extension, optional password, and drive specifier (e.g., ARTICLE/TXT:0), validated via system service calls (SVCs) like @FSPEC, which terminate parsing at end-of-text or carriage return markers. Parameters, if enclosed in parentheses, are parsed separately using @PARAM SVC, supporting formats like hexadecimal (X'hhhh'), decimal numbers, quoted strings, or toggles (ON/OFF), with abbreviations allowed (e.g., "L" for "LENGTH").[20][27]
Execution differentiates between internal commands, executed in resident memory below address X'2800' via routines like @CMNDI, and external commands, loaded and run using @RUN or @LOAD SVCs, which allocate memory dynamically and pass the command buffer address in the HL register. Device redirection integrates seamlessly, allowing output or input reassignment—such as "ROUTE *PR TO FILE/TXT:3" to send printer output to a file—managed through logical device control blocks (DCBs) and options like {PRT} for printer routing or SPOOL for buffering to disk. Input can originate from the keyboard (*KI device), serial ports via configured channels, or redirected files/devices, but TRSDOS lacks native scripting; batch processing occurs via manually chained commands or automated startup lines stored with the AUTO command.[20][27]
Error handling during parsing and execution returns specific codes in the accumulator register, triggering messages like "SYNTAX ERROR", "FILE NOT FOUND", "ILLEGAL DRIVE NUMBER" (code 32), or "PARAMETER ERROR" (code 44), displayed via the @ERROR SVC from a system dictionary. The non-zero (NZ) flag indicates failure, enabling programs to recover or prompt retries, while successful operations set the zero (Z) flag. This mechanism ensures robust user interaction without halting the system abruptly.[20]
Key Commands
TRSDOS provides a set of built-in commands for managing files, disks, and system operations, accessible via the command-line interface. Commands vary by version; the following describes common ones with version-specific notes where applicable. These commands are essential for everyday tasks such as listing files, deleting data, copying content, and configuring hardware. The syntax generally follows a simple format where commands are typed followed by parameters like filenames or drive specifiers (e.g., :0 for the first drive), and options in parentheses for advanced control.[28][7]
Directory Commands
The directory commands allow users to view, manage space, and remove files on a disk.
- DIR: This command displays a list of files on the specified drive, including filenames, extensions, and attributes like file size or type. Syntax:
DIR [:d] [(options)], where options such as S (system files), I (invisible files), or A (allocation details) can be added for filtered output. For example, DIR :0 lists files on drive 0, while DIR (S) includes hidden system files. It supports wildcard characters for partial matches.[28][7][14]
- FREE: Displays the available space on all or a specific drive, showing the number of free granules (allocation units) and maximum file slots. Syntax:
FREE [:d] [(P)], where P prints the output to a printer. On a standard 35-track disk, it might report up to 67 free granules for data storage. This helps users assess disk capacity before operations.[28][7][14]
- KILL: Deletes one or more files from a drive, freeing their allocated space; it supports wildcards for batch deletion (e.g.,
KILL *.BAS removes all BASIC files). Syntax: KILL filespec [:d]. In later versions like TRSDOS 6.x, the equivalent is REMOVE filespec, which also handles device removal but requires confirmation for safety. Users must have write access, and it cannot delete open files.[28][7][14]
Copy and Backup Commands
These facilitate data transfer and disk duplication, often with built-in verification to ensure integrity.
- COPY: Transfers files from one location to another, either between drives or within the same disk (in versions supporting single-drive mode). Syntax:
COPY filespec1 [TO] filespec2 [:d] [(options)], where options like V (verify) or L (record length) control behavior. For instance, COPY FILE/TXT:0 TO FILE/TXT:1 duplicates a text file across drives, preserving attributes. It requires sufficient space on the destination.[28][7][14]
- BACKUP/RESTORE: Performs full disk mirroring by copying all tracks and sectors from a source to a destination drive, automatically formatting the target if needed. Syntax for BACKUP:
BACKUP :s TO :d [(options)], with options like Query (prompt for each file) or Sys (include system files). RESTORE reverses this process to recover from a backup disk. This is particularly useful for archiving or error recovery, though it requires two drives and can take several minutes for a full 80-track disk.[7][14]
Disk Utilities
Commands in this category prepare and maintain disk media, including surface integrity checks.
- FORMAT: Initializes a blank diskette by creating tracks, sectors, and a directory structure, optionally locking out bad sectors. Syntax:
FORMAT [:d] [(options)], such as Name (disk label) or Sides (for double-sided drives in later versions). For example, FORMAT :1 prepares drive 1 as a data disk with default 35 tracks (single-density). It erases all data, so backups are recommended beforehand.[28][7][14]
- TEST/VERIFY: TEST performs diagnostic checks on memory, while VERIFY toggles read-after-write confirmation during file operations to detect errors. Syntax for VERIFY:
VERIFY (ON|OFF). Enabling VERIFY (default off) slows operations by about 50% but ensures data accuracy, especially on older media. TEST is often used in system utilities for memory scanning.[28][7][28]
System Commands
These handle basic system reconfiguration and output routing.
Programming and Utilities
System Interfaces
TRSDOS provides programming interfaces primarily through SuperVisor Calls (SVCs), which enable developers to access system functions such as file operations and device control. These SVCs are invoked using the Z80 restart instruction RST 40H or equivalent interrupt mechanisms, with function codes ranging from 0 to 127.[20] Parameters for SVCs are passed via CPU registers, following a standardized protocol where, for instance, register B holds the function code (e.g., 1 for GET, 2 for PUT, 4 for CTL), HL points to the I/O buffer, and DE references the Device Control Block (DCB) or File Control Block (FCB).[20] Return values include error codes in register A and a set Z flag indicating success.[20] Key SVCs for file and disk management include @OPEN (SVC 59) to open files or devices, @CLOSE (SVC 60, often via @REMOV SVC 57) to close them, @READ (SVC 67) and @WRITE (SVC 75) for sequential I/O, and @POSN (SVC 66) for positioning in random-access files.[20]
The following table outlines the register protocol for common disk I/O SVCs, such as @RDSEC (SVC 49) for reading sectors:
| Register | Purpose | Example Usage |
|---|
| B | Function Code | 1 (GET), 2 (PUT), 4 (CTL) |
| C | Drive Number | 0-255 |
| D | Cylinder Number | Disk geometry-specific |
| E | Sector Number | Disk geometry-specific |
| HL | Buffer Pointer | Memory address for data |
| DE | DCB/FCB Pointer | Structure for file/device info |
| IY | Drive Control Table Ptr | Pointer to DCT fields like CURCYL |
@VRSEC) and directory sector writing (@WRSSC).[20]
TRSDOS includes utilities tailored for software development and disk preparation. The LINK command connects devices for I/O redirection and chaining, such as linking input/output streams between logical devices (e.g., LINK *KI TO *CL). In the file system, granules—typically groups of 3 to 5 sectors depending on media density—serve as the minimum allocation unit, managed via the Granule Allocation Table (GAT) for efficient file storage and random access.[20] These features streamline the development process, allowing programmers to build and deploy applications directly on TRSDOS media.
Device drivers in TRSDOS support customization for non-standard peripherals through Device Control Blocks (DCBs) and Drive Control Tables (DCTs), which define up to 31 handler entries for I/O routing.[20] Custom handlers are registered via DCB TYPE bits, enabling tailored responses to device-specific requests.[20] I/O redirection is handled by the @CHNIO SVC (20), which chains or filters data streams, such as linking logical devices or applying modifications like the TRAP or SLASH0 filters in high memory.[20] DCT fields, including CURCYL and MAXCYL, manage physical disk parameters for these drivers, ensuring compatibility with varied hardware configurations.[20]
Documentation for these interfaces is comprehensively covered in the Programmer's Guide to TRSDOS Version 6.x, which details SVC usage, register protocols, and driver implementation across chapters on system calls and device management.[20] In 1984, Logical Systems published "The Source," a three-volume set of commented assembler source code for TRSDOS 6.2 (also known as LS-DOS 6.2); Volume 1 covers core OS code, Volume 2 library commands, and Volume 3 utilities (excluding BASIC), with some proprietary sections blanked but opcodes preserved.[22] This resource, originally priced at $99 per volume, aids in-depth study and modification of the system.[22]
Example Usage
One practical example of using TRSDOS involves the DIR command to list files matching a specific pattern, such as BASIC program files. Entering DIR *.BAS displays all files with the .BAS extension on the current drive, showing details including the filename, file type (e.g., BAS), protection level (0-6, where 0 is read/write and 6 is read-only), logical record length, file size in kilobytes, last modification date, and the number of granules allocated to the file.[20] The output is formatted in columns for readability, with each line representing one file, and the display pauses if it exceeds the screen capacity to allow user review.[20]
TRSDOS integrates seamlessly with Disk BASIC for file operations, allowing programs to access files using built-in statements that invoke underlying DOS calls, often via low-level memory manipulation with POKE and PEEK for custom control. For instance, to open a data file for random input access, the statement OPEN #1,"FILE.DAT,RI" assigns file number 1 to FILE.DAT in random input mode (RI), enabling direct record addressing with subsequent FIELD or GET statements.[29] This mode supports fixed-length records, where the file's logical record length (set during creation) determines the buffer size; PEEK can then inspect the file control block at a known memory location (e.g., PEEK(16512) for status flags) to verify open success or handle errors like file-not-found.[29] File access modes such as RI are defined for efficient I/O without delving into sector-level details.[20]
For lower-level programming in assembly language, TRSDOS provides SuperVisor Calls (SVCs) accessible via Z80 instructions to interact with system features like directory reading. A sample snippet to read a specific directory entry using the @DIRRD SVC (number 87 decimal) sets up registers for the drive and entry code, then invokes the call; here's the Z80 code:
LD C, 0 ; Logical drive 0
LD B, 5 ; Directory Entry Code (DEC) example: entry 5
LD HL, [BUFFER](/page/Buffer) ; HL points to 16-byte buffer for entry data
LD A, 87 ; Load @DIRRD SVC number
RST 40H ; Invoke SVC
JP NZ, [ERROR](/page/Error) ; Jump if error (NZ flag set, A holds error [code](/page/Code))
; Buffer now contains [filename](/page/Filename), extent, granules, etc.
[ERROR](/page/Error):
; Handle error, e.g., RET or display [code](/page/Code) in A
LD C, 0 ; Logical drive 0
LD B, 5 ; Directory Entry Code (DEC) example: entry 5
LD HL, [BUFFER](/page/Buffer) ; HL points to 16-byte buffer for entry data
LD A, 87 ; Load @DIRRD SVC number
RST 40H ; Invoke SVC
JP NZ, [ERROR](/page/Error) ; Jump if error (NZ flag set, A holds error [code](/page/Code))
; Buffer now contains [filename](/page/Filename), extent, granules, etc.
[ERROR](/page/Error):
; Handle error, e.g., RET or display [code](/page/Code) in A
This call retrieves the fixed-page directory entry (FPDE) into the buffer, including allocation details like granule map; success sets the Z flag, while failure returns an error code in A (e.g., 12 for invalid DEC).[20] The RST 40H instruction dispatches to the SVC handler in low memory, preserving registers except as specified.
A common scenario for disk management is backing up an entire disk using the BACKUP command, which copies files while preserving directory structure and attributes. The sequence begins with BACKUP :0 TO :1 to mirror drive 0 to drive 1, prompting for source and target disk insertion if needed; for selective backups, use BACKUP *.BAS:0 TO :2 to copy only BASIC files.[20] Error handling is crucial: if the target drive is write-protected or full, TRSDOS halts with an error code (e.g., 9 for disk full) displayed via the last-error mechanism, requiring the user to verify drive status with FREE or reformat the target; always run VERIFY afterward to confirm integrity.[20]