Path: utzoo!attcan!uunet!husc6!rutgers!rochester!pt.cs.cmu.edu!andrew.cmu.edu!mp1u+ From: mp1u+@andrew.cmu.edu (Michael Portuesi) Newsgroups: comp.sys.amiga Subject: Re: problems with using 1.3 FFS with Pacific Peripherals Overdrive Message-ID: Date: 4 Nov 88 18:18:42 GMT References: <41342@linus.UUCP> <5145@cbmvax.UUCP>, <54@sns.UUCP> Organization: Carnegie Mellon Lines: 30 In-Reply-To: <54@sns.UUCP> > *Excerpts from ext.nn.comp.sys.amiga: 2-Nov-88 Re: problems with using 1.3..* > *Lars Soltau@sns.UUCP (714)* > I never use FastMemFirst, for one good reason: > I have 512K (how do you call it) "special" memory at $C00000 and 2M fast memory > at $200000. I use 512 buffers for the HD and start quite a lot of programs at > boot-up, like AmyCron etc. > So after boot-up the $C00000 RAM is completely occupied but I still have nearly > 2M of *CONTIGUOUS* RAM. If I did call FastMemFirst, all those boot-up > processes would eat up my $200000 memory and while I still had about 2M fast > mem, it would be in one 512K and one 1.5M block My situation is the other way around. I have 1 MB of $C00000 RAM (which is non-CHIP non-FAST ram) and 512K of genuine FAST RAM. If I don't use FastMemFirst in my Startup-Sequence, RAD: my FaccII buffers, DMouse, et al. will wind up in the 1 MB of slow/fast mem, reducing the largest available free memory block. If I do use FastMemFirst, they will wind up in the genuine FAST memory, and my application programs will not get use of the FAST memory. DPaint running at high-res four bitplanes slows down quite considerably if it is not running from genuine FAST memory. Is it better to put up with the memory fragmentation so that the FAST memory can be put to better use? --M Michael Portuesi / Information Technology Center / Carnegie Mellon University ARPA: mp1u+@andrew.cmu.edu BITNET: mp1u+%andrew.cmu.edu@cmccvb UUCP: ...harvard!andrew.cmu.edu!mp1u+ "my friends say she's a dumb blonde, but they don't know she dyes her hair"