vblank

[MausBoy]

Batari,

 

I read your description of the vblank command in your blog, but I'm confused about how to implement it. Can you post a quick example of how it would work? Does it require an end statement, and where does it go? Inside the main program loop, before or after drawscreen, etc?

 

Also, what can expect to be able to fit in vblank? Is there a guess on how many lines, or suggestions on commands to definately leave out of it? Can I fit playercolor/player definition subroutine calls inside it? I really don't know the technical side of this, but I know that I'm getting flashing screens like crazy when I use debug cycles on a lot of projects, so i'm looking for ways to better balance what's going on.

 

Also, does that speed/size flag you can set effect how easy it is to run out of cycles?

Edited August 23, 2006 by MausBoy

[SeaGtGruff]

Batari,

 

I read your description of the vblank command in your blog, but I'm confused about how to implement it. Can you post a quick example of how it would work? Does it require an end statement, and where does it go? Inside the main program loop, before or after drawscreen, etc?

It looks like maybe it's supposed to be as simple as this:

 

  COLUBK = $44 : rem * set background to red
loop
  drawscreen
  goto loop

  vblank
  COLUBK = $94 : rem * set background to blue
  return

When the above code is compiled, the subroutine after the "vblank" keyword will be preceded with the label "vblank_bB_code", which is the name of the subroutine that bB runs for the user-written vblank routine. So that *should* work. But unfortunately, all labels after the "jsr vblank_bB_code" instruction end up being 3 bytes off from where DASM expects them to be, and I can't figure out how to prevent that.

 

MR

[+batari]

It looks like maybe it's supposed to be as simple as this:

...

That's correct. However, in a bankswitched game, vblank should be in the last bank, and you would use "return thisbank" to exit.

When the above code is compiled, the subroutine after the "vblank" keyword will be preceded with the label "vblank_bB_code", which is the name of the subroutine that bB runs for the user-written vblank routine. So that *should* work. But unfortunately, all labels after the "jsr vblank_bB_code" instruction end up being 3 bytes off from where DASM expects them to be, and I can't figure out how to prevent that.

Aha... I wonder if that is one reason why DASM sometimes spits out tons of bogus label mismatches but still assembles successfully?

 

If that's what you were talking about, I have been considering filtering the output of DASM to prevent those bogus label mismatches.

Also, what can expect to be able to fit in vblank? Is there a guess on how many lines, or suggestions on commands to definately leave out of it? Can I fit playercolor/player definition subroutine calls inside it? I really don't know the technical side of this, but I know that I'm getting flashing screens like crazy when I use debug cycles on a lot of projects, so i'm looking for ways to better balance what's going on.

I think vblank will give you maybe 10-12 scanlines, or roughly 800-1000 cycles. Maybe less depending on what objects you are using. Basically, your vblank routine is called automatically during every drawscreen. The code is run in the spare time between the display kernel setup routines and the display kernel itself.

 

I think that any command will work in vblank, but setting the x-positions of the sprites and the score will not take effect until the next drawscreen.

Also, does that speed/size flag you can set effect how easy it is to run out of cycles?

Right now, the speed/size flags don't change very much. Sooner or later I will figure out ways to make these more useful.

[SeaGtGruff]

Aha... I wonder if that is one reason why DASM sometimes spits out tons of bogus label mismatches but still assembles successfully?

These aren't bogus label mismatches, they're real label mismatches. The code I posted should set the background color to red, but then the vblank routine should set the background color to blue, so the screen should be blue. That's why I chose such a simple test-- so it would be obvious whether or not the vblank routine was being performed. What actually happens is that the "compiled" program is only slightly larger than 1K, because DASM aborts the assembly. If you try to run the .bin in Stella anyway, you get a black screen.

 

MR

[+batari]

Aha... I wonder if that is one reason why DASM sometimes spits out tons of bogus label mismatches but still assembles successfully?

These aren't bogus label mismatches, they're real label mismatches. The code I posted should set the background color to red, but then the vblank routine should set the background color to blue, so the screen should be blue. That's why I chose such a simple test-- so it would be obvious whether or not the vblank routine was being performed. What actually happens is that the "compiled" program is only slightly larger than 1K, because DASM aborts the assembly. If you try to run the .bin in Stella anyway, you get a black screen.

 

MR

Grrr... I see the problem - DASM 2.20.10 sees the label mismatches and thinks that the errors are unrecoverable (they are not!) If you use DASM 2.20.07, the label mismatches are correctly resolved in later passes, but still with a screen full of the bogus messages.

 

I've had other problems with stuff that doesn't assemble in 2.20.10 but does in 2.20.07. I think I will package the older version with the next release.

[SeaGtGruff]

Grrr... I see the problem - DASM 2.20.10 sees the label mismatches and thinks that the errors are unrecoverable (they are not!) If you use DASM 2.20.07, the label mismatches are correctly resolved in later passes, but still with a screen full of the bogus messages.

 

I've had other problems with stuff that doesn't assemble in 2.20.10 but does in 2.20.07. I think I will package the older version with the next release.

Okay, I'll try the older version of DASM. But yes, I think that's probably the source of many of the messages about label mismatches that occur with bB 0.99, because I see that there are a lot of places where you're using "ifconst" or "ifnconst" to determine whether or not to include a particular line of code, and that's messing with the label addresses in DASM. So the ultimate solution would appear to involve either finding a different way to handle those situations (which doesn't result in any label mismatches), or contact the DASM folks and report this as a bug that needs looking into.

 

MR