Interrupts during VDP access?

[matteus]

Should I be disabling the interrupts for every VDP call? If I don't what will happen?

I'm really a newbie when it comes to this stuff Does this include calls to the SPR engine also?

[Stef]

SGDK will handle some internals stuff during the V-Int and may access the VDP (to update the sprites for instance) so yes, if you access the VDP outside the V-Int callback then you really need to disable interrupts before accessing it (and restore them after) to avoid conflict accesses.

Imagine your code is doing VDP accesses, then V-Int happen during the VDP accesses, the SGDK internals works will completely mess the VDP state and your resuming VDP operations will be corrupted. That is why you have to disable interrupts during VDP access outside V-Int callback.
Generally speaking it's better to centralize all VDP accesses in the V-Int callback (as VDP accesses are faster during VBlank), if it's too complicated to do that then at least, protect your VDP accesses by disabling interrupts

[matteus]

This is my structure

Code: Select all

    
int main {    
    << DO INITIAL STUFF >>
    
    while(TRUE)
    {
     
     	<< DO STUFF >>

        VDP_waitVSync();
 
    }
    
}

[Stef]

Yeah, that is what I call the "main thread" or "main loop" code. In this part you should handle the game logic for the current/next frame depending how you see it and the waitVSync() call allow to synchronize the game speed. Normally in this "thread" you should not access the VDP directly but instead use the vint callback for that :

Code: Select all

  // init stuff
  ...
  SYS_setVIntCallback(vint);

  while(true)
  {
    VDP_waitVSync();
    // prepare next frame
    ...
    frameDone = TRUE;
  }
}

void vint()
{
  if (frameDone)
  {
    // do VDP stuff
    VDP_setTileMap(..);
    VDP_drawText(...);
    ...
    
    frameDone = FALSE;
  }
}

But sometime isolating the VDP stuff in the VInt handler can be overkilling / overcomplicated so you can just do in your main loop :

Code: Select all

  while(true)
  {
    VDP_waitVSync();
    // prepare next frame
    ...
    // disable ints
    SYS_disableInterrupts();
    // do VDP stuff
    VDP_drawText(..);
    // re-enable ints
    SYS_enableInterrupts();
    ...
    frameDone = TRUE;
  }

Oh and by the way, you can of course use the SPR_xxx methods in your main loop without disabling interrupts. SPR_xx methods take care of not accessing VDP immediately, all accesses are centralized in the internal SGDK VInt callback.

[matteus]

It all makes sense to me now! I could rewrite things to work like this but I think I'll leave it for now. If it looks like it's not going to run well on real hardware I'll move to using vint rather than switching off interrupts. I guess I'm lucky that my code never actively updates the screen during calculations and input anyway!

[matteus]

Is there much of a performance different between the two methods? I can understand this would probably be the case if I was continously updating the screen in a game with lots of movement and A.I?

[Stef]

Generally updating the screen during the active period is slow (because VDP accesses are very slow during active period).
It's why it's better to move all your VDP update code in the VInt callback and doing the game logic in the main loop

[matteus]

So for instance I have a function to type text. Do I need a function to allocate the letter and another to print the letter in vint? where would I control the text print speed? Vint?

Code: Select all

u16 writeOnScreenMessage(char * Message, u16 MessageRow) {
    u16 completeOnScreenMessage = FALSE;
    u16 static increment = 0;
    u16 static TextTimer = 0;
    char static character[1];
    if (TextTimer == 0) {
        u16 stringLength = strlen(Message) - 1;
        if (increment <= stringLength) {
            character[0] = Message[increment];
            SYS_disableInts();
            VDP_drawText(character, 2+increment, MessageRow);
            SYS_enableInts();
            strclr(character);
            TextTimer = TIMERSECONDS;
            increment++;
        } else {
            TextTimer = 0;
            increment = 0;
            completeOnScreenMessage = TRUE;
        }
    } else if (TextTimer > 0) {
        TextTimer--;
    }
    return completeOnScreenMessage;
}

[Stef]

Given the method you can keep it in the main loop (with V-Int protection). This is easier to handle the whole and here you don't need it to be blazing fast