Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucla-cs!acm
From: acm@valhalla.cs.ucla.edu (Association for Computing Machinery)
Newsgroups: comp.sys.atari.st
Subject: Re: NeXT announcement (was Re: Atari Workstation)
Message-ID: <17109@shemp.CS.UCLA.EDU>
Date: 24 Oct 88 07:26:13 GMT
References: <1449@wayback.UUCP> <6528@pyr.gatech.EDU> <10019@cup.portal.com> <9236@watdragon.waterloo.edu> <2893@sugar.uu.net>
Sender: news@CS.UCLA.EDU
Reply-To: acm@cs.ucla.edu (Association for Computing Machinery)
Organization: UCLA Computer Science
Lines: 24

In article <2893@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes:
>In article <9236@watdragon.waterloo.edu>, jafischer@spurge.waterloo.edu (Jonathan A. Fischer) writes:
>> assuming that the graphics load is handled by the '030.  A big lose.
>
>Not necessarily. According to Henry Spencer the 68030 can run a BitBlt in
>cache fast enough that there's one useful memory reference every clock cycle.
>This is also the maximum speed a DMA device can be expected to support. Thus,
>a 68030 cannot be speeded up by a Blitter. See the blitter wars in comp.arch

It depends.  If they would have implemented screen memory separate from 
main memory (as on the ATW, I believe), then, theoretically, the processor 
could be using main memory's bandwidth how it wants at the same time that 
the blitter is working at full bandwidth.  In reality, there should be some 
conflict as data is passed between the two, but the blitter should result 
in a net speed-up.  Also, you're assuming a 32-bit bus.  Just think if the
bus was wider than the 68030 could chew at once.  Then you could again share
bus cycles with DMA devices.


Plinio Barbeito

---
UUCP:  ...!{...}!ucla-cs!acm
ARPA:  acm@cs.ucla.edu