Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!sco!gorn!ucscc!filbo
From: filbo@gorn.santa-cruz.ca.us (Bela Lubkin)
Newsgroups: comp.sys.amiga
Subject: Re: Game: Heroes of the Lance.
Message-ID: <134.filbo@gorn.santa-cruz.ca.us>
Date: 5 Jan 90 22:11:34 GMT
References: <129894@sun.Eng.Sun.COM>
Organization: R Pentomino
Lines: 34
X-Claimer: I >am< R Pentomino!

In article <129894@sun.Eng.Sun.COM> Chuck McManis writes:
>The problem is will allocating memory. Some people allocate memory with
>AllocMem() or AllocRemember() and use the attribute MEMF_FAST. Why ? I
>suppose because they want to insure they get fast memory, but this has
>a nasty side effect on 512K Amigas and 1Meg Amigas with a Super Agnus.
>Namely, THERE IS NO FAST RAM. Oops, the allocation fails and the game
>goes Ptooey! This of course is the evil twin of those same programmers
>not specifying MEMF_CHIP on the early games when they needed it and
>having people with expanded Amigas yell and scream because the images
>and such looked like garbage! Read and understand :
>
>	Don't ask for MEMF_FAST unless you *must* have it, just ask for
>	0 (essentally MEMF_ANY). If there is fast ram available you will
>	get it, if there isn't you will get chip ram. This is generally
>	the desired behaviour.

Perhaps it's time for another program along the lines of 'FastMemFirst'
and 'NoFastMem', etc.  'SatisfyMEMF_FAST' should cause requests for
MEMF_FAST to be satisfied on machines with no fast RAM, returning chip
RAM instead.  A good design for this would be to A) fail to run
(returning an error) on machines which do have fast RAM; B) trap memory
allocations and clear the MEMF_FAST bit.  I could see C) a flag which
tells SatisfyMEMF_FAST 'I do have fast RAM, but stay in memory and if a
MEMF_FAST request fails, retry it without that flag'.  I don't think
that is safe or desirable default behavior; we're talking about
essentially a single-purpose program: running brain-dead games on 512K
A1000/500's and 1MB Super Agnus A500/2000's).

* Newgroup vote in progress: comp.sys.amiga.hardware; see call for votes in *
* news.announce.newgroups. Unambiguous YES/NO votes to trent@ucscb.ucsc.edu *
--
Bela Lubkin    * *    //  filbo@gorn.santa-cruz.ca.us  CI$: 73047,1112 (slow)
     @       * *     //  belal@sco.com  ..ucbvax!ucscc!{gorn!filbo,sco!belal}
R Pentomino    *   \X/  Filbo @ Pyrzqxgl +408-476-4633 and XBBS +408-476-4945