Apple-2-SW/beneath-apple-dos
1
0
Fork 0
mirror of https://github.com/iKarith/beneath-apple-dos.git synced 2024-12-13 23:31:49 +00:00
Code Issues Projects Releases Wiki Activity

Dump all the documents to text files with markup

Browse Source 
Looks like CH4 is somewhat hosed, a small amount of bit rot?  Doesn't look like
too much actually.
This commit is contained in:
T. Joseph Carter 2017-07-20 14:50:14 -07:00
parent 19a429d22c
commit 1d9b739d80
28 changed files with 8566 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

120
D1S1/CH1#064000.txt Normal file
View File

@ -0,0 +1,120 @@
.ec ^
.na
.ll60
.m11
.m22
.m48
.fo ''-%-
.pn 5
.pi0
.br
.np
.ce
CHAPTER 1 - INTRODUCTION
.sp 2
.pp
Beneath Apple DOS is intended
to serve as a companion to Apple's
DOS Manual, providing additional
information for the advanced
programmer or
the novice Apple user who wants to
know more about the structure of
diskettes.
It is not the intent of this manual
to replace the documentation provided
by Apple Computer Inc.
Although, for the
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
with the
contents of the DOS Manual. Since
all chapters presented here may not
be of use to each Apple owner, each
has been written to stand on its own.
.pp
The information presented here is a
result of intensive disassembly and
annotation of various versions of DOS
by the authors and by other
experienced systems programmers.
It also draws from application notes,
articles, and discussions with
knowledgeable people. This
manual was not prepared with the
assistance of Apple Computer Inc.
Although no
guarantee can be made concerning the
accuracy of the information
presented here, all of the material
included in Beneath Apple DOS has
been thoroughly researched and
tested.
.pp
There were several reasons
for writing Beneath Apple DOS:
.SP1
.nf
To show direct assembly language access to DOS.
.br
To help you to fix clobbered diskettes.
.br
To correct errors and omissions in the Apple documentation.
.br
To allow you to customize DOS to fit your needs.
.br
To provide complete information on diskette formatting.
.br
.pp
When Apple Computer Inc. introduced
its Disk Operating System (DOS)
version 3 in 1978 to support the
new DISK II drive, very little
documentation was provided. Later,
when DOS 3.2 was released, a 178 page
instructional and reference manual
became available covering the
use of DOS from BASIC in depth and
even touched upon some of the
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,
there have been no significant
additions to the documentation on
DOS,
apart from a few articles in APPLE
user group magazines and newsletters.
This manual takes up
where the
Disk Operating System
Manual leaves off.
.bp
.pp
Throughout this manual, discussion
centers primarily on DOS version
3.3. The reasons for this are that 3.3
was the most recent release of DOS at
the time of this writing and that it
differs less from DOS 3.2 than one
would imagine. Wherever there is a
major difference between the various
DOS releases in a given topic, each
release will be covered.
.pp
In addition to the DOS dependent
information provided, many of the
discussions also apply to
other operating systems on the Apple
II and Apple III. For example,
disk formatting at
the track and sector level is, for
the most part, the same.
.br
.nx ch2
\x00

249
D1S1/CH2#064000.txt Normal file
View File

@ -0,0 +1,249 @@
.bp
.np
.ce
CHAPTER 2 - THE EVOLUTION OF DOS
.sp 2
.pp
Since its introduction, Apple DOS has
gone through three major versions.
All of these versions look
very much the same on the surface.
All commands supported by DOS 3.3
are also supported in 3.2 and 3.1.
The need for additional versions has
been more to fix errors in DOS and to
make minor enhancements than to
provide additional functionality.
Only DOS 3.3 has offered any major
improvement in function; an increase
in the number of sectors that will
fit on a track from 13 to 16.
.sp1
DOS 3 - 29 June 1978
.br
DOS 3.1 - 20 July 1978
.pp
The first release of DOS was
apparently a victim of a rush at
Apple to introduce the DISK II. As
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
DOS 3.2 - 16 February 1979
.pp
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
was retained. The major differences
between DOS 3.1 and 3.2 and later versions of DOS
are listed below:
.sp1
.pi-2
.in2
.ps0
.pp
- NOMON C,I,O is the initial default
under DOS 3.2. MON C,I,O was the
default under DOS 3.1.
.pp
- Input prompts (>,],*) are echoed
when MON O is in effect, not under
MON I as was the case under 3.1.
.pp
- When a DOS command was entered from
the keyboard, DOS executed it and
then passed a blank followed by a
carriage return to BASIC under 3.1. Under 3.2
only a carriage return is passed.
.pp
- Under 3.2, certain commands may not
be entered from the keyboard but may
only be used within a BASIC program
(READ, WRITE, POSITION, OPEN,
APPEND).
.pp
- Under 3.2, when LOADing an APPLESOFT program,
DOS automatically
converts from APPLESOFT ROM format to
APPLESOFT RAM format if the RAM version of
BASIC is in use and vice versa.
.pp
- DOS 3.1 could not read lower case
characters from a text file; DOS 3.2
can.
.pp
.bp
- Some DOS commands are allowed to
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
then delete it if a new file was not
desired. (LOAD XYZ under 3.1 if XYZ
did not exist, created XYZ, deleted
XYZ, and then printed the file not
found error message.) Under 3.2, OPEN
is allowed to create a file if one
does not exist, but LOAD may not.
.pp
- Under 3.1, exiting to the monitor
required that the monitor status
register location ($48) be set to
zero before reentering DOS. Under DOS
3.2 this is no longer necessary.
.pp
- The Read/Write-Track/Sector (RWTS)
section of DOS disables interrupts
while it is executing. Under 3.1,
RWTS could be interrupted by a
peripheral while writing to a disk,
destroying the disk.
.pp
- The default for the B (byte offset) keyword is 0
under 3.2.
.pp
- DOS was reassembled for 3.2 causing most of
its interesting locations and
routines to move slightly. This
played havoc with user programs and
utilities which had DOS addresses
built into them.
.pp
- Additional file types (beyond
T, I, A, and B) are defined within
DOS 3.2, although no commands yet
support them. The new types are S,
R, a new A, and a new B.
R has subsequently been used by the
DOS TOOLKIT for relocatable object
module assembler files. At present,
no other use is made of these
extra file types.
.pp
- Support was added under 3.2 for the
AUTOSTART ROM.
.pp
- All files open when a disk full
condition occurs are closed by DOS
3.2.
.pp
- As with each new release of DOS,
several new programs were added to
the master diskette for 3.2. Among
these was UPDATE 3.2, a replacement
for MASTER.CREATE, the utility for
creating master diskettes. UPDATE
3.2 converts a slave into a master
and allows the HELLO file to be
renamed.
.br
.pi0
.in0
.ps1
.sp1
DOS 3.2.1 - 31 July 1979
.PP
DOS 3.2.1 was essentially a
"maintenance release" of DOS 3.2.
Minor patches were made to RWTS and
the COPY program to correct a timing
problem when a dual drive copy was
done. Additional delays were added
following a switch between drives.
.bp
DOS 3.3 - 25 August 1980
.PP
Introduced in mid 1980 as a
hardware/software upgrade from DOS
3.2.1, the DOS 3.3 package includes
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.
(These ROMs are the
same ones used with the LANGUAGE
SYSTEM.)
This improvement
represents almost a 25% increase in
available disk space over the old
13 sector format.
Also included in the 3.3
package is an updated version of the
DOS manual, a BASICS diskette (for 13
sector boots), and a master diskette.
Although the RWTS portion of DOS was
almost totally rewritten, the rest of
DOS was not reassembled and only
received a few patches:
.sp1
.pi-2
.in2
.ps0
.pp
- The initial DOS bootstrap loader
was moved to $800 under 3.3. It was
at $300 under 3.2. In addition, as
stored on the diskette (track 0
sector 0) it is nibbilized in the
same way as all other sectors under
3.3.
.pp
- A bug in APPEND which caused it to
position improperly if the file was a
multiple of 256 bytes long was fixed
under 3.3.
.pp
- A VERIFY command is internally
executed after every SAVE or BSAVE
under 3.3.
.pp
- All 4 bytes are used in the Volume
Table Of Contents (VTOC) free sector bit map when
keeping track of free sectors. This
allows DOS to handle up to 32 sectors
per track. Of course, RWTS will only
handle 16 sectors due to hardware
limitations.
.pp
- If a LANGUAGE CARD is present, DOS
stores a zero on it at $E000 during
bootstrap to force the HELLO program
on the master diskette to reload
BASIC.
.pp
- DOS is read into memory from the
top down (backwards) under 3.3 rather than the
bottom up. Its image is
still stored in the same order on the
diskette (tracks 0, 1, and 2),
however.
.pp
- Additional programs added to the
master diskette under 3.3 include
FID, a generalized file utility which
allows individual files or groups of
files to be copied, MUFFIN, a
conversion copy routine to allow 3.2
files to be moved to 16 sector 3.3
diskettes, BOOT 13, a program which
will boot a 13 sector diskette,
and a new COPY program
which will also support single drive
copies.
.pp
- Under 3.2, speed differences in
some drives prevented their use
together with the DOS COPY program.
Because the COPY program was rewritten
under 3.3, that restriction no longer
applies.
.br
.pi0
.in0
.ps1
.nx ch3.1
\x00

578
D1S1/CH3.1#064000.txt Normal file
View File

@ -0,0 +1,578 @@
.bp
.np
.ce
CHAPTER 3 - DISK II HARDWARE AND TRACK FORMATTING
.sp 2
.pp
Apple Computer's excellent manual on
the Disk Operating System (DOS)
provides only very basic information
about how diskettes are formatted.
This chapter will explain in detail
how information is structured on a
diskette. The first section will
contain a brief introduction to the
hardware, and may be skipped by those
already familiar with the DOS manual.
.pp
For system housekeeping, DOS divides
diskettes into tracks and sectors.
This is done during the
initialization process. A track is a
physically defined circular path
which is concentric with the hole in
the center of the diskette. Each
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.
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.
Apple formats its diskettes into 35
tracks. They are numbered from 0 to
34, track 0 being the outermost track
and track 34 the innermost. Figure
3.1 illustrates the concept of
tracks, although they are invisible
to the eye on a real diskette.
.sp1
*** INSERT FIGURE 3.1 HERE ***
.pp
It should be pointed out, for the
sake of accuracy, that the disk arm
can position itself over 70 "phases".
To move the arm past one track to the
next, two phases of the stepper
motor, which moves the arm, must be
cycled. This implies that data might
be stored on 70 tracks, rather than
35. Unfortunately, the resolution of
the read/write head and the accuracy
of the stepper motor are such, that
attempts to use these phantom
"half" tracks create so much
cross-talk that data is lost or
overwritten. Although the standard
DOS uses only even phases, some
protected disks use odd phases or
combinations of the two, provided
that no two tracks are closer than
two phases from one another. See
APPENDIX B for more information on
protection schemes.
.bp
.pp
A sector is a subdivision of a track.
It is the smallest unit of
"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
buffer to read or write an entire
track.
Apple has used two different track
formats
to date. One divides the track into
13 sectors, the other, 16 sectors. The
sectoring does not use the index
hole, provided on most diskettes, to
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.
This scheme, known as "soft sectoring",
takes a little more space
for storage but allows flexibility,
as evidenced by the recent change
from 13 sectors to 16 sectors per
track. The following table
catagorizes the amount of data stored
on a diskette under both 13 and 16
sector formats.
.sp1
.ne10
.nf
DISK ORGANIZATION
.SP1
TRACKS
All DOS versions................35
.SP1
SECTORS PER TRACK
DOS 3.2.1 and earlier...........13
DOS 3.3.........................16
.SP1
SECTORS PER DISKETTE
DOS 3.2.1 and earlier..........455
DOS 3.3........................560
.sp1
BYTES PER SECTOR
All DOS versions...............256
.sp1
BYTES PER DISKETTE
DOS 3.2.1 and earlier.......116480
DOS 3.3.....................143360
.SP1
USABLE* SECTORS FOR DATA STORAGE
DOS 3.2.1 and earlier..........403
DOS 3.3........................496
.SP1
USABLE* BYTES PER DISKETTE
DOS 3.2.1 and earlier.......103168
DOS 3.3.....................126976
.SP2
* Excludes DOS, VTOC, and CATALOG
.bp
TRACK FORMATTING
.pp
Up to this point we have broken down
the structure of data to the track
and sector level. To better
understand how
data is stored and retrieved, we will
start at the bottom and work up.
.pp
As this manual is primarily concerned
with software, no attempt will be
made to deal with the specifics of
the hardware. For example, while in
fact data is stored as a continuous
stream of analog signals, we will
deal with discrete digital data, i.e.
a 0 or a 1. We recognize that the
hardware converts analog data to
digital data but how this is
accomplished is beyond the scope of
this manual.
.pp
Data is recorded on the diskette
using frequency modulation as the
recording mode. Each data bit
recorded on the diskette has an
associated clock bit recorded with
it. Data written on and read back
from the diskette takes the form
shown in Figure 3.2. The data
pattern shown represents a binary
value of 101.
.sp1
*** INSERT FIGURE 3.2 HERE ***
.pp
As can be seen in Figure 3.3, the
clock bits and data bits (if present)
are interleaved. The presence of a
data bit between two clock bits
represents a binary 1, the absence of
a data bit between two clock bits
represents a binary 0. We will
define a "bit cell" as the period
between the leading edge of one clock
bit and the leading edge of the next
clock bit.
.sp1
*** INSERT FIGURE 3.3 HERE ***
.PP
A byte would consist of eight (8)
consecutive bit cells. The most
significant bit cell is usually
referred to as bit cell 7 and the
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).
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.
Correspondingly, when data is being
read back from the diskette, bit cell
7 is read first and bit cell 0 is
read last. The diagram below
illustrates the relationship of the
bits within a byte.
.bp
*** INSERT FIGURE 3.4 HERE ***
.PP
To graphically show how bits are
stored and retrieved, we must take
certain liberties. The diagrams are
a representation of what functionally
occurs within the disk drive. For
the purposes of our presentation, the
hardware interface
to the diskette will be
represented as an eight bit "data latch".
While the hardware involves
considerably more complication, from a software
standpoint it is reasonable to use
the data latch, as it accurately
embodies the function of data flow to
and from the diskette.
.sp1
*** INSERT FIGURE 3.5 HERE ***
.pp
Figure 3.5 shows the three bits, 101,
being read from the diskette data
stream into the data latch. Of
course another five bits would be
read to fill the latch. As can be
seen, the data is separated from the
clock bits. This task is done by the
hardware and is shown more for
accuracy than for its importance to
our discussion.
.pp
Writing data can be depicted in much
the same way (see Figure 3.6).
The clock bits which
were separated from the data must now
be interleaved with the data as it is
written. It should be noted that,
while in write mode, zeros are being
brought into the data latch to
replace the data being written. It
is the task of the software to make
sure that the latch is loaded and
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.
Self-sync bytes will be covered in
detail shortly.
.sp1
*** INSERT FIGURE 3.6 HERE ***
.PP
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
similar in that they both contain a
prologue, a data area, a checksum, and
an epilogue. Each field on a track is
separated from adjacent fields by a
number of bytes. These areas of
separation are called "gaps" and are
provided for two reasons. One, they
allow the updating of one field
without affecting adjacent fields (on
the Apple, only data fields are
updated). Secondly, they allow the
computer time
to decode the address field before
the corresponding data field can pass
beneath the read/write head.
.pp
All gaps are primarily alike in
content, consisting of self-sync
hexadecimal FF's, and vary only in
the number of bytes they contain.
Figure 3.7 is a diagram of a portion
of a typical track, broken into its
major components.
.bp
*** INSERT FIGURE 3.7 HERE ***
.PP
Self-sync or auto-sync bytes are
special bytes that make up the three
different types of gaps on a track.
They are so named because of their
ability to automatically bring the
hardware into synchronization with
data bytes on the disk. The
difficulty in doing this lies in the
fact that the hardware reads bits and
the data must be stored as eight bit
bytes. It has been mentioned that a
track is literally a continuous
stream of data bits. In fact, at the
bit level, there is no way to
determine where a byte starts or
ends, because each bit cell is
exactly the same, written in precise
intervals with its neighbors. When
the drive is instructed to read data,
it will start wherever it happens to
be on a particular track. That could
be anywhere among the 50,000 or so
bits on a track. Distinguishing
clock bits from data bits,
the hardware finds
the first bit cell with data in it
and proceeds to read the following
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.
Pictured in Figure 3.8 is a small
portion of a track. The clock bits
have been stripped out and 0's and
1's have been used for clarity.
.sp1
*** INSERT FIGURE 3.8 HERE ***
.pp
There is no way from looking at the
data to tell what bytes are
represented, because we don't know
where to start. This is exactly the
problem that self-sync bytes
overcome.
.pp
A self-sync byte is defined to be a
hexadecimal FF with a special
difference. It is, in fact, a 10 bit
byte rather than an eight bit byte. Its
two extra bits are zeros. Figure 3.9
shows the difference between a normal
data hex FF that might be found
elsewhere on the disk and a self-sync
hex FF byte.
.bp
*** INSERT FIGURE 3.9 HERE ***
.pp
A self-sync is generated by using a
40 cycle (micro-second) loop while
writing an FF. A bit is written
every four cycles, so two of the zero bits
brought into the data latch while the
FF was being written are also
written to the disk, making the 10
bit byte. (DOS 3.2.1 and earlier versions use
a nine bit byte due to the hardware's
inability to always detect two
consecutive zero bits.) It can be
shown, using Figure 3.10, that five
self-sync bytes are sufficient to
guarantee that the hardware is
reading valid data. The reason for
this is that the hardware requires
the first bit of a byte to be a 1.
Pictured at the top of the figure is
a stream of five auto-sync bytes. Each
row below that demonstates what the
hardware will read should it start
reading at any given bit in the
first byte. In each case, by the
time the five sync bytes have passed
beneath the read/write head, the
hardware will be "synched" to read the
data bytes that follow. As long as
the disk is left in read mode, it
will continue to correctly interpret
the data unless there is an error on
the track.
.sp1
*** INSERT FIGURE 3.10 ***
.PP
We can now discuss the particular
portions of a track in detail. The
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
track to track. During the
initialization process, DOS will
start with large gaps and keep making
them smaller until an entire track
can be written without overlapping
itself. A minimum of five self-sync
bytes must be maintained for
each gap type (as discussed earlier).
The result is fairly uniform gap
sizes within each particular track.
.pp
Gap 1 is the first data written to a
track during initialization. Its
purpose is twofold. The gap
originally consists of 128 bytes of
self-sync, a large enough area to
insure that all portions of a track
will contain data. Since the speed
of a particular drive may vary, the
total length of the track in bytes is
uncertain, and the percentage
occupied by data is unknown. The
initialization process is set up,
however, so that even on drives of
differing speeds, the last data field
written will overlap Gap 1, providing
continuity over the entire physical
track. Care is taken to make sure
the remaining portion of Gap 1 is at
as long as a typical Gap 3
(in practice its length
is usually more than 40),
enabling it to serve
as a Gap 3 type for Address Field
number 0 (See Figure 3.7 for
clarity).
.bp
.pp
Gap 2 appears after each Address
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.
If the gap were too short, the
beginning of the Data Field might
spin past while DOS was still
determining if this was the
sector to be read. The 240 odd
cycles that six self-sync bytes provide
seems ample time to decode an address
field. When a Data Field is written
there is no guarantee that the write
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.
Since the speed of the drives can
vary, it is possible that the write
could start in mid-byte. (See Figure
3.11) This is not
a problem as long as the difference
in positioning is not great. To
insure the integrity of Gap 2, when
writing a data field, five self-sync
bytes are written prior to writing
the Data Field itself. This serves
two purposes. Since relatively
little time is spent decoding an
address field, the five bytes help place
the Data Field near its original
position. Secondly, and more
importantly, the five self-sync bytes
are the minimum number required to
guarantee read-synchronization. It
is probable that, in writing a Data
Field, at least one sync byte will be
destroyed. This is because, just as
in reading bits on the track, the
write may not begin on a byte
boundary, thus altering an existing
byte. Figure 3.12 illustrates this.
.sp1
*** INSERT FIGURE 3.11 HERE ***
.SP1
*** INSERT FIGURE 3.12 HERE ***
.PP
Gap 3 appears after each
Data Field and before each Address
Field. It is longer than Gap 2 and
generally ranges from 14 to 24 bytes
in length. It is quite similar in
purpose to Gap 2. Gap 3 allows the
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
following Address
Field is missed, DOS can always wait
for the next time it spins around
under the read/write head, at most
one revolution of the disk. Since
Address Fields are never rewritten,
there is no problem with this gap
providing synchronization, since only
the first part of the gap can be
overwritten or damaged. (See Figure
3.11 for clarity)
.bp
.pp
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
which follows it. The volume, track,
and sector number of any given sector
can be thought of as its "address",
much like a country, city, and street
number might identify a house. As
shown previously in Figure 3.7, there
are a number of components which make
up the Address Field. A more
detailed illustration is given in
Figure 3.13.
.sp1
*** INSERT FIGURE 3.13 HERE ***
.PP
The prologue consists of three bytes
which form a unique sequence, found
in no other component of the track.
This fact enables DOS to locate an
Address Field with almost no
possibility of error. The three
bytes are $D5, $AA, and $96. The $D5
and $AA are reserved (never written
as data) thus insuring the uniqueness
of the prologue. The $96, following
this unique string, indicates that
the data following constitutes an
Address Field (as opposed to a Data
Field). The address information
follows next, consisting of the
volume, track, and sector number and
a checksum. This information is
absolutely essential for DOS to know
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.
Lastly follows the epilogue, which
contains the three bytes $DE, $AA and
$EB. Oddly, the $EB is always written
during initialization but is never
verified when an Address Field is
read. The epilogue bytes are
sometimes referred to as "bit-slip
marks", which provide added assurance
that the drive is still in sync with
the bytes on the disk. These bytes
are probably unnecessary, but do
provide a means of double checking.
.pp
The other field type is the Data
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.
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.
The data is followed by a checksum
byte, used to verify the integrity of
the data just read. The epilogue
portion of the Data Field is
absolutely identical to the epilogue
in the Address Field and it serves
the same function.
.bp
.nx ch3.2
\x00

563
D1S1/CH3.1T#040000.txt Normal file
View File

@ -0,0 +1,563 @@
.bp
.np
.ce
CHAPTER 3 - DISK II HARDWARE AND TRACK FORMATTING
.sp 2
.pp
Apple Computer's excellent manual on
the Disk Operating System (DOS)
provides only very basic information
about how diskettes are formatted.
This chapter will explain in detail
how information is structured on a
diskette. The first section will
contain a brief introduction to the
hardware, and may be skipped by those
already familiar with the DOS manual.
.pp
For system housekeeping, DOS divides
diskettes into tracks and sectors.
This is done during the
initialization process. A track is a
physically defined circular path
which is concentric with the hole in
the center of the diskette. Each
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.
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.
Apple formats its diskettes into 35
tracks. They are numbered from 0 to
34, track 0 being the outermost track
and track 34 the innermost. Figure
3.1 illustrates the concept of
tracks, although they are invisible
to the eye on a real diskette.
.sp1
*** INSERT FIGURE 3.1 HERE ***
.pp
It should be pointed out, for the
sake of accuracy, that the disk arm
can position itself over 70 "phases".
To move the arm past one track to the
next, two phases of the stepper
motor, which moves the arm, must be
cycled. This implies that data might
be stored on 70 tracks, rather than
35. Unfortunately, the resolution of
the read/write head and the accuracy
of the stepper motor are such, that
attempts to use these phantom
"half" tracks create so much
cross-talk that data is lost or
overwritten. Although the standard
DOS uses only even phases, some
protected disks use odd phases or
combinations of the two, provided
that no two tracks are closer than
two phases from one another. See
APPENDIX B for more information on
protection schemes.
.bp
.pp
A sector is a subdivision of a track.
It is the smallest unit of
"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
buffer to read or write an entire
track.
Apple has used two different track
formats
to date. One divides the track into
13 sectors, the other, 16 sectors. The
sectoring does not use the index
hole, provided on most diskettes, to
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.
This scheme, known as "soft sectoring",
takes a little more space
for storage but allows flexibility,
as evidenced by the recent change
from 13 sectors to 16 sectors per
track. The following table
catagorizes the amount of data stored
on a diskette under both 13 and 16
sector formats.
.sp1
.ne10
.nf
DISK ORGANIZATION
.SP1
TRACKS
All DOS versions................35
.SP1
SECTORS PER TRACK
DOS 3.2.1 and earlier...........13
DOS 3.3.........................16
.SP1
SECTORS PER DISKETTE
DOS 3.2.1 and earlier..........455
DOS 3.3........................560
.sp1
BYTES PER SECTOR
All DOS versions...............256
.sp1
BYTES PER DISKETTE
DOS 3.2.1 and earlier.......116480
DOS 3.3.....................143360
.SP1
USABLE* SECTORS FOR DATA STORAGE
DOS 3.2.1 and earlier..........403
DOS 3.3........................496
.SP1
USABLE* BYTES PER DISKETTE
DOS 3.2.1 and earlier.......103168
DOS 3.3.....................126976
.SP2
* Excludes DOS, VTOC, and CATALOG
.bp
TRACK FORMATTING
.pp
Up to this point we have broken down
the structure of data to the track
and sector level. To better
understand how
data is stored and retrieved, we will
start at the bottom and work up.
.pp
As this manual is primarily concerned
with software, no attempt will be
made to deal with the specifics of
the hardware. For example, while in
fact data is stored as a continuous
stream of analog signals, we will
deal with discrete digital data, i.e.
a 0 or a 1. We recognize that the
hardware converts analog data to
digital data but how this is
accomplished is beyond the scope of
this manual.
.pp
Data is recorded on the diskette
using frequency modulation as the
recording mode. Each data bit
recorded on the diskette has an
associated clock bit recorded with
it. Data written on and read back
from the diskette takes the form
shown in Figure 3.2. The data
pattern shown represents a binary
value of 101.
.sp1
*** INSERT FIGURE 3.2 HERE ***
.pp
As can be seen in Figure 3.3, the
clock bits and data bits (if present)
are interleaved. The presence of a
data bit between two clock bits
represents a binary 1, the absence of
a data bit between two clock bits
represents a binary 0. We will
define a "bit cell" as the period
between the leading edge of one clock
bit and the leading edge of the next
clock bit.
.sp1
*** INSERT FIGURE 3.3 HERE ***
.PP
A byte would consist of eight (8)
consecutive bit cells. The most
significant bit cell is usually
referred to as bit cell 7 and the
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).
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.
Correspondingly, when data is being
read back from the diskette, bit cell
7 is read first and bit cell 0 is
read last. The diagram below
illustrates the relationship of the
bits within a byte.
.bp
*** INSERT FIGURE 3.4 HERE ***
.PP
To graphically show how bits are
stored and retrieved, we must take
certain liberties. The diagrams are
a representation of what functionally
occurs within the disk drive. For
the purposes of our presentation, the
hardware interface
to the diskette will be
represented as an eight bit "data latch".
While the hardware involves
considerably more complication, from a software
standpoint it is reasonable to use
the data latch, as it accurately
embodies the function of data flow to
and from the diskette.
.sp1
*** INSERT FIGURE 3.5 HERE ***
.pp
Figure 3.5 shows the three bits, 101,
being read from the diskette data
stream into the data latch. Of
course another five bits would be
read to fill the latch. As can be
seen, the data is separated from the
clock bits. This task is done by the
hardware and is shown more for
accuracy than for its importance to
our discussion.
.pp
Writing data can be depicted in much
the same way (see Figure 3.6).
The clock bits which
were separated from the data must now
be interleaved with the data as it is
written. It should be noted that,
while in write mode, zeros are being
brought into the data latch to
replace the data being written. It
is the task of the software to make
sure that the latch is loaded and
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.
Self-sync bytes will be covered in
detail shortly.
.sp1
*** INSERT FIGURE 3.6 HERE ***
.PP
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
similar in that they both contain a
prologue, a data area, a checksum, and
an epilogue. Each field on a track is
separated from adjacent fields by a
number of bytes. These areas of
separation are called "gaps" and are
provided for two reasons. One, they
allow the updating of one field
without affecting adjacent fields (on
the Apple, only data fields are
updated). Secondly, they allow the
computer time
to decode the address field before
the corresponding data field can pass
beneath the read/write head.
.pp
All gaps are primarily alike in
content, consisting of self-sync
hexadecimal FF's, and vary only in
the number of bytes they contain.
Figure 3.7 is a diagram of a portion
of a typical track, broken into its
major components.
.bp
*** INSERT FIGURE 3.7 HERE ***
.PP
Self-sync or auto-sync bytes are
special bytes that make up the three
different types of gaps on a track.
They are so named because of their
ability to automatically bring the
hardware into synchronization with
data bytes on the disk. The
difficulty in doing this lies in the
fact that the hardware reads bits and
the data must be stored as eight bit
bytes. It has been mentioned that a
track is literally a continuous
stream of data bits. In fact, at the
bit level, there is no way to
determine where a byte starts or
ends, because each bit cell is
exactly the same, written in precise
intervals with its neighbors. When
the drive is instructed to read data,
it will start wherever it happens to
be on a particular track. That could
be anywhere among the 50,000 or so
bits on a track. Distinguishing
clock bits from data bits,
the hardware finds
the first bit cell with data in it
and proceeds to read the following
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.
Pictured in Figure 3.8 is a small
portion of a track. The clock bits
have been stripped out and 0's and
1's have been used for clarity.
.sp1
*** INSERT FIGURE 3.8 HERE ***
.pp
There is no way from looking at the
data to tell what bytes are
represented, because we don't know
where to start. This is exactly the
problem that self-sync bytes
overcome.
.pp
A self-sync byte is defined to be a
hexadecimal FF with a special
difference. It is, in fact, a 10 bit
byte rather than an eight bit byte. Its
two extra bits are zeros. Figure 3.9
shows the difference between a normal
data hex FF that might be found
elsewhere on the disk and a self-sync
hex FF byte.
.bp
*** INSERT FIGURE 3.9 HERE ***
.pp
A self-sync is generated by using a
40 cycle (micro-second) loop while
writing an FF. A bit is written
every four cycles, so two of the zero bits
brought into the data latch while the
FF was being written are also
written to the disk, making the 10
bit byte. (DOS 3.2.1 and earlier versions use
a nine bit byte due to the hardware's
inability to always detect two
consecutive zero bits.) It can be
shown, using Figure 3.10, that five
self-sync bytes are sufficient to
guarantee that the hardware is
reading valid data. The reason for
this is that the hardware requires
the first bit of a byte to be a 1.
Pictured at the top of the figure is
a stream of five auto-sync bytes. Each
row below that demonstates what the
hardware will read should it start
reading at any given bit in the
first byte. In each case, by the
time the five sync bytes have passed
beneath the read/write head, the
hardware will be "synched" to read the
data bytes that follow. As long as
the disk is left in read mode, it
will continue to correctly interpret
the data unless there is an error on
the track.
.sp1
*** INSERT FIGURE 3.10 ***
.PP
We can now discuss the particular
portions of a track in detail. The
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
track to track. During the
initialization process, DOS will
start with large gaps and keep making
them smaller until an entire track
can be written without overlapping
itself. A minimum of five self-sync
bytes must be maintained for
each gap type (as discussed earlier).
The result is fairly uniform gap
sizes within each particular track.
.pp
Gap 1 is the first data written to a
track during initialization. Its
purpose is twofold. The gap
originally consists of 128 bytes of
self-sync, a large enough area to
insure that all portions of a track
will contain data. Since the speed
of a particular drive may vary, the
total length of the track in bytes is
uncertain, and the percentage
occupied by data is unknown. The
initialization process is set up,
however, so that even on drives of
differing speeds, the last data field
written will overlap Gap 1, providing
continuity over the entire physical
track. Care is taken to make sure
the remaining portion of Gap 1 is at
as long as a typical Gap 3
(in practice its length
is usually more than 40),
enabling it to serve
as a Gap 3 type for Address Field
number 0 (See Figure 3.7 for
clarity).
.bp
.pp
Gap 2 appears after each Address
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.
If the gap were too short, the
beginning of the Data Field might
spin past while DOS was still
determining if this was the
sector to be read. The 240 odd
cycles that six self-sync bytes provide
seems ample time to decode an address
field. When a Data Field is written
there is no guarantee that the write
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.
Since the speed of the drives can
vary, it is possible that the write
could start in mid-byte. (See Figure
3.11) This is not
a problem as long as the difference
in positioning is not great. To
insure the integrity of Gap 2, when
writing a data field, five self-sync
bytes are written prior to writing
the Data Field itself. This serves
two purposes. Since relatively
little time is spent decoding an
address field, the five bytes help place
the Data Field near its original
position. Secondly, and more
importantly, the five self-sync bytes
are the minimum number required to
guarantee read-synchronization. It
is probable that, in writing a Data
Field, at least one sync byte will be
destroyed. This is because, just as
in reading bits on the track, the
write may not begin on a byte
boundary, thus altering an existing
byte. Figure 3.12 illustrates this.
.sp1
*** INSERT FIGURE 3.11 HERE ***
.SP1
*** INSERT FIGURE 3.12 HERE ***
.PP
Gap 3 appears after each
Data Field and before each Address
Field. It is longer than Gap 2 and
generally ranges from 14 to 24 bytes
in length. It is quite similar in
purpose to Gap 2. Gap 3 allows the
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
following Address
Field is missed, DOS can always wait
for the next time it spins around
under the read/write head, at most
one revolution of the disk. Since
Address Fields are never rewritten,
there is no problem with this gap
providing synchronization, since only
the first part of the gap can be
overwritten or damaged. (See Figure
3.11 for clarity)
.bp
.pp
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
which follows it. The volume, track,
and sector number of any given sector
can be thought of as its "address",
much like a country, city, and street
number might identify a house. As
shown previously in Figure 3.7, there
are a number of components which make
up the Address Field. A more
detailed illustration is given in
Figure 3.13.
.sp1
*** INSERT FIGURE 3.13 HERE ***
.PP
The prologue consists of three bytes
which form a unique sequence, found
in no other component of the track.
This fact enables DOS to locate an
Address Field with almost no
possibility of error. The three
bytes are $D5, $AA, and $96. The $D5
and $AA are reserved (never written
as data) thus insuring the uniqueness
of the prologue. The $96, following
this unique string, indicates that
the data following constitutes an
Address Field (as opposed to a Data
Field). The address information
follows next, consisting of the
volume, track, and sector number and
a checksum. This information is
absolutely essential for DOS to know
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.
Lastly follows the epilogue, which
contains the three bytes $DE, $AA and
$EB. Oddly, the $EB is always written
during initialization but is never
verified when an Address Field is
read. The epilogue bytes are
sometimes referred to as "bit-slip
marks", which provide added assurance
that the drive is still in sync with
the bytes on the disk. These bytes
are probably unnecessary, but do
provide a means of double checking.
.pp
The other field type is the Data
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.
The bytes are $D5, $AA, and $AD,
which again form a

334
D1S1/CH3.2#064000.txt Normal file
View File

@ -0,0 +1,334 @@
.SP2
DATA FIELD ENCODING
.pp
Due to Apple's hardware, it is not
possible to read all 256 possible
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
techniques have been used. The first
one, which is currently used in
Address Fields, involves
writing a data byte as two disk
bytes, one containing the odd bits,
and the other containing the even
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.
This amounts to about 88K of data per
diskette, or roughly 72K of space
available to the user; typical for 5
1/4 single density drives.
.pp
Fortunately, a second technique for
writing data to diskette was devised
that allows 13
sectors per track. This new method
involved a "5 and 3" split of the
data bits, versus the "4 and 4"
mentioned earlier. Each byte written
to the disk contains five valid bits
rather than four. This requires 410
"disk" bytes to store a 256 byte
sector. This latter density allows
the now well known 13 sectors per
track format used by DOS 3 through
DOS 3.2.1. The "5 and 3" scheme
represented a hefty 33% increase over
comparable drives of the day.
.pp
Currently, of course, DOS 3.3
features 16 sectors per track and
provides a 23% increase in disk
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
and 2" split of the data. The change
was to the logic of the "state
machine" in the P6 PROM, now allowing
two consecutive zero bits in data
bytes.
.pp
These three different encoding
techniques
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
could be stored and retrieved. It
required that a disk byte have the
high bit set and, in addition, no two
consecutive bits could be zero.
The odd-even "4 and 4" technique meets
these requirements. Each data byte
is represented as two bytes, one
containing the even data bits and the
other the odd data bits. Figure 3.15
illustrates this transformation. It
should be noted that the unused bits
are all set to one to guarantee
meeting the two requirements.
.sp1
*** INSERT FIGURE 3.15 HERE ***
.PP
No matter what value the original
data data byte has, this technique
insures that the high bit is set and
that there can not be two consecutive
zero bits. The "4 and 4" technique is
used to store the information
(volume, track, sector, checksum)
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.
This is illustrated in Figure 3.16.
.sp1
*** INSERT FIGURE 3.16 HERE ***
.PP
It is important that the least
significant bit contain a 1 when the
odd-bits byte is left shifted. The
entire
operation is carried out in the
RDADR subroutine at $B944 in DOS
(48K).
.pp
The major difficulty with the above
technique is that it takes up a lot of
room on the track. To overcome this
deficiency the "5 and 3" encoding
technique was developed. It is so named
because, instead of splitting the
bytes in half, as in the odd-even
technique, they are split five and three. A
byte would have the form 000XXXXX,
where X is a valid data bit. The
above byte could range in value from
$00 to $1F, a total of 32 different
values. It so happens that there are
34 valid "disk" bytes, ranging
from $AA up to $FF, which meet the
two requirements (high bit set, no
consecutive zero bits). Two bytes,
$D5 and $AA, were chosen as reserved
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.
An overview is diagrammed in Figure
3.17.
.sp1
*** INSERT FIGURE 3.17 HERE ***
.PP
First, the 256 bytes that will make
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.
Figure 3.18 shows the before and
after of prenibbilizing. On the left
is a buffer of eight bit data bytes, as
passed to the RWTS subroutine
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 primary buffer contains five
distinct areas of five bit bytes (the
top three bits of the eight bit bytes
zero-filled) and the secondary buffer
contains three areas, graphically
illustrating the name "5 and 3".
.bp
*** INSERT FIGURE 3.18 HERE ***
.PP
A total of 410 bytes are needed to
store the original 256. This can be
calculated by finding the total bits
of data (256 x 8 = 2048) and dividing
that by the number of bits per byte
(2048 / 5 = 409.6). (two bits are
not used) Once this process is
completed, the data is further
transformed to make it valid "disk"
bytes, meeting the disk's
requirements. This is much easier,
involving a one to one look-up in the
table given in Figure 3.19.
.sp1
*** INSERT FIGURE 3.19 HERE ***
.pp
The Data Field has a checksum much
like the one in the Address Field,
used to verify the integrity of the
data. It also involves
exclusive-ORing the information, but,
due to time constraints during
reading bytes, it is implemented
differently. The data is
exclusive-ORed in pairs before being
transformed by the look-up table in
Figure 3.19. This can best be
illustrated by Figure 3.20 on the following page.
.sp1
*** INSERT FIGURE 3.20 HERE ***
.PP
The reason for this transformation
can be better understood by examining
how the information is retrieved from
the disk. The read routine must read
a byte, transform it, and store it --
all in under 32 cycles (the time
taken to write a byte) or the
information will be lost. By using
the checksum computation to decode
data, the
transformation shown in Figure 3.20
greatly facilitates the time
constraint. As the data is being
read from a sector the accumulator
contains the cumulative result of
all previous bytes, exclusive-ORed
together. The value of the
accumulator after any exclusive-OR
operation is the actual data byte
for that point in the series.
This process is diagrammed in Figure 3.21.
.bp
*** INSERT FIGURE 3.21 HERE ***
.pp
The third encoding technique, currently
used by DOS 3.3, is similar to the "5
and 3". It was made possible by a
change in the hardware which eased
the requirements for valid data
somewhat. The high bit must still be
set, but now the byte may contain one
(and only one) pair of consecutive
zero bits. This allows a greater
number of valid bytes and permits the
use of a "6 and 2" encoding technique.
A six bit byte would have the form
00XXXXXX and has values from $00 to
$3F for a total of 64 different
values. With the new, relaxed
requirements for valid "disk" bytes
there are 69 different bytes ranging
in value from $96 up to $FF. After
removing the two reserved bytes, $AA
and $D5, there are still 67 "disk" bytes
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.
This produces exactly 64 valid "disk"
values. The initial transformation
is done by the prenibble routine
(still located at $B800) and its
results are shown in Figure 3.22.
.sp1
*** INSERT FIGURE 3.22 (20) HERE ***
.PP
A total of 342 bytes are needed,
shown by finding the total number of
bits (256 x 8 = 2048) and dividing by
the number of bits per byte (2048 / 6
= 341.33). The transformation from
the six bit bytes to valid data bytes
is again performed by a one to one
mapping shown in Figure 3.23.
Once again, the stream of data bytes
written to the diskette are a product
of exclusive-ORs, exactly as with the
"5 and 3" technique discussed earlier.
.sp1
*** INSERT FIGURE 3.23 (21) HERE ***
.sp1
SECTOR INTERLEAVING
.PP
Sector interleaving is the staggering
of sectors on a track to maximize
access speed. There is usually a
delay between the time DOS reads or
writes a sector and the time it is
ready to read or write another. This
delay depends upon the application
program using the disk and can vary
greatly. If sectors were stored
on the track
sequentially, in ascending numerical
order, unless the
application was very quick indeed,
it would
usually be necessary to wait an
entire revolution of the diskette
before the next sector could be
accessed. Rearranging the sectors
into a different order or
"interleaving" them can provide
different access speeds.
.bp
On DOS 3.2.1 and earlier versions,
the 13 sectors are physically
interleaved on the disk. Since DOS
resides on the diskette in ascending
sequential order and files generally
are stored in descending sequential
order, no single interleaving scheme
works well for both booting and
sequentially accessing a file.
.pp
A different approach has been used in
DOS 3.3 in an attempt to maximize
performance. The interleaving is now
done in software. The 16 sectors are
stored in numerically ascending order
on the diskette (0, 1, 2, ... , 15)
and are not physically interleaved at
all. A look-up table is used to
translate the physical sector number
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.
Thus, DOS treats the physical sector
2 as sector 11 ($0B) for all intents
and purposes. This presents no
problem if RWTS is used for disk
access, but would become a
consideration if access were made
without RWTS.
.pp
To eliminate the access differences
between booting and reading files,
another change has been made. During
the boot process, DOS is loaded
backwards in descending sequential
order into memory, just as files are
accessed. This means one
interleaving scheme can minimize disk
access time.
.pp
It is interesting to point out that
Pascal, Fortran, and CP/M diskettes
all use software interleaving also.
However, each uses a different
sector order. A comparison of these
differences is presented in Figure
3.24.
.sp1
*** INSERT FIGURE 3.24 (22) HERE ***
.br
.nxch4
\x00

664
D1S1/CH4#064000.txt Normal file
View File

@ -0,0 +1,664 @@
.bp
.np
.ce
CHAPTER 4 - DISKETTE DATA FORMATS
.pp
As was described in CHAPTER 3, a 16
sector diskette consists of 560 data