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

Cleanup chapter 4

Browse Source
This commit is contained in:
T. Joseph Carter 2017-07-20 19:00:10 -07:00
parent 4461e45278
commit 035a79a67d
1 changed files with 242 additions and 499 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

741
ch04.txt
View File

@ -1,17 +1,9 @@
.bp
.np
.ce
CHAPTER 4 - DISKETTE DATA FORMATS
## CHAPTER 4 - DISKETTE DATA FORMATS
As was described in CHAPTER 3, a 16
sector diskette consists of 560 data
areas of 256 bytes each, called
sectors. These sectors are arranged
on the diskette in 35 concentric
rings or tracks of 16 sectors each.
The way DOS allocates these tracks of
sectors is the subject of
this chapter.
As was described in CHAPTER 3, a 16 sector diskette consists of 560 data areas
of 256 bytes each, called sectors. These sectors are arranged on the diskette in
35 concentric rings or tracks of 16 sectors each. The way DOS allocates these
tracks of sectors is the subject of this chapter.
A file (be it APPLESOFT, INTEGER, BINARY, or TEXT type) consists of one or more
sectors containing data. Since the sector is the smallest unit of allocatable
@ -23,9 +15,9 @@ expect to be able to use up to 16 times 35 times 256 or 143,360 bytes of space
on a diskette for files. Actually, the largest file that can be stored is about
126,000 bytes long. The reason for this is that some of the sectors on the
diskette must be used for what is called "overhead".
.sp1
*** INSERT FIGURE 4.1 ***
.sp1
Overhead sectors contain the image of DOS which is 1oaded when booting the
diskette, a list of the names and locations of the files on the diskette, and an
accounting of the sectors which are free for use with new files or expansions of
@ -33,61 +25,35 @@ existing files. An example of the way DOS uses sectors is given in Figure 4.1.
DISKETTE SPACE ALLOCATION
The map in Figure 4.1 shows that the
first three tracks of each diskette
are always reserved for the bootstrap
image of DOS. In the exact center
track (track 17) is the VTOC and
catalog. The reason for placing the
catalog here is simple. Since the
greatest delay when using the disk is
waiting for the arm to move from
track to track, it is advantageous to
minimize this arm movement whenever
possible. By placing the catalog in
the exact center track of the disk,
the arm need never travel more than
17 tracks to get to the catalog
track.
As files are allocated
on a diskette, they occupy the tracks
just above the catalog track first.
When the last track, track 34, has been used, track 16,
the track adjacent and below the
catalog,
is used next, then 15, 14, 13, and so
on, moving away from the catalog
again, toward the DOS image tracks.
If there are very few files on
the diskette, they will all be
clustered, hopefully, near the
catalog and arm movement will be
minimized. Additional space for a
file, if it is needed, is first allocated
in the same track occupied by the file.
When that track is full, another
track is allocated elsewhere on the
disk in the manner described above.
.bp
The map in Figure 4.1 shows that the first three tracks of each diskette are
always reserved for the bootstrap image of DOS. In the exact center track (track
17) is the VTOC and catalog. The reason for placing the catalog here is simple.
Since the greatest delay when using the disk is waiting for the arm to move from
track to track, it is advantageous to minimize this arm movement whenever
possible. By placing the catalog in the exact center track of the disk, the arm
need never travel more than 17 tracks to get to the catalog track. As files are
allocated on a diskette, they occupy the tracks just above the catalog track
first. When the last track, track 34, has been used, track 16, the track
adjacent and below the catalog, is used next, then 15, 14, 13, and so on, moving
away from the catalog again, toward the DOS image tracks. If there are very few
files on the diskette, they will all be clustered, hopefully, near the catalog
and arm movement will be minimized. Additional space for a file, if it is
needed, is first allocated in the same track occupied by the file. When that
track is full, another track is allocated elsewhere on the disk in the manner
described above.
THE VTOC
The Volume Table Of Contents is the "anchor" of the
entire diskette. On any diskette
accessible by any version of DOS, the
VTOC sector is always in the same
place; track 17, sector 0. (Some protected
disks have the VTOC at another location
and provide a special DOS which can find it.)
Since files can end up anywhere on the
diskette, it is through the VTOC
anchor that DOS is able to find them.
The VTOC of a diskette has the
following format (all byte offsets are
The Volume Table Of Contents is the "anchor" of the entire diskette. On any
diskette accessible by any version of DOS, the VTOC sector is always in the same
place; track 17, sector 0. (Some protected disks have the VTOC at another
location and provide a special DOS which can find it.) Since files can end up
anywhere on the diskette, it is through the VTOC anchor that DOS is able to find
them. The VTOC of a diskette has the following format (all byte offsets are
given in base 16, hexadecimal):
.np
VOLUME TABLE OF CONTENTS (VTOC) FORMAT
.sp1
.un
BYTE DESCRIPTION
00 Not used
01 Track number of first catalog sector
@ -114,87 +80,57 @@ BC-BF Bit map of free sectors in track 33
C0-C3 Bit map of free sectors in track 34
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
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
+1 7654 3210
+2 .... .... (not used)
+3 .... .... (not used)
.sp1
Thus, if only sectors E and 8 are free and all
others are allocated, the bit map will be:
.sp1
41000000
.sp1
If all sectors are free:
FFFF0000
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
*** INSERT FIGURE 4.2 ***
.bp
THE CATALOG
.ll30
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.
*** INSERT FIGURE 4.2 ***
THE CATALOG
In order for DOS to find a given file, it must first read the VTOC to find out
where the first catalog sector is located. Typically, the catalog sectors for a
diskette are the remaining sectors on track 17, following the VTOC sector. Of
course, as long as a track/sector pointer exists in the VTOC and the VTOC is
located at track 17, sector 0, DOS does not really care where the catalog
resides. Figure 4.3 diagrams the catalog track. The figure shows the
track/sector pointer in the VTOC at bytes 01 and 02 as an arrow pointing to
track 17 (11 in hexadecimal) sector F. The last sector in the track is the first
catalog sector and describes the first seven files on the diskette. Each catalog
sector has a track/sector pointer in the same position (bytes 01 and 02) which
points to the next catalog sector. The last catalog sector (sector 1) has a zero
pointer to indicate that there are no more catalog sectors in the chain.
In order for DOS to find a given
file, it must first read the VTOC to
find out where the first catalog
sector is located. Typically, the
catalog sectors for a diskette are
the remaining sectors on track 17,
following the VTOC sector. Of course,
as long as a track/sector pointer
exists in the VTOC and the VTOC is
located at track 17, sector 0, DOS
does not really care where the
catalog resides.
Figure 4.3 diagrams the catalog
track. The figure shows the
track/sector pointer
in the VTOC at bytes 01 and 02 as an
arrow pointing to track 17 (11 in
hexadecimal)
sector F. The last sector in the
track is the first catalog sector and
describes the first seven files on
the diskette. Each catalog
sector has a track/sector
pointer in the same position (bytes
01 and 02) which points to the next
catalog sector. The last catalog
sector (sector 1)
has a zero pointer to indicate
that there are no more catalog
sectors in the chain.
.sp1
*** INSERT FIGURE 4.3 ***
In each catalog
sector up to seven files may be
listed and described. Thus, on a
typical DOS 3.3 diskette, the catalog can
hold up to 15 times
7, or 105 files. A
catalog sector is formatted as
described on the following page.
.br
.ll60
.sp1
.np
In each catalog sector up to seven files may be listed and described. Thus, on a
typical DOS 3.3 diskette, the catalog can hold up to 15 times 7, or 105 files. A
catalog sector is formatted as described on the following page.
CATALOG SECTOR FORMAT
.sp1
.un
BYTE DESCRIPTION
00 Not used
01 Track number of next catalog sector (usually 11 hex)
@ -207,11 +143,11 @@ BYTE DESCRIPTION
97-B9 Fifth file descriptive entry
BA-DC Sixth file descriptive entry
DD-FF Seventh file descriptive entry
.bp
FILE DESCRIPTIVE ENTRY FORMAT
.sp1
RELATIVE
.un
BYTE DESCRIPTION
00 Track of first track/sector list sector.
If this is a deleted file, this byte contains a hex
@ -240,52 +176,32 @@ BYTE DESCRIPTION
The CATALOG command will only format the LO byte of
this length giving 1-255 but a full 65,535 may be
stored here.
.sp
Figure 4.4 is an example of a typical
catalog sector. In this example there
are only four files on the entire
diskette, so only one catalog sector
was needed to describe them. There
are four entries in use and three
entries which have never been used
and contain zeros.
.sp1
Figure 4.4 is an example of a typical catalog sector. In this example there are
only four files on the entire diskette, so only one catalog sector was needed to
describe them. There are four entries in use and three entries which have never
been used and contain zeros.
*** INSERT FIGURE 4.4 ***
.sp1
THE TRACK/SECTOR LIST
Each file has
associated with it a "Track/Sector
List" sector. This sector contains a
list of track/sector pointer pairs
which sequentially list the data sectors
which make up the file. The file
descriptive entry in the catalog
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
Each file has associated with it a "Track/Sector List" sector. This sector
contains a list of track/sector pointer pairs which sequentially list the data
sectors which make up the file. The file descriptive entry in the catalog 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.
*** INSERT FIGURE 4.5 ***
.bp
The format of a Track/Sector List
sector is given below. Note that
since even a minimal file requires
one T/S List sector and one data
sector, the least number of sectors a
non-empty
file can have is 2. Also, note that a
very large file, having more than 122
data sectors, will need more than one
Track/Sector List to hold all the
Track/Sector pointer pairs.
.sp1
.ne10
.np
The format of a Track/Sector List sector is given below. Note that since even a
minimal file requires one T/S List sector and one data sector, the least number
of sectors a non-empty file can have is 2. Also, note that a very large file,
having more than 122 data sectors, will need more than one Track/Sector List to
hold all the Track/Sector pointer pairs.
TRACK/SECTOR LIST FORMAT
.sp1
.un
BYTE DESCRIPTION
00 Not used
01 Track number of next T/S List sector if one was
@ -298,356 +214,183 @@ BYTE DESCRIPTION
0C-0D Track and sector of first data sector or zeros
0E-0F Track and sector of second data sector or zeros
10-FF Up to 120 more Track/Sector pairs
.sp1
A sequential file will end when the first zero T/S List entry
is encountered. A random file, however, can have spaces within
it which were never allocated and therefore
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.
A sequential file will end when the first zero T/S List entry is encountered. A
random file, however, can have spaces within it which were never allocated and
therefore 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.
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
bytes in length. Counting this data 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.
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
bytes in length. Counting this data
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
*** INSERT FIGURE 4.6 ***
.bp
Following the Track/Sector pointer in
the T/S List sector, we come to the
first data sector of the file. As
we examine the data sectors, the
differences between the file types
become apparent. All files (except,
perhaps, a random TEXT file) are
considered to be continuous streams
of data, even though they must be
broken up into 256 byte chunks to
fit in sectors on the diskette.
Although these sectors are not
necessarily contiguous (or next to
each other on the diskette), by using
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
Following the Track/Sector pointer in the T/S List sector, we come to the first
data sector of the file. As we examine the data sectors, the differences between
the file types become apparent. All files (except, perhaps, a random TEXT file)
are considered to be continuous streams of data, even though they must be broken
up into 256 byte chunks to fit in sectors on the diskette. Although these
sectors are not necessarily contiguous (or next to each other on the diskette),
by using 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.
TEXT FILES
The TEXT data type is the least
complicated
file data structure. It consists of
one or more records, separated from
each other by carriage return
characters (hex 8D's). This structure
is diagrammed and an example file is
given in Figure 4.7. Usually, the end
of a TEXT file is signaled by the
presence of a hex 00 or the lack of
any more data sectors in the T/S List
for the file. As mentioned
earlier, if the file has random
organization, there may be hex 00's
imbedded in the data and even missing
data sectors in areas where nothing
was ever written. In this case, the
only way to find the end of the file
is to scan the Track/Sector List for
the last non-zero Track/Sector pair.
Since carriage return characters and
hex 00's have special meaning in a
TEXT type file, they can not be part
of the data itself. For this reason,
and to make the data accessible to
BASIC, the data can only contain
printable or ASCII characters
(alphabetics, numerics or special
characters, see p. 8 in the APPLE II
REFERENCE MANUAL)
This restriction makes
processing of a TEXT file slower and
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
The TEXT data type is the least complicated file data structure. It consists of
one or more records, separated from each other by carriage return characters
(hex 8D's). This structure is diagrammed and an example file is given in Figure
4.7. Usually, the end of a TEXT file is signaled by the presence of a hex 00 or
the lack of any more data sectors in the T/S List for the file. As mentioned
earlier, if the file has random organization, there may be hex 00's imbedded in
the data and even missing data sectors in areas where nothing was ever written.
In this case, the only way to find the end of the file is to scan the
Track/Sector List for the last non-zero Track/Sector pair. Since carriage
return characters and hex 00's have special meaning in a TEXT type file, they
can not be part of the data itself. For this reason, and to make the data
accessible to BASIC, the data can only contain printable or ASCII characters
(alphabetics, numerics or special characters, see p. 8 in the APPLE II REFERENCE
MANUAL) This restriction makes processing of a TEXT file slower and 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.
*** INSERT FIGURE 4.7 ***
.bp
BINARY FILES
The structure of a BINARY type file is
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 address and length (in low order,
high order format) are those given in
the A and L keywords from the BSAVE
command which created the file.
Notice that DOS writes one extra byte
to the file. This does not matter too
much since BLOAD and BRUN
will only read the
number of bytes given in the length
field. (Of course, if you BSAVE a
multiple of 256 bytes, a sector will
be wasted because of this error)
DOS could be made to BLOAD or BRUN
the binary image at a different
address either by providing the A
(address) keyword when the command is
entered, or by changing the address
in the first two bytes of the file on
the diskette.
.sp1
The structure of a BINARY type file is 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 address and
length (in low order, high order format) are those given in the A and L keywords
from the BSAVE command which created the file. Notice that DOS writes one extra
byte to the file. This does not matter too much since BLOAD and BRUN will only
read the number of bytes given in the length field. (Of course, if you BSAVE a
multiple of 256 bytes, a sector will be wasted because of this error) DOS could
be made to BLOAD or BRUN the binary image at a different address either by
providing the A (address) keyword when the command is entered, or by changing
the address in the first two bytes of the file on the diskette.
*** INSERT FIGURE 4.8 ***
.sp1
APPLESOFT AND INTEGER FILES
A BASIC program, be it APPLESOFT or
INTEGER, is saved to the diskette in
a way that is similar to BSAVE. The
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
in memory and its length. Since a
BASIC program is always loaded at a
location known to the BASIC
interpreter, it is not necessary to
store the address in the file as with
a BINARY file. The length is stored,
however, as the first two bytes, and
is followed by the image from memory.
Notice that, again, DOS incorrectly
writes an additional byte, even though
it will be ignored by LOAD. The
memory image of the program consists
of program lines in an internal
format which is made up of what are
called "tokens". A treatment of the
structure of a BASIC program as it
appears in memory is outside the
scope of this manual, but a
breakdown of the example INTEGER
BASIC program is given in Figure
4.10.
.sp1
A BASIC program, be it APPLESOFT or INTEGER, is saved to the diskette in a way
that is similar to BSAVE. The 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 in memory and its length.
Since a BASIC program is always loaded at a location known to the BASIC
interpreter, it is not necessary to store the address in the file as with a
BINARY file. The length is stored, however, as the first two bytes, and is
followed by the image from memory. Notice that, again, DOS incorrectly writes
an additional byte, even though it will be ignored by LOAD. The memory image of
the program consists of program lines in an internal format which is made up of
what are called "tokens". A treatment of the structure of a BASIC program as it
appears in memory is outside the scope of this manual, but a breakdown of the
example INTEGER BASIC program is given in Figure 4.10.
*** INSERT FIGURES 4.9 AND 4.10 ***
.bp
OTHER FILE TYPES (S,R,A,B)
Additional file types have been
defined within DOS as can be seen in
the file descriptive entry format,
shown
earlier. No DOS commands at present
use these additional types so their
eventual meaning is anybody's guess.
The R file type, however, has been
used with the DOS TOOLKIT assembler
for its output file, a relocatable
object module. This file type is used
with a
special form of BINARY file which can
contain the memory image of a machine
language program which may be
relocated anywhere in the machine
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.
It is recommended that if the
reader requires more information
about R files he should refer to that
documentation.
.sp1
Additional file types have been defined within DOS as can be seen in the file
descriptive entry format, shown earlier. No DOS commands at present use these
additional types so their eventual meaning is anybody's guess. The R file type,
however, has been used with the DOS TOOLKIT assembler for its output file, a
relocatable object module. This file type is used with a special form of BINARY
file which can contain the memory image of a machine language program which may
be relocated anywhere in the machine 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. It is recommended that if the reader requires
more information about R files he should refer to that documentation.
EMERGENCY REPAIRS
From time to time the information on
a diskette can become damaged or
lost. This can create various
symptoms, ranging from mild side
effects, such as the disk not
booting, to major problems, such as
an input/output (I/O) error in the catalog. A good
understanding of the format of a
diskette, as described previously,
and a few program tools can allow any
reasonably sharp APPLE II user to
patch up most errors on his
diskettes.
From time to time the information on a diskette can become damaged or lost. This
can create various symptoms, ranging from mild side effects, such as the disk
not booting, to major problems, such as an input/output (I/O) error in the
catalog. A good understanding of the format of a diskette, as described
previously, and a few program tools can allow any reasonably sharp APPLE II user
to patch up most errors on his diskettes.
A first question would be, "how do
errors occur". The most common cause
of an error is a worn or physically
damaged diskette. Usually, a diskette
will warn you that it is wearing out
by producing "soft errors". Soft
errors are I/O errors which occur
only randomly. You may get an I/O
error message when you catalog a
disk one time and have it catalog
correctly if you
try again. When this happens, the
smart programmer immediately copies
the files on
the aged diskette to a brand new one
and discards the old one or keeps it
as a backup.
A first question would be, "how do errors occur". The most common cause of an
error is a worn or physically damaged diskette. Usually, a diskette will warn
you that it is wearing out by producing "soft errors". Soft errors are I/O
errors which occur only randomly. You may get an I/O error message when you
catalog a disk one time and have it catalog correctly if you try again. When
this happens, the smart programmer immediately copies the files on the aged
diskette to a brand new one and discards the old one or keeps it as a backup.
Another cause of damaged diskettes is
the practice of hitting the RESET key
to abort the execution of a program
which is
accessing the diskette. Damage will
usually occur when the RESET signal
comes just as data is being written
onto the disk. Powering the machine
off just as data is being written to
the disk is also a sure way to
clobber a diskette. Of course, real
hardware problems in the disk drive
or controller card and ribbon cable
can cause damage as well.
.bp
If the damaged diskette can be
cataloged, recovery is much easier.
A damaged DOS image in the first
three tracks can usually be corrected
by running the MASTER CREATE program
against the diskette
or by copying all the files to
another diskette. If only one file
produces an I/O error when it is
VERIFYed, it may be possible to copy
most of the sectors of the file to
another diskette by skipping over the
bad sector with an assembler program
which calls RWTS in DOS or with a
BASIC program (if the file is a TEXT
file). Indeed, if the problem is a bad
checksum (see CHAPTER 3) it may be
possible to read the bad sector and
ignore the error and get most of the
data.
Another cause of damaged diskettes is the practice of hitting the RESET key to
abort the execution of a program which is accessing the diskette. Damage will
usually occur when the RESET signal comes just as data is being written onto the
disk. Powering the machine off just as data is being written to the disk is also
a sure way to clobber a diskette. Of course, real hardware problems in the disk
drive or controller card and ribbon cable can cause damage as well.
An I/O error usually means that one
of two conditions has occured. Either
a bad checksum was detected on the
data in a sector, meaning that one or
more bytes is bad; or the
sectoring is clobbered such that the
sector no longer even exists on the
diskette. If the latter is the case,
the diskette (or at the very least,
the track) must be reformatted,
resulting in a massive loss of data.
Although DOS can be patched to format
a single track, it is usually easier
to copy all readable sectors from the
damaged diskette to another formatted
diskette and then reconstruct the
lost data there.
If the damaged diskette can be cataloged, recovery is much easier. A damaged
DOS image in the first three tracks can usually be corrected by running the
MASTER CREATE program against the diskette or by copying all the files to
another diskette. If only one file produces an I/O error when it is VERIFYed, it
may be possible to copy most of the sectors of the file to another diskette by
skipping over the bad sector with an assembler program which calls RWTS in DOS
or with a BASIC program (if the file is a TEXT file). Indeed, if the problem is
a bad checksum (see CHAPTER 3) it may be possible to read the bad sector and
ignore the error and get most of the data.
Many commercially available utilities
exist which allow the user to
read and display the contents of
sectors. Some of these utilities also
allow you to modify the sector data
and rewrite it to the same or another
diskette. A simple version of such a
utility is provided in APPENDIX A.
The ZAP program given there will read
any track/sector into memory,
allowing the user to examine it or
modify the data and then, optionally,
rewrite it to a diskette. Using such
a program is very important when
learning about diskette formats and
when fixing clobbered data.
.bp
Using ZAP, a bad sector within a file
can be localized by reading each
track/sector listed in the T/S List
sector for the file. If the bad
sector is a catalog sector, the
pointers of up to seven files may be
lost. When this occurs, a
search of the diskette can be made to
find T/S List sectors which do not
correspond to any files listed in the
remaining "good" catalog sectors.
As these
sectors are found, new file
descriptive entries can be made in the
damaged sector which point to these
T/S Lists. When the entire catalog is
lost, this process can take hours,
even with a good understanding of
the format of DOS diskettes. Such an
endeavor should only be undertaken if
there is no other way to recover the
data. Of course the best policy is to
create backup copies of important
files periodically to simplify
recovery. More information on the
above procedures is given in APPENDIX
A.
An I/O error usually means that one of two conditions has occured. Either a bad
checksum was detected on the data in a sector, meaning that one or more bytes is
bad; or the sectoring is clobbered such that the sector no longer even exists on
the diskette. If the latter is the case, the diskette (or at the very least, the
track) must be reformatted, resulting in a massive loss of data. Although DOS
can be patched to format a single track, it is usually easier to copy all
readable sectors from the damaged diskette to another formatted diskette and
then reconstruct the lost data there.
A less significant form of diskette
clobber, but very annoying, is the
loss of free sectors. Since DOS
allocates an entire track of sectors
at a time while a file is open,
hitting RESET can cause these sectors
to be marked in use in the VTOC even
though they have not yet been added
to any T/S List. These lost sectors
can never be recovered by normal
means, even when the file is deleted,
since they are not in its T/S List.
The result is a DISK FULL message
before the diskette is actually full.
To reclaim the lost sectors
it is necessary to
compare every sector listed in every
T/S List against the VTOC bit map to
see if there are any discrepancies.
There are utility programs which will
do this automatically but the best
way to solve this problem is to copy
all the files on the diskette to
another diskette (note that FID must
be used, not COPY, since COPY copies
an image of the diskette, bad VTOC
and all).
Many commercially available utilities exist which allow the user to read and
display the contents of sectors. Some of these utilities also allow you to
modify the sector data and rewrite it to the same or another diskette. A simple
version of such a utility is provided in APPENDIX A. The ZAP program given
there will read any track/sector into memory, allowing the user to examine it or
modify the data and then, optionally, rewrite it to a diskette. Using such a
program is very important when learning about diskette formats and when fixing
clobbered data.
Using ZAP, a bad sector within a file can be localized by reading each
track/sector listed in the T/S List sector for the file. If the bad sector is a
catalog sector, the pointers of up to seven files may be lost. When this occurs,
a search of the diskette can be made to find T/S List sectors which do not
correspond to any files listed in the remaining "good" catalog sectors. As
these sectors are found, new file descriptive entries can be made in the damaged
sector which point to these T/S Lists. When the entire catalog is lost, this
process can take hours, even with a good understanding of the format of DOS
diskettes. Such an endeavor should only be undertaken if there is no other way
to recover the data. Of course the best policy is to create backup copies of
important files periodically to simplify recovery. More information on the
above procedures is given in APPENDIX A.
A less significant form of diskette clobber, but very annoying, is the loss of
free sectors. Since DOS allocates an entire track of sectors at a time while a
file is open, hitting RESET can cause these sectors to be marked in use in the
VTOC even though they have not yet been added to any T/S List. These lost
sectors can never be recovered by normal means, even when the file is deleted,
since they are not in its T/S List. The result is a DISK FULL message before
the diskette is actually full. To reclaim the lost sectors it is necessary to
compare every sector listed in every T/S List against the VTOC bit map to see if
there are any discrepancies. There are utility programs which will do this
automatically but the best way to solve this problem is to copy all the files on
the diskette to another diskette (note that FID must be used, not COPY, since
COPY copies an image of the diskette, bad VTOC and all).
If a file is deleted it can usually be recovered, providing that additional
sector allocations have not occured since it was deleted. If another file was
created after the DELETE command, DOS might have reused some or all of the
sectors of the old file. The catalog can be quickly ZAPped to move the track
number of the T/S List from byte 20 of the file descriptive entry to byte 0. The
file should then be copied to another disk and then the original deleted so that
the VTOC freespace bit map will be updated.
If a file is deleted it can usually
be recovered, providing that
additional sector allocations have
not occured since it was deleted.
If another file was created after the
DELETE command, DOS might have reused
some or all of the sectors of the old
file. The catalog can be quickly
ZAPped to move the track number of the T/S
List from byte 20 of the file
descriptive entry to byte 0. The file
should then be copied to another disk
and then the original deleted so that
the VTOC freespace bit map will
be updated.
.nx ch5