File Recovery with VOYEUR N2.0


VOYEUR can be valuable after a cold start in recovering BASIC programs from tokenized (.BA) files.  It can also be used to salvage ASCII text (.DO) files.  During recovery, VOYEUR should read the original "dead" files since the nulls which trigger the reading of line numbers, and which may be part of them, are lost during conventional recovery to a text file.  Also, VOYEUR cannot easily copy to a file while reading another "live" text file, since the latter is periodically shifted upward in RAM as blocks of the new file are inserted beneath, causing repeated reading of the same data.

Loading VOYEUR N2.0 will destroy almost 4KB of dead code near the bottom of RAM unless the dead files are first shifted higher by running a small relocation program.  For an 8201A bank with 32K of RAM, enter BASIC and type

	FORA=57300TO32768STEP-1:POKEA+4000,PEEK(A):NEXT:BEEP

then press the return key.  Running time is about five minutes.  Limited experience with relocation suggests that 61300 (57300 + 4000) is about the highest 8201A address to which files should be poked; attempts to poke higher in corresponding Tandy M100 addresses have resulted in error messages and even in lockups requiring new cold starts!  Starting even lower may be safer, although file code above the starting address will be destroyed.  With RAM fully packed, a choice may be required as to which files to sacrifice.  Fortunately, the most recent files, least likely to have been backed up, tend to be located near the middle of RAM, above the older .BA files and below the older .DO files, so that the relocation program may not be needed or, if used, may not damage anything of importance.

If RAM must be used for the recovered files, the shift may need to be greatly increased (with a corresponding reduction in the starting address) in order to prevent dead .BA files from being overwritten, before they can be read by VOYEUR, by the larger live .DO versions being created.  Dead files can be relocated more than once: load VOYEUR after a 4K shift in order to survey RAM prior to a second shift.

Load VOYEUR in .BA form, via tape or a ROM based DOS.  Loading a .DO version of VOYEUR or a RAM based DOS would use much more space.  For TS-DOS in ROM, first activate the chip from BASIC by entering

	POKE63911,1:EXEC62394

Enter VOYEUR to copy with BASIC decoding on to rescue .BA files, and off for .DO files.  Scan to find the start of a dead file to be recovered, place the cursor over the null preceding a .BA file or over the first text character in a .DO file, and then press key "F" for the filename prompt.  (Press "0" or only the return key at the second prompt.)  For recovery to disk using TS-DOS with a TPDD2, enter each filename with the bank prefix "0:" or "1:"; with a TPDD1 (untested), use only "0:".  For recovery to tape (untested), use the prefix "CAS:"

If another computer is available, VOYEUR and the recovered files can be transferred via a null-modem cable.  Transfer VOYEUR as a .BA file to the cold-started machine by first loading it into BASIC of the other (similar) machine; then, from BASIC, LOAD in the cold-started machine and SAVE in the other, in that order, using for both the filename of "COM:" followed by five communication parameters, such as "5N81XS".  In the "rescue" machine, enter TELCOM terminal mode and prepare to download using regular names for the recovered files.  When copying files in VOYEUR, enter at the filename prompt "COM:5N81XS", e.g., using the same communication parameters for both machines.  It is fascinating to watch two computers side by side displaying on one screen the original tokenized program being read, and on the other the ASCII equivalent as VOYEUR translates.

If RAM files in the cold-started machine must be used for the recovered text, start with the file to be recovered that is lowest in memory and always work upwards.  Copying should not start too close to VOYEUR; either use a large relocation shift or leave a buffer of sacrificed files.  These can first be saved to paper by entering the filename "LPT:"; the colon is essential even though nothing follows it.  It may be thought that ASCII text overgrowth could be limited by trimming, loading, saving in .BA form, and then KILLing the .DO version immediately after recovering each file.  KILLing a file, however, or even trimming its ends, results in an overwrite with nulls of "unused" RAM, totally destroying the earthly remains of all deceased files.

To minimize the size of recovered files and to make recovery less tedious, an automatic stop at the end of each dead file will help.  Setting a search for a sequence of three nulls will stop the run at the end of a .BA file: press key "S" for the search prompt, enter three zeroes individually, and then enter "xxx" as a single string.  A sequence of three nulls can occur within a program (in binary numbers), but if a stop occurs before the file end, pressing key "R" again will restart the run without a glitch.  If .DO files are to be saved, enter a search for byte 26, the EOF (end-of-file) marker, but only after all .BA files have been saved, since the string length searched for is different (and remember to copy with BASIC decoding off).

Trim and load the rescued BASIC files only after all files have been recovered.