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.