ASM: Wait for Vertical Blank

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