Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!rutgers!bpa!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: Cramming an 030 into an 020 hole
Message-ID: <9822@cbmvax.commodore.com>
Date: 26 Feb 90 18:18:29 GMT
References: <86.25e424b2@intersil.uucp> <9813@cbmvax.commodore.com>
Reply-To: daveh@cbmvax.cbm.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 25

In article <9813@cbmvax.commodore.com> valentin@cbmvax.cbm.commodore.com (Valentin Pepelea) writes:
>In article <86.25e424b2@intersil.uucp> hamilton@intersil.uucp (Fred Hamilton) writes:

>>1)  Should I be able to turn on the data cache and have everything work OK,
>>    or should it always be off when accessing chip ram because of DMA going
>>    on?  Is that why it crashed?  How do other 030 boards deal with it?

>Yes, that's what the problem was. The A2630 board disables the cache
>automatically through hardware (MMUDIS pin) when chip and I/O memory is
>accessed.

That's actually the CIIN* pin, which is the input used to disable '030
caching on a cycle-by-cycle basis.  Right idea, though.  The MMUDIS* pin
is actually for use by emulators to disable the MMU when necessary.

The A2630 enables the I-Cache but not the D-Cache for Chip memory or 
autoconfig space $00E80000-$00EFFFFF; it enables both caches for 
$00C00000-$00CFFFFF and $00200000-$009FFFFF.

>Valentin  :-)

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