ftp.barnyard.co.uk/2015.02.ftp.barnyard.co.uk.tar/ftp.barnyard.co.uk/cpm/walnut-creek-CDROM/ENTERPRS/CPM/UTILS/A/EDIR.ZIP/EDIR.DOC

Text File | 1990-11-24 | 35KB | 720 lines

              EDIR V1.0 FOR CP/M 2.2 COMPUTERS

        FILE UNERASER AND ERASED DIRECTORY ACCESSER

    INCLUDING ASSORTED FILE RECOVERY PALS AND TECHNIQUES

                       As of 12/14/87

             Copyright 1987 by Robert Greenlee

                       P.O. Box 23286
                San Diego, California 92123
              Telephone: [phone] Voice
              Telephone: [phone] Modem

              ** Frequented Bulletin Boards **
                   SABALINE: 619-692-1961
                   ZNODE #9: 619-270-3148

Please tell me what kind of CP/M or MSDOS computer/printer you have so that I
can add your name to my mailing list.

                    ====================

Version 1.0 downloaded 12/14/87 for BBS Distribution.  Next version to include
EDIR machine code routines for Turbo Pascal, dBASE, and BASIC.

                    ====================

                   EDIR LIBRARY CONTENTS

This EDIR software library should contain at least the
following files:

EDIR.ASM.......Source.
EDIR.DOC.......What you're reading now.
EDIR.COM.......Erased directory accessing program.  Unerases
               files and more.
NO-WRITE.ASM...Source.
NO-WRITE.COM...Lost file recovery aid.  Allows saving data
               contained in the free space of a disk into
               files.  A useful worm but be careful!
NO-STOP.ASM....Source.
NO-STOP.COM....Stops CP/M from waiting for a keypress after
               every "Bdos Err On B: Bad Sector" message.
NO-ERRS.ASM....Source.
NO-ERRS.COM....Stops CP/M (BIOS READ) from detecting bad
               sectors.  Useful to enable some COPY programs
               to copy disks containing bad sectors so that
               file recovery can be attempted with the copy.
               (Probably won't work with Kaypro COPY.COM).

If you're missing any of the programs then you should still be able to create
stripped down but working versions by using DDT as shown below.  The stripped
down versions don't have sign-on messages.

                    ====================

                     TABLE OF CONTENTS

         1. The EDIR Philosophy and How to Use EDIR.
         2. Unerasing Pitfalls - Duplicate Filenames.
         3. User Areas - Do you even use them?
         4. PIP Tip (Just PIPed over a precious file?)
         5. EDIR System Requirements.
         6. Creating EDIR.COM with DDT.COM.
         7. About unerasing with ERA *.* under EDIR
         8. First-Aid for Corrupted Files.
        9a. Recovering Lost Files using NO-WRITE (lost files
            are files which are no longer even listed in the
            erased file directory).
        9b. Recovering Lost Files - One Final Tip.
        10. Determining the file sizes of any
            erased files before unerasing them.
        11. Getting Around BDOS Bad Sectors (Using NO-STOP).
        12. Getting Around BIOS Bad Sectors (Using NO-ERRS).
        13. Original Intent - Unerasing by Telephone.

                    ====================

          THE EDIR PHILOSOPHY AND HOW TO USE EDIR

Physically CP/M 2.2 has just one file directory per disk.  But CP/M can divide
its one physical directory into many logical file directories.  CP/M lets you
easily switch between the many logical file directories with its USERn
command.  The USERn command can switch between 16 logical file directories
which are called User Areas 0 through 15.  For example to log into User Area 6
you would use the CP/M command:  A>USER 6 <cr>.

When CP/M first erases a file it only changes one byte of data in the physical
file directory.  At first glance the change CP/M makes to a file in order to
erase it just puts the file into User Area #227.  But actually erased files go
into a logical erased file directory.

This logical erased file directory coexists with the currently active user
area.  It coexists because whenever a disk write operation is made any
directory entries and disk data space required by the write operation are
first taken out of the logical erased file directory before any virgin
directory entries or disk space is consumed.  So once a file is placed into
the erased file directory CP/M no longer protects that files data or directory
entries from being reused by subsequent disk write operations.

To access the forbidden erased file directory, the place where all erased
files go and where they start to fade away, I've come up with a small program
called EDIR, which is short for Erased DIRectory.  What EDIR does is to trick
CP/M into actually entering into the erased file directory. Running EDIR, like
so:

     A>EDIR <cr>

takes you into the erased file directory just as you might change from one
drive to another drive or from one user area to another user area.  Once
inside the erased file directory you can use CP/M's DIR, REN, TYPE, and ERA
commands to manipulate the erased files therein.

The ERA command will unERAse files back into the currently selected user area.
The REN command is handy for renaming any duplicate files before unerasing
them.  (Try not to unerase a file into a user area which already contains a
file of the same name.)

Since the erased file directory is a real directory you can run the programs
in it.  Doing so isn't recommended because many programs just won't work right
when run from there.  However certain programs like STAT and PIP can be of use
when run from the erased file directory.  An example of using PIP from there
is presented below in the section ABOUT ERASING WITH ERA *.*.  An example
using STAT is presented below in the section DETERMINING THE FILE SIZES OF
ERASED FILES.

On most computers EDIR can maintain its influence over CP/M only until the
next Warm Boot.  So typing Control-C usually gets CP/M back to normal again
and takes you out of the erased file directory.  Some computers may require a
cold boot or system reset to override EDIR and exit from the erased file
directory.

The files in the erased file directory of a disk are very fragile and can be
disturbed anytime data is written onto the disk.  The disturbance caused to
the erased file directory can range from the permanent loss of the names of
files in that directory and/or the overwriting of file data belonging to one
or more files in that directory (the latter is almost a certainty).

Only immediately after erasing a file is it a sure thing that you'll be able
to find that file in the erased file directory and be sure of the integrity of
the unerased file.  But if after erasing a file you use a program which writes
to the disk then you may not even find the name of the file you erased in the
erased file directory and even if the name of the erased file is listed in the
directory the file might not be totally intact when unerased.

The CP/M DIRectory command under EDIR will only show the names of erased files
which can probably be completely unerased.  So if an erased file has had one
or more of its directory entries reclaimed by a subsequent disk write
operation then the DIR command would no longer display that files name.
However if some of a files directory entries are still left in the directory
and you suspect that's so, then the ERA command could still be used to unerase
the remaining directory entries, just as would be the case when using
UNERA.COM or MAKE.COM.

However there's a problem with unerasing incomplete files (files not shown by
DIR under EDIR which are missing at least one of their directory entries -
which usually means at the very least their first directory entry).  When you
do so by using ERA under EDIR with a file name not shown by DIR under EDIR (or
with programs like UNERA, UNERA+ and MAKE) you end up with a file that's an
abomination to CP/M.  CP/M won't show the recovered file using DIR, you can't
TYPE it, you can't PIP it, DISK.COM can't see it, SWEEP.COM can't open it, but
the file will show up in the directory listing displayed by the typical D.COM
sorted directory program.  Yuck.

Now there are solutions to the abominable file problem but I haven't had time
to think up something simple yet (if you don't need simple then use DU).  So
what I suggest you do for now is to use the procedure presented in RECOVERING
LOST FILES and don't bother with trying to first recover an incomplete piece
of a file.  If it doesn't show up using DIR under EDIR then it's a LOST FILE
so use the procedure outlined in RECOVERING LOST FILES below.

                    ====================

                          PITFALLS

There are two closely related pitfalls to avoid when unerasing files in the
erased file directory.  First you should know that in the erased file
directory more than one file can have the same name.  Second you shouldn't
unerase a file which has a name already being used by an unerased file.  This
is the first obstacle which most UNERA programs can't jump over.  You see most
UNERA programs will unerase all files having the same filename leaving you
with duplicate filenames in the disk directory.

So before unerasing files which have the same name you should use the rename
command REN to give them different filenames.  If you do wind up with
duplicate filenames in the unerased file directory one solution would be to
erase the duplicates and rename them in the erased file directory before
unerasing them again.

The problem with having duplicate filenames in the unerased file directory is
that you only have access to one of the duplicate files.  Unfortunately the
REName and ERAse commands effect all files having the same name in the
unerased file directory.  But fortunately when you're logged into the erased
file directory the REName and ERAse commands only effect the first of the
duplicate files so that you can rename files which have the same filenames
before unerasing them.

Another more subtle mind trap awaiting you concerns the many directory
programs called D.COM, SD.COM, etc.  Most of these programs tell you how many
files there are on a disk and how many empty directory entries remain.  When
getting ready to unerase some files don't outsmart yourself by trying to
calculate the number of files and empty directory entries which SHOULD exist
once the files have been unerased.

Such calculations often comes out wrong.  The number of empty directory
entries is different from the number of files the disk will hold.  That's
because a large file can take up more than one directory entry.  So more than
one directory entry might be consumed by you're unerasing a single file.
Anyway it's hard to see any benefit in calculating how many empty directory
entries you should end up with.  Why bother?

                    ====================

               USER AREAS - DO YOU USE THEM?

Most hard disk users take advantage of CP/M's ability to place files into
different user areas on the hard disk.  Because erased files don't belong to
any of the valid CP/M user areas the erased file directory doesn't change when
you switch user areas.  However whenever you unerase a file it goes into the
currently logged user area.

                    ====================

                          PIP TIP

It can be useful to know that when PIP.COM (and many other programs and
utilities) copies a file onto a disk it first copies to a temporary file and
only when and if the copy is entirely successful is any file having the same
name erased and the temporary file renamed.  What that means is that if you
mistakenly copy over a good file using PIP you can recover that good file if
you don't copy anything else onto the disk prior to recovering it.

                    ====================

                  EDIR SYSTEM REQUIREMENTS

EDIR only works under genuine CP/M 2.2 Basic Disk Operating System (the BDOS).
If you've replaced the CP/M 2.2 Console Command Processor (the CCP) with ZCPR
that's ok as long as you haven't also replaced the BDOS part of CP/M.  EDIR
won't work with ZRDOS.  EDIR runs with 8080, 8085, and Z80 CPU's.

EDIR works by changing a few locations in the BDOS of CP/M and then returns
control back to the CCP part of CP/M.  At that point you're logged into the
fragile erased file directory, a directory which is both imaginary and real, a
directory which could only exist in the outermost reaches of The Twilight
Zone.

                    ====================

             CREATING EDIR.COM WITH DDT.COM

Here's how to use DDT to create a working version of EDIR
and save it to disk as a program named EDIR.COM.

A>DDT
DDT VERS 2.2
-F100,200,1A
-S100
0100 1A 2A     ,---> 011F 1A 32     ,---> 013E 1A 41
0101 1A 01     |     0120 1A 3F     |     013F 1A 00
0102 1A 00     |     0121 1A 01     |     0140 1A 32
0103 1A 25     |     0122 1A 2E     |     0141 1A AF
0104 1A 25     |     0123 1A 59     |     0142 1A 00
0105 1A 2E     |     0124 1A 11     |     0143 1A 3E
0106 1A 7F     |     0125 1A 3B     |     0144 1A C8
0107 1A 3E     |     0126 1A 01     |     0145 1A 01
0108 1A 22     |     0127 1A 06     |     0146 1A 3E
0109 1A BE     |     0128 1A 11     |     0147 1A C9
010A 1A C2     |     0129 1A CD     |     0148 1A 32
010B 1A 00     |     012A 1A 32     |     0149 1A 2A
010C 1A 00     |     012B 1A 01     |     014A 1A 00
010D 1A 7C     |     012C 1A F1     |     014B 1A C9
010E 1A 32     |     012D 1A 67     |     014C 1A 0F
010F 1A 56     |     012E 1A 2E     |     014D 1A 00
0110 1A 01     |     012F 1A 48     |     014E 1A 19
0111 1A D6     |     0130 1A 06     |     014F 1A 7E
0112 1A 04     |     0131 1A 0D     |     0150 1A 3D
0113 1A 32     |     0132 1A 1A     |     0151 1A E8
0114 1A 4A     |     0133 1A 77     |     0152 1A FE
0115 1A 01     |     0134 1A 13     |     0153 1A E4
0116 1A 3D     |     0135 1A 23     |     0154 1A C2
0117 1A 32     |     0136 1A 05     |     0155 1A 64
0118 1A 42     |     0137 1A C2     |     0156 1A 00
0119 1A 01     |     0138 1A 32     |     0157 1A F1
011A 1A D6     |     0139 1A 01     |     0158 1A C9
011B 1A 02     |     013A 1A C9     |     0159 1A .
011C 1A F5     |     013B 1A 36     |     -^C
011D 1A D6     |     013C 1A E5     |     A>SAVE 1 EDIR.COM
011E 1A 02 >---'     013D 1A 3A >---'

At this point the file EDIR.COM should now exist in your
disk directory.  Here's how the EDIR programs code should
look when displayed by DDT:

A>DDT EDIR.COM
DDT VERS 2.2
NEXT  PC
0200 0100
-D100,15F

0100 2A 01 00 25 25 2E 7F 3E 22 BE C2 00 00 7C 32 56
0110 01 D6 04 32 4A 01 3D 32 42 01 D6 02 F5 D6 02 32
0120 3F 01 2E 59 11 3B 01 06 11 CD 32 01 F1 67 2E 48
0130 06 0D 1A 77 13 23 05 C2 32 01 C9 36 E5 3A 41 00
0140 32 AF 00 3E C8 01 3E C9 32 2A 00 C9 0F 00 19 7E
0150 3D E8 FE E4 C2 64 00 F1 C9 1A 1A 1A 1A 1A 1A 1A

                    ====================

                ABOUT UNERASING WITH ERA *.*

For me there is only really scary thing to do with EDIR and that is to unerase
all the files at once by using ERA *.*.  That's when EDIR performs its
toughest trick which is to stop unerasing when it reaches the point in the
directory where no file has gone before.

For you technical users the way EDIR makes the BDOS detect that point is by
checking to see if the sixteenth position in the file control block is the
byte value E5h.  That works only because most computers initialize the data in
the disk directory to the value E5h when formatting a disk.  Most computers
do.

But a few computers do not write the value E5h into every location of the disk
directory when formatting a new disk, and so using ERA *.* to unerase all the
files on such disks would even turn directory entries which had never before
been used into unerased files.  That of course would leave you fresh out of
directory space.

Here's what I do when there are both many unerased files on a disk and many
erased files are going to be unerased.  First I use EDIR to rename any
duplicates among the erased files and then I put a write protect sticker on
that disk.  Then I prepare an empty disk onto which I then transfer the erased
files using PIP.COM before unerasing them.

To use PIP.COM to copy the erased files I place EDIR.COM and PIP.COM onto an
otherwise blank disk, erase PIP.COM, run EDIR.COM, and then with the disk
containing the erased files in drive B I run the erased PIP.COM program on the
A drive to transfer all the erased files from drive B onto the empty disk in
drive A like so:

     A>PIP A:=B:*.*[OV]

The files which PIP copies end up still being erased files on the disk in the
A drive.  Then I take the original disk out of drive B and put it aside.
Next, still logged onto drive A, I run EDIR again (because PIP caused a Warm
Boot when it finished copying which on my computer kicks EDIR out) and use ERA
*.* to unerase the files on drive A.  At that time I can use ERA *.* with more
confidence since I don't have to worry about conflicts with already existing
unerased files (because there are none) and besides the original disk will
still be intact should something go wrong with the ERA *.* operation.

Another potential problem that might come up when using ambiguous file names
is that files which are missing directory entries might get unerased.  Such
files would not be displayed by DIR under EDIR and once unerased they are
untouchable.

                    ====================

               FIRST-AID FOR CORRUPTED FILES

      MODIFYING PIP.COM TO FILTER THE END-OF-FILE CODE

In certain instances the well equipped file uneraser (you and me) needs to
have a program which can filter the CP/M End-of-File marker Control-Z out of
an unerased file.  Here's one scenario of when you might need it:

     You have a very large text file which you've
     accidentally erased.  After you erased the file
     you copied a small file (or files) onto the same
     disk.  Now when you run EDIR the large file shows
     up in the erased file directory so you unERAse it
     and then exit EDIR.  You check the size of the
     large file in the unerased file directory and the
     size seems ok.  You feel lucky because you were
     afraid that copying the smaller file onto the disk
     might have deleted the name of the big file from
     the erased file directory.

     Then you call up the big file you unerased using
     your word processor but there's some gibberish in
     the file which looks as if its part of the
     smaller file which was copied onto the disk after
     the big file was erased.  Where the gibberish ends
     the file seems to end but that doesn't make sense
     because the file size indicates there should be
     quite a bit more in the file.

What has probably happened in the scenario above is that when the smaller file
was copied onto the disk some of its data copied over some of the data
belonging to the big erased file.  Among the data belonging to the small file
is one or more CP/M Control-Z End-of-File Markers and your word processor (eg.
WordStar) won't go beyond the first such marker in a file.

What you need to do is to remove all the Control-Z End-of File Markers from
the big file so that you'll be able to get at the portion of the big file
beyond the gibberish.  However you won't be able to recover the data the
gibberish covered over, that's gone forever.

Here's a patch which can allow PIP.COM to strip all Control-Z End-of-File
Markers from a file.  The patched version of PIP is called PIPZ.  The patch
changes PIP's [F] parameter which normally removes Form Feeds so that it
filters Control-Z codes instead.  Once patched with DDT the new PIP can be
used to filter out the unwanted Control-Z codes using the following command
line:

     A>PIPZ FILENAME=FILENAME[FO]

The letter O option tells PIP that the entire file is to be filtered so that
PIP will not also stop upon encountering the first Control-Z just as your word
processor does.  The letter F options tells the modified PIP to strip out the
Control-Z codes.

Here's how to use DDT.COM to modify PIP.COM so that it will filter out
Control-Z's (1A Hex):

A>DDT PIP.COM
DDT VERS 2.2
NEXT  PC
2100 0100
-FE54,E54,1A
-FE64,E64,1A
-^C
A>SAVE 32 PIPZ.COM

(Above patch to PIP created by Nil R. Olson, N7BCV).

                    ====================

                   RECOVERING LOST FILES

Lost files are files which where unerased but no longer appear in the erased
file directory.  That can happen because whenever a disk is written to the
files in the erased file directory are usually overwritten.  However even
after the name of an erased file disappears from the erased file directory the
data that file contained may be still be wholly or partially intact somewhere
on the disk.

For example here's a typical scenario:

     The latest version of your unpublished novel, all
     150K of it, was on drive B when you mistakenly
     erased it and then copied some small 4K files
     onto the disk.  The file name of your novel isn't
     listed in the erased file directory but you know
     that those 4K files couldn't have overwritten very
     much of your 150K novel.

     You're desperate to retrieve as much of your novel
     as possible.  Even if 8K or so of the novel is
     permanently gone and sections of it are out of
     place it would be much easier to repair the damage
     than to start all over.  After all every paragraph
     is precious!

The first thing to do, if you can do it, is to put a write protect sticker on
the disk with your novel on it and then make a disk image copy of that disk.
All of your attempts at recovering your novel should be made using the copy of
your novel disk and not the original, if possible.  The reason for using the
copy in the following procedure is so that if you make a mistake your novel
won't be lost forever.

The COPY.COM program used to copy Kaypro disks makes the type of disk image
copy I'm referring to in that it copies the entire disk track-by-track and
doesn't concern itself with copying individual files the way PIP.COM does.  By
copying everything on all of the disk tracks the copy will also contain any
erased file data present on the original disk.

Note:  Some COPY.COM programs will abort copying if a bad sector is detected.
In that case what you can do is to try running the NO-ERRS program (see below)
just before running your COPY.COM program.  The NO-ERRS program prevents the
detection of bad sectors and so it may fool your COPY.COM program into copying
the entire disk.  This only works with some COPY.COM programs, probably not
with the Kaypro version.

Now that you've made a disk image copy of the disk containing your erased
novel, and have put the original in a safe place with a write protect sticker
on it, what you're going to do next is to create some 32K files on the copy
without writing any data onto the disk.  In other words you want the 32K files
to claim the data already on the disk, hopefully 32K chunks of your erased
novel, so that you can then transfer those files off of the disk and begin
reconstructing your novel from whatever you find in those files.

Here's how to create the 32K files which claim data already on the disk.  On
another disk create this tiny program which I call NO-WRITE.COM using DDT.COM
like so:

A>DDT
DDT VERS 2.2
-F100,200,1A
-S100
0100 1A 3A    ,--> 0109 1A C1    ,--> 0112 1A C0
0101 1A 02    |    010A 1A BE    |    0113 1A 36
0102 1A 00    |    010B 1A C2    |    0114 1A 01
0103 1A D6    |    010C 1A 00    |    0115 1A C9
0104 1A 04    |    010D 1A 00    |    0116 1A .
0105 1A 67    |    010E 1A 2C    |    -^C
0106 1A 2E    |    010F 1A 36    |    A>SAVE 1 NO-WRITE.COM
0107 1A A1    |    0110 1A 01    |
0108 1A 3E >--'    0111 1A 2E >--'

At this point the file NO-WRITE.COM should exist on the A drive.  Now to start
creating the 32K files which will claim data already on the disk instead of
writing their own data onto the disk put the copy of the disk containing your
erased novel in drive B and log onto drive B.  Now use the commands shown
below to create the files.

Note:  If a Warm Boot occurs immediately after you run NO-WRITE then NO-WRITE
did not install itself because it didn't see the authentic CP/M 2.2 BDOS which
is required in order for NO-WRITE to work.

B>A:NO-WRITE
B>SAVE 128 FILE1
B>SAVE 128 FILE2
B>SAVE 128 FILE3
B>SAVE 128 FILE4
B>SAVE 128 FILE5
B>SAVE 128 FILE6   Keep creating more files until you get
B>SAVE 128 FILE7   the NO SPACE message shown below.
NO SPACE

Notice the NO SPACE message which was displayed by CP/M after the last SAVE
command.  That message means that when CP/M was creating FILE7 it ran out of
disk space and so FILE7 may not be a 32K file.  You must execute the commands
shown above one after another exactly as shown without Warm Booting between
commands.  If you Warm Boot even once between any of the commands then the
SAVE commands after the Warm Boot will actually write data onto the disk which
will destroy 32K chunks of your erased novel!

Now reset your computer in order to get the NO-WRITE program out of the
computers memory.  Typing Control-C would also probably remove the NO-WRITE
program from memory but reset your system anyway just to be sure.

Ok so now you have a bunch of 32K chunks of your novel.  The first thing you
should do now is to filter each of those chunks using the PIPZ program
discussed in the section above called "FIRST-AID FOR CORRUPTED FILES."  After
that it's up to you and your word processor.

When you're looking at the recovered 32K chunks using your word processor,
let's assume WordStar, you may see lots of very long strings of the lower-case
letter e.  Those represent empty sectors on the disk which have not been
filled with file data even once since the disk was originally formatted.
Because each empty logical sector has 128 e's in it if you do a global replace
of the e's to get rid of them you should use a string of e's the length of
which is an even divisor of 128, such as a string of 8 or 16 e's.


           RECOVERING LOST FILES - ONE FINAL TIP

In the scenario outlined above two small 4K files where copied onto the disk
after the 150K novel was erased.  If either or both of the 4K files overwrote
some of the novel there is a chance that some of the novel might still be left
in areas of the disk claimed by, but not used by, the two 4K files.  The
reason this can be is related to the minimum file size on individual
computers.  On the Kaypro 2, Kaypro 4, and Kaypro 10 the maximum remaining
tidbit of your novel which might remain intact in the disk data space claimed
by each of 4K files would be 128 bytes less than 1K, 2K, or 4K respectively.

To try and recover such tidbits, assuming they exist, you can start by erasing
just those two 4K files.  At that point, since the disk would already be
completely filled with files because of your previous use of the WRITE-NO/SAVE
procedure, the only free space on the disk should be that which was made
available by your erasure of the two 4K files.

Now repeat the NO-WRITE/SAVE procedure using a different filename in the SAVE
command.  That will produce a file containing all the data in the disk areas
previously claimed by the two 4K files.  Finally run the resulting file
through PIPZ and you'll be ready to check it for novel data using your word
processor.

                    ====================

         DETERMINING THE FILE SIZES OF ERASED FILES

To see the file sizes of the erased files on drive B place a copy of STAT.COM
on drive A and then erase it.  Once EDIR is run you can then run the erased
STAT.COM to list the file sizes of the erased files on drive B like so:

If logged onto drive B use the command  B>A:STAT *.*
If logged onto drive A use the command  A>STAT B:*.*

                    ====================

              GETTING AROUND BDOS BAD SECTORS

If you have a damaged floppy diskette in drive B and CP/M reads a bad sector
from the disk then CP/M will make the announcement "BDOS Err on B: Bad Sector"
and suspend operations until you tell it what to do.  If you type a Control-C
at that point CP/M will cause a Warm Boot.  If you type anything other than a
Control-C then CP/M will disregard that the data read from the bad sector is
probably corrupted and continue operations as if the bad sector had not even
been detected.

Note:  Each bad sector CP/M reports might mean anywhere from 128 to 1024 or
more bytes of possibly corrupted data, depending on the physical disk sector
size used in your particular computer.

When a damaged diskette has a great many bad sectors and you're trying to
transfer the damaged files then you might not like having to stay by the
computer in order to type a key each time the bad sector message is displayed.
So here's a small program which will prevent CP/M from waiting for a keypress.
You can create this program, which I call NO-STOP.COM, by using DDT.COM like
so:

A>DDT
DDT VERS 2.2
-F100,200,1A
-S100
0100 1A 3A    ,--> 0107 1A F7    ,--> 010E 1A 2C
0101 1A 02    |    0108 1A 3E    |    010F 1A 36
0102 1A 00    |    0109 1A C1    |    0110 1A C3
0103 1A D6    |    010A 1A BE    |    0111 1A C9
0104 1A 0E    |    010B 1A C2    |    0112 1A .
0105 1A 67    |    010C 1A 00    |    -^C
0106 1A 2E >--'    010D 1A 00 >--'    A>SAVE 1 NO-STOP.COM

The file NO-STOP.COM should now exist on the A drive.  The NO-STOP program,
like EDIR and NO-WRITE, will only stay in operation on most computers until a
Warm Boot comes along at which time it gets kicked out of the computers RAM
memory.

So here's exactly what I'd do to copy files from a damaged diskette using
PIP.COM.  First I'd put a diskette containing only the two files PIP.COM and
NO-STOP.COM into drive A.  Next I'd put the damaged diskette into drive B.
I'd turn on the printer and type Control-P so that I'd have a printed record
of the file transfer.  Then I'd run NO-STOP and PIP to copy all the files from
drive B to drive A like so:

     A>NO-STOP
     A>PIP A:=B:*.*[OV]

Once PIP started copying the files I'd leave the room and come back later
after all the files had been copied.  At that point the listing on the printer
might look like this:

     A>NO-STOP

     A>PIP A:=B:*.*[OV]

     COPYING -
     FILENAME1
     FILENAME2
     FILENAME3
     Bdos Err On B: Bad Sector
     FILENAME4
     FILENAME5
     Bdos Err On B: Bad Sector
     Bdos Err On B: Bad Sector
     FILENAME6
     FILENAME7

Of course in a real listing the FILENAME's would be the actual names of files.
From the printed listing above I could tell that FILENAME3 had one bad sector
and FILENAME5 had two bad sectors.

                    ====================

              GETTING AROUND BIOS BAD SECTORS

Sometimes you may want to prevent CP/M from even detecting bad sectors.  For
example many COPY.COM programs which copy disks track-by-track instead of
file-by-file bypass the BDOS entirely go straight to the CP/M BIOS.  Many of
these COPY programs will abort copying if even one bad sector is detected.  So
here's a small program which will prevent CP/M from detecting bad sectors.
You can create this program, which I have named NO-ERRS.COM, by using DDT.COM
like so:

A>DDT
DDT VERS 2.2
-F100,200,1A
-S100
0100 1A 3A    ,--> 010C 1A 1A    ,--> 0118 1A 23
0101 1A 02    |    010D 1A 77    |    0119 1A 36
0102 1A 00    |    010E 1A 3E    |    011A 1A AF
0103 1A 57    |    010F 1A 54    |    011B 1A 23
0104 1A 1E    |    0110 1A 12    |    011C 1A 36
0105 1A 28    |    0111 1A 23    |    011D 1A C9
0106 1A 21    |    0112 1A 13    |    011E 1A C9
0107 1A 54    |    0113 1A 1A    |    011F 1A .
0108 1A 00    |    0114 1A 77    |    -^C
0109 1A 36    |    0115 1A 3E    |    A>SAVE 1 NO-ERRS.COM
010A 1A CD    |    0116 1A 00    |
010B 1A 23 >--'    0117 1A 12 >--'

At this point the file NO-ERRS.COM should be present in your disk directory.
The NO-ERRS program differs from EDIR, NO-WRITE and NO-STOP in that NO-ERRS
will survive Warm Boot's.  Therefore you must reset your computer in order to
stop it from preventing the detection of bad disk sectors.

If you make use of the NO-ERRS program in order to allow a COPY.COM type
program to copy a disk with bad sectors then the resulting copy will not have
any bad sectors.  However the bad data in the bad sectors will probably end up
in the corresponding good sectors on the copy.  That means that on the copy
there will be no way to tell which sectors have the bad data in them unless
you can visually examine the data.  Visual examination can be practical
however, especially when the data is text from a novel for example.

                    ====================

          ORIGINAL INTENT - UNERASING BY TELEPHONE

I began writing EDIR because of a few people who called me asking if there's
any way to unerase files without having an UNERA utility which they didn't
have (but had just ordered).  When a precious file has been erased it can be
very hard to wait for an UNERA program to arrive by mail.  Especially hard if
you have a hard disk since you don't dare write anything onto the hard disk
until you first unerase the file(s).

The EDIR program and its assorted pals are small enough to be created using
DDT.COM in a few minutes.  The small program size allows reading the codes
over the phone to someone entering them into DDT.  Once EDIR is created then
recovery of erased files is even easier than using UNERA programs such as
UNERA.COM or MAKE.COM.

                    ====================