Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!rutgers!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: 68030 options.
Message-ID: <20201@cbmvax.commodore.com>
Date: 29 Mar 91 17:41:05 GMT
References: <4517.27EAC576@voice>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 50

In article <4517.27EAC576@voice> Thomas.Dorn@p3.f42.n310.z2.at (Thomas Dorn) writes:
>From: daveh@cbmvax.commodore.com (Dave Haynie) 

> DH> Assuming the board was designed with proper cache support, you should
> DH> never have any problem turning on both caches and both cache burst
> DH> enables on any 68030 system.  

>If you have a Framebuffer in your Amiga 3000, and this buffer is only
>Zorro II compatible, there are great problems, if you don't switch off 
>the Data-Cache!

My comment above is referring only to the 68030 board itself.  Any 68030 board
and 68030 memory device should support cache and burst, even if burst isn't
actually used by the memory subsystem (like A2630).

There is  a basic problem with cache support and Zorro II.  The Zorro II bus
was designed long before any hard thought was given to cache support of any kind.
We have adopted a convention for Zorro II that splits up the available Zorro II
address space into I/O (uncached) and Memory (cached) regions.  The 8 Meg chunk
starting at $00200000 is Memory, the 512K at $00e80000 and (A3000 only) 1.5 Meg
at $00a00000 are I/O.  Things like FrameBuffers, BridgeCards, and perhaps another 
goody or two break under this model -- they're I/O devices that don't neatly 
fit in the 512K I/O space.  The simple solution to use them is to turn off the
data cache.  Perhaps a better solution would be an A3000-MMU-Setup update of
a program I wrote called CacheCard, which allows the caching of individual
cards to be controlled by the MMU tables (aways present in current A3000s).

In Zorro II, there's an autoconfig bit that says "Prefers the 8M space", a
hint to the OS that the card in question wants to be located in the 8M
space, rather than being placed in I/O space somewhere.  While I don't know
the original need for this bit, the Zorro III convention uses it to allow a
board to state that it's either basically a memory board (cachable) or
basically an I/O board (uncachable).  If that same convention were applicable
to Zorro II, a CacheCard replacement could be automatic; reading the 
expansion database and marking any I/O device as uncachable, rather than
going the CacheCard route, where every uncachable card must be explicitly
listed.

>Greetings from Vienna (cbmvie)

I had a blast in Vienna!  One of these days, I'll have to write up my
expense report for it ....

> UUCP: ...!tuvie!edvvie!voice!42.3!Thomas.Dorn


-- 
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.