xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/10/91)
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
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> \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.kdarling@hobbes.ncsu.edu (Kevin Darling) (01/11/91)
LK> 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. And displaying hires gfx. A while back I got curious, because the Amiga hardware manual seems to infer that the higher res modes (over four bitplanes in lores 320 or two bitplanes in hires 640) could block out the cpu/blitter entirely. So I did some calculations and came up with these figures, which weren't near as bad as I had thought: XY Res Colors Lockout amt ------- ------ ----------- 320x200 32 14% 360x480 32 18% ( % of cycles that 320x200 Ham 27% the cpu and blitter 360x480 Ham 36% are locked out of 640x200 8 27% video RAM access) 640x200 16 54% 720x480 8 36% 720x480 16 73% 736x480 16 75% I believe them to be correct... but add salt if you wish. ;-) kevin <kdarling@catt.ncsu.edu> PS: belated thanks to Kent for the new groups!