Extended Vertical Blank

[sandruzzo]

According to HW Manual, VB can be extended by copper, and have it enabled at the end of viewport. By extending it, is it possible to have more dma slots avilable?

"The minimum time of vertical blanking is 20 horizontal scan lines for an
NTSC system and 25 horizontal scan lines for a PAL system. The range
starts at line 0 and ends at line 20 for NTSC or line 25 for PAL. After
the minimum vertical blanking range, you can control where the display
actually starts by using the DIWSTRT (display window start) register
to extend the effective vertical blanking time. See Chapter 3, "Playfield
Hardware," for more information on DIWSTRT .

If you find that you still require additional time during vertical
blanking, you can use the Copper to create a level 3 interrupt . This
Copper interrupt would be timed to occur just after the last line of
display on the screen (after the display window stop which you have
defined by using the DIWSTOP register)."

Alessandro

[britelite]

Originally Posted by sandruzzo

According to HW Manual, VB can be extended by copper, and have it enabled at the end of viewport. By extending it, is it possible to have more dma slots avilable?

No, you don't get more DMA slots. But it does make it easier to trigger your code to run during screen dma free areas of the screen.

[roondar]

I'd say the only way to really get more DMA slots for the Blitter or CPU is to limit DMA usage for the other DMA sources. Reducing screen depth is an obvious choice, as it limiting screen width or height. Some gains are also possible by intelligently choosing how to interleave the CPU with other DMA: do as much of the CPU only work (such as game/demo logic) as possibly during bitplane fetches and only activate 'Blitter Nasty' when you have nothing left to do but wait. This optimises bus usage and allows the Blitter to use more of the non-bitplane DMA time.

In other words, don't use VBLANK for timing but rather Copper interrupts at the beginning of actual bitplane fetches. I've tested this repeatedly and found it ends up giving a small percentage of extra 'free' slots to the Blitter. Similarly, by switching Blitter Nasty on during the Blitter Wait and off afterwards, you also gain a small amount of apparent extra cycles (depending on how big the blit is and how much you can do while it runs)

Nothing amazing and usually ends up being less than 5%, but it's essentially free, so why not do it?

[sandruzzo]

@roondar

Indeed by reducing screen area you'll gain a lot of free dma cycles. Btw It' has been always my first choice!

[phx]

Originally Posted by roondar

In other words, don't use VBLANK for timing but rather Copper interrupts at the beginning of actual bitplane fetches.

I don't quite understand that. When you synchronise your program with a copper interrupt at the first line with bitplane-fetches, you will be starting with the least amount of free DMA slots. Why is that an advantage?

Originally Posted by sandruzzo

Indeed by reducing screen area you'll gain a lot of free dma cycles. Btw It' has been always my first choice!

It has always been my last choice to limit the visual appearance of a game (so I'm generally using 320x256 with 5 planes). I prefer to optimise the code first.

[Antiriad_UK]

Interesting. I'd been experimenting with a copper interrupt instead of VBlank recently but I was triggering the interrupt at the last line of bitplane display instead (like HWRM description). Most of my routines are setup as this order
- Start blitter screen clear
- big cpu tasks
- If any CPU free help blitter clear
- Some more blitter/cpu tasks interleaved as best as possible

Not sure if changing interrupt to first line of bitplane dma would help me but I'll try anything once

Agree with the blitter nasty tip. All my old code just turned blit nasty on at the start and then left it (think I read aboout that in Menace coding article and took it as gospel). Since starting coding again I'm finding it's 99% best to leave it off all the time except when doing blitwaits.

[roondar]

Originally Posted by phx

I don't quite understand that. When you synchronise your program with a copper interrupt at the first line with bitplane-fetches, you will be starting with the least amount of free DMA slots. Why is that an advantage?

Because the CPU doesn't actually use all free slots, but the Blitter normally does. This means that bitplane fetches slow down the CPU by a relatively lower amount than they slow down the Blitter. By running the main part of the logic during bitplane fetches you make optimal use of this difference.

Perhaps this is best explained by looking at 4 bitplane mode. In 4 bitplane mode the CPU is normally not slowed down* during bitplane fetches, but the Blitter is slowed down by 50% during 4BPL bitplane fetches. Meanwhile when there is no bitplane fetches, both run at full speed**.

Edit: if you start your game logic with restoring old blits or other blits that use all DMA slots, that will do better in VBlank. It's purely the logic-only parts that benefit from this.

*) there are some exceptions to this, but they are really rather rare.
**) assuming no other DMA

[phx]

Originally Posted by roondar

Edit: if you start your game logic with restoring old blits, that will do better in VBlank. It's purely the logic-only parts that benefit from this.

Ah, ok. Now I understand! So do the CPU-intensive game logic first in parallel to bitplane DMA, then do the Blitter-work which may even partly happen after the display window. Interesting.

[roondar]

Yup, that's it

Don't expect massive gains though - it sounds much more effective than it usually ends up being. Most Amiga games and demos rely a lot on the Blitter and that part won't speed up

[sandruzzo]

Originally Posted by phx

It has always been my last choice to limit the visual appearance of a game (so I'm generally using 320x256 with 5 planes). I prefer to optimise the code first.

That's true, but you can't overrun dma slots' shortage!