From: u894776@bruny.cc.utas.edu.au (James McCoull)
Subject: Re: Amiga Blitter 40% slower than Atari Blitter (???)
Organization: University of Tasmania, Australia.
Date: Mon, 5 Oct 1992 01:40:57 GMT

wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:

>Let me check out how this might be worst case though.
>You are just scrolling in a window, keeping your finger on the arrow down key.

>You forgot to run ye olde raytracer in the background. The CPU can't do 
>anything useful. (Even on this HP Workstation that's the regular state 
>of affairs 90% of the time). That cuts the 4x factor into 2x. 

Anyone care to explain this bit of logic to me?  How does the 4x factor
get cut down to 2x? 

>Now lets assume that the Amiga is running in a comparable resolution, 
>640x200x2 bitplanes or 320x200x4 bitplanes to the Atari.
>According to the Amiga Hardware Reference Manual '86 Page 188-190, (*)
>this means that the Blitter isn't able to hit the bus twice as fast in
>those modes, since the display needs those cycles.
>That cuts the 2x factor into 1x.

Hmmm your calculations are way out here.  Try 227.5 colour clock cycles
per scan line, with a fair few of the scan lines not fetching any data
[heard of vertical+horizontal blanking? I guess not...]  Anyway lets
take your 320x200x4 bitplane screen on ye olde standard PAL machine
[you are in germany so I am comparing the standard ST display size
with the equivalent amiga display on a PAL machine - call me a cheat
if you must].
	So your chipram system has about 3575450 memory slots available.
Say take 4 clocks per scan line for the memory refresh, and a few other
things [cant remember the exact details sorry].  Take off another 80 slots
for the video fetch [320 pixels = 20 short words x 4].  So that leaves us
with about 140 memory slots per display line, and over 220 memory display
slots for the vblank area.  So the total of cycles available for the blitter
and cpu is: 220*(312.5-200)+140*200 ie over 52000 memory slots in chipram.
That is over 2637500 memory slots per second, each slot capable of transfering
16 bits [I assume you understand this much no?].

Now lets compare with the bog standard Atari STe.  There are no more than
2000000 memory cycles available per second.  Add the overhead of the
atari blitter, and its a real chuckle.

>Since the Amiga blitter is apparently unable (**) to smartly detect when not
>to fetch the destination in a  src/dst->dst operation (the usual one for
>scrolling a window up or down) we have another perfomance lossage of about
>30%. Add to this that the Amiga has a 10% lower system clock anyway, then
>this comes off worstcase as a factor of 0.6x bandwidth.

Hmmm tell me how you can add this detection into a two staged pipeline
blitter with more than two sources?  Your logic functions on the atari blitter
are so brain dead that its easy to detect - you can just base it on the midword
mask - with the minterms on the amiga its a bit harder.

Anyway if you are really after speed... then you split it up into three
blits no?

>Actually you still have the capacity of the Amiga to use the time multi-
>tasking, but you won't be scrolling any faster.

Lets be honest?  Who actually owns an STe to test this out?  Last time
I heard, CBM were selling more C64's a year than Atari could dream of
selling STes.

And if scrolling is your game... then you open a screen... and do it all
in hardware.

Now I will state it clearly - I have nothing against STs, but the blitter
in the STe is an absolute joke.  Even a "hardcore" atari coder I know
[owns an ST, STe, Amiga1000 [which he hates]] admits that the blitter in
the STe is a waste of space.

The STe was an "amiga killer" wasnt it?  The amiga is a games machine [as
the atari folk say].  Then why is the STe blitter only good for scrolling
desktop windows, rather than real game work?

Newsgroups: comp.sys.amiga.advocacy