Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!mintaka!yale!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!daver!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga.introduction Subject: Re: Beginer Questions (How Does the amiga use MEMORY?) Message-ID: <1991Jan10.131436.248@zorch.SF-Bay.ORG> Date: 10 Jan 91 13:14:36 GMT References: <6812@crash.cts.com> Organization: SF-Bay Public-Access Unix Lines: 142 This is a typical excellent tutorial of the kind I hope to see frequently in .introduction, so I have taken the liberty of reposting it here, as well as mailing it to Ferry de Jong for possible inclusing in a FAQ posting. Thanks to LaMonte for writing the original. This is the kind of work that keeps the Amiga community strong. /// It's Amiga /// for me: why Kent, the man from xanth. \\\/// settle for \XX/ anything less? -- Convener, COMPLETED comp.sys.amiga grand reorganization. In article <6812@crash.cts.com> lkoop@pnet01.cts.com writes: > yorkw@stable.ecn.purdue.edu (Willis F York) writes: WY> Autoconfig RAM - Memory over the 512K Chip, where other data is WY> stored. No "Program" needs be run for the amiga to see it on boot WY> up. WY> Public RAM- (Got a better name?) NON-AutoConfig, if ya use ADRAM, WY> and other programs to tell the computer the memory is there it's WY> Public. WY> Fast RAM - Same as Autoconfig Ram (RIGHT???) LK> Not really. FAST RAM on the Amiga is any RAM out of the reach of the LK> custom chips. It is known as FAST RAM because code and data may be LK> accessed by the CPU there faster, as it does not have to deal with LK> the bus contention in the CHIP RAM addressing space. Look at it like LK> this: On the CHIP RAM bus, time has to be shared by both the LK> processor and the custom chips. If the custom chips are very active LK> at a given time, the CPU must wait for the bus to be free for it's LK> use. [Some activities of the custom chips can 'cycle steal' from the LK> CPU, causing it to be forced to wait]. Normally, the 68000 on the LK> Amiga only needs the bus every alternate clock cycle in order to run LK> full speed...thus the other cycles not used are taken up by the LK> custom chips. However, when the blitter is in use, or the LK> coprocessor (COPPER), you see some of this cycle stealing. As a LK> result, the CPU can usually run quite close to full speed on the LK> CHIP RAM bus, but there is almost always some activity which slows LK> it down a bit. And of course any heavy graphics use will cause LK> considerable slowing if the CPU is forced to run code out of the LK> CHIP RAM area. Now, with FAST RAM on the system, the CPU can LK> generally run full speed regardless, provided the code/data being LK> accessed is in said FAST RAM, as the custom chips cannot access this LK> memory medium, and are not using it's bus. LK> Now, AutoConfig memory is basically a setup of the OS and the memory LK> board which uses it. When a memory board is considered to be LK> AutoConfig, the system will automatically configure it into the free LK> memory pool upon startup. Basically, AutoConfig allows a board to be LK> assigned to a memory address slot based on what is free on the LK> system at configuration time, without your habing to configure it LK> manually. On startup, the each board along the line (of physical LK> slots in the machine) appears at a specific memory location ($E80000 LK> I belive..but I'm not sure I remember offhand), and presents ID LK> information, whereby it is configured to a suitable address space on LK> the system. This done, the next board in line appears, and the same LK> process repeats...on down the line until no further AutoConfig LK> boards remain. Non-AutoConfig memory is not recognized in this LK> manner, and is designed for a specific memory address location only. LK> Using a program such as AddMem, or AddRAM, you are telling the OS LK> where in the addressing space this board can be found, and adding LK> it's memory to free pool list. WY> 32 bit RAM - Better then the normal 16 bit RAM normally used. (More WY> info??) LK> No such animal. There is no difference in the chips themselves. What LK> IS different is how they are accessed. On a 16 bit bus (16-bit LK> memory), 16 bits of data can be operated on at one time (transferred LK> about, etc...). The 32-bit bus can work with 32-bits of data at a LK> time. Thus if you are running two different buses...on 16-bit and LK> one 32-bit, the 32-bit bus can handle more data at a given interval LK> (assuming appropriate processors for each and equivalent bus LK> speeds). But this is handled at the interface logic and bus LK> level...NOT within the memory chips themselves. A 256x4 chip is just LK> that...not a 32-bit or 16-bit creature. WY> And on a chip is a Number and the last didgets tell the speed in WY> nano-seconds, 120ns is slow, 90-80 is ok, 60ns is fast and big $$$. WY> If ya have slow memory chips then ya get into wait states. LK> Not necessarily. You will only run into having to have wait states LK> if the memory being utilized is slower than the speed at which the LK> processor needs it to come back. For instance, FAST RAM on the A2000 LK> (68000) is usually rated at 120-100ns...this is perfectly fine for LK> zero-wait state operation on that bus. The processor is incapable of LK> "asking for" the data any faster. Putting 80ns memory here would be LK> a waste of money, as the processor will not be able to access it any LK> faster. [The processor/bus is running at a certain speed...it will LK> not speed up for faster memory]. Now, if you were to put 200ns parts LK> on a FAST RAM expansion board, you would have to put some wait LK> states into that. >Does the "ROM" get copied to "RAM" and get run LK> (Bad word) from there? >(I heard this and it "seems" silly) LK> I think you are confusing something done on accelerators here. On LK> normal systems, the ROM code is run straight out of the ROM LK> itself...no "copying to RAM" occurs. On many accelerators, (ones LK> with an MMU in place), it is possible to take an "image" of that LK> ROM, copy it to a faster medium (32-bitr bus area...the LK> accelerator's memory area), then use the MMU to translate address LK> requests to where the ROM image originally was to it's new LK> (hopefully faster) location. THis is done to speed up the system ROM LK> calls. However, normally the ROM is simply accessed directly. WY> What's so important about "Fastmemfirst" ? Does it prevent the using WY> up of "CHIP" befor "Other" memory is full? How does it do it? LK> Memory on the Amiga is prioritized. Now, normally CHIP RAM is given LK> a priority on the system of -10. This is to insure it is not used by LK> programs requesting simply "I want a chunk of memory", and not LK> saying "and it needs to be CHIP". This helps prevent CHIP RAM from LK> being used for things which do not need to be there. Now, LK> FastMemFirst is special. On Amigas with 512K of CHIP RAM, the other LK> 512K which make up the 1 meg std. complement is what is called LK> "SLOW-FAST" RAM. This is because, while the custom chips cannot use LK> it, it is still subject to the bus contention for CHIP RAM I LK> mentioned earlier, as it is in fact on that bus. [When you upgrade LK> to the 1-meg Agnus, this "SLOW-FAST" memory is what becomes the LK> other 512K of CHIP RAM.] FastMemFirst is useful if you have this LK> "SLOW-FAST" memory, and also have true FAST memory on the system. LK> What it does is place your "SLOW-FAST" memory at the same -10 LK> priority as CHIP RAM. Since most true FAST RAM will default to a LK> priority of 0, it places your true FAST RAM ahead of the CHIP and LK> SLOW-FAST memory on the memory lists. This is so programs which do LK> not need to use CHIP RAM (and a program's actual CODE never does for LK> the most part) will be placed in you FAST RAM, and run somewhat LK> faster. SLOW-FAST and CHIP will only be used when either requested LK> specifically by a program, or when your FAST RAM is filled. LK> LaMonte Koop LK> Internet: lkoop@pnet01.cts.com ARPA: crash!pnet01!lkoop@nosc.mil LK> UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!lkoop LK> A scientist is one who finds interest in the kinetic energy of Jell-O LK> moving at ridiculous velocities...an engineer is one who can find a LK> real-life application for such silliness.