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.