Extended Vertical Blank
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 |
Quote:
|
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? |
@roondar
Indeed by reducing screen area you'll gain a lot of free dma cycles. Btw It' has been always my first choice! |
Quote:
Quote:
|
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 :D 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. |
Quote:
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 |
Quote:
|
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 ;) |
Quote:
|
All times are GMT +2. The time now is 17:27. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.