Irq Blitter

[LeCaravage]

Hi there,

I've been trying to set a bob routine. In the main loop. Works fine. But could be faster I'm sure.
I've checked the fast bob routine of Lotus 3. Seems to use the Irq Blitter.
I've implemented an own irq bob routine, but it's slower. Removed the movem.l save/restore registre but still, it's slow.

So, I said to myself, Lotus 3 is smooth and fast, so it's probably not a bad idea to use IrqBlitter. What I am missing ?

Also something strange, Lotus 3 does not use movem.l save/restore instructions within irq. Dangerous.

Thanks for help,

[Asman]

Frankly hard to guess if your bob routine could be faster or not without seeing the code I think. If the routine is not a secret then just post it and perhaps someone will help you with optimization. One obvious idea is to use blitter in copper list.

[Toni Wilen]

Blitter interrupts are only useful if blits are relatively large and number of blits is small because interrupts are very slow on 68000 (interrupt startup + RTE = more than 60 cycles!)

[a/b]

As Toni noted, the key is to reduce the number of blits as the overhead is substantial.
I was in a similar situation a couple of months ago. I needed copper for sprite multiplexing, and had to turn a lot of stuff around to go from copper based blits to interrupts without losing too many cycles.
Are you using interleaved bitmaps? That will significantly reduce how many blits you have to do (e.g. with 4 bitplanes it'll be 4x fewer blits).

[LeCaravage]

Thanks for helping guys

Originally Posted by Asman

If the routine is not a secret

Not a secret at all. But I'm just at the very beginning of the routine. Roughly, using the same bob, static display, just for timing infos purpose using $dff180.

Originally Posted by Toni Wilen

Blitter interrupts are only useful if blits are relatively large and number of blits is small because interrupts are very slow on 68000 (interrupt startup + RTE = more than 60 cycles!)

Originally Posted by a/b

As Toni noted, the key is to reduce the number of blits as the overhead is substantial.
I was in a similar situation a couple of months ago. I needed copper for sprite multiplexing, and had to turn a lot of stuff around to go from copper based blits to interrupts without losing too many cycles.
Are you using interleaved bitmaps? That will significantly reduce how many blits you have to do (e.g. with 4 bitplanes it'll be 4x fewer blits).

I was suspecting blit size but not number of them
You are probably right. My bobs are RawNorm in 5 bitplans. I don't use RawBlit because chip ram -Amiga 500 OCS- is lacking.
Max blitter operations are : 80 per animation period -25Hz in PAL-.
Average Bob dimension : 8 words per 35 lines.
40 blits for restoring screen -using 2 DMA sources each- and 40 blits for displaying bobs -using 3 DMA sources each-.

Edit : My mistake. 16 bobs in 5 bpls with restaure screen should make 160 blits operations and not 80.

Edit2: 8 BYTES horizontal size of Bobs and not Word as written previously...

[a/b]

Originally Posted by LeCaravage

My bobs are RawNorm in 5 bitplans. I don't use RawBlit because chip ram -Amiga 500 OCS- is lacking.

It's exactly the same amount of memory, only differently organized. Just in case, to make sure we are on the same (bit)plane :

- rawnorm/non-interleaved
000000 ; bp0
000000
000000
111111 ; bp1
111111
111111
...
444444 ; bp4
444444
444444
= 3*5=15 rows total

- rawblit/interleaved:
000000 ; bp0 first row
111111 ; bp1 first row
...
444444 ; bp4 first row
000000 ; bp0 second row
111111 ; bp1 second row
...
444444 ; bp4 second row
000000 ; bp0 last row
111111 ; bp1 last row
...
444444 ; bp4 last row
= 5*3=15 rows total

So if you use interleaved for bitmap and bobs, unless there are additional constraints I'm not aware of, you can do the whole thing in 15 restore and 15 copy blits.
And interleaved bobs are small enough for OCS blitter to handle.

[Asman]

@a/b
But you forget about bob mask, as I know it will take more memory in interleaved bitmaps . If I am wrong then please correct me.

[LeCaravage]

Thanks for helping guys. See you in next coding question's thread

[a/b]

Ah, my bad. OK, based on your numbers you'd need additional ~36K for masks. I guess that's the price of speed. And regardless of how you execute them, setting up 32 or 160 blits is a big difference in terms of speed.
Hmm, if you can't afford that much memory, and your copper lists aren't too complicated you could try copper blits. Otherwise you are down to optimizing your blit interrupt code as much as possible. Generally speaking, shouldn't need more than 2 regs ($dff000 and pointer to blit queue), set constant stuff like modulos control words, and masks only once, write consecutive words as longwords, etc.

[LeCaravage]

Unfortunately 16 is the max number of bobs displayed at the same time. But, I have banks of animations which take much memory.
Copperlist for blitting, not feeling confortable with it as I've never used it. But I guess it needs some kind of copperlist construct every frame (?).
About Irq Blit. My very early test was to set up an empty irqblit with no use at all of movem.l - Raster time hugely increased, something like plus 50 or 60 raster lines. During screen-restore blits section irqblit is worse, because only 2 DMA source channels are used.
A game like SuperFrog uses RawNorm blits and have a smooth frame rate.