Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!ames!oliveb!amiga!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.sys.amiga Subject: Re: GVP 68030 reviewed in Sentry Message-ID: <7069@cbmvax.UUCP> Date: 8 Jun 89 17:23:53 GMT References: <2461@van-bc.UUCP> Organization: Commodore Technology, West Chester, PA Lines: 36 in article <2461@van-bc.UUCP>, lphillips@lpami.wimsey.bc.ca (Larry Phillips) says: > There are only two choices here, one being to disable the cache (I don't know > if you can disable data cache separately from instruction cache), You sure can. In fact, the OS doesn't turn on the data cache when you power up on an '030 based Amiga, it not knowing the difference between '020 and '030. You need something like SetCPU (which is supplied by GVP, and also recently posted to listings). The third choice, of course, is to use a device driver that knows about '030s and flushes the data cache after a DMA transfer. > and the other is to use a 'Mask = ' entry in the mountlist to limit DMA to > the 16 bit memory. Actually, that means limiting DMA to CHIP memory, which can't be data cached anyway. > GVP claims that it is better to do the latter, since the 68030 is fast > enough to make the programmed IO transfer speeds go very quickly. DMA into CHIP memory is a very losing proposition. The data cache is your choice. I'd recommend keeping it off in a DMA system until you get a device driver that definitely supports cache flushing. Programmed I/O with an '030 isn't much slower than DMA if it's over the bus, and if it's on a magic 32 bit bus like GVP's on-card controller, it's probably about as fast as 16 bit DMA currently is. Note that, chances are, you'll get away with DMA and the data cache MOST of the time. Of course, Murphy will tell you the times you won't.... > -larry -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession