Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun-barr!rutgers!netnews.upenn.edu!eecae!cps3xx!usenet
From: usenet@cps3xx.UUCP (Usenet file owner)
Newsgroups: comp.sys.amiga
Subject: Re: GVP 68030 reviewed in Sentry
Message-ID: <3374@cps3xx.UUCP>
Date: 12 Jun 89 19:39:43 GMT
References: <9831@polya.Stanford.EDU> <7081@cbmvax.UUCP>
Reply-To: porkka@frith.UUCP (Joe Porkka)
Distribution: na
Organization: Michigan State University
Lines: 20

In article <7081@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
>in article <9831@polya.Stanford.EDU>, jwl@Feanor.Stanford.EDU (John Lockhart) says:
>> Keywords: A2090, hard drive, DMA, 68030, cache
>
[stuff deleted]
>> driver to deal with the 68030 cache?
[stuff deleted]
>DMA, and if it's seen, calling a Supervisor() function that'll clear the cache.
[stuff deleted]

Dave, does the '030's data cache cause problems when
(real hardware)device drivers play with
the devices memory-mapped IO registers?

How about another flag in task/interrupt structures
telling EXEC to turn off the data cache when executing this chunk of
code. Even better "MEMF_NOCACHE" :-), but I don't think you can do
that with the MMU, can you?

This is an example of a short .signature   jap@frith.cl.msu.edu