Msg: 5932 *Conference*
08-09-95 15:14:55
From: RON WIESEN
To : COMET _
Subj: REPLY TO MSG #5926 (UNDELETE -- COLD START RECOVERY)
Looks like my prior message got truncated in the area of Idea #9 because "BUFFER FULL". I've split the message in two; and this is part 2 of 2. ---------- I've experimented with the 95-byte area at F8C1, which I reported in my last MSG (truncated). To date I've found that the first 23 bytes of this area are modified by the OS. That then leaves us with a 72-byte area at F8D8. I've put a test pattern within this area in my Model 102 and I'll check it every few days to see if this area shows further use by the OS. Below is an update of idea #9 from my last MSG; note that the region for recover/save code is now reduced to a 30-byte block. 9. Idea -- This bears on "piece of RAM... to store this" in MSG 6013. For the 10 byte minimum storage, there are several choices: A. within 18-byte area at FA8E B. within 72-byte area at F8D8 C. 10-byte end of 64-byte RS-232 buffer (ends at FF85H) D. 10-byte end of 64-byte Typeahead buffer (ends at FFEAH) Choice A seems best to me. I don't know what the OS uses this area for but it appears to survive a cold-start. Choice B also appears to survive a cold-start. Given its large size, I suspect it may conflict with some operation such as file buffering. Choices C and D can conflict with operator usage. I'm not sure they survive a cold-start, so they may not be viable. For the 57 byte storage requirement, choice B is the only choice. If choice A and choice B are both viable, there is a tidy arrangement that dovetails with "M/L to copy the directory... the entry invisible" in MSG 6013. Assuming one particular file directory slot (e.g., last one) is either ignored or dedicated to some special purpose, then only 18 RAM file slots need be saved. Choice A is where the file type info (1st byte of 11-byte slot) is saved. No packing is used, so bits 3 to 0 of each byte (file type) may be transient flags the OS uses during shuffles and thus may prove helpful. Choice B is where the File_Address (2nd and 3rd bytes) is saved followed by a copy of 3 critical RAM address pointers (low/high byte pairs) from the OS, plus a 30-byte block of recover/save code. Although file name and name extension info is not saved, names A through R can be arbitrarily assigned to the 18 slots at recovery and the name extensions .BA, .DO, and .CO can be presumed per the file type. See detail below. 18-byte cell (18 by 1) FA8E file type, RAM file slot #1 .. .. FA9F file type, RAM file slot #18. 72-byte cell (18 by 2, 3 by 2, plus 30) F8D8/F8D9 File_Address, RAM file slot #1 .. .. F8FA/F8FB File_Address, RAM file slot #18. F8FC/F8FD address to first BASIC file F8FE/F8FF address to first ASCII file F900/F901 address to first M/L file F902 to F91F recover/save code. Recovery is invoked from BASIC by CALL-1813. Code at F902 (-1790 or 63746) recovers files. First it assigns file names A through R to the 18 files slots. Based on file type, it assigns the name extensions .BA, .DO, and .CO to the slots. The addresses to the first BASIC, ASCII and M/L files assist in the progressive file recovery that I outlined earlier. For example, after recovery file names on the main Menu might look like this. BASIC TEXT TELCOM ADDRSS SCHEDL G.DO K.DO A.DO C.DO L.DO R.DO D.BA I.BA B.BA F.BA N.CO E.CO O.CO -.- -.- -.- -.- -.- -.- The operator can view the ASCII files and the BASIC files and rename them accordingly. With HIMEM equal to MAXRAM (cold-start default), the operator can safely (.CO images won't load) LOADM each M/L file to see the TOP:, END:, and EXE: values. These values are his only clue for renaming the M/L files.