Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!ginosko!brutus.cs.uiuc.edu!psuvax1!rutgers!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: 68030 Accelerators, Info Wanted
Message-ID: <8266@cbmvax.UUCP>
Date: 25 Oct 89 14:18:46 GMT
References: <14108@well.UUCP>
Organization: Commodore Technology, West Chester, PA
Lines: 39

in article <14108@well.UUCP>, theobaby@well.UUCP (Paul Theodoropoulos) says:

> I'm currently using a Ronin 030 on my A1000, at 14Mcycles. The hardware is 
> excellent. The Ronin 030 for the A2000 supports 28Mcycles. I also have an
> 881 overclocked to 20Mcycles. Unlike some 030 boards, the Ronin boards 
> support the data cache (video ram must not be cached, so most boards inhibit
> the Dcache, which kind of limits the value of the board). 

If this new Ronin board is like the Ronin "020 board converted to 030 board",
it's not quite up to par with the other '030 boards (GVP and Commodore) in the
way it handles the data cache.  Ronin's previous board controlled the data
cache in software only, via an MMU table.  This allowed data caching of the
Ronin 32 bit memory only.  All other memory in the system was uncached.  This
has two problems.  First of all, requiring an MMU table of any kind is going
to waste some memory.  Secondly, without any hardware control of data caching,
you have to have multiple tables for different data spaces, so that caching can
be on for instruction space, off for data space.  That at least doubles the 
size of the MMU table required.

Both the Commodore and GVP boards control caching in Hardware.  Since I 
designed the '030 board for Commodore, I can tell exactly what it does -- the
GVP board is apparently doing a similar thing.  The A2630 hardware inhibits
the data cache for chip memory, I/O registers, and the I/O section of 
expansion memory.  It also generates port wide reads for cachable areas of
Amiga memory, so that the data cache can operate on $00C00000, ROM, and
normal expansion memory.  This solves most of the data caching problems 
based on Amiga system problems.  DMA devices need to have a cache dump
instruction incorporated in their device driver to properly maintain cache
consistency in conjunction with the data cache.  And MMU tables can still be
used for finer control of the MMU table to support ROM mapping (of the
system ROM or and device driver ROMs) or unusual device that don't follow
the normal memory-I/O space assignments of the expansion bus (like the bridge
card).  The SetCPU program manages all of these extras, and should work with
any '030 card.

-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough