Wiki link: https://wiki.apollo-accelerators.com/doku.php/saga:video

Thanks for that!  It is this kind of information that is so very useful and interesting.  I never realized that the blitter would not have been so good in later Amigas because they did not need it, except I guess, for backward compatibility.

Pity the blitter chip was not multitasking friendly.

1) Does multitask matter for a graphical co-cpu? Doesn't the same argument apply to the copper?
 
  2) Could a modern blitter be made faster than 080 in moving data? And thus still be able to complement it?

Actually using Blitter makes programs more complex and more error prone. But it was paying of as its faster then the old 68000.
A big problem with the Blitter/HW memcopy function is that in a multitasking environment if 2 programs call it same time - the hell breaks loose - so it need be protected with a semaphore.

It's still possible to use the blitter from different interrupt levels, without making faulty blits. This would correspond to multitasking or context switches.

Before writing into any blitter registers, the blitter setup values need to be saved into memory and then if there's an interrupt, the interrupt needs to write these saved values from previous blit back into blitter registers before returning. This will ensure that the previous blit will not fail because its registers were messed up before it had the chance to start the blitter operation.

Of course you need to also wait before blitter finishes, before starting a new blitter operation. To alleviate this problem no large blits should be allowed in a multitasking environment, but instead break up larger blits into smaller ones.

I guess this is only of value to 68000-based Amigas, but does using the Blitter this way make programs more efficient considering the overhead required in saving states and still having to wait for the previous blitter operation?  I'm not an Amiga programmer, although I did learn C programming on my A500 in the 80's. So asking out of curiosity.

The blitter is certainly useful on all m68k-Amigas. On a 68020-68060 with fast ram, it can be used for gfx operations in parallel with CPU when CPU is accessing only fast ram and doing other things. The efficiency comes here from that you can have blitter doing something useful on the chip ram bus, when the CPU is doing something else.

Saving blitter state causes some overhead, but not much. Instead of busy waiting for blitter ready bit, one can also use blitter finished interrupt, to get an interrupt-driven feeding of new blitter operations.

The reason why one would want to use the blitter from several interrupt levels is e.g. you have some gfx objects that needs to be updated 50 FPS, and then also want to allocate rest of blitter time for some non timing critical operations.

A blitter chip would also be useful on Vampire, but it would need to be improved, and memory bandwidth is a problem as CPU and blitter would then share the same memory bus, which is not enough for both operating in parallel.

Also you need to mind that the Blitter is slower than a 68030 CPU for many tasks - this means many GFX operations like printing TEXT
will run slower if you use the Blitter instead the CPU.

This is very interesting and I get the idea that only experience through trial and error, or asking here, will let us know when using the Blitter would benefit.  It doesn't guarantee us better performance, it could be slower in many cases, but in others, it may offer improvements, depending on our implementation.  For now, probably not something I should worry about until I become  more experienced with ASM.

Thanks for the information.

Also when doing a BLijob you have choices as coder.
For example when doing a typical 5 plane(32color) Bob blit.
This means "normally" 5 Blitjobs per BOB.
The amount of overhead is very high here.

You can lower the overhead to 1 job, if you create a 5 times bigger MASK for the BOB in memory - but this wastes precious chipmem.

As you see the whole calculation does depend on many factors.

> The OS will generally not use CPU and Blitter in parallel.

The OS, or the game engines?

Lets say you want to PRINTF some text of 20 Chars.

Lets say the Blitter needs per char

Time=2 setup with CPU
Time=5 Blitting
Time = 20*7 == 140 total
 
Lets say the CPU needs time 4 per Char
Time = 20*4 == 80 total
 
Does this example make it clearer?

No? Since the CPU is free to do other stuff while the blitter is blitting. 2*20 = 40 CPU setup time, which gives 40 cycles more for the CPU than if it did all the work. Right?

> As the blitter is an asynchronous coprocessor, the 680x0 CPU continues to run as the blit is executing.

EXTERNAL LINK

 
In our example the time to print 1 char might be 30 or 40 instructions. Also in a multitasking environment this time can not be used, as "timeslices" for multitasking switches are measured in MILLIONs. This means there are cases were a slow blitter will make a fast CPU wait, and this time is then lost.
 

Yes, the blitter can be useful in some special cases:
-Blitter can CLEAR (not copy data) chip ram in parallel with CPU accessing chip ram also at same time without slowdowns (useful for example for 3D-stars effect)
-in a flight simulator blitter can update the lower screen with various meters, when cpu is calculating next frame in fast ram
-anytime when CPU is doing some longer calculations in fast ram, you can fire up the blitter with some task
-more ideas...

But for AmigaOS performance, the blitter is generally no good - there is a program that patches blitter calls with CPU calls called FBlit on Aminet. It makes Workbench run clearly faster on accelerated Amigas with fast ram.