ASM: Wait for Vertical Blank
 

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

I do it like this:

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

#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 :D


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

This is 100% acceptable and reliable :)

Worst you can do is to poll INTREQR VBLANK bit when VBLANK interrupt is enabled. Very unreliable.

Bits 8-16 rather (VPOS). See VPOSR and VHPOSR documentation and you'll understand how and why it works. :)


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.

I find

but I'm not sure if above code is 100% acceptable and reliable. :)

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.

Which can be easily fixed:
And the likelihood that a routine needs less than 1 rasterline is not very high anyway.

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 :)

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.

@Leffmann, StingRay - thanks a lot.

Is there any difference between

and

?

And second ( stupid :) ) question. Is legal to do btst on odd address _custom+vposr+1 ?

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

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 :D)

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

yes, that may happen (if the code is not well synchronized and does not work properly on 68000-68060)

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 :)

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

No. NTSC has 262/263 lines.

I've been using this approach in countless demos which had CIA/keyboard interrupts enabled and never experienced any problem.

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.