English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. General > Coders. Tutorials

 
 
Thread Tools
Old 31 March 2010, 10:49   #1
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
ASM: Wait for Vertical Blank

I'm looking for best/accurate wait vb routine. Any examples are welcome
Asman is offline  
AdSense AdSense  
Old 31 March 2010, 11:08   #2
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,531
I do it like this:
Code:
.loop	move.l	$dff004,d0
	and.l	#$1ff00,d0
	cmp.l	#303<<8,d0
	bne.b	.loop
StingRay is offline  
Old 31 March 2010, 12:07   #3
Doc Mindie
In deep Trouble
 
Join Date: Sep 2004
Location: Manchester, Made in Norway
Age: 45
Posts: 827
what does the << in the cmp.l line do?
Doc Mindie is offline  
Old 31 March 2010, 12:27   #4
copperkid
Registered User
copperkid's Avatar
 
Join Date: Feb 2010
Location: Germany
Posts: 30
Post

#303<<8 should be a shift 8 bits to the left

303 == $12f, so #$12f<<8 becomes #$12f00

given the initial
and.l #$1ff00,d0
basically the comparison is only for bits 33-16 of the value initially read in d0

why this works is a mystery to me, but I assume StingRay knows what he's doing


By the way, just this morning I was playing around with the exec routines to add my handler to the vertical blank interrupt, is there a lot of difference in performance?
I took and modified the code from the HRM, something on the lines of

Code:
    
    move.l  _GfxBase,a6
    jsr     _LVOOwnBlitter(a6)
    move.l  $4.w,a6
    jsr     _LVOForbid(a6)
    moveq.l #INTB_VERTB,d0
    lea     VBlankServer(pc),a1
    jsr     _LVOAddIntServer(a6)
copperkid is offline  
Old 31 March 2010, 12:56   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,674
Quote:
Originally Posted by StingRay View Post
I do it like this:
Code:
.loop	move.l	$dff004,d0
	and.l	#$1ff00,d0
	cmp.l	#303<<8,d0
	bne.b	.loop
This is 100% acceptable and reliable

Worst you can do is to poll INTREQR VBLANK bit when VBLANK interrupt is enabled. Very unreliable.
Toni Wilen is offline  
Old 31 March 2010, 13:51   #6
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,531
Quote:
Originally Posted by copperkid View Post
given the initial
and.l #$1ff00,d0
basically the comparison is only for bits 33-16 of the value initially read in d0

why this works is a mystery to me, but I assume StingRay knows what he's doing
Bits 8-16 rather (VPOS). See VPOSR and VHPOSR documentation and you'll understand how and why it works.


Quote:
Originally Posted by copperkid View Post
By the way, just this morning I was playing around with the exec routines to add my handler to the vertical blank interrupt, is there a lot of difference in performance?
I took and modified the code from the HRM, something on the lines of

Code:
    
    move.l  _GfxBase,a6
    jsr     _LVOOwnBlitter(a6)
    move.l  $4.w,a6
    jsr     _LVOForbid(a6)
    moveq.l #INTB_VERTB,d0
    lea     VBlankServer(pc),a1
    jsr     _LVOAddIntServer(a6)
Nothing wrong with that, one advantage is that you don't have to care about acknowledging the IRQ (and thus you don't have to deal with interrupt related bugs that can occur on A4000's f.e.) because the OS does that for you.
StingRay is offline  
Old 31 March 2010, 14:06   #7
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
I find

Code:
wait_vb
.1	btst	#0,(_custom+vposr+1)
	beq	.1
.2	btst	#0,(_custom+vposr+1)
	bne	.2\@ 
	rts
but I'm not sure if above code is 100% acceptable and reliable.
Asman is offline  
Old 31 March 2010, 15:15   #8
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,017
Looks perfectly fine to me, and it's both safe for all displays up to 512 scanlines and guaranteed to only run once per frame, as opposed to a single wait that might run several times if the other code in the loop finishes in less than 1 scanline.

I use this, works with any operand like WaitLine D3, #$FF, (A0)+ etc.

Code:
WaitLine  macro
.\@       move.l    vposr(a6), d0
          lsr.l     #1, d0
          lsr.w     #7, d0
          cmp.w     \1, d0
          bne       .\@
          endm
Leffmann is offline  
Old 31 March 2010, 15:20   #9
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,531
Quote:
Originally Posted by Leffmann View Post
Looks perfectly fine to me, and it's both safe for all displays up to 512 scanlines and guaranteed to only run once per frame, as opposed to a single wait that might run several times if the other code in the loop finishes in less than 1 scanline.
Which can be easily fixed:
Code:
.loop	move.l	$dff004,d0
	and.l	#$1ff00,d0
	cmp.l	#303<<8,d0
	bne.b	.loop

.loop2	move.l	$dff004,d0
	and.l	#$1ff00,d0
	cmp.l	#303<<8,d0
	beq.b	.loop2
And the likelihood that a routine needs less than 1 rasterline is not very high anyway.
StingRay is offline  
Old 31 March 2010, 15:33   #10
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,017
No there's not a whole lot of code that will run in less than 1 scanline, BUT there are a few very good examples that will, and many more things run under WinUAE with JIT and immediate blitter or on a faster system might as well.

Try something like a simple fade to black of a 16 color screen in 12-bit RGB on an 060 and you'll be looking at 1 scanline or less.

I'm just saying the check for the MSB switch from 1 to 0 is safe, short, and works for all programmed displays. If people wrote solid code to begin with they wouldn't have to sit in sorry hindsight when their code freaks out on faster systems, and people like you wouldn't have to sit and WHD-fix poor games that won't run on A1200
Leffmann is offline  
Old 31 March 2010, 15:38   #11
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,531
Quote:
Originally Posted by Leffmann View Post
No there's not a whole lot of code that will run in less than 1 scanline, BUT there are a few very good examples that will, and many more things run under WinUAE with JIT and immediate blitter or on a faster system might as well.
I know that they exist, I wrote that the likelihood is "not very high" after all (WinUAE and JIT do not count for me!). In 99% of all cases a standard "wait for line xxx" routine does the job without wasting cycles.
StingRay is offline  
Old 08 April 2010, 14:00   #12
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
@Leffmann, StingRay - thanks a lot.

Is there any difference between

Code:
wait_vb_1
.1	btst	#0,(_custom+vposr+1)
	beq	.1
.2	btst	#0,(_custom+vposr+1)
	bne	.2
	rts
and

Code:
wait_vb_2
.1	btst	#0,(_custom+vposr+1)
	bne	.1
.2	btst	#0,(_custom+vposr+1)
	beq	.2
	rts
?

And second ( stupid ) question. Is legal to do btst on odd address _custom+vposr+1 ?
Asman is offline  
Old 08 April 2010, 14:26   #13
pmc
rebooting...
pmc's Avatar
 
Join Date: Apr 2007
Location: Elsewhere
Posts: 1,595
@ Asman - btst when used with mem locations is btst.b so yes, testing bytes at odd mem locations is legal.

I used a btst to an odd mem address (intreqr+1) in my trackloader.
pmc is offline  
Old 08 April 2010, 19:54   #14
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,674
Quote:
Originally Posted by Asman View Post
@Leffmann, StingRay - thanks a lot.

Is there any difference between

Code:
wait_vb_1
.1	btst	#0,(_custom+vposr+1)
	beq	.1
.2	btst	#0,(_custom+vposr+1)
	bne	.2
	rts
and

Code:
wait_vb_2
.1	btst	#0,(_custom+vposr+1)
	bne	.1
.2	btst	#0,(_custom+vposr+1)
	beq	.2
	rts
?
First waits for line 0, second waits for line 256. (it can also wait for line 512, 1024 and so on but I think this was about standard video modes )

Quote:
And second ( stupid ) question. Is legal to do btst on odd address _custom+vposr+1 ?
Technically byte read from custom register is "illegal" but has always worked perfectly fine. Everyone did that

Byte writes to custom registers may not work properly with all accelerator models (Blizzard 1260 for example, only to odd or even bytes, if I remember correctly)
Toni Wilen is offline  
Old 10 April 2010, 16:24   #15
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 633
I would avoid waiting for a fixed raster line number. Because if there are interrupts like sound via cia interrupt or also a keyboard handler which uses direct wait for ack, it may tigger not in the following frame or several frames later.
Wepl is offline  
Old 10 April 2010, 17:07   #16
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,674
Quote:
Originally Posted by Wepl View Post
I would avoid waiting for a fixed raster line number. Because if there are interrupts like sound via cia interrupt or also a keyboard handler which uses direct wait for ack, it may tigger not in the following frame or several frames later.
In worst case you get near-impossible to debug very rare display corruption if your "vblank wait" ends in the middle of display

There is no 100% safe way to wait for vblank if "random" interrupts are enabled.
Toni Wilen is offline  
Old 10 April 2010, 17:24   #17
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 633
Quote:
Originally Posted by Toni Wilen View Post
In worst case you get near-impossible to debug very rare display corruption if your "vblank wait" ends in the middle of display
yes, that may happen (if the code is not well synchronized and does not work properly on 68000-68060)

Quote:
Originally Posted by Toni Wilen View Post
There is no 100% safe way to wait for vblank if "random" interrupts are enabled.
yes, but it's possible to wait for the next free slot after the vblank as long as the interrupts are not eating half of the frame
Wepl is offline  
Old 10 April 2010, 17:29   #18
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 633
Quote:
Originally Posted by StingRay View Post
I do it like this:
Code:
.loop	move.l	$dff004,d0
	and.l	#$1ff00,d0
	cmp.l	#303<<8,d0
	bne.b	.loop
is it guaranteed that line 303 is reached on every display mode (PAL/NTSC)?
Wepl is offline  
Old 10 April 2010, 18:13   #19
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,674
Quote:
Originally Posted by Wepl View Post
is it guaranteed that line 303 is reached on every display mode (PAL/NTSC)?
No. NTSC has 262/263 lines.
Toni Wilen is offline  
Old 10 April 2010, 20:19   #20
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,531
Quote:
Originally Posted by Wepl View Post
I would avoid waiting for a fixed raster line number. Because if there are interrupts like sound via cia interrupt or also a keyboard handler which uses direct wait for ack, it may tigger not in the following frame or several frames later.
I've been using this approach in countless demos which had CIA/keyboard interrupts enabled and never experienced any problem.

Quote:
Originally Posted by Wepl View Post
is it guaranteed that line 303 is reached on every display mode (PAL/NTSC)?
This is PAL only as Toni already said. TBH, I never cared about NTSC compatibility at all.

Maybe a better way would be to set a flag in the VBI and poll that flag in the mainloop? Disadvantage is that you need a vertical blank interrupt though.

Last edited by StingRay; 10 April 2010 at 20:25. Reason: additions
StingRay is offline  
AdSense AdSense  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Removing the IDE Wait on Kickstart 3.1 Zetr0 support.Hardware 26 16 June 2010 08:31
'Wait' program that checks for a joy button press instead of 'Return' key... Heavy Stylus request.Apps 7 10 May 2009 19:01
timed wait using CIAs jotd support.Other 3 23 March 2008 14:55
HD won't boot now..wait failed returncode? Amigan25 project.ClassicWB 2 08 June 2007 18:21
Wait a sec - what about Macs? Computolio Amiga scene 10 02 June 2004 07:23

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 12:11.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.32476 seconds with 12 queries