VBLANK wait in C

[8bitsten]

Hi,

Is the below code OK? Or is there something wrong I do not see please?

Thanks
STeN

Code:

// Actual vertical and horizontal scan line
// High byte (08-15): vertical scanline
// Low byte  (00-07): horizontal scanline
// Note: We need only MSB
volatile UBYTE* REG_VHPOSR_MSB = (UBYTE *) 0xDFF006;

// PAL uses 320x256
// But it is better for games to use the NTSC resolution 320x200 (e.g. scan lines fits a byte)
// which most games of the era used
#define SCANLINE_FIRST_INDEX 0x2C  // (44)
#define SCANLINE_NTSC_LAST_INDEX (SCANLINE_FIRST_INDEX + 199)
#define SCANLINE_PAL_LAST_INDEX (SCANLINE_FIRST_INDEX + 255)

void waitVBLANK()
{
    while ( *REG_VHPOSR_MSB != (UBYTE)( SCANLINE_NTSC_LAST_INDEX + 1 ) )
    {
    }
}

[a/b]

Looks OK to me, as long as you don't change the scanline values drastically. If it compiles to cmp.b #$f4,$dff006, bne.b <back_to_cmp> then it's OK.

[phx]

Although the comparison with

SCANLINE_PAL_LAST_INDEX

wouldn't work so well.

[Thomas Richter]

The easiest way to wait for the vertical blank is to call WaitTOF() of the graphics.library. Unlike your approach it does not even burn CPU cycles. Essentially, it enqueues your task into a wait list which the graphics.library will trigger in its vertical blank interrupt processing, and the CPU is free to do a lot more useful things than idling.

[paraj]

One downside of WaitTOF is that top of frame is later than end of the displayed area (which it looks like OP is actually going for). Then there's WaitBOVP of course, but that burns cycles (or at at least the docs says it does), and also assumes that the game is system friendly. But yes, definitely WaitTOF is the place to go unless there are other considerations.

N.B. If you're using VBCC it (currently at least) generates better code if you use:

#define REG_VHPOSR_MSB ((volatile UBYTE*)0xDFF006)

rather than a global pointer (it doesn't seem to be able to hoist the load of the pointer value outside the loop otherwise).

And note that any interrupts triggering around that line can cause you to miss the wait and have to wait one (or more) extra frames. I find that's it's usually more robust to use the copper to set a bit in INTREQ (doesn't have to cause an actual interrupt) and use that as a "bottom of frame" marker instead.

[Thomas Richter]

WaitTOF() waits for the vertical blank - and that was really the requirements of the original poster as far as I got it. That is, it is triggered by the vertical blank interrupt. WaitBOVP() burns cycles indeed, and it is not recommendable.

Just note that both calls, and the code of the OP would operate under the constraints of the system in total. That is, if there is any other task of the system that requires CPU time, or an interrupt of higher priority, then the CPU will not reach your code until some lower part of the screen.

If the screen is an RTG screen, WaitTOF() may be - depending on hardware - in perfect relation to the actual screen refresh, or in no relation to it whatsoever. The OP code would be in the second class (no relation whatsoever).

Thus, the real question is: What is the reason to wait on the vertical blank? To synchronize some on screen activity to avoid tearing? If so. double buffering and the intuition double-buffering framework ensures that always, also on graphics cards. If, however, the desire is robust timing to ensure consistent game speed, the timer.device is a much better tool for that as it operates independent of the screen mode, and the graphics hardware.

[8bitsten]

Wow!!

Thanks for the answers. I learned so many new things. Literally EVERY answer to my question was helpful. This is a great community and great forum.

STeN