Msg: 5938 *Conference*

08-10-95 15:48:37

From: RON WIESEN

To : COMET _

Subj: REPLY TO MSG #5937 (UNDELETE -- COLD START RECOVERY)

Regarding "the data won't contain a triple null", I can think of cases where
this is not true.  "The data" is the file type byte (1st byte of 11-byte slot)
and the FILE_ADDRESS (2nd and 3rd bytes of 11-byte slot).  Regardless of how
you arrange this data, triple nulls will occur.  The presence of any file slot
that has not been assigned since the last cold-start is in itself a triple nul.
Even if you segregate the file type bytes and the FILE_ADDRESS byte pairs,
three nul file bytes can occur (3 file slots not used) and one nul FILE_ADDRESS
byte pair (not assigned since last cold-start) will adjoin another null pair or
preceed a pair where the low byte is zero (e.g., FILE_ADDRESS of 9000).
 
You could store the data in byte-interleave fashion with non-nul pad bytes
interleaved to prevent a triple nul, but this consumes twice as much storage
space.  Still, it allows you to keep "the data" inside the "first BASIC" file
if that is your wish.  Of course an end pad is needed to prevent the BASIC line
end (nul) from falling between a data nul byte and the low byte of the
subsequent NEXT_LINE_@ byte pair (e.g., NEXT_LINE_@ of 9000).
 
Recognize that the memory space for the "first BASIC file" is a constant (but
dependent on equipped RAM size) which is attractive for invocation of a
CALLaddr to the recovery M/L code, is also the memory space which is occupied
by the "unnamed BASIC file" after a cold-start.  This leads to two
considerations:
 
1.  The operator MUST NOT enter and line numbered BASIC statement before he
performs recovery (immediate mode statements are OK), lest he obliterate a
portion of this memory space.
 
2.  If the recovery code is completely M/L (masquarading within a BASIC file
enclosure), rather than some initial BASIC code with subsequent M/L de, then
the operator MUST FIRST invoke BASIC from the main Menu and then issue a direct
CALLPEEK(-1343)*256+offset statement (-1343 is high byte of byte pair for
"lowest equipped RAM address" and offset depends on how deep you locate the
data within the "first BASIC file") to start recovery.  The point is that it is
overly burdensome to the operator and complex enough for him to screw it up
while he's unnerved by the recent cold-start.
 
Where the recovery code: is initially BASIC and subsequent M/L, is enclosed
within the first BASIC file, and can have a hidden file name, BASIC file type,
and FILE_ADDRESS recovered before it recovers the remaining files, life is
easier for the operator.  He just types the hidden file name on the Select
line.  If he mistypes it, nothing happens and nothing gets screwed up, and he
can calm down and try again.  Unfortunately, operator steps to "recover the
recovery file" must be just as complex.
 
With the recovery code: completely M/L, and located above HIMEM in a locale
that doesn't depend on the "lowest equippen RAM address", operator steps are a
bit simpler, yet not foolproof.  This is a reason to locate the recovery code
where I indicated in prior MSGs.  You can locate the data in the "first BASIC
file" and the recovery code can refer to FAC1 to obtain the high byte of
"lowest equipped RAM address".
 
Nuff said.  Let me know your thoughts _Comet.  BTW, my Model 102 shows no
further encroachment of the OS into the 72-byte area at FA8E at this time.
I'll keep checking it.