From: u894776@bruny.cc.utas.edu.au (James McCoull)
Subject: Re: Atari BLiTTER
Organization: University of Tasmania, Australia.
Date: Wed, 30 Sep 1992 13:28:20 GMT

gerrymon@eng.umd.edu (Gerry Mon) writes:

>There are rumors that the BLiTTER in the Falcon has some added
>functionality along with the increase in clock speed.  I sure hope so.

	So do I.  But so far I have been unable to obtain any useful
[hardware level/cycle] information on the Falcons BLiTTER.  All I have
is that it is twice as fast as the STe's blitter, and may provide a few
more features for pixel planes modes [chunky to you strange ones].

	If this is the case, then I don't know why they bother - except
possibly for STe compatibility.  I will say it again - IMHO the STe
blitter is an *absolute* waste of money and time - it was just an image/
marketing thing - deemed necessary for a supposed "amiga killer".

	Now I've got that out of my system are it might be a good time for
discussion on possible features that could be added to the amigas blitter.


o. Interleaved bitplane support:

	Consider ye-olde traditional cookie cut blit.  The "mask" is
read once for each bitplane - the aim is to reduce this to reading the mask
only once.  It might be useful to be able to hold a complete "horizontal-line"
of one of the input sources, and associate a counter with it.  This way in
an interleaved bitplane - it would be possible to read each line of the mask
once for each destination line (irrespective of the depth of this destination
line).

	Is this feature worth its cost? Maybe with 8 bitplane deep images
the saving is worth the cost of the 1000 or so bit registers in the blitter -
as a coder I would say add the feature - as a designer/coster I would say try
again laddie.  If the blitter is to be modified to buffer one complete line of
each source - then add this feature, otherwise do not.  [Buffer one complete
line of each source?  I'm not sure, but this could be added for SCRAM [and
similar] support - this way the blitter would grab a complete line of all
the destinations in first [subject to a width restriction], while
simultaneously peforming the required logic on the previously grabbed lines].


o. Rectangle [window support]:

	Consider blitting a window from position A to B.  Only the extreme
columns need to be mixed with the destinations.  Software solution -
break the blit into three parts [to save cycles], do the two outermost
column blits using a "destination" source, do the internal segment as a 
direct copy [no "destination" source].  Hardware solution - offer a mode
where a source may only actually be fetched for the first and the last word
of a horizontal line.  Ok Ok this doesnt save you many cycles - but when
you are a performance freak you cant help it.


o. More Ideas [at a later date :) - when I'm not so tired].

o. Blitter Copper/Feeder [anyone who has tried to write high-performance
3d graphics routines on the amiga [fastram friendly], knows what this is
for :) ]

o. Polygon support [at least filling between two horizontal lines -
without preprocessing [or without need for "destination" source fetch when the
words being written are not at the edges]].


I guess of course all this is a load of bollocks [been a long day], and
the best idea would be to retain all the current blitter features, speed up
the blitter say 4-8x [over ECS] - but add more support for handling small
blits without a great deal of overhead [it would be nice if the only time
waitblit was called was when we really needed to know the blitter had modified
its memory, and not when we wanted to know it was free - a queue can handle
that].