Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: A3000 and Bridgeboard
Message-ID: <20121@cbmvax.commodore.com>
Date: 26 Mar 91 14:31:15 GMT
References: <1991Mar25.192928.20577@isis.cs.du.edu>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Distribution: usa
Organization: Commodore, West Chester, PA
Lines: 33

In article <1991Mar25.192928.20577@isis.cs.du.edu> echadez@isis.UUCP (Edward Vincent Chadez) writes:

>I have heard rumors that the Bridgeboard from Commodore/Amiga (that works with
>A2x00 series computers) won't work with the A3000.

>1)	Is this true?

No, BridgeBoards work just dandy in the A3000.  Due to the OS's mapping of
autoconfiguration space at present, you have to turn off the data cache to
use a BridgeBoard.  This is because the BridgeBoard is what we call a 
"shared memory coprocessor" device, it contains a processor which acts on a
pool of memory shared with the host CPU.  Since the host can't see when any
changes are made by the BB's processor, it's easy for the host '030 to have
cached something that has externally been altered by the BB processor.  I
don't know about software conflicts under 2.0, but I have used a BridgeBoard
on an A3000 under 1.3 myself.

>2)	Is there a fix in the future??

The BridgeBoard software might be able to address the caching issues.  Also,
system software could attempt to locate any 512K autoconfig device it 
encounters in the I/O autoconfiguration space from $00a00000-$00b7ffff, rather
than sticking it in the memory autoconfiguration space from $00200000-$009fffff
although the large I/O space is only available on the A3000, not previous 
systems, so that's not a general solution.

>--ed


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
      "That's me in the corner, that's me in the spotlight" -R.E.M.