Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!munnari!acp!sns From: sns@acp.OZ (Stuart Nixon) Newsgroups: comp.sys.amiga.tech Subject: Re: Problems with trying to grab all FAST ram Summary: Thanks - using a custom memory allocation routine works fine Message-ID: <529@acp.OZ> Date: 2 Dec 88 08:56:19 GMT References: <528@acp.OZ> <5351@cbmvax.UUCP> Organization: Australian Computer Products, Perth, Australia Lines: 78 In article <5351@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <528@acp.OZ>, sns@acp.OZ (Stuart Nixon) says: > > Keywords: memory fragmentation, CHIP vs FAST ram on a3000? > > > 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 > [useful comments about a dedicated memory allocation routine deleted] The memory frag problem mainly occurs on the development system, as it not surprisingly frags memory a bit during normal development cycles. My program tries to allocate large chunks (e.g. 200K to 1Mb) first, then does the small allocations. Not withstanding, I've changed to a dedicated memory allocation routine within my program, which grabs *all* fast ram, and then hands that memory down to lower levels. This works just fine. Thanx. > > 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/ > Then you must be doing something wrong. With the simple allocator that's Perhaps I should have explained further. Given an application that requires about 350K of CHIP on a dynamic basic during normal operation, that also wants to grab all of FAST ram, then combining FAST and CHIP ram on the bus causes problems, as by consuming all of FAST ram you have also consumed all of CHIP ram (as they are the same in my hypothetical example of an Amiga 3000 bus). In other words, currently a program can grab all of FAST ram, and then know that there is still about 400K of CHIP ram free (more using ECS chips with 1Mb CHIP ram). I wanted to be sure that I can assume CHIP and FAST will be separate areas of RAM. Anyway, the program now manages CHIP ram internally, so it is a moot point. > 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 In my application, I avoid CHIP ram for buffers as the display is typically running OverScanned, with maximum bitmaps in any given resolution (because this is an Image Processing application). Because of this, it is best to avoid CHIP ram to prevent bogging the processor down during the extensive calculations that can occur on the cache data. For the same reason, the program tries to avoid the Slow-FAST ram on Amiga 2000's and 500's for cache buffers. Some of these calculations require tens of 1,000,000 of calculations, so you don't want the processor running at 50% speed or whatever while processing the cache buffers.... > > sns (Stuart Nixon) > -- > Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" ^^^^^^^^^^^^^^^^^^^^^^ By the way, I would like to express my thanks in general for the time that you and the other CATS/DOGS people spend helping out people on the net. In Australia, we have minimal [read no] support from Australia Commodore-Amiga, and I rely heavily on Usenet as the main line of technical support available. For example, C-A Australia decided not to distribute the Developers Conference notes to Australian developers. This attitude is a pity, as Australia has a very active developers community. sns (Stuart Nixon) sns Stuart Nixon Software, via Australian Computer Products Phone : +61 9 322 6497 Uucp : ...{uunet,mcvax,ukc}!munnari!acp.oz!sns ACSnet: sns@acp.oz