English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 23 October 2019, 10:58   #1
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,660
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
sandruzzo is offline  
Old 23 October 2019, 11:30   #2
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 612
Quote:
Originally Posted by sandruzzo View Post
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.

Last edited by britelite; 23 October 2019 at 11:32. Reason: Rewording
britelite is offline  
Old 23 October 2019, 11:59   #3
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,385
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 is offline  
Old 23 October 2019, 12:20   #4
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,660
@roondar

Indeed by reducing screen area you'll gain a lot of free dma cycles. Btw It' has been always my first choice!
sandruzzo is offline  
Old 23 October 2019, 14:44   #5
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,485
Quote:
Originally Posted by roondar View Post
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?

Quote:
Originally Posted by sandruzzo View Post
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.
phx is offline  
Old 23 October 2019, 14:48   #6
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 147
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.
Antiriad_UK is offline  
Old 23 October 2019, 14:48   #7
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,385
Quote:
Originally Posted by phx View Post
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

Last edited by roondar; 23 October 2019 at 15:08.
roondar is offline  
Old 23 October 2019, 15:07   #8
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,485
Quote:
Originally Posted by roondar View Post
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.
phx is offline  
Old 23 October 2019, 15:09   #9
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,385
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
roondar is offline  
Old 23 October 2019, 16:17   #10
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,660
Quote:
Originally Posted by phx View Post
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!
sandruzzo is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Vertical blank and Bobs geldo79 Coders. Asm / Hardware 4 21 October 2019 11:04
ASM: Wait for Vertical Blank Asman Coders. Tutorials 75 01 October 2019 13:11
Looking for vertical shooter amiades Looking for a game name ? 2 03 February 2012 12:43
Game needs blank disk? Gonzouk support.WinUAE 4 05 May 2007 18:19

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 15:23.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.07169 seconds with 15 queries