Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdcad!sun!pitstop!sundc!seismo!uunet!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: Still More 68020 Questions
Message-ID: <3197@cbmvax.UUCP>
Date: 25 Jan 88 18:41:50 GMT
References: <4795@videovax.Tek.COM>
Organization: Commodore Technology, West Chester, PA
Lines: 26

in article <4795@videovax.Tek.COM>, stever@videovax.Tek.COM (Steven E. Rice, P.E.) says:

> Fortunately, no!  There is an input, Cache Inhibit In (CIIN*), which
> inhibits cacheing of data and/or instructions on a cycle-by-cycle basis.
> By asserting CIIN* on each access to CHIP RAM, you will prevent the
> cacheing of data (and instructions) that come from the area accessible
> to the blitter, et. al.

Of course, you also want CINN* asserted for any access to any I/O devices.

> As long as you keep your instructions, stack, and non-displayed data in
> FAST RAM, you will still have the caches working for you.  8^)

> 					Steve Rice

And you make sure that you can invalidate the cache after a DMA from the
expansion bus takes place.

And intelligent map expansion devices into your CINN* equation; if the device
is regular memory, you'd like it cachable, if it's an I/O device, or something
weird like bridge card memory, you'd want it to be non-cachable.

-- 
Dave Haynie  "The B2000 Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {ihnp4|uunet|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
		"I can't relax, 'cause I'm a Boinger!"