Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: 68030 in a LUCAS board, and 2.0 in FRANCES
Message-ID: <14194@cbmvax.commodore.com>
Date: 4 Sep 90 20:46:07 GMT
References: <144.26d7d916@intersil.uucp>
Reply-To: daveh@cbmvax (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 45

In article <144.26d7d916@intersil.uucp> hamilton@intersil.uucp writes:

>I've adapted my LUCAS board to use a 68030, and it's working fine except
>that it's performing just like the old 68020.  

>But the system crashes everytime I do a "SetCPU cache".  My first thought 
>was that perhaps SETCPU turns on data cache write allocation when it turns
>on the data cache.  

SetCPU, as of V1.5 at least (latest is V1.6), always turns on Write Allocation.
That's 100% necessary, because User and Supervisor data spaces are shared.

>This would permit the possibility that the 030 was writing to a DMAable 
>location and caching the data (*CIIN is ignored during writes).  

Actually, the chances of problems with that "feature" (we call it a bug) is
reasonably minimal, and in practice mainly a problem for systems in which
there exist 32 bit wide I/O ports.  DMA devices, to be safe for use with
cache, clear the cache after they do transfers (the A2091 and A3000 hard
disk drivers, for example, do this).  But I/O ports aren't so easily taken
care of.  The cache is only updated on a longword write to a longword port,
though, so you're pretty safe on an A1000.  In any case, SetCPU V1.6 will
set up a memory map with the normal Chip and I/O regions uncachable if you
use FASTROM, if you're worried.  But that's definitely not enough of a problem
to cause instant crashes.

>So it appears one of two things must be happening:  The FRANCES data buffers
>are being enabled during reads of non-FRANCES data (yikes!), or the FRANCES
>memory is not cacheable, but I have no idea why this would be.  Nothing is
>reading or writing to FRANCES except the 030.

The problem is very likely that your FRANCES memory isn't cachable.  In order
to be considered data cachable by the '030, your memory board must always 
read its full port width, regardless of SIZ1-0 or A1-0.  Simply put, all four
bytes of your 32 bit memory must be valid for reads, or it won't be cachable.
Most 68020 memory designs use the same byte enable logic for reads as writes,
and therein lies the problem.

>Fred Hamilton                  Any views, comments, or ideas expressed here
>Harris Semiconductor           are entirely my own.  Even good ones.

-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
      Get that coffee outta my face, put a Margarita in its place!