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