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