Newsgroups: comp.sys.amiga.advocacy
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!geech.gnu.ai.mit.edu!rjc
From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell)
Subject: Re: (Video) Hardware Idiots ?
Message-ID: <1991Jun12.232718.2373@mintaka.lcs.mit.edu>
Sender: news@mintaka.lcs.mit.edu
Organization: The Internet
References: <1991Jun10.065629.21255@marlin.jcu.edu.au> <1991Jun10.074421.6782@mintaka.lcs.mit.edu> <22368@cbmvax.commodore.com>
Date: Wed, 12 Jun 91 23:27:18 GMT
Lines: 74

In article <22368@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
>In article <1991Jun10.074421.6782@mintaka.lcs.mit.edu> rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) writes:
>>In article <1991Jun10.065629.21255@marlin.jcu.edu.au> cpca@marlin.jcu.edu.au (Colin Adams) writes:
>
>>Assuming those 5 million instructions were all move's theoretically
>>the 030 could transfer 20 megs of data/sec if there was no bus
>>contention and using fast ram. (5 MIPS * 4 bytes per longword = 20meg)
>
>Strangely enough, the A3000's fast RAM bus runs at 20 MB/s (megabytes per
>second), nonburst, 33 MB/s burst.  A 25MHz 68030 running with 0 wait states
>(you never use burst at 0 wait states, the '030 cache is too small for that
>to always win) manages 50 MB/s.  Obviously, if you're talking about data
>transfers, the best you do is half of that, since the CPU need to read in,
>then write out, any particular datum.  

 [I feel like a dummy, in my example I started out by figuring out
the transfer rate on the fast ram bus @25mhz and then tried to 
apply it to the chip bus, I must be losing my mind.]

  So the max transfer rate, with 0 wait states is 10mb/sec (theoretical) on
the fast ram bus at @25mhz. Can you explain how burst works? I remember
reading about it a long time ago, but can't recall it, something about
eliminating wait states on sequential ram accesses?

>>Chip ram cuts this figure in half (the processor only gets access
>>every other cycle), and a 16bit bus cuts it in half again. 
>
>Essentially wrong on both counts.  Forget about "every other cycle", that only
>has meaning to Agnus.  Think "bandwidth".  Agnus will support 7.16MHz 68000
>accesses at full speed, which turns out to be roughly 3.5 MB/s.  An A2500 can
>only hit chip RAM at 3.5 MB/s, but since an A3000 has a 32 bit Chip RAM bus,
>it's 68030 can hit chip RAM at 7 MB/s.  Since the blitter, if allowed, can also
>manage 7MB/s (twice the RAM speed but half the bus width), there's no clear
>winner in any race, it depends totally on what you're doing.

  IMHO, it looks like the blitter wins in the majority of situations like
large blits, masking and shifting, arbitrary bit boundaries and complex
logic operations. [feel free to correct me on this Dave]. Now in
operations involving multiple planes, like drawing colored lines
a 68030 might win. Someone told me the blitter will access a ram
address up to 16 times to draw a line (worst cast is horizontal)?
It seems like a simple optimization to cache last word read and
set pixels in the cache then write it back when the pixel location
crosses a word boundary. I recently wrote a line plotter on the
Commodore 64 that cached the current bitmap byte, it sped the plot
tremendously. (instead of a lda (bitmapptr),y; ora bittable,x; 
sta (bitmapptr),y; [15 cycles] it was lda temp; ora bittable,x; sta temp;
[9 cycles]  when incrementing the x coordinate, I simply did a 
inx; txa; and #07; beq writecache, this would write the cache back,
recalculate the bitmap vector, and fetch a new value. I noticed
most other line plotters recalculated the bitmap address ptr every 
pixel. Apologies for the 6502 code. BTW, the cache was a zero page
location. )

>> And I wouldn't want 100% of my CPU being eaten up to copy data, 
>
>That's true; people seem amazed when the CPU does something faster than the
>blitter.  "Why not have the CPU do this?", they ask.  They are missing the 
>big picture.

  Yep. I love the Amiga's DMA philosophy, even the hardware multitasked.
I think  Polled I/O should go the way 8bit machines.

>-- 
>Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
>   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
>	"This is my mistake.  Let me make it good." -R.E.M.


--
/ INET:rjc@gnu.ai.mit.edu     *   // The opinions expressed here do not      \
| INET:r_cromwe@upr2.clu.net  | \X/  in any way reflect the views of my self.|
\ UUCP:uunet!tnc!m0023        *                                              /