Conference hydra::amiga_v1

Re: .0

>If I get an accelerator board with say 2mb of 32bit ram what should I do
>with the 16 bit ram in the scsi board??

Ignore that you ever heard that there was a difference between 16 bit RAM
and 32 bit RAM.  Leave your SCSI/Memory board plugged in and just plug in
your new accelerator board.  The electronics in the system will take care
of everything for you.

In case you want to know:

The "16 bit" and "32 bit" is not describing the memory itself as much as
the bus that the memory lives on.

Lets say you had eight memory chips that were 256k by four bits.  Memory
chips of that type are designed that they give you four bits in parallel
whenever you ask to read from the chip.  The chip will store 256K of
such four bit "nibbles."

You you wanted to build a memory board out of such chips, then by wiring
the four such chips in parallel, you could have them give you 16 bits
in parallel.  Given eight chips, you would arrange them in two banks
of four chips.  Upon command, either bank could deliver a 16 word.

Alternatively, you might wire all eight chips in parallel.  You would
then one bank of memory that would give you 32 bits in parallel.

Notice that in either configuration, you have two megabytes of memory.
However, you can read it in 512K clumps of 16 bits or 256K clumps
of 32 bits depending on how you wired it together.

Memory, of course, is only really useful when attached to something that
is going to read or write it.  Here's where the CPU comes in.

When Motorola designed the 68000, they wanted a computer architecture
that they could use for a while, and they wanted to be able to address
lots of memory.  The cleanest way to achieve this was to have a 32
bit memory address and make the word size of the machine 32 bits wide.
However, that can be expensive: it would be much easier to build and
interface to 16 bit wide machine.  So, Motorola got tricky.  The 68000
acts as if it deals with 32 bit longwords.  However, the 68000's interface
to the outside world is 16 bit words.  Every time the 68000 needs 32 bits of
information from memory, it will automatically read two 16 bit clumps
of memory, and act as if they were pasted together.

When Motorola designed the 68020, they wanted the machine to be faster
than the 68000.  One way to make the machine faster is to make it do
more in parallel.  They made the 68020 a true 32 bit machine:  when it
operates on a 32 bit longword, it treats it as a single 32 bit item,
not as two clumps of 16 bits.  Memory that attaches to a 68020 delivers
32 bits in parallel to it in one chunk.

The typical 68020 board for the Amiga speeds it up by as much as four
times under ideal conditions, yet the board only runs at twice the
normal clock rate.  The additional factor of to comes from the fact
that 32 bits are processed in parallel instead of 16 bits.  The
68020 is working twice as fast doing twice as much at a time.

How this applies to accelerator boards:

The memory on the accelerator boards is arranged in 32 bit clumps.  This
is ideal for a 68020.

The memory on a normal Amiga expansion card is arranged in 16 bit clumps.
This is ideal for a 68000.

If the accelerator board references the 16 bit memory, it will automatically
ask for a first 16 bit clump, then a second 16 bit clump, and paste
them together so that they can be processed normally.

The net effect is that you don't have to care that you have two different
arrangements of memory.  The electronics was built to handle the situation.

There are probably two things of interest in this situation:

1.  The memory on the accelerator board probably runs four times faster
    than your other memory.  So, expect your system to slow down after
    you allocate all the memory on the accelerator board.

2.  The autoconfig protocol doesn't automatically merge memory on two
    different boards into one big chunk of unallocated memory.  This means
    that if you have 2 Meg on an accelerator board and 2 Meg on a
    expansion board, that you can not allocate a 3 Meg data structure,
    because as far as the Exec is concerned there isn't any one memory
    region big enough to get 3 Meg from.  If you run the Commodore
    program MergeMem in your start sequence, it will make the memory
    regions on the two different cards into one big region as far as
    the software is concerned.  This is a good idea.  I believe that
    the standard startup-sequence on the Workbench disk already runs
    this program.

>If the accelerator board references the 16 bit memory, it will automatically
>ask for a first 16 bit clump, then a second 16 bit clump, and paste
>them together so that they can be processed normally.

    This is functionally true, but not exactly technically correct.  When
    the cpu puts out an address, the addressed device must put out its port
    size (8, 16, or 32 bits); the cpu then knows what data bits to latch
    and how to steer the data through the internal data multiplexors.  The
    rules include which data lines different port sizes must appear on, for
    example, on the '030, eight bit ports must appear on data lines 24 -
    31, and the addressed device would assert /DSACK1 high and /DSACK0 low
    to indicate port size and complete the cycle.
    
    So, the accelerator card probably does this by mapping (in additional
    hardware) the A2000 bus as a 16 bit port and the acc. cards ram as a 32
    bit port.  The software never knows the difference.
    
    John

    GREAT. bit more - does the electronics automatically map the additional
    16 bit ram to space that the 32 bit doesn't occupy. Or do I have to
    shift the ram chips in the memory board?? I suspect that the ami is
    smart enuf to automatically add memory in unique addresses based on
    slot usage as well - ie further out the higher the address bank would
    probably become
    
    so the 0-2mb mapping in my scsi/ram bd would just be added to the end
    of whatever memory had been configured from earlier slots. 
    
    probably answered my own question :-}.
    
    regards
    kevin.

    Hoo boy... First, understand that the Amiga's "autoconfig" feature will
    set up memory addresses properly for your boards.  I think there are no
    longer any companies making non-autoconfig memory boards for use in a
    stock Amiga.  The only exception to this is that some accelerator board
    _sets_ put 32 bit memory on a separate card with ribbon cable between
    cards, and typically this memory sits outside the normal autoconfig
    address range.  But if you don't have one of these oddball boards, then
    you will never have to set an address jumper, ever.
    
    Now, there's no harm in mixing 16- and 32-bit memory in one machine. 
    However, for maximum performance in all circumstances you would be
    better off to put all your RAM on the 32-bit card.  This way, all
    "fast" RAM (i.e. not graphics memory) will be accessed at maximum
    speed.  However, be aware that the two boards may require different
    kinds of memory chips, so to upgrade everything to 32-bit RAM you might
    have to sell one flavor of chips and buy another.
    
    So to summarize, your present setup is fine.  You may see the same
    program running sometimes faster, sometimes slower when your memory is
    pretty full.  You can optimize performance by putting all your RAM
    chips on the widest data path, i.e. on the accelerator card.
    
    Wes

    Re: all
    
    You can even _choose_ where you want specific programs to go, given
    that you have a program like mempri (should be in one of the download
    locations, if not so, nag me).
    Here's what I do:
    I have an A2620 with 4MB of 32bit RAM and an ancient A2052 2MB 16bit
    RAM expansion.
    I use mempri to give the A2052 a higher priority than the RAM on the
    A2620 and start such things as BlitzDisk (with 2000 buffers) and the
    WShell filename completer. Since VD0: always eats up memory from the
    "top" of the memory pool, it also uses the A2052 RAM. So after startup
    I still have more than 3MB (FastROM takes it's toll) of 32bit memory at
    my disposal.
    
    Cheers,
    
    <CB>

    I just had a look through tape and wjg - no mempri. So unless it's
    buried in a fish disk somewhere (anyone know which one if so) could you
    please UL it CB.
    
    regards
    kevin

    Re: .6
    
    I'll upload it on Tuesday next week, the next day I'm going to be in
    the office... ;-)
    
    Cheers,
    
    <CB>
    

    
    
    MEMPRI.LZH is on  TAPE::USER2:[UPLOAD] .
    
    Have fun,
    
    <CB>