Msg: 5969 *Conference*
08-17-95 15:01:04
From: RON WIESEN
To : TRACY ALLEN
Subj: REPLY TO MSG #5964 (UNDELETE -- COLD START RECOVERY)
Haven't figured it yet. Nothing yet has encroached within the F8EAh to F91Fh locale. With a memory power cycle (switch on bottom set OFF, then ON), the OS writes an alternating test pattern throughout RAM. This is more extreme than a cold-start and not relevent to recovery (no way to recover from drastic RAM power loss), but this area only shows the test pattern after a memory power cycle. The pattern is present ahead of F8EAh but the OS encroaches up to F8E9h during "usage". Whatever it's used for, it is either used "during" a memory power cycle but subsequently overlaid with the test pattern, or it's used during some "usage" that as yet I've not happened upon, or it's reserved for an OS extension such as the DVI which I don't own so I can't "discover" it. Like you, I'm interested in knowing "if" and if then "what" this area is used for so that I can know what conflict can arise in using it for "other purposes". Let me clarify what I've done and what I know. First, I'm using a Model 102 so I don't know that the Model 100 corresponds but I suspect it does given that OS items below and above this area do correspond (are the same address and the same fuction) between the 102 and the 100. Secondly, I tried some "obvious" BASIC operations: no encroachment. Rather than go beyond these "obvious" operations, I have put my own test pattern (considerably ahead of F8EAh) up to F91Fh and then ran a bunch of BASIC and M/L programs. Some are commercial (LAPDOS, RAM100), some are complex in that they use several "little know" areas as scratch-pad (PACK.CO which goes so far as to use the current screen area so that when the screen scrools the top 7 lines show junk), and most are not so complex. So far, encroachment ends at F8E9h. An edit of a max length BASIC line (de-token and re-token) doesn't encroach but bits of text and 2-byte addresses do show well below F8E9h as a result of "normal" operations. The last clarification is that I have not made any recovery code, as you stated. But I have gotten confident enough that I've put high usage M/L code at the end of this area: M/L code from F8EAh to F91Fh that is linked with BASIC entry from the main Menu (via Bar Code Reader linkage). This M/L code directs control, after sensing GRPH/CODE/SHIFT key bits and assuring HIMEM is equal or less than where control is going, to one of 3 M/L image blocks previously LOADMed: D (improved variant of TINY.CO, R ), R (RELOCed RAM100.CO), and P (essentially PACK.CO). Various BASIC programs access these block via CALL 44 or CALL 45 (JMP F5F9h ;the BCR link which then is JMP F914h ;entry to M/L code that directs the control according to presence of GRPH/CODE/SHIFT or to BASIC interpreter in no key present. Now my question to you Tracy. RE a byte repeatedly found, at a constant interval through memory, after a cold-start: have you found the interval to ever exceed 255? I have not been that observant in the past: I noted as you told _Comet that a "byte" overwrote RAM locations that were equally spaced (interval), and I only figured the OS got into a loop prior to its cold-start. I wish I had noted whether the interval modulus is 8-bit or 16-bit. At an 8-bit modulus, recovery code can look for it within reasonable time constraint but beyond an 8-bit modulus for the interval it's out of the question for recovery code to bother with it.