sierra@ati.tis.llnl.gov (Frankie Sierra) (05/10/88)
When setting up large startup screen files on a Mac II (with res PICT ID = 0), memory under FINDER gets swallowed on the System Heap. Normally StartUpScreens (SUS) of less than 50K does not represent any problem, but larger 256-gray-or-color pictures tend to eats memory on the system heap, and you get stuck with considerable less memory in your machine (I had exprienced 300+K of memory lost with some SUSs). Checking Inside Mac. Vol V (The Start Manager) there is a description of the order of things that happens when the machine is booted up. Among others: the SUS is displayed; then the ROM patches are applied; and later on the system heap is determined from files on the System Folder. This could mean, that is there is a bug in ROM, it may take a full physical ROM change, or a very clever system kludge, to solve it. On the other hand, if the problem is on the determination of System Heap, and somehow, the SUS is getting accounted for, then some ROM patch should suffice. BTW: I found out that SUS with res fork and a data fork (for Mac+ SE compatibility, check PixelPaint SUSs), tend to crash Mac IIs with one Meg of Memory. Leaving out the Data Fork solve the problem. Under MultiFinder the Ball Play is quite different, and it is argued that MultiFinder reclaims any memory left on the system heap. I am not sure of this, or if MultiFinder can effectively solve the problem that I had experience under FINDER. Frankie Sierra sierra@ati.tis.llnl.gov
dan@Apple.COM (Dan Allen) (05/11/88)
Most startup screen INITs that I have seen do NOT allocate their memory on the system heap, but rather put the startup PICT in high memory and adjust the low memory global BufPtr accordingly. Apple's RAM caching scheme and MacsBug the Debugger both also use this method. Dan Allen Software Explorer Apple Computer
sierra@ati.tis.llnl.gov (Frankie Sierra) (05/11/88)
In article <9488@apple.Apple.Com> dan@apple.UUCP (Dan Allen) writes: >Most startup screen INITs that I have seen do NOT allocate their memory >on the system heap, but rather put the startup PICT in high memory and >adjust the low memory global BufPtr accordingly. Apple's RAM caching >scheme and MacsBug the Debugger both also use this method. > >Dan Allen >Software Explorer >Apple Computer StartUpScreen INITs are another game here, and yes, they do tend to gobble memory too. What I was referring to, in my original posting, was about standard vanilla files with just a resource fork with a PICT resource of ID = 0. No init, code, or whatever other resources. In other words, this is not the file's problem, but somehow a system problem, that is allocating system heap space for something that doesn't require it. Frankie Sierra Frankie Sierra sierra@ati.tis.llnl.gov
clay@claris.UUCP (Clay Maeckel) (05/11/88)
In article <9488@apple.Apple.Com> dan@apple.UUCP (Dan Allen) writes: >Most startup screen INITs that I have seen do NOT allocate their memory >on the system heap, but rather put the startup PICT in high memory and >adjust the low memory global BufPtr accordingly. Apple's RAM caching >scheme and MacsBug the Debugger both also use this method. What Dan states is true, but is not the problem the Frankie Sierra and I are having with the StartUpScreen. But while we are on the topic of BufPtr, how much longer is it going to be around? There are hints in either Inside Mac or the Tech Notes that is may be going away soon. For my init, DeskPict, I use the BufPtr trick to store the color bitmap up high in memory but for version 2.0 I will try putting into the system heap. After that change the free space in the system heap would be eaten up by the desktop picture. Back to the StartUpScreen. MultiFinder, for me, effectively reclaims the space used up by the SUS because of the 150+ K of stuff that gets loading into it with everything else that is running in my system. Under the UniFinder I lose around 150 to 180 K of memory in the system heap if I have SUS. I have not had the time to track down what happens in those early stages of booting but the memory used by the SUS code is not being reclaimed after its use. Can anyone at Apple (or elsewhere) shed any light on this problem? Some type of patch or fancy init should be able to reclaim the space but I get scared of the thought of moving zone pointers around :-). -- Clay Maeckel * UUCP: {ames,apple,portal,sun,voder}!claris!clay (I know nothing!) * Arpanet: claris!clay@ames.arc.nasa.gov Claris Corporation * AppleLink: Maeckel1 * CompuServe: 73057,255
alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg) (05/11/88)
I heard about this problem as far back as last July. When a PICT file with PICT id=0 is loaded (this does not occur for MacPaint startupscreens), the memory on the heap is not recovered, and you lose big time. The trick here is in determining which part of the Mac system does the loading of the StartupScreen. Since the boot blocks on disks have the filename to load in them, we must assume that the startupscreen loader is contained in the boot blocks of the startup drive. Since Apple apparently already knows about this bug (it was a compuserve topic a while back...) they will probably (hopefully???) have it fixed in System 6.0. It probably isn't very difficult to fix, but low on the prority list, as StartUpScreens are a frill. I am not totally sure of the fix as I have not looked at the loader code. ------------------------------------------------------------------------------- - Alexander M. Rosenberg - INTERNET: alibaba@ucscb.ucsc.edu - Yoyodyne - - Crown College, UCSC - UUCP:...!ucbvax!ucscc!ucscb!alibaba- Propulsion - - Santa Cruz, CA 95064 - BITNET:alibaba%ucscb@ucscc.BITNET - Systems - - (408) 426-8869 - Disclaimer: Nobody is my employer - :-) - - - so nobody cares what I say. - -
darin@Apple.COM (Darin Adler) (05/12/88)
In article <3243@saturn.ucsc.edu> alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg) writes: > ... Since the boot blocks on disks have the filename to > load in them, we must assume that the startupscreen loader is contained in > the boot blocks of the startup drive. ... This is not true. The file name from the boot blocks is used, but the boot code in the Mac does not execute the boot code in the boot blocks UNLESS the version field is new enough. The boot code that is currently used (including the part that loads/displays the picture) is in the Mac II ROMs. Note that the bug is doesn't have to do with reclaiming space in the system heap. The problem is that the system heap grows to a size big enough to contain the picture, and it can only grow, not shrink. Thus, the space is reused by any other code that uses the system heap, but will never be used as part of the application heap. This is all without MultiFinder...I don't know exactly what the differences are with MultiFinder, although I seem to recall that it does have a mechanism for shrinking (as well as growing) the system heap on the fly. -- Darin Adler AppleLink:Adler4 UUCP: {sun,voder,nsc,mtxinu,dual}!apple!darin CSNET: darin@Apple.com
alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg) (05/12/88)
In article <9543@apple.Apple.Com> darin@apple.UUCP (Darin Adler) writes: >In article <3243@saturn.ucsc.edu> alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg) writes: >> ... Since the boot blocks on disks have the filename to >> load in them, we must assume that the startupscreen loader is contained in >> the boot blocks of the startup drive. ... > >This is not true. The file name from the boot blocks is used, but the boot code >in the Mac does not execute the boot code in the boot blocks UNLESS the version >field is new enough. The boot code that is currently used (including the part >that loads/displays the picture) is in the Mac II ROMs. > >Note that the bug is doesn't have to do with reclaiming space in the system >heap. The problem is that the system heap grows to a size big enough to contain >the picture, and it can only grow, not shrink. Thus, the space is reused by any >other code that uses the system heap, but will never be used as part of the >application heap. This is all without MultiFinder...I don't know exactly what >the differences are with MultiFinder, although I seem to recall that it does >have a mechanism for shrinking (as well as growing) the system heap on the fly. >-- >Darin Adler AppleLink:Adler4 >UUCP: {sun,voder,nsc,mtxinu,dual}!apple!darin CSNET: darin@Apple.com Ok, so if a newer set of boot blocks are produced, will they take over and load the picture? If this is true, then the bug can be fixed in the next release right? As for the actual nature of the bug, doesn't this all happen before any INITs are loaded? If that is so, then it can be loaded, displayed, and then the heap can be compacted. I don't see why this problem ever occured. It is clear that this is a bug. Leaving the heap with an arbitrarily large size forces the stack to be smaller. Bomb ID 28's must be more common. We all know that many of our favorite applications do not manage their heap and stack spaces properly. The system heap is supposted to be small. If it is stuck at a larger than normal (i.e. after a SUS loadup) size, then the application heap and the stack must be smaller. This is not good. Programs like PixelPaint chew up memory, and memory is getting more expensive now. These programs do not tolerate a large system heap very well, and they are important to Apple's market penetration. Is somebody at Apple working on a fix for this? Is this fixed in the B ROMs (Are they called B or what?)? Inqiring minds wanna know. Can a quick fix INIT solve this problem by recognizing that a certain quantity of the sys heap was used by a SUS, and somehow order a compaction. (What is legit as for compaction on the sys heap? Is there any _safe_ way?) ------------------------------------------------------------------------------- - Alexander M. Rosenberg - INTERNET: alibaba@ucscb.ucsc.edu - Yoyodyne - - Crown College, UCSC - UUCP:...!ucbvax!ucscc!ucscb!alibaba- Propulsion - - Santa Cruz, CA 95064 - BITNET:alibaba%ucscb@ucscc.BITNET - Systems - - (408) 426-8869 - Disclaimer: Nobody is my employer - :-) - - - so nobody cares what I say. - -
sierra@ati.tis.llnl.gov (Frankie Sierra) (05/14/88)
If you read the Start Manager on Inside Mac Vol. V, they state among
other things, that the order of events follows as:
- the video card is searched, and initialized.
.
.
- resource manager initialized.
- StartUpScreen looked for, if found display it.
- Apply ROM Patches.
.
.
- Determine System Heap from info on System Folder.
(SUS accounted for, here?).
.
.
- Load INITs.
.
.
This looks to me as if no ROM patches will solve the bug, and changing
the boot blocks won't either (I guess). Looks like a very deep ROM
bug (unexpurgable by software). Although, a kludge after the facts
may solve the problem (a CLEVER kludge).
Frankie Sierra
sierra@ati.tis.llnl.gov