ASM: Wait for Vertical Blank

[mcgeezer]

Apologies for ressrecting this thread after a couple of years but after some testing with Rygar on much faster cards I came a cropper of this... basically very fast routines such as fades and transitions would screw up because they all trigger and run on line 303.

.vpos:  move.l  VPOSR(a5),d0
        and.l   #$1ff00,d0
        cmp.l   #303<<8,d0              ; Wait for line 303
        bne.b   .vpos						 
        rts

I've modified the Wait for Vertical Blank routine to wait for the line and then to reach at least near to the end of the horizontal line. It seems OK but wondered if anyone else has insights on a better way, or even if this isn't a good way to do it?

move.l  VPOSR(a5),d0
        and.l   #$1ff00,d0
        cmp.l   #303<<8,d0              ; Wait for line 303
        bne.b   .vpos

.hpos:  move.w  VHPOSR(a5),d0
	cmp.b	#208,d0			; Horizontal position...
	blt.s	.hpos

[/CODE]

Geezer

[Toni Wilen]

I usually simply wait for line x and then wait until line is not x.

[mcgeezer]

Originally Posted by Toni Wilen

I usually simply wait for line x and then wait until line is not x.

Yup, I don't think it makes much difference...but I'll go with your method.

.vpos:  move.l  VPOSR(a5),d0
        and.l   #$1ff00,d0
        cmp.l   #303<<8,d0              ; Wait for line 303
        bne.s   .vpos
	
.vposn:
	move.l  VPOSR(a5),d0
        and.l   #$1ff00,d0
        cmp.l   #303<<8,d0              ; Wait till line 303 finished.
        beq.s   .vposn

[Asman]

I usually use this.

;-----------------------------------------------------------------------------

;; - wait for top of frame
;
;in	a5 - _custom
;out	-
;used	d0/a0/a5
;
	xdef	HwWaitTopOfFrame
HwWaitTopOfFrame:
		lea	vposr(a5),a0
.1		moveq	#1,d0
		and.w	(a0),d0
		beq.b	.1
.2		and.w	(a0),d0
		bne.b	.2
		rts

;-----------------------------------------------------------------------------

[ross]

Hi Asman!
This however does not wait for line 303 (although I don't know why line 303 )

[Asman]

Hi ross!
Yeah right, I've forgot about that 303 line , just wait for top of frame. You know I don't like wasting cycles.

[ross]

Originally Posted by Asman

You know I don't like wasting cycles.

yep, the 68k motto: every cycle worth the effort

[hitchhikr]

I use this:

wait_sync:
    btst.b  #0,$dff005
    beq.b   wait_sync
wait_sync_line:
    btst.b  #0,$dff005
    bne.b   wait_sync_line

[meynaf]

If you really want to wait for the top of frame, why not just this :

 move.w #$20,$dff09c
.wait
 moveq #$20,d0
 and.w $dff01e,d0
 beq.s .wait

And if you use vert beam interrupt, it's even easier - set a flag there and wait for it to change.

[ross]

Ok, if you are in the dark side of the force:

	lea	$dff004,a0
	
.l1	lsr	(a0)
	bcc.b	.l1	
.l2	lsr	(a0)
	bcs.b	.l2

[hooverphonique]

Originally Posted by ross

Ok, if you are in the dark side of the force:

    lea    $dff004,a0
    
.l1    lsr    (a0)
    bcc.b    .l1    
.l2    lsr    (a0)
     bcs.b    .l2

Maybe it doesn't matter in practice, but this writes to a read-only register, which is not recommended.

[ross]

Originally Posted by hooverphonique

Maybe it doesn't matter in practice, but this writes to a read-only register, which is not recommended.

As specified only for those in the dark side of the force.
In practice it does not hurt, but really annoying during debugging

So don't try it at home!


I have never logically used it, I have put it only as a working case study not to be used.

[Photon]

Originally Posted by Toni Wilen

I usually simply wait for line x and then wait until line is not x.

This is reliable, but the CPU would then do nothing but busy-wait for a whole scanline, i.e. 0.4% CPU time wasted.

EOF vs TOF

Waiting for line $138 = EOF is essentially the same as waiting for line $1a = TOF, except for the flyback of the beam. So if you poll for these raster lines and execute code, any Vblank interrupt will interrupt that code after a very short while.

So if code is executed after a raster busy wait in main, that relies on values set by the int, read them at EOF quickly before the int hits (and never re-read them later in the code), because they may be changed by the int mid-execution.

[ross]

Originally Posted by Photon

This is reliable, but the CPU would then do nothing but busy-wait for a whole scanline, i.e. 0.4% CPU time wasted.




Waiting for line $138 = EOF is the same as waiting for line $2a = TOF, there's just 1/3 of a scanline worth of cycles during the flyback of the beam. So if you poll for these raster lines and execute code, any Vblank interrupt will interrupt that code after a very short while.



So if code is executed after a raster busy wait in main, that relies on values set by the int, read them at EOF quickly before the int hits (and never re-read them later in the code), because they may be changed by the int mid-execution.

I apologize in advance because it may be that I did not understand exactly what you wrote.
But it seems you have made some confusion between vsync, vblank and VBI.
Excluding the vsync signals, which at the moment are not of interest to us as they are generated by the Amiga hardware (for a standard PAL or NTSC signal), we are interested in vblank and VBI.
Vblank because we have to exploit it to the maximum because nothing is put on video in that period, the VBI because it references us the position 0,0 of the internal video counters and the generation of a level 3 IRQ for the CPU.
The vblank is between lines 0 and $19. The first visible line in maximum overscan is the $1a.
The VBI is generated only once per frame at the beginning of line 0.
The copper execute little before the CPU because the IRQ response requires some machine cycles.

[Photon]

I've edited my post. I will measure the time in CPU instructions executed across the vblank, and then I'll know exactly. I guess it should correspond to the $1a scanlines, but the actual time it takes for the monitor vsync pulse should be ~576ms = 9 rasterlines.

I guess my main point is that if you have interrupts running that change values you rely on, results could vary depending on when the interrupt hits in your running main code. And that if you have interrupts or a BLTPRI=1 blit running during a VPOS check with beq, it could be skipped so that you get a stagger.

[Asman]

@ross - Thanks for pointing me that stupid bugs in HwWaitTopOfFrame (post #66). I corrected and checked. Now works correctly. Thanks