Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!rutgers!gatech!bbn!ulowell!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.sys.amiga Subject: Re: fastmemfirst Message-ID: <7578@cbmvax.UUCP> Date: 8 Aug 89 20:57:44 GMT References: <11353@mcdphx.phx.mcd.mot.com> Distribution: na Organization: Commodore Technology, West Chester, PA Lines: 70 in article <11353@mcdphx.phx.mcd.mot.com>, stan@teroach.phx.mcd.mot.com (Stan Fisher) says: > 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? Perhaps. The use of FastMemFirst was never for conservation of Chip RAM. Rather, the 1.2 and 1.3 OS links $00C00000 memory into the memory list prior to any autoconfigured memory. In the A2000 and A500 system implementations, $00C00000 memory is subject to blitter contention, just as if it were Chip memory. So the FastMemFirst program moves that chunk of memory to the end of the memory list, where it will be the last Fast memory used. In all Amiga 32 bit systems, the 32 bit memory is always autoconfigured before any 16 bit memory, so you don't need to worry about reordering anything but the $00C00000 memory, and of course, once all your Chip bus memory is in fact Chip memory, you don't need to use FastMemFirst. > Was it the Super Agnes alone that changed this? or was it the use of SetCPU > 1.5 too? The 1 Meg Agnus eliminated the need for FastMemFirst. SetCPU is smart enough to use 32 bit RAM for it's ROM images if such memory is available and you're using an A2620 or A2630, but it doesn't change the ordering of any normal allocations. > Seems to me irregardless of Super/old Agnes, a program requesting "either > type of RAM" could be given chip, when fast is available. If AllocMem() works as specified, an AllocMem(x,0L) would always return a block of size x in Fast memory before considering any Chip memory. This does imply that it may be traversing the memory list twice, should there only be a block of size x free in the last region of Chip memory (you usually only have one region of Chip memory, but it's possible to have more). > Don't I still want to run fastmemfirst? No. > And does Mergemem really merge 16bit and 32bit memory pools into contiguous > space? Yes. And SetCPU handles that case too, though if you are concerned about having the maximum contiguous chunk of memory available, you should fire up SetCPU FASTROM with the "HEAD" option, so that it'll allocate it's ROM image and maps at the start of 32 bit RAM, rather than at the end. > System = A2000 Rev. 4.x > A2620 > ProRAM w/2Meg > SuperAgnus 1Meg Chip > 1.3 Rom > Also (since I mentioned SetCPU) does Dave Haynie's .profile on cbmvax > do a 'mail > /dev/null' B^) It's more sophisticated than that. When I get mail, I pass it to a filter I wrote (about 50,000 lines of LISP) that's smart enough to know if such mail is Worth My Time To Read. Actually, I've been kind of out of it for at least two weeks; first finishing up a long-term project, then away on vacation for a week. And again, you never know about stuff actually making it through usenet. > Stan Fisher - stan@teroach.phx.mcd.mot.com - asuvax!mcdphx!teroach!stan > Motorola Microcomputer Division, Tempe, Arizona - (602) 438-3228 -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Be careful what you wish for -- you just might get it