mirror of
https://github.com/iKarith/beneath-apple-dos.git
synced 2024-06-03 14:29:32 +00:00
Finished with D1S1, remove it
Every relevant we can preserve from D1S1 is now extracted, so we don't need these anymore.
This commit is contained in:
parent
1315e34995
commit
e7446c1d4f
BIN
D1S1/CH1#064000
BIN
D1S1/CH1#064000
Binary file not shown.
BIN
D1S1/CH2#064000
BIN
D1S1/CH2#064000
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
@ -1,563 +0,0 @@
|
||||||
.bp
|
|
||||||
.np
|
|
||||||
.ce
|
|
||||||
CHAPTER 3 - DISK II HARDWARE AND TRACK FORMATTING
|
|
||||||
.sp2
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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 ***
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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 ***
|
|
||||||
|
|
||||||
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 ***
|
|
||||||
|
|
||||||
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 ***
|
|
||||||
|
|
||||||
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 ***
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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 ***
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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 ***
|
|
||||||
|
|
||||||
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 ***
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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 ***
|
|
||||||
|
|
||||||
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 ***
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
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 ***
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
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 ***
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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
|
|
Binary file not shown.
BIN
D1S1/CH4#064000
BIN
D1S1/CH4#064000
Binary file not shown.
BIN
D1S1/CH5#064000
BIN
D1S1/CH5#064000
Binary file not shown.
Binary file not shown.
Binary file not shown.
BIN
D1S1/CH7#064000
BIN
D1S1/CH7#064000
Binary file not shown.
Loading…
Reference in New Issue
Block a user