ASM: Wait for Vertical Blank

[Asman]

I'm looking for best/accurate wait vb routine. Any examples are welcome

[StingRay]

I do it like this:

.loop	move.l	$dff004,d0
	and.l	#$1ff00,d0
	cmp.l	#303<<8,d0
	bne.b	.loop

[Doc Mindie]

what does the << in the cmp.l line do?

[copperkid]

#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

    
    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)

[Toni Wilen]

Originally Posted by StingRay

I do it like this:

.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.

[StingRay]

Originally Posted by copperkid

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.

Originally Posted by copperkid

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

    
    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.

[Asman]

I find

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.

[Leffmann]

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.

WaitLine  macro
.\@       move.l    vposr(a6), d0
          lsr.l     #1, d0
          lsr.w     #7, d0
          cmp.w     \1, d0
          bne       .\@
          endm

[StingRay]

Originally Posted by Leffmann

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:

.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.

[Leffmann]

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

[StingRay]

Originally Posted by Leffmann

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.

[Asman]

@Leffmann, StingRay - thanks a lot.

Is there any difference between

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

and

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 ?

[pmc]

@ 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.

[Toni Wilen]

Originally Posted by Asman

@Leffmann, StingRay - thanks a lot.

Is there any difference between

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

and

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 )

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)

[Wepl]

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.

[Toni Wilen]

Originally Posted by Wepl

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.

[Wepl]

Originally Posted by Toni Wilen

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)

Originally Posted by Toni Wilen

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]

Originally Posted by StingRay

I do it like this:

.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)?

[Toni Wilen]

Originally Posted by Wepl

is it guaranteed that line 303 is reached on every display mode (PAL/NTSC)?

No. NTSC has 262/263 lines.

[StingRay]

Originally Posted by Wepl

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.

Originally Posted by Wepl

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.

[Asman]

Originally Posted by StingRay

Maybe a better way would be to set a flag in the VBI and poll that flag in the mainloop?

As far as I remember some games uses this technique ( For example unfinished polish game Robbo, http://korin.ppa.pl/ ). Rare example of using VERTB as main loop is GordianTomb ( all things are done in VERTB and main loop only drawscreen as I remember ).

[StingRay]

Originally Posted by Asman

Rare example of using VERTB as main loop is GordianTomb ( all things are done in VERTB and main loop only drawscreen as I remember ).

Actually it is not that rare, a lot of demos from "the good old days" (i.e. 50FPS effects or die! ;D) do everything in the VBI and the only thing they do outside the VBI is checking left mouse button.

[Photon]

I execute "stuff to happen at Vblank" with a Vblank interrupt Or use a lib function. If you have a copper running you can write to INTREQ and poll a bit. If you have random ints running you can have a bhs-wait for a rasterline and a bhi-wait to make sure you leave it in case you do nothing that frame.

The Amiga is versatile

[pmc]

Originally Posted by StingRay

Actually it is not that rare, a lot of demos from "the good old days" (i.e. 50FPS effects or die! ;D) do everything in the VBI and the only thing they do outside the VBI is checking left mouse button.

Just like all my stuff does.

My good old days are today! \o/

[TheDarkCoder]

Originally Posted by Toni Wilen

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 )



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)

I don't remember any Official docs saying that byte read/writes are illegal. Are you sure?

I do remember that HRM says its legal to read/write a pair of registers with
a long access, and that since many (or all?) registers are either read-only or write-only, it is illegal to access a register with a CPU instruction that perform both a read and a write on its operand like CLR on 68000, or BSET/BCLR. But BTST should only read its operand, I think.

[Toni Wilen]

Originally Posted by TheDarkCoder

I don't remember any Official docs saying that byte read/writes are illegal. Are you sure?

I said "technically" illegal, as "illegal" as word or long CIA accesses and because byte writes can have different results on different Amigas:

A500: 0x12 byte write is written as 0x1212 but in some accelerators it can be 0x0012 or even 0x<garbage byte>12 or something similar. (afaik whdload AUDxVOL byte write fixes on 68060 are needed because of above "feature")

(getting a bit offtopic, sorry)

[Asman]

Just for clarification. About byte read from custom register ($dff005). If I understand correctly below code

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

can be changed to (more legal)

wait_vb_2
	moveq	#1,d0
	lea	(_custom+vposr),a0
.1	move.w	(a0),d1
	and.w	d0,d1
	bne	.1
.2	move.w	(a0),d1
	and.w	d0,d1
	beq	.2
	rts

Any comments are welcome especially If I am wrong.

[mc6809e]

Originally Posted by Asman

Any comments are welcome especially If I am wrong.

A bit off-topic, but I'd give yourself some more processing time by waiting for the last displayable scanline instead of VB. The best place to begin running code for the next frame if single-buffering is often just after the last displayable line, especially if some memory needs to be cleared. You get almost double the normal memory bandwidth when there's no other DMA going on. Pairing MOVEM with a blitter memory clear is especially fast. A blit using channels BCD (a rectangular bitmap move, for example) runs nicely in parallel with the CPU during the overscan areas, even with blitter-nasty turned on.

If you're double buffering, beginning your processing at the first line is often best, especially if you're calling anything in ROM.

[Wepl]

Originally Posted by Asman

Just for clarification. About byte read from custom register ($dff005). If I understand correctly below code

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

can be changed to (more legal)

wait_vb_2
	moveq	#1,d0
	lea	(_custom+vposr),a0
.1	move.w	(a0),d1
	and.w	d0,d1
	bne	.1
.2	move.w	(a0),d1
	and.w	d0,d1
	beq	.2
	rts

Any comments are welcome especially If I am wrong.

ok, but what should be the advantage of this?

[dalton]

I usually set a flag in the vblank isr, like this:

	bset.b	#0,flags(pc)

and then poll it inside the main loop, like this:

.wait	bclr.b	#0,flags(pc)
	beq.b	.wait

It's nice because I know that the main loop will not continue until after vblank isr is finished (maybe that's guaranteed anyway, but I'm not sure about that), and also the wait-code is guaranteed to finish only once per vblank because it clears the flag in conjunction with the test.

[phx]

Originally Posted by dalton

    bset.b    #0,flags(pc)

Your approach is recommendable, although the PC-relative addressing mode is not allowed here.

In Sqrxz I am incrementing a frame counter during a copper interrupt, caused at the bottom of the display. The rendering routine can then compare its frame counter with the hardware frame counter and decide to either drop the frame, when the hw-counter is higher, or wait until both are equal again.

[StingRay]

Originally Posted by phx

Your approach is recommendable

The disadvantage is that you need a level 3 interrupt which is not always what you want.

[Thorham]

Why not do it properly and use the VBL interrupt instead of doing it like they do it on the peecee? On the peecee polling is necessary, on the Amiga it's not

[StingRay]

It can be done "properly" without a VBL interrupt too! And there are situations where you just don't want any interrupts at all.

[Thorham]

Originally Posted by StingRay

It can be done "properly" without a VBL interrupt too!

Of course, but it's peecee like and therefore uncool

Originally Posted by StingRay

And there are situations where you just don't want any interrupts at all.

Interesting, which situations are those (serious question )?

[StingRay]

Originally Posted by Thorham

Of course, but it's peecee like and therefore uncool

So you call more than 50% of the old and classic demos "uncool"?

Originally Posted by Thorham

Interesting, which situations are those (serious question )?

Interrupt processing needs CPU time, need I say more?

[Thorham]

Originally Posted by StingRay

So you call more than 50% of the old and classic demos "uncool"?

Not saying that, I'm saying that peecee style VBL handling is uncool.

Originally Posted by StingRay

Interrupt processing needs CPU time, need I say more?

Does it take up so much time you'd use polling? That sucks

Maybe I'm missing the point

[mc6809e]

Originally Posted by Thorham

Not saying that, I'm saying that peecee style VBL handling is uncool.


Does it take up so much time you'd use polling? That sucks

Maybe I'm missing the point

Autovectored interrupts on the 68000 have the annoying property that the 68000 must sync with an internally generated E-clock running at CLK/10 during interrupt handling. This can add up to 18 cycles on top of the time needed to push state onto the stack -- up to 44 cycles total.

And then you have to worry about the time it takes for the current instruction to complete before interrupt handling can even begin. A DIVU can delay interrupt handling by 100+cycles. This can be helped by executing a STOP and waiting for an interrupt, but the E-clock still complicates things. There are even situations where an interrupt handler must be padded with a variable number of instructions based on the predicted phase of the E-clock so as to perfectly time 68000 writes to chip registers. This might happen when reprogramming the sprite registers with a MOVEM in the middle of a scanline.

Polling is quick and simple.

[Toni Wilen]

Originally Posted by mc6809e

Autovectored interrupts on the 68000 have the annoying property that the 68000 must sync with an internally generated E-clock running at CLK/10 during interrupt handling.

Where is this documented? Never heard or noticed when I was checking interrupt cycle usage.

[StingRay]

Originally Posted by Thorham

Does it take up so much time you'd use polling? That sucks

Maybe I'm missing the point

Well, you need 2x movem (if you do more than just just testing the VBL flag in the interrupt at least) plus the rte which take up a fair amount of processor time. It can make quite a difference not to use interrupts in time critical situations.