Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!pasteur!cory.Berkeley.EDU!johnhlee From: johnhlee@cory.Berkeley.EDU (Vince Lee) Newsgroups: comp.sys.amiga Subject: Re: fastmemfirst Message-ID: <16026@pasteur.Berkeley.EDU> Date: 3 Aug 89 21:29:07 GMT References: <11353@mcdphx.phx.mcd.mot.com> Sender: news@pasteur.Berkeley.EDU Reply-To: johnhlee@cory.Berkeley.EDU.UUCP (Vince Lee) Organization: University of California, Berkeley Lines: 30 In article <11353@mcdphx.phx.mcd.mot.com> stan@teroach.phx.mcd.mot.com (Stan Fisher) writes: > >Recently I believe I read on the net that: > > When using the Super Agnes chip, therefore elimating the C00000 RAM, >it is no longer necessary to run fastmemfirst in the startup-sequence, in >order to conserve Chip RAM. Was I dreaming this? Was it the Super Agnes >alone that changed this? or was it the use of SetCPU 1.5 too? Seems to me >irregardless of Super/old Agnes, a program requesting "either type of RAM" >could be given chip, when fast is available. Don't I still want to run >fastmemfirst? And does Mergemem really merge 16bit and 32bit memory pools >into contiguous space? You seem to be quite confused to what fastmemfirst does. Not surprising, since a recent issue of Amigaworld spouted out the same misunderstanding to all its readers in a help column (who would write AmigaWorld for help anyway?) When a program asks for either type of ram (MEMF_PUBLIC) is automatically receives Fast RAM first if a sufficient block is available regardless of whether or not FastMemFirst is run. What FastMemFirst does is insure that REAL fast RAM (fast memory on the FAST bus) is given preference over fake fast (slow) RAM, which is memory on the CHIP bus which has been configured as fast RAM. If you have a fat agnus, your c00000 ram is now configured as chip RAM, so you have no slow RAM and don't need FastMemFirst. -Vince Lee > Stan Fisher - stan@teroach.phx.mcd.mot.com - asuvax!mcdphx!teroach!stan > Motorola Microcomputer Division, Tempe, Arizona - (602) 438-3228