grunau_b@husc4.harvard.edu (justin grunau) (12/03/86)
I'm very confused about how the 1040 memory is used up, and I would distinctly appreciate some help figuring out what is going on ... Basically, to cut a very long story short, I have two pieces of software that are supposed to tell me how much free RAM I have at any given time. Neither of them are things I trust particularly, especially since they are never in agreement (one would not expect them to be in agreement, since being different programs they take up different amounts of memory to run: however, they do not disagree in the right way: the smaller program consistently reports less memory than the large one). I decided to try to figure out why I always seemed to have less memory than I thought I would on a megabyte machine (why, for instance, I can never allocate a buffer larger than 32K with Uniterm, and even that is very rare; and other similar problems). So I booted with a disk that did not have any desk accessories on it or anything in an auto folder. The only thing it had on it was the program STSHELL.TOS that was included on one of Compute!s Atari ST disk magazines (issue one). This program is 23447 bytes, and has no resources, being a non-GEM program. The amount of memory it said I had free was 912476 (if I put it in an AUTO folder, it gives me 938106, presumably since the AUTO folder is run prior to GEM's being loaded, suggesting that GEM uses 25K of RAM). This means that the operating system (including GEM), is apparently using 136100 (more than 133K) of RAM. This seemed a little surprising to me. Two specific questions: is this amount of 133K consistent with other people's experiences, or with any technical documentation out there? Also, how do the desk accessories work: I assume they are permanently in memory, but that the change one gets by actually running them is due to their allocating buffers and so forth? How does that work? thanks, JJMG
braner@batcomputer.tn.cornell.edu (braner) (12/03/86)
[] TOS/GEM do allocate various buffers in RAM. To start with, there's the 32K video RAM. Then there's a certain amount at low RAM (I think about 64K, but I forget) (The screen is at the very high end of RAM). 900K sounds just fine. I rarely have problems with lack of RAM. If you cannot allocate a 32K buffer from the ONLY running program there is some other problem: Your RAMdisk is wacky, or some program you ran before has fragmented RAM. For example: some programs install themselves in RAM and stay resident. Suppose you run a CLI which takes up 50K, then invoke such a stay-resident thing from the CLI. It installs ABOVE the CLI, and stays there even after you quit from the CLI to the desktop! Next time you invoke a big program, it has no choice but to run from above the resident utility! Moral: install all your resident utilities from the auto folder! - Moshe Braner
atwell@utah-cs.UUCP (Bart L. Atwell) (12/03/86)
I've noticed that in using the Intersect Ramdisk posted here, memory seems to decrease as the time since you booted increases. More specifically, if you allocate the ramdisk, do some work, deallocate the ramdisk (possible with Intersect), do some more work, then try to allocate a new ramdisk, you don't have as much memory to allocate. Are the "work" tasks somehow not deallocating memory when they terminate or is the free memory part of the ramdisk not working? Also, how is the amount of free memory determined? Does TOS use a TPA (Transient Program Area from CP/M jargon) or is there some other method of allocating memory? Bart atwell@utah-cs.arpa