Remove trailing whitespace, normalize dot commands

This commit is contained in:
T. Joseph Carter 2017-07-20 15:45:47 -07:00
parent d9046beb1d
commit b773fd6d8c
27 changed files with 382 additions and 382 deletions

View File

@ -7,8 +7,5 @@ insert_final_newline = true
trim_trailing_whitespace = true
max_line_length=80
[*.txt]
trim_trailing_whitespace = false
[*.md]
trim_trailing_whitespace = false

View File

@ -1,35 +1,35 @@
.ec ^
.ec^
.na
.ll60
.m11
.m22
.m48
.fo ''-%-
.pn 5
.pn5
.pi0
.br
.np
.ce
CHAPTER 1 - INTRODUCTION
.sp 2
.sp2
Beneath Apple DOS is intended
to serve as a companion to Apple's
DOS Manual, providing additional
information for the advanced
information for the advanced
programmer or
the novice Apple user who wants to
know more about the structure of
diskettes.
diskettes.
It is not the intent of this manual
to replace the documentation provided
by Apple Computer Inc.
by Apple Computer Inc.
Although, for the
sake of
sake of
continuity, some of the material
covered in the Apple manual is also
covered here, it will be assumed that
the reader is reasonably familiar
the reader is reasonably familiar
with the
contents of the DOS Manual. Since
all chapters presented here may not
@ -45,7 +45,7 @@ It also draws from application notes,
articles, and discussions with
knowledgeable people. This
manual was not prepared with the
assistance of Apple Computer Inc.
assistance of Apple Computer Inc.
Although no
guarantee can be made concerning the
accuracy of the information
@ -56,7 +56,7 @@ tested.
There were several reasons
for writing Beneath Apple DOS:
.SP1
.sp1
.nf
To show direct assembly language access to DOS.
.br
@ -83,15 +83,15 @@ internal workings of DOS. With the
advent of DOS 3.3, the old 3.2 manual
was updated but the body of
information in it remained
essentially intact. Beyond these
Apple manuals,
essentially intact. Beyond these
Apple manuals,
there have been no significant
additions to the documentation on
DOS,
DOS,
apart from a few articles in APPLE
user group magazines and newsletters.
This manual takes up
where the
where the
Disk Operating System
Manual leaves off.
.bp

View File

@ -2,7 +2,7 @@
.np
.ce
CHAPTER 2 - THE EVOLUTION OF DOS
.sp 2
.sp2
Since its introduction, Apple DOS has
gone through three major versions.
@ -30,10 +30,10 @@ such, it had a number of bugs. With the
movement towards the APPLE II PLUS
and the introduction of the AUTOSTART
ROM, a new release was needed.
.SP1
.sp1
DOS 3.2 - 16 February 1979
Although DOS 3.2 embodied more
Although DOS 3.2 embodied more
changes from its
predecessor than any other release of
DOS, 90% of the basic structure of DOS 3.1
@ -77,7 +77,7 @@ can.
.bp
- Some DOS commands are allowed to
create a new file, others will not.
create a new file, others will not.
Under DOS 3.1, any reference to a
file that didn't exist, caused it to
be created. This forced DOS 3.1 to
@ -140,7 +140,7 @@ creating master diskettes. UPDATE
and allows the HELLO file to be
renamed.
.br
.pi0
.pi0
.in0
.ps1
.sp1
@ -163,14 +163,14 @@ new bootstrap and state ROM chips for
the disk controller card which
provide the capability to
format, read, and write a
diskette with 16 sectors.
diskette with 16 sectors.
(These ROMs are the
same ones used with the LANGUAGE
SYSTEM.)
SYSTEM.)
This improvement
represents almost a 25% increase in
available disk space over the old
13 sector format.
13 sector format.
Also included in the 3.3
package is an updated version of the
DOS manual, a BASICS diskette (for 13
@ -242,7 +242,7 @@ Because the COPY program was rewritten
under 3.3, that restriction no longer
applies.
.br
.pi0
.pi0
.in0
.ps1
.nx ch3.1

View File

@ -2,12 +2,12 @@
.np
.ce
CHAPTER 3 - DISK II HARDWARE AND TRACK FORMATTING
.sp 2
.sp2
Apple Computer's excellent manual on
the Disk Operating System (DOS)
provides only very basic information
about how diskettes are formatted.
about how diskettes are formatted.
This chapter will explain in detail
how information is structured on a
diskette. The first section will
@ -16,7 +16,7 @@ hardware, and may be skipped by those
already familiar with the DOS manual.
For system housekeeping, DOS divides
diskettes into tracks and sectors.
diskettes into tracks and sectors.
This is done during the
initialization process. A track is a
physically defined circular path
@ -26,14 +26,14 @@ track is identified by its distance
from the center of the disk. Similar
to a phonograph stylus, the
read/write head of the disk drive may
be positioned over any given track.
be positioned over any given track.
The tracks are similar to the grooves
in a record, but they are not
connected in a spiral. Much like
playing a record, the diskette is
spun at a constant speed while the
data is read from or written to its
surface with the read/write head.
surface with the read/write head.
Apple formats its diskettes into 35
tracks. They are numbered from 0 to
34, track 0 being the outermost track
@ -70,7 +70,7 @@ protection schemes.
A sector is a subdivision of a track.
It is the smallest unit of
"updatable" data on the diskette.
"updatable" data on the diskette.
DOS generally reads or writes data a
sector at a time. This is to avoid
using a large chunk of memory as a
@ -86,7 +86,7 @@ locate the first sector of the track.
The implication is that
the software must be able
to locate any given track and sector
with no help from the hardware.
with no help from the hardware.
This scheme, known as "soft sectoring",
takes a little more space
for storage but allows flexibility,
@ -100,14 +100,14 @@ sector formats.
.ne10
.nf
DISK ORGANIZATION
.SP1
.sp1
TRACKS
All DOS versions................35
.SP1
.sp1
SECTORS PER TRACK
DOS 3.2.1 and earlier...........13
DOS 3.3.........................16
.SP1
.sp1
SECTORS PER DISKETTE
DOS 3.2.1 and earlier..........455
DOS 3.3........................560
@ -118,15 +118,15 @@ BYTES PER SECTOR
BYTES PER DISKETTE
DOS 3.2.1 and earlier.......116480
DOS 3.3.....................143360
.SP1
.sp1
USABLE* SECTORS FOR DATA STORAGE
DOS 3.2.1 and earlier..........403
DOS 3.3........................496
.SP1
.sp1
USABLE* BYTES PER DISKETTE
DOS 3.2.1 and earlier.......103168
DOS 3.3.....................126976
.SP2
.sp2
* Excludes DOS, VTOC, and CATALOG
.bp
TRACK FORMATTING
@ -186,12 +186,12 @@ least significant bit cell would be
bit cell 0. When reference is made
to a specific data bit (i.e. data bit
5), it is with respect to the
corresponding bit cell (bit cell 5).
corresponding bit cell (bit cell 5).
Data is written and read serially,
one bit at a time. Thus, during a
write operation, bit cell 7 of each
byte would be written first, with bit
cell 0 being written last.
cell 0 being written last.
Correspondingly, when data is being
read back from the diskette, bit cell
7 is read first and bit cell 0 is
@ -245,19 +245,19 @@ instructed to write in 32
cycle intervals. If not, zero bits
will continue to be written every four
cycles, which is, in fact, exactly
how self-sync bytes are created.
how self-sync bytes are created.
Self-sync bytes will be covered in
detail shortly.
.sp1
*** INSERT FIGURE 3.6 HERE ***
A "field" is made up of a group of
A "field" is made up of a group of
consecutive
bytes. The number of bytes varies,
depending upon the nature of the
field. The two types of fields
present on a diskette are the Address
Field and the Data Field. They are
Field and the Data Field. They are
similar in that they both contain a
prologue, a data area, a checksum, and
an epilogue. Each field on a track is
@ -277,7 +277,7 @@ beneath the read/write head.
All gaps are primarily alike in
content, consisting of self-sync
hexadecimal FF's, and vary only in
the number of bytes they contain.
the number of bytes they contain.
Figure 3.7 is a diagram of a portion
of a typical track, broken into its
major components.
@ -286,7 +286,7 @@ major components.
Self-sync or auto-sync bytes are
special bytes that make up the three
different types of gaps on a track.
different types of gaps on a track.
They are so named because of their
ability to automatically bring the
hardware into synchronization with
@ -311,14 +311,14 @@ clock bits from data bits,
the hardware finds
the first bit cell with data in it
and proceeds to read the following
seven data
seven data
bits into the eight bit latch. In
effect, it assumes that it had
started at the beginning of a data
byte. Of course, in reality, the
odds of its having started at the
beginning of a byte are only one in
eight.
eight.
Pictured in Figure 3.8 is a small
portion of a track. The clock bits
have been stripped out and 0's and
@ -381,7 +381,7 @@ the track.
We can now discuss the particular
portions of a track in detail. The
three gaps will be covered first.
three gaps will be covered first.
Unlike some other disk formats, the
size of the three gap types will vary
from drive to drive and even from
@ -424,13 +424,13 @@ clarity).
.bp
Gap 2 appears after each Address
Field and before each Data Field.
Field and before each Data Field.
Its length varies from five to ten bytes
on a normal drive. The primary
purpose of Gap 2 is to provide time
for the information in an Address
Field to be decoded by the computer
before a read or write takes place.
before a read or write takes place.
If the gap were too short, the
beginning of the Data Field might
spin past while DOS was still
@ -444,7 +444,7 @@ will occur in exactly the same spot
each time. This is due to the fact
that the drive which is rewriting
the Data Field may not be the one
which originally INITed or wrote it.
which originally INITed or wrote it.
Since the speed of the drives can
vary, it is possible that the write
could start in mid-byte. (See Figure
@ -472,7 +472,7 @@ boundary, thus altering an existing
byte. Figure 3.12 illustrates this.
.sp1
*** INSERT FIGURE 3.11 HERE ***
.SP1
.sp1
*** INSERT FIGURE 3.12 HERE ***
Gap 3 appears after each
@ -485,7 +485,7 @@ additional time needed to manipulate
the data that has been read before
the next sector is to be read. The
length of Gap 3 is not as critical as
that of Gap 2. If the
that of Gap 2. If the
following Address
Field is missed, DOS can always wait
for the next time it spins around
@ -503,7 +503,7 @@ An examination of the contents of the
two types of fields is in order.
The Address Field contains
the "address" or identifying
information about the Data Field
information about the Data Field
which follows it. The volume, track,
and sector number of any given sector
can be thought of as its "address",
@ -519,7 +519,7 @@ Figure 3.13.
The prologue consists of three bytes
which form a unique sequence, found
in no other component of the track.
in no other component of the track.
This fact enables DOS to locate an
Address Field with almost no
possibility of error. The three
@ -539,7 +539,7 @@ where it is positioned on a
particular diskette. The checksum is
computed by exclusive-ORing the first
three pieces of information, and is
used to verify its integrity.
used to verify its integrity.
Lastly follows the epilogue, which
contains the three bytes $DE, $AA and
$EB. Oddly, the $EB is always written
@ -558,14 +558,14 @@ Field. Much like the Address Field,
it consists of a prologue, data,
checksum, and an epilogue. (Refer to
Figure 3.14) The prologue is
different only in the third byte.
different only in the third byte.
The bytes are $D5, $AA, and $AD,
which again form a unique sequence,
enabling DOS to locate the beginning
of the sector data. The data
consists of 342 bytes of encoded
data. The encoding scheme used will
be discussed in the next section.
be discussed in the next section.
The data is followed by a checksum
byte, used to verify the integrity of
the data just read. The epilogue

View File

@ -2,12 +2,12 @@
.np
.ce
CHAPTER 3 - DISK II HARDWARE AND TRACK FORMATTING
.sp 2
.sp2
Apple Computer's excellent manual on
the Disk Operating System (DOS)
provides only very basic information
about how diskettes are formatted.
about how diskettes are formatted.
This chapter will explain in detail
how information is structured on a
diskette. The first section will
@ -16,7 +16,7 @@ hardware, and may be skipped by those
already familiar with the DOS manual.
For system housekeeping, DOS divides
diskettes into tracks and sectors.
diskettes into tracks and sectors.
This is done during the
initialization process. A track is a
physically defined circular path
@ -26,14 +26,14 @@ track is identified by its distance
from the center of the disk. Similar
to a phonograph stylus, the
read/write head of the disk drive may
be positioned over any given track.
be positioned over any given track.
The tracks are similar to the grooves
in a record, but they are not
connected in a spiral. Much like
playing a record, the diskette is
spun at a constant speed while the
data is read from or written to its
surface with the read/write head.
surface with the read/write head.
Apple formats its diskettes into 35
tracks. They are numbered from 0 to
34, track 0 being the outermost track
@ -70,7 +70,7 @@ protection schemes.
A sector is a subdivision of a track.
It is the smallest unit of
"updatable" data on the diskette.
"updatable" data on the diskette.
DOS generally reads or writes data a
sector at a time. This is to avoid
using a large chunk of memory as a
@ -86,7 +86,7 @@ locate the first sector of the track.
The implication is that
the software must be able
to locate any given track and sector
with no help from the hardware.
with no help from the hardware.
This scheme, known as "soft sectoring",
takes a little more space
for storage but allows flexibility,
@ -100,14 +100,14 @@ sector formats.
.ne10
.nf
DISK ORGANIZATION
.SP1
.sp1
TRACKS
All DOS versions................35
.SP1
.sp1
SECTORS PER TRACK
DOS 3.2.1 and earlier...........13
DOS 3.3.........................16
.SP1
.sp1
SECTORS PER DISKETTE
DOS 3.2.1 and earlier..........455
DOS 3.3........................560
@ -118,15 +118,15 @@ BYTES PER SECTOR
BYTES PER DISKETTE
DOS 3.2.1 and earlier.......116480
DOS 3.3.....................143360
.SP1
.sp1
USABLE* SECTORS FOR DATA STORAGE
DOS 3.2.1 and earlier..........403
DOS 3.3........................496
.SP1
.sp1
USABLE* BYTES PER DISKETTE
DOS 3.2.1 and earlier.......103168
DOS 3.3.....................126976
.SP2
.sp2
* Excludes DOS, VTOC, and CATALOG
.bp
TRACK FORMATTING
@ -186,12 +186,12 @@ least significant bit cell would be
bit cell 0. When reference is made
to a specific data bit (i.e. data bit
5), it is with respect to the
corresponding bit cell (bit cell 5).
corresponding bit cell (bit cell 5).
Data is written and read serially,
one bit at a time. Thus, during a
write operation, bit cell 7 of each
byte would be written first, with bit
cell 0 being written last.
cell 0 being written last.
Correspondingly, when data is being
read back from the diskette, bit cell
7 is read first and bit cell 0 is
@ -245,19 +245,19 @@ instructed to write in 32
cycle intervals. If not, zero bits
will continue to be written every four
cycles, which is, in fact, exactly
how self-sync bytes are created.
how self-sync bytes are created.
Self-sync bytes will be covered in
detail shortly.
.sp1
*** INSERT FIGURE 3.6 HERE ***
A "field" is made up of a group of
A "field" is made up of a group of
consecutive
bytes. The number of bytes varies,
depending upon the nature of the
field. The two types of fields
present on a diskette are the Address
Field and the Data Field. They are
Field and the Data Field. They are
similar in that they both contain a
prologue, a data area, a checksum, and
an epilogue. Each field on a track is
@ -277,7 +277,7 @@ beneath the read/write head.
All gaps are primarily alike in
content, consisting of self-sync
hexadecimal FF's, and vary only in
the number of bytes they contain.
the number of bytes they contain.
Figure 3.7 is a diagram of a portion
of a typical track, broken into its
major components.
@ -286,7 +286,7 @@ major components.
Self-sync or auto-sync bytes are
special bytes that make up the three
different types of gaps on a track.
different types of gaps on a track.
They are so named because of their
ability to automatically bring the
hardware into synchronization with
@ -311,14 +311,14 @@ clock bits from data bits,
the hardware finds
the first bit cell with data in it
and proceeds to read the following
seven data
seven data
bits into the eight bit latch. In
effect, it assumes that it had
started at the beginning of a data
byte. Of course, in reality, the
odds of its having started at the
beginning of a byte are only one in
eight.
eight.
Pictured in Figure 3.8 is a small
portion of a track. The clock bits
have been stripped out and 0's and
@ -381,7 +381,7 @@ the track.
We can now discuss the particular
portions of a track in detail. The
three gaps will be covered first.
three gaps will be covered first.
Unlike some other disk formats, the
size of the three gap types will vary
from drive to drive and even from
@ -424,13 +424,13 @@ clarity).
.bp
Gap 2 appears after each Address
Field and before each Data Field.
Field and before each Data Field.
Its length varies from five to ten bytes
on a normal drive. The primary
purpose of Gap 2 is to provide time
for the information in an Address
Field to be decoded by the computer
before a read or write takes place.
before a read or write takes place.
If the gap were too short, the
beginning of the Data Field might
spin past while DOS was still
@ -444,7 +444,7 @@ will occur in exactly the same spot
each time. This is due to the fact
that the drive which is rewriting
the Data Field may not be the one
which originally INITed or wrote it.
which originally INITed or wrote it.
Since the speed of the drives can
vary, it is possible that the write
could start in mid-byte. (See Figure
@ -472,7 +472,7 @@ boundary, thus altering an existing
byte. Figure 3.12 illustrates this.
.sp1
*** INSERT FIGURE 3.11 HERE ***
.SP1
.sp1
*** INSERT FIGURE 3.12 HERE ***
Gap 3 appears after each
@ -485,7 +485,7 @@ additional time needed to manipulate
the data that has been read before
the next sector is to be read. The
length of Gap 3 is not as critical as
that of Gap 2. If the
that of Gap 2. If the
following Address
Field is missed, DOS can always wait
for the next time it spins around
@ -503,7 +503,7 @@ An examination of the contents of the
two types of fields is in order.
The Address Field contains
the "address" or identifying
information about the Data Field
information about the Data Field
which follows it. The volume, track,
and sector number of any given sector
can be thought of as its "address",
@ -519,7 +519,7 @@ Figure 3.13.
The prologue consists of three bytes
which form a unique sequence, found
in no other component of the track.
in no other component of the track.
This fact enables DOS to locate an
Address Field with almost no
possibility of error. The three
@ -539,7 +539,7 @@ where it is positioned on a
particular diskette. The checksum is
computed by exclusive-ORing the first
three pieces of information, and is
used to verify its integrity.
used to verify its integrity.
Lastly follows the epilogue, which
contains the three bytes $DE, $AA and
$EB. Oddly, the $EB is always written
@ -558,6 +558,6 @@ Field. Much like the Address Field,
it consists of a prologue, data,
checksum, and an epilogue. (Refer to
Figure 3.14) The prologue is
different only in the third byte.
different only in the third byte.
The bytes are $D5, $AA, and $AD,
which again form a

View File

@ -1,9 +1,9 @@
.SP2
.sp2
DATA FIELD ENCODING
Due to Apple's hardware, it is not
possible to read all 256 possible
byte values from a diskette.
byte values from a diskette.
This is not a great problem, but it
does require that the data written to
the disk be encoded. Three different
@ -17,7 +17,7 @@ bits. It would thus require 512
"disk" bytes for each 256 byte sector
of data. Had this technique been used
for sector data, no more than 10
sectors would have fit on a track.
sectors would have fit on a track.
This amounts to about 88K of data per
diskette, or roughly 72K of space
available to the user; typical for 5
@ -43,7 +43,7 @@ comparable drives of the day.
Currently, of course, DOS 3.3
features 16 sectors per track and
provides a 23% increase in disk
storage over the 13 sector format.
storage over the 13 sector format.
This was made possible by a hardware
modification (the P6 PROM on the disk
controller card) which allowed a "6
@ -55,7 +55,7 @@ bytes.
These three different encoding
techniques
will now be covered in some detail.
will now be covered in some detail.
The hardware for DOS 3.2.1 (and
earlier versions of DOS) imposed a
number of restrictions upon how data
@ -86,7 +86,7 @@ contained in the Address Field. It
is quite easy to decode the data, since the
byte with the odd bits is simply
shifted left and logically ANDed with
the byte containing the even bits.
the byte containing the even bits.
This is illustrated in Figure 3.16.
.sp1
*** INSERT FIGURE 3.16 HERE ***
@ -121,7 +121,7 @@ bytes, thus leaving an exact mapping
between five bit data bytes and eight bit
"disk" bytes. The process of
converting eight bit data bytes to eight bit
"disk" bytes, then, is twofold.
"disk" bytes, then, is twofold.
An overview is diagrammed in Figure
3.17.
.sp1
@ -132,7 +132,7 @@ up a sector must be translated to
five bit bytes. This is done by the
"prenibble" routine at $B800. It is
a fairly involved process, involving
a good deal of bit rearrangement.
a good deal of bit rearrangement.
Figure 3.18 shows the before and
after of prenibbilizing. On the left
is a buffer of eight bit data bytes, as
@ -141,7 +141,7 @@ package by DOS. Each byte in this
buffer is represented by a letter (A,
B, C, etc.) and each bit by a number
(7 through 0). On the right side are
the results of the transformation.
the results of the transformation.
The primary buffer contains five
distinct areas of five bit bytes (the
top three bits of the eight bit bytes
@ -194,7 +194,7 @@ the checksum computation to decode
data, the
transformation shown in Figure 3.20
greatly facilitates the time
constraint. As the data is being
constraint. As the data is being
read from a sector the accumulator
contains the cumulative result of
all previous bytes, exclusive-ORed
@ -230,7 +230,7 @@ with only 64 needed. An additional
requirement was introduced to force
the mapping to be one to one, namely,
that there must be at least two
adjacent bits set, excluding bit 7.
adjacent bits set, excluding bit 7.
This produces exactly 64 valid "disk"
values. The initial transformation
is done by the prenibble routine
@ -301,7 +301,7 @@ into a "pseudo" or soft sector number
used by DOS. For example, if the
sector number found on the disk were a
2, this is used as an offset into a
table where the number $0B is found.
table where the number $0B is found.
Thus, DOS treats the physical sector
2 as sector 11 ($0B) for all intents
and purposes. This presents no
@ -322,7 +322,7 @@ access time.
It is interesting to point out that
Pascal, Fortran, and CP/M diskettes
all use software interleaving also.
all use software interleaving also.
However, each uses a different
sector order. A comparison of these
differences is presented in Figure
@ -330,4 +330,4 @@ differences is presented in Figure
.sp1
*** INSERT FIGURE 3.24 (22) HERE ***
.br
.nxch4
.nx ch4

View File

@ -38,7 +38,7 @@ with new files or expansions of
existing files. An example of the way
DOS uses sectors is given in Figure
4.1.
.SP1
.sp1
*** INSERT FIGURE 4.1 ***
.sp1
DISKETTE SPACE ALLOCATION
@ -96,7 +96,7 @@ following format (all byte offsets are
given in base 16, hexadecimal):
.np
VOLUME TABLE OF CONTENTS (VTOC) FORMAT
.SP1
.sp1
.un
BYTE DESCRIPTION
00 Not used
@ -126,14 +126,14 @@ C4-FF Bit maps for additional tracks if there are more
than 35 tracks per diskette
.bp
BIT MAPS OF FREE SECTORS ON A GIVEN TRACK
.SP1
.sp1
A four byte binary string of ones and zeros,
representing free and allocated sectors respectively.
Hexadecimal sector numbers are assigned to bit
positions as follows:
.sp1
BYTE SECTORS
+0 FEDC BA98
+0 FEDC BA98
+1 7654 3210
+2 .... .... (not used)
+3 .... .... (not used)
@ -151,7 +151,7 @@ An example of a VTOC sector is given
in Figure 4.2. This VTOC corresponds
to the map of the diskette given in
Figure 4.1.
.SP1
.sp1
*** INSERT FIGURE 4.2 ***
.bp
THE CATALOG
@ -187,7 +187,7 @@ sector (sector 1)
has a zero pointer to indicate
that there are no more catalog
sectors in the chain.
.SP1
.sp1
*** INSERT FIGURE 4.3 ***
In each catalog
@ -203,8 +203,8 @@ described on the following page.
.sp1
.np
CATALOG SECTOR FORMAT
.SP1
.UN
.sp1
.un
BYTE DESCRIPTION
00 Not used
01 Track number of next catalog sector (usually 11 hex)
@ -219,9 +219,9 @@ BA-DC Sixth file descriptive entry
DD-FF Seventh file descriptive entry
.bp
FILE DESCRIPTIVE ENTRY FORMAT
.SP1
.sp1
RELATIVE
.UN
.un
BYTE DESCRIPTION
00 Track of first track/sector list sector.
If this is a deleted file, this byte contains a hex
@ -260,9 +260,9 @@ was needed to describe them. There
are four entries in use and three
entries which have never been used
and contain zeros.
.SP1
.sp1
*** INSERT FIGURE 4.4 ***
.SP1
.sp1
THE TRACK/SECTOR LIST
Each file has
@ -276,7 +276,7 @@ sector points to this T/S List sector
which, in turn, points to each sector
in the file. This concept is
diagramed in Figure 4.5.
.SP1
.sp1
*** INSERT FIGURE 4.5 ***
.bp
The format of a Track/Sector List
@ -317,9 +317,9 @@ have no data sectors allocated
in the T/S List. This distinction is not always handled
correctly by DOS. The VERIFY command, for instance, stops when
it gets to the first zero T/S List entry and can not be used
to verify some random organization text files.
to verify some random organization text files.
An example T/S List sector is given in Figure 4.6.
An example T/S List sector is given in Figure 4.6.
The example file (HELLO, from our
previous examples) has only one data
sector, since it is less than 256
@ -328,7 +328,7 @@ sector and the T/S List sector, HELLO
is 2 sectors long, and this will be
the value shown when a CATALOG
command is done.
.SP1
.sp1
*** INSERT FIGURE 4.6 ***
.bp
Following the Track/Sector pointer in
@ -349,8 +349,8 @@ the Track/Sector List, DOS can read
each sector of the file in the correct order so
that the programmer need never know
that the data was broken up into
sectors at all.
.SP1
sectors at all.
.sp1
TEXT FILES
The TEXT data type is the least
@ -389,7 +389,7 @@ less efficient in the use of disk space than
with a BINARY type file, since each
digit must occupy a full byte in the
file.
.SP1
.sp1
*** INSERT FIGURE 4.7 ***
.bp
BINARY FILES
@ -399,7 +399,7 @@ shown in Figure 4.8. An exact copy of
the memory involved is written to the
disk sector(s), preceded by the
memory address where it was found and
the length (a total of four bytes).
the length (a total of four bytes).
The address and length (in low order,
high order format) are those given in
the A and L keywords from the BSAVE
@ -419,9 +419,9 @@ address either by providing the A
entered, or by changing the address
in the first two bytes of the file on
the diskette.
.SP1
.sp1
*** INSERT FIGURE 4.8 ***
.SP1
.sp1
APPLESOFT AND INTEGER FILES
A BASIC program, be it APPLESOFT or
@ -431,7 +431,7 @@ format of an APPLESOFT file type is
given in Figure 4.9 and that of
INTEGER BASIC in 4.10. When the SAVE
command is typed, DOS determines the
location of the BASIC program image
location of the BASIC program image
in memory and its length. Since a
BASIC program is always loaded at a
location known to the BASIC
@ -453,7 +453,7 @@ scope of this manual, but a
breakdown of the example INTEGER
BASIC program is given in Figure
4.10.
.SP1
.sp1
*** INSERT FIGURES 4.9 AND 4.10 ***
.bp
OTHER FILE TYPES (S,R,A,B)
@ -478,7 +478,7 @@ based on additional information
stored with the image itself. The
format for this type of file is given
in the documentation accompanying the
DOS TOOLKIT.
DOS TOOLKIT.
It is recommended that if the
reader requires more information
about R files he should refer to that

View File

@ -2,7 +2,7 @@
.np
.ce
CHAPTER 5 - THE STRUCTURE OF DOS
.sp 2
.sp2
DOS MEMORY USE
DOS is an assembly language program
@ -37,7 +37,7 @@ on a 48K system, it will not boot on
less than 48K since the RAM DOS
occupied does not exist on a smaller
machine.
.SP1
.sp1
*** INSERT FIGURE 5.1 ***
A diagram of DOS's memory for a 48K
@ -57,7 +57,7 @@ changed from 3, the space occupied by
the file buffers also changes. This
affects the placement of HIMEM,
moving it up or down with fewer or
more buffers respectively.
more buffers respectively.
The 3.5K
above the file buffers is occupied by
@ -69,7 +69,7 @@ interfacing to BASIC, interpreting
commands, and managing the file
buffers. All disk functions are
passed on via subroutine calls to the
file manager.
file manager.
.bp
The file manager,
occupying about 4.3K, is a collection
@ -85,7 +85,7 @@ lanaguage program which is not part
of DOS. This interface is generalized
through a group of vectors in page 3
of RAM and is documented in the next
chapter.
chapter.
The last 2.5K of DOS is the
Read/Write Track/Sector (RWTS)
@ -147,19 +147,19 @@ table itself starts at $3D0.
.ll60
.bp
DOS VECTOR TABLE ($3D0-$3FF)
.NP
.np
ADDR USAGE
3D0 A JMP (jump or GOTO) instruction to the DOS warmstart
routine. This routine reenters DOS but does not
routine. This routine reenters DOS but does not
discard the current BASIC program and does not reset
MAXFILES or other DOS environmental variables.
3D3 A JMP to the DOS coldstart routine. This routine
3D3 A JMP to the DOS coldstart routine. This routine
reinitializes DOS as if it was rebooted, clearing the
current BASIC file and resetting HIMEM.
3D6 A JMP to the DOS file manager subroutine to allow a
user written assembly language program to call it.
3D9 A JMP to the DOS Read/Write Track/Sector (RWTS)
routine to allow user written assembly language
routine to allow user written assembly language
programs to call it.
3DC A short subroutine which locates the input parameter
list for the file manager to allow a user written
@ -170,9 +170,9 @@ ADDR USAGE
up input parameters before calling RWTS.
3EA A JMP to the DOS subroutine which "reconnects" the DOS
intercepts to the keyboard and screen data streams.
3EF A JMP to the routine which will handle a BRK machine
3EF A JMP to the routine which will handle a BRK machine
language instruction. This vector is only supported by
the AUTOSTART ROM. Normally the vector contains the
the AUTOSTART ROM. Normally the vector contains the
address of the monitor ROM subroutine which displays
the registers.
3F2 LO/HI address of routine which will handle RESET for
@ -185,7 +185,7 @@ ADDR USAGE
RESET was pressed. If a power-up occured, the
AUTOSTART ROM ignores the address at 3F2 (since it has
never been initialized) and attempts to boot a
diskette. To prevent this from happening when you
diskette. To prevent this from happening when you
change $3F2 to handle your own RESETs, EOR (exclusive
OR) the new value at $3F2 with a $A5 and store the
result in the power-up byte.
@ -216,7 +216,7 @@ The location of these stages on the
diskette and a memory map are given
in Figure 5.2 and a description of
the bootstrap process follows.
.SP1
.sp1
*** INSERT FIGURE 5.2 ***
The first boot stage (let's call it
@ -368,7 +368,7 @@ The various stages of the bootstrap
process will be covered again in greater
detail in Chapter 8, DOS PROGRAM
LOGIC.
.SP1
.sp1
*** INSERT FIGURE 5.3 HERE ***
.BR
.NX CH6.1
.br
.nx CH6.1

View File

@ -29,7 +29,7 @@ eight two byte toggles that essentially
represent pulling a TTL line high or
low. Applications which could use
direct disk access range from a
user written operating system to DOS-independent
user written operating system to DOS-independent
utility programs. The
device address assignments are given
in Figure 6.1.
@ -64,7 +64,7 @@ ADDRESS LABEL DESCRIPTION
.bp
The addresses are slot dependent and
the offsets are computed by
multiplying the slot number by 16.
multiplying the slot number by 16.
In hexadecimal this works out nicely
and we can add the value $s0 (where s
is the slot number) to the base
@ -106,7 +106,7 @@ Basically, each of the four phases
(0-3) must be turned on and then off
again. Done in ascending order, this
moves the arm inward. In descending
order, this moves the arm outward.
order, this moves the arm outward.
The timing between accesses to these
locations is critical, making this a
non-trivial exercise. It is
@ -119,10 +119,10 @@ MOTOR OFF/ON:
.sp1
.nf
LDA $C088,X Turn motor off.
.SP1
.sp1
LDA $C089,X Turn motor on.
.SP1
.FI
.sp1
.fi
NOTE: A sufficient delay should be
provided to allow the motor time to
come up to speed. Shugart recommends
@ -132,39 +132,39 @@ until data starts to change.
.bp
.nf
ENGAGE DRIVE 1/2:
.SP1
.sp1
LDA $C08A,X Engage drive 1.
.sp1
LDA $C08B,X Engage drive 2.
.sp1
READ A BYTE:
.SP1
.sp1
READ LDA $C08C,X
BPL READ
.SP1
.FI
.sp1
.fi
NOTE: $C08E,X must already have been
accessed to assure Read mode. The
loop is necessary to assure that the
accumulator will contain valid data.
accumulator will contain valid data.
If the data latch does not yet
contain valid data the high bit will
be zero.
.sp1
.nf
SENSE WRITE PROTECT:
.SP1
.sp1
LDA $C08D,X
LDA $C08E,X Sense write protect.
BMI ERROR If high bit set, protected.
.sp1
WRITE LOAD AND WRITE A BYTE
.SP1
.sp1
LDA DATA
STA $C08D,X Write load.
ORA $C08C,X Write byte.
.sp1
.FI
.fi
NOTE: $C08F,X must already have been
accessed to insure Write mode and a
100 microsecond delay should be
@ -195,7 +195,7 @@ without an adjustment.
WRITE STA $C08D,X (5)
ORA $C08C,X (4)
RTS (6)
.SP2
.sp2
CALLING READ/WRITE TRACK/SECTOR (RWTS)
Read/Write Track/Sector (RWTS) exists
@ -205,7 +205,7 @@ roughly the top third of the DOS
program. The interface to RWTS is
standardized and thoroughly documented by Apple
and may be called by a
program running outside of DOS.
program running outside of DOS.
There are two subroutines which must
be called or whose function must be
@ -241,7 +241,7 @@ on the facing page (offsets are given in hexadecimal):
.bp
.nf
INPUT/OUTPUT CONTROL BLOCK - GENERAL FORMAT
.SP1
.sp1
BYTE DESCRIPTION
00 Table type, must be $01
01 Slot number times 16 (s0: s=slot. Example: $60)
@ -272,14 +272,14 @@ BYTE DESCRIPTION
10 Drive number of last access (must be initialized)
.sp1
DEVICE CHARACTERISTICS TABLE
.SP1
.sp1
BYTE DESCRIPTION
00 Device type (should be $00 for DISK II)
01 Phases per track (should be $01 for DISK II)
02-03 Motor on time count (should be $EFD8 for DISK II)
.bp
RWTS IOB BY CALL TYPE
.SP1
.sp1
SEEK Move disk arm to desired track
.sp1
Input: Byte 00 - Table type ($01)
@ -293,7 +293,7 @@ Input: Byte 00 - Table type ($01)
.sp1
Output: Byte 0D - Return code (See previous definition)
0F - Current Slot number * 16
10 - Current Drive number
10 - Current Drive number
.sp1
READ Read a sector into a specified buffer
.sp1
@ -314,7 +314,7 @@ Input: Byte 00 - Table type ($01)
Output: Byte 0D - Return code (See previous definition)
0E - Current Volume number
0F - Current Slot number * 16
10 - Current Drive number
10 - Current Drive number
.bp
WRITE Write a sector from a specified buffer
.sp1
@ -335,7 +335,7 @@ Input: Byte 00 - Table type ($01)
Output: Byte 0D - Return code (See previous definition)
0E - Current Volume number
0F - Current Slot number * 16
10 - Current Drive number
10 - Current Drive number
.sp1
FORMAT Initialize the diskette (does not put DOS on disk,
create a VTOC/CATALOG, or store HELLO program)
@ -353,6 +353,6 @@ Input: Byte 00 - Table type ($01)
Output: Byte 0D - Return code (See previous definition)
0E - Current Volume number
0F - Current Slot number * 16
10 - Current Drive number
10 - Current Drive number
.bp
.nx ch6.2

View File

@ -7,7 +7,7 @@ the central third of the DOS program.
The interface to these routines is
generalized in such a way that they
may be called by a program running
outside of DOS. The definition of
outside of DOS. The definition of
this interface has
never been published by APPLE (or
anyone else, for that manner) but
@ -19,7 +19,7 @@ these routines may be relied upon as
"safe". Indeed, the new FID utility
program
uses these routines to process files
on the diskette.
on the diskette.
There are
two subroutines which must be called
@ -81,7 +81,7 @@ The general format of the file
manager parameter list is as follows:
.bp
FILE MANAGER PARAMETER LIST - GENERAL FORMAT
.NP
.np
BYTE DESCRIPTION
00 Call type: 01=OPEN 05=DELETE 09=RENAME
02=CLOSE 06=CATALOG 0A=POSITION
@ -97,7 +97,7 @@ BYTE DESCRIPTION
FILE MANAGER PARAMETER LIST BY CALL TYPE below.
0A Return code (note: not all return codes can occur
for any call type). The processor CARRY
flag is set upon return from the file
flag is set upon return from the file
manager if there is a non-zero return code:
00=No errors
01=Not used ("LANGUAGE NOT AVAILABLE")
@ -114,7 +114,7 @@ BYTE DESCRIPTION
0C-0D Address of a 45 byte buffer which will be used by the
file manager to save its status between calls. This
area is called the file manager workarea and need not
be initialized by the caller but the space must be
be initialized by the caller but the space must be
provided and this two byte address field initialized.
(addresses are in low/high order format)
0E-0F Address of a 256 byte buffer which will be used by the
@ -124,15 +124,15 @@ BYTE DESCRIPTION
10-11 Address of a 256 byte buffer which will be used by the
file manager to maintain the data sector buffer.
Buffer need not be initialized by the caller.
.SP1
.sp1
*** INSERT FIGURE 6.2 ***
.bp
FILE MANAGER PARAMETER LIST BY CALL TYPE
.NP
.np
OPEN Locates or creates a file. A call to POSITION should
follow every OPEN.
.sp1
Input: Byte 00 - 01
Input: Byte 00 - 01
02/03 - Fixed record length or 0000 if variable
04 - Volume number or 00 for any volume
05 - Drive number to be used (01 or 02)
@ -280,7 +280,7 @@ Input: Byte 00 - 0B
.sp1
Output: Byte 0A - Return code
.sp2
VERIFY Verify that there are no bad sectors in a file by
VERIFY Verify that there are no bad sectors in a file by
reading every sector.
.sp1
Input: Byte 00 - 0C
@ -292,7 +292,7 @@ DOS BUFFERS
Usually it is desirable to use one of DOS's buffers when
calling the file manager to save memory. DOS buffers consist of
each of the three buffers used by the file manager (file
each of the three buffers used by the file manager (file
manager workarea, T/S List sector, and data sector) as well as
a 30 byte file name buffer and some link pointers. All together
a DOS buffer occupies 595 bytes of memory. The address of the
@ -300,7 +300,7 @@ first DOS buffer is stored in the first two bytes of DOS ($9D00
on a 48K APPLE II). The address of the next buffer is stored in
the first and so on in a chain of linked elements. The link
address to the next buffer in the last buffer is zeros. If the
buffer is not being used by DOS, the first byte of the file
buffer is not being used by DOS, the first byte of the file
name field is a hex 00. Otherwise, it contains the first
character of the name of the open file. The assembly language
programmer should follow these conventions to avoid having DOS
@ -309,18 +309,18 @@ name of the file should be stored in the buffer to reserve it
for exclusive use (or at least a non-zero byte stored on the
first character) and later, when the user is through with the
buffer, a 00 should be stored on the file name to return it
to DOS's use. If the later is not done, DOS will eventually
run out of available buffers and will refuse even to do a
to DOS's use. If the later is not done, DOS will eventually
run out of available buffers and will refuse even to do a
CATALOG command. A diagram of the DOS
buffers for MAXFILES 3 is given in
Figure 6.3 and
Figure 6.3 and
the format of a DOS buffer is given below.
.SP1
.sp1
*** INSERT FIGURE 6.3 ***
.sp1
.ne10
DOS BUFFER FORMAT
.NP
.np
BYTE DESCRIPTION
000/0FF Data sector buffer (256 bytes in length)
100/1FF T/S List sector buffer (256 bytes in length)
@ -401,15 +401,15 @@ COMMON ALGORITHMS
Given below are several pieces of code
which are used when working with DOS:
.SP1
.sp1
.ne5
LOCATE A FREE DOS BUFFER
The following subroutine may be used
to locate an unallocated DOS buffer
for use with the DOS file manager.
.SP1
.NP
.sp1
.np
FBUFF LDA $3D2 LOCATE DOS LOAD POINT
STA $1
LDY #0
@ -445,11 +445,11 @@ call RWTS or the file manager to
insure that DOS is present on this
machine.
.sp1
.NP
.np
LDA $3D0 GET VECTOR JMP
CMP #$4C IS IT A JUMP?
BNE NODOS NO, DOS NOT LOADED
.SP2
.sp2
.ne5
WHICH VERSION OF DOS IS ACTIVE?
@ -469,7 +469,7 @@ the DOS version may be required:
.sp2
.ne5
WHICH BASIC IS SELECTED?
.PP
Some programs depend upon either the
INTEGER BASIC ROM or the APPLESOFT
ROM. To find out which is active and
@ -481,7 +481,7 @@ is used for INTEGER BASIC and $4C is
used for APPLESOFT. To set up for
APPLESOFT, for example:
.sp1
.NP
.np
LDA #$4C CODE FOR APPLESOFT
JSR SETBSC CALL SUBROUTINE
BNE ERROR LANGUAGE NOT AVAILABLE

View File

@ -64,18 +64,18 @@ be followed to do this: