Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!mailrus!ulowell!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Problems with trying to grab all FAST ram
Message-ID: <5351@cbmvax.UUCP>
Date: 29 Nov 88 22:45:31 GMT
References: <528@acp.OZ>
Organization: Commodore Technology, West Chester, PA
Lines: 47

in article <528@acp.OZ>, sns@acp.OZ (Stuart Nixon) says:
> Keywords: memory fragmentation, CHIP vs FAST ram on a3000?

> There are two problems with this :

> 1. Memory Fragmentation. As FAST ram may be fragmented, the allocation may
>    fail, even though there is actually ram present. 

Who's fragging the memory.  Certainly if there are other programs running
who intermix small allocations with your big allocations, this can happen.
However, if YOU are the one mixing in small allocations with the big ones,
it's a real easy fix.  Write a friendly allocation function to handle all
of the details.  This function would allocate system memory in medium 
sized chunks, unless otherwise instructed.  When you ask for a small chunk
of memory, your allocator would take that from a moderate memory chunk.
When you ask for a large chunk, your allocator would get that from the
system instead.  If your moderate chunk size is chosen correctly, none
of your small allocations will cause any frags.  The OS provides the 
Allocate() function for allocations from a memory chunk that you own.

> 2. FAST ram vs CHIP ram. As you can see, I only use FAST ram for the cache
>    buffers. All of CHIP ram is taken up by other operations, such as high-res/
>    high bitplane screens with superbitmaps. The problem is that the program
>    is assuming that CHIP ram is always distinct from FAST ram. Is this a
>    valid assumption? In other words, does [or will :-)] the mythical Amiga
>    3000 combine CHIP and FAST ram? 

If they were combined (seems pretty unlikely), you shouldn't have any problems.
The MEMF_CHIP and MEMF_FAST bits in the attribute word aren't mutually
exclusive, so at least in theory, you could have memory that's both CHIP
and FAST using the current OS definitions.  Don't wait up for it...

>    If so, then I would like to somehow consider this fact during cache 
>    allocation, as the current method will break on such a system.

Then you must be doing something wrong.  With the simple allocator that's
available in the OS now, you have no choice but to ask for MEMF_CHIP when
you need CHIP memory for graphics, and MEMF_FAST (and perhaps 0 if that
fails) for that buffering.  You have to assume that the system memory lists
have been set up to give you the best MEMF_FAST for your particular
application, but that's about all you really can do.

> sns	(Stuart Nixon)
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession