Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!ousrvr!news From: nix@stekt.oulu.fi (Tero Manninen) Newsgroups: comp.sys.amiga.tech Subject: Re: A Rad: using only 16 bit memory... Message-ID: Date: 20 Sep 90 19:41:40 GMT References: <13089@june.cs.washington.edu> Sender: news@ousrvr.oulu.fi Organization: University of Oulu, Dept. of EE, Finland Lines: 32 In-reply-to: dylan@cs.washington.edu's message of Thu, 20 Sep 90 18:59:34 GM In article <13089@june.cs.washington.edu> dylan@cs.washington.edu (Dylan McNamee) writes: > I am about to bring the 32 bit memory in my system up to 4 megabytes. > This makes me think of creative ways of using the 2 megs of 16 > bit memory on my 2091 card. I'd prefer not to run code from the > 16 bit memory, so the idea of a 16 bit RAD: seems natural. The static > nature of RAD: makes it more handy for this than ram:. Here's a > first cut at a scheme for doing this: > > 1) Allocate all of the 32 bit memory in the system. (Using the > routines in MTest seems the easiest, although slow.) I guess this > would be doable by checking the address returned for range in 32 bit > memory space, and freeing it if it weren't. I don't know how legal this is to do but.. (We are now dealing with private system lists) If you know where this 32 bit memory starts you can lower the priority of that memory block (for a moment). Look the right MemHeader node from exec MemList structure. Then just change the node priority so low that it is below the 16 bit memory (maybe -1 ?). Now make your RAD: and change the 32 bit memory priority back. > Comments? Easier methods? Mistakes (will this indeed work?) I hope this works :-) I have used this method some times to load old buggy programs into chip memory. > dylan > dylan@cs.washington.edu ++Tero