Path: utzoo!mnetor!uunet!seismo!lll-tis!ati.tis.llnl.gov!sierra From: sierra@ati.tis.llnl.gov (Frankie Sierra) Newsgroups: comp.sys.mac.programmer Subject: StartUpScreens Eats Memory!? Message-ID: <22188@tis.llnl.gov> Date: 10 May 88 05:36:58 GMT Sender: news@tis.llnl.gov Reply-To: sierra@ati.tis.llnl.gov (Frankie Sierra) Organization: Lawrence Livermore National Laboratory, Livermore CA Lines: 28 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