ATARI
DOS
OVERVIEW
The standard Atari Disk Operating System, DOS 2.0S, consists of four separate elements, ranked as follows in order of their “visibility” to the average DOS user.
1. DUP — Disk Utility PackageIt is helpful to understand the entire Input/Output (I/O) process. While this book is intended to give detailed information on the workings of FMS, this overview will attempt to at least show how the four elements of DOS are connected. To this end, we would first call your attention to Figure 1. This figure is, itself, an overview of the entire Atari I/O system, including indications as to how and where data and control flows between the various elements thereof. Figures 1-1 through 1-4 show “close-ups” of portions of this diagram as they relate to the four elements of DOS.
2. CIO — Central Input/Output
3. FMS — File Management System
4. SIO — Serial Input/Output
In these figures, the rectangular boxes represent system elements, and are appropriately labeled. The wide, lettered arrows represent the flow of data (via buffers, control blocks, or even registers) between the various elements. The narrow, numbered arrows show how and where control, and control information, is transferred.
1-1. Disk Utility Package
DUP (which shows as “DUP.SYS” in a disk directory listing) is the most
obvious and visible element of Atari DOS. DUP's function is to provide
the user with keyboard access to the various file management functions
in FMS. It does so via the menu which is displayed when, for example, the
user keys “DOS” from BASIC. Actually, the menu offers several options which
are not directly a part of the FMS (e.g., copy and duplicate files). Refer
to the Atari Disk Operating System II Reference Manual (part number C016347) for more information.
DUP is not an integral part of FMS. DUP may
be relatively easily replaced with a program of the user's choice. In fact,
our own OS/A + does exactly that: instead of a menu, the user is given
a command-driven keyboard interface to the other elements of DOS.
DUP is not even a privileged portion of DOS
(excepting, perhaps, for needing to know a little of the internals of FMS
when it performs a Duplicate Disk function). Any user application program
(and that includes Atari BASIC, BASIC A +, EASMD, and many, many more)
interacts the same way DUP does. Figure 1-1 shows the “proper” flow of
control in DOS. Note that DUP transfers control only to CIO, which, in
turn, transfers control to FMS and thence to SIO. An application program
which maintains this protocol should he able to perform correctly in any
Atari system, regardless of the revision of the OS ROMs and/or FMS.
Of course, control is not the only thing which
DUP must transfer. It must also tell CIO where its data is and what to
do with it. Refer to Figure 1-2 for a diagram of the complete application/CIO
interface (again, it is labeled in this way because DUP is just another
application program as far as the rest of DOS is concerned). CIO always
expects an Input/Output Control Block (IOCB) and usually (i.e., for all
but the simplest operations) needs a buffer into or out of which it may
perform its operations.
1-2. Central Input/Output
CIO is actually the heart of the entire Atari Computer. It is less
than 800 bytes long and yet serves to handle virtually all the input and
output which takes place in the computer. CIO is a part of the Atari “OS
ROMs,” the 10K byte package which also houses the floating point routines,
the default character set, the interrupt handlers, and several device drivers.
The entire set of operations summarized in
Figure 1-2 is covered in detail in the Atari OS Manual (C01655) and will
he covered only briefly here. Readers of COMPUTE!
will also find some helpful material on this subject in issues #18 through
#21 (November, 1981, through February, 1982) in the “INSIGHT: ATARI” columns.
In order to allow easy control and data flow,
CIO is written to expect and provide for eight Input/Output Control Blocks
(IOCBs) which are used to pass the information needed to process the various
kinds of I/O requests. An application places the necessary command and
control information in an IOCB which it selects (data path A). If a buffer
is required, the application must provide one (data path C) and place its
address into the IOCB. When ready to execute the I/O command, the application
places the IOCB number (times 16) in the 6502's X-register (data path C)
and executes a JSR call to CIO (control path 1). Note that a few command
variations may pass data via the 6502's A-register, but we may consider
that simply a special case location of the user's buffer.
When CIO receives control, it examines the
information in the IOCB (and, for some operations, in the user buffer)
to determine what actions it is to perform. Generally, this action requires
the execution of a device handler routine.
A device handler (interchangeably known as
a device driver) is a system routine that performs I/O operations for a
specific device (or class of devices). Examples of device handlers include
the “P:” driver (the printer) and the “E:” driver (the screen/keyboard
editor). Figure 1-3 illustrates the interface between CIO and the various
device handlers. Note that FMS is simply another device handler as far
as CIO is concerned, having been given the name “D:”.
All device drivers are required to contain
a table of address pointers (known as the Device Vector Table) to various
specific routines within themselves, including a device OPEN routine, GET
CHARACTER routine, etc. The name of a device and the address of this table
is placed in CIO's Device Handler Table. When an application program makes
an I/O request to CIO for a specific device, CIO searches the Device Handler
Table for the given name and corresponding Device Vector Table address.
With the thus-located vector table, CIO can then call the appropriate device
handler routine (via a JSR, along control path two of Figure 1-3).
1-3. File Management System
As stated above, FMS is actually simply another device driver as far
as CIO is concerned. The control and data flows shown in Figure 1-3 are
equally valid for all device drivers in the Atari system. Note that many
of the drivers in the default (“as-shipped”) system reside entirely within
the so-called OS ROMs. Although it resides in RAM, what is somewhat unique
about FMS is that the Atari system initialization code contains a segment
of “boot” code which loads FMS into memory upon power-on.
FMS is the system device handler for all I/O
operations that specify the device name “D” (including “Dl:”, “D2:”, etc.).
In order to perform its functions, FMS examines the data in the specified
IOCB (data path F). It may also examine, read, or write data to or from
the user-supplied buffer (data path I). Data path H is used to pass the
IOCB-designator (again, via the X-register) and single-byte transfer data
(via the A-register).
FMS is called upon to perform a variety of
tasks, including all disk I/O, file renaming, protecting, deleting, etc.
Since the rest of this book consists of a listing of FMS along with detailed
explanations of all sections thereof, we will not now dwell on the inner
workings of FMS.
However, we do need to note that, in order
to perform its work, FMS must transfer data to and from the disk. FMS accesses
the disk drive via SIO, the fourth element of DOS.
1-4. Serial Input/Output
SIO is the name given to the component of DOS which drives and controls
the Atari serial I/O bus and the various peripherals (disk, printer, modem,
etc.) which are placed on that bus. Figure 1-4 illustrates the interface
between FMS and SIO, but it could just as well serve to show (for example)
how the printer driver talks to the various Atari printers.
The SIO is primarily driven by a request placed
in SIO's Device Control Block (DCB) by the device handler (data path K)
followed by a transfer of control (control path three) via a JSR. SIO uses
the information in the DCB (data path M) to determine what it needs to
do. If the DCB specifies a serial bus data transfer (as opposed to, for
example, a status request), then the address of the data buffer must also
be passed (via a field in the DCB). For example, the FMS buffer shown is
accessed via data paths J (from FMS) and L (from SIO).
Although SIO only understands the single system
DCB, the buffer specified may be located anywhere in memory. FMS takes
advantage of this to implement “burst I/O” (discussed in section 12), which
has SIO transferring data directly to or from the user's buffer (data path
E).
Since the actual disk data transfer occurs
in fact within the 810 disk drive and, since SIO communicates to the drive
via data path N, one might reasonably argue that the disk drive constitutes
a fifth component of DOS. However, because the disk drive functions are
preprogrammed in ROM, and because SIO implements the only method of accessing
the disk (as well as most other peripherals), then, for all practical purposes,
even machine language software may treat SIO as the last link in the I/O
chain on the Atari Computers.
Once again, we remind you to study Figure
1. In the following dissertation and dissection of FMS, we shall refer
to this chart often.
Return to Table of Contents | Previous Chapter | Next Chapter
