Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site amiga.amiga.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!nsc!pyramid!amiga!bobp
From: bobp@amiga.UUCP (Robert S. Pariseau)
Newsgroups: net.micro.amiga
Subject: Re: Questions about Rumors
Message-ID: <272@amiga.amiga.UUCP>
Date: Sun, 17-Nov-85 14:55:48 EST
Article-I.D.: amiga.272
Posted: Sun Nov 17 14:55:48 1985
Date-Received: Mon, 18-Nov-85 08:12:37 EST
References: <1199@pucc-i>
Reply-To: bobp@snake.UUCP (Robert S. Pariseau)
Organization: Commodore-Amiga Inc., 983 University Ave #D, Los Gatos CA 95030
Lines: 64
Keywords: amiga, memory, updates

The speed of RAM placed on the expansion bus depends, to some extent,
upon the quality of it's implementation.  The Amiga architecture ALLOWS
expansion bus memory (that is memory over the first 512K) to run at
full bus speeds.  I don't know of anyone implementing expansion bus
memory who expects to provide slower memory -- but you never know.

The first 512K of memory, known as Chip memory to the AllocMem()
function, is the only memory the custom chips can get to.  It is
possible to configure your Amiga such that the bandwidth out of
chip memory is largely consumed for video display.  In this high
data rate mode of operation, the 68000 yields to the higher priority
needs of the system DMA channels such as the video.  This is called
memory "contention".  [For newcomers:  There is NO contention in
the 320x200, 16 color mode normally used for games, or in the
640x200, 4 color mode normally used for Workbench and text functions.]

There can NEVER be contention in the Writeable Control Store (where the
system firmware is kept) or in the expansion bus memory [ignoring, of
course, any contention BUILT-IN to stuff on the expansion bus].  For
this reason, the AllocMem() function identifies expansion bus memory
as Fast memory.  Note that Fast memory can NEVER be faster than Chip
memory in the no-contention modes of operation.

As a programmer, you need to be sure that data structures you make
which are directly referenced by the custom chips are allocated in
Chip memory.  This means, don't statically allocate them, or place them
on the stack, since that may place them in Fast memory depending upon
what else is in the machine --> ergo, your programs stop working
when people add expansion bus memory.

For V1.0, you must dynamically allocate your Chip structures in Chip
memory -- moving data from your static structures as necessary.

For V1.1, the system loader recognizes flags in the program image
which say that certain portions of the program MUST be loaded into
Chip or Fast memory.  If a preference is not specified, then Fast
memory is generally used first -- maximizing system resources.  The
program flags can be set using the new Atom utility which is applied
to your object binary files BEFORE you link them with Alink.  [This
means you can set the flags on routines which are then placed in
libraries so that anyone can use your routines without having to
know special rules about where they can go.]  Note that you STILL
can not safely allocte Chip structures on the stack.

-----------------

Commodore can NOT recommend that you replace the 68000 in your
Amiga with any other processor.  This warning is brought to you
by our good friends at the FCC who insist that we test any hardware
configuration against Class B restrictions before we recommend it
to anyone.

That aside, we HAVE heard from folks who (in STRICT VIOLATION of their
warranty) have opened up their Amigas and replaced the processor.
Their reports say that the system software works fine unless you
have a buggy program that generates one of the 68000 exceptions that
changed for the 68010.  The trap catcher and the stuff that puts up
alerts and gets you into ROMWack is not prepared for the new-fangled
stack frame put out by a 68000.

Note that there is a routine called GetCC() in EXEC which gets you
your processor condition code in a manner that is compatable across
the 68000 family.  This is the only normal-operation incompatability
that needs to be addressed.