🚀 go-pugleaf

In article <1990Jun4.134811.12142@watdragon.waterloo.edu> dgaudet@crocus.uwaterloo.ca (Dean Gaudet) writes:
>Call me crazy, but wouldn't using the CPU (a 020 or 030 I suppose) instead of
>the blitter for speed cause a decrease in the overall speed of the machine?  
>i.e., one of the reasons the Amiga seems faster than a similar speed PC or Mac
>is because of the support hardware and the parallelism.

  Unfortunately, with a bitplane oriented display, you only get parallelism
on your last bitplane blit. True, you can compute you next blit values before
waiting, but that buys you little time.  For polygons, the processor is
definitely faster, even on a nofastmem A500. But, for general block copying,
such as windows, arcade style animation, etc, the blitter is much faster,
and easier to use.  If the application is oriented such that the blits
can be interleaved with other processor operation, more parallelism could
be achieved, but this is usually not the case in a general purpose
application.

>Perhaps someone should rewrite the blitter in software so and make the blit
>routines "intelligently" decide whether to use the CPU or the blitter chip.
>For example:  if CPU is a 030 and CPU traffic is slow, then use the CPU
>otherwise use the blitter.

  As far as the ROM is concerned, it's fine as is. If a specific application
warrants higher performance, do what is fastest. Either directly access
the blitter with custom code, or use the processor to render polygons. I
haven't tried using the 030 for block moves as the blitter is highly
efficient in this case. Using the blitter and processor on alternate
bitplanes *simultaneously* would yield very high throughput.


  John