Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!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: <9799@cbmvax.commodore.com>
Date: 23 Feb 90 17:21:10 GMT
References: <86.25e424b2@intersil.uucp>
Reply-To: daveh@cbmvax.cbm.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 48

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?

Chip memory absolutely can't be data cached.  You will crash instantly, just
as you suspected; the blitter can modify data that's cached, and thus the
CPU gets confused about what's really in memory.  You also have to disable
the cache for all I/O registers; on a stock A1000, these are from $00A00000
through $00DFFFFF.

That's not the whole picture, though.  Memory that's data cachable has one
more restriction -- such memory must always return full port width on read
cycles.  So basically, on a read you'd ignore the bus sizing and return
either 16 or 32 bits wide.  

I'm not sure how every board does this, but I can certainly tell you how
the A2630 does it (and GVP apparently does something very similar).  The
68030 has one new pin called CIIN*, which is a cycle-by-cycle cache
inhibit.  A PAL on the A2630 drives CIIN* for any data space access to
chip memory or I/O.  During those accesses, it also creates UDS* and LDS*
based on actually requested bus sizing.  For cachable areas, it won't
assert CIIN*, but will drive both UDS* and LDS* for reads, regardless of
the sizing information.  

>2)  Any ideas why I can't add my 32 bit Frances RAM to the system?

With or without the D-cache on?  The 68030 bus timing is the same as
that of the 68020's for asynchronous cycles; if it worked before, it
should work now.  Unless you've added additional noise somehow; a hand
wiring job may be a bit noisy for high speed stuff.  Use lots of bypass
capacitors in varying values near the '030, that could help.  It's
impossible to tell just what failed from here.

However, if FRANCES returns full port data on a read, you should be
able to map cachability using the MMU such that only FRANCES is considered
cachable.  That would allow data caching; this is how the Hurricanes do
it.  It's not as good as real hardware support for caching, but it can
work.

>Fred Hamilton                  Any views, comments, or ideas expressed here


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