Questions about VBLANK and Stella game properties

[TROGDOR]

Hi all,

 

I'm doing work on The Battle of Midway again. One of the things I'm trying to fix is an unexpected HMOVE bar in the upper left corner of the screen. I attempted to debug this by setting a break at the beginning of my kernel, immediately after the timed VBLANK wait completes. I was surprised to find that it returned on scanline 36. There should be 3 scanlines for vertical sync, then 37 lines of vertical blank. So a WSYNC right after VBLANK ends should start the screen on scanline 40, correct? If my VBLANK is ending at scanline 36, I can only guess that my TIM64 setting isn't long enough. I'm using 44, which I grabbed from an Atari programming tutorial 4 years ago. It's set after the initial 3 WSYNCs for vertical sync.

 

My other question is what display property values should be used in Stella for a standard NTSC cart? The default values seem strange. YStart is 34. Shouldn't that be 40 for NTSC? And the Height is 210. Shouldn't that be 192 for NTSC? An explanation of these values would be greatly appreciated.

 

TIA,

TROGDOR

Edited August 19, 2007 by TROGDOR

[+stephena]

My other question is what display property values should be used in Stella for a standard NTSC cart? The default values seem strange. YStart is 34. Shouldn't that be 40 for NTSC? And the Height is 210. Shouldn't that be 192 for NTSC? An explanation of these values would be greatly appreciated.

 

TIA,

TROGDOR

Those values were picked, I think, through experimentation on what ones worked best for a large number of ROMs. I agree that they're somewhat arbitrary, and future versions of Stella with an updated TIA infrastructure will be more accurate (and will be able to determine these numbers automatically). So to answer your question, I have no explanation

[supercat]

My other question is what display property values should be used in Stella for a standard NTSC cart? The default values seem strange. YStart is 34. Shouldn't that be 40 for NTSC? And the Height is 210. Shouldn't that be 192 for NTSC? An explanation of these values would be greatly appreciated.

 

Televisions are virtually guaranteed to display scan lines 40-232 (counting after the end of VSYNC, I think), while not displaying anything before line 20 or after line 259. It is proper--and often a good thing--for games to display content outside of the 40-232 range provided that they do not rely upon the player being able to see it. For example, if a player character is standing on the "ground", it's aesthetically nicer to have the ground extend all the way to the bottom of the screen than to have it stop short. It may well be that one 19" television set shows 1.5 inches of "ground" while another only shows half an inch, but that doesn't really matter. Having 1.5" of ground on the first set is nicer than having an inch of ground and 0.5" of black. Showing color instead of black on the inch of image that's chopped off on the second set won't hurt anything.

 

From a programming standpoint, one should make sure that VBLANK is enabled at least two scan lines before VSYNC and remains enabled for at least 18 scan lines after, and that anything 'important' is within the range of scan lines that's guaranteed to appear.

 

BTW, the Commodore 64 relied upon televisions being able to show 200 scan lines, and there don't seem to have been many problems with that.

[TROGDOR]

Thanks for the explanation supercat. That makes sense.

 

I'll stop worrying about the extra black line in The Battle of Midway. This appears to be a display bug in Stella. If I set it to start at the 34th scanline, it shows 2 full black scanlines at the top of the screen, which is expected. The first blue line for the sky is complete across the entire scanline, and looks fine. But, if I set Stella to start at the 36th scanline, it doesn't start with a smooth blue line like I'd expect. Instead it has 8 pixels of black (similar to an HMOVE comb), followed by blue sky. I double checked this in Z26, and the black line wasn't there.

[SeaGtGruff]

I'll stop worrying about the extra black line in The Battle of Midway. This appears to be a display bug in Stella. If I set it to start at the 34th scanline, it shows 2 full black scanlines at the top of the screen, which is expected. The first blue line for the sky is complete across the entire scanline, and looks fine. But, if I set Stella to start at the 36th scanline, it doesn't start with a smooth blue line like I'd expect. Instead it has 8 pixels of black (similar to an HMOVE comb), followed by blue sky. I double checked this in Z26, and the black line wasn't there.

Yes, it's a display bug in Stella. The bug was reported in another thread, and will hopefully go away when the TIA emulation is rewritten.

 

For the record (and this is based on my experiments, so it might not be entirely correct), the phantom HMOVE bar seems to show up on the first displayed line whenever you do an HMOVE on any line that's outside of the display window, regardless of whether it's "below" the last displayed line or "above" the first displayed line. It's as though Stella is storing the HMOVE bar in its line display buffer when it does the HMOVE command, but since the line on which the HMOVE actually occurs is outside of the display window, the HMOVE bar is "delayed" until Stella outputs the next displayed line. If the first line being displayed happens to be a blanked line, then the HMOVE bar is essentially invisible because it doesn't show up against the blanking, but it's still there. If this is indeed what's happening, then a simple fix might be to clear the line display buffer each time a WSYNC occurs, or the equivalent (i.e., whenever color clock 228 is reached). Note that I don't know how Stella draws the screen, so I'm just guessing about it using a "line display buffer."

 

Michael

[SeaGtGruff]

You asked about the line numbering in Stella. On a 262-line display, Stella numbers the lines from 0 to 262, where line 262 is also line 0.

 

Specifically, Stella considers the frame as beginning on the first cycle *after* VSYNC is turned off, regardless of where the beam happens to be on that line when VSYNC is turned off. So the line where that cycle is gets numbered as "line 262" up through the completion of the instruction to turn off VSYNC, and then gets numbered as "line 0" for the remainder of the line, as follows:

 

| C00 | some code | STA VSYNC | more code | C75 |
| L262|262|262|...|262|262|262|262|000|...|L000 |

 

Here, "C00" refers to cycle 0, "C75" is cycle 75, and "L262" and "L000" are line numbers.

 

Note that this can look a little weird depending on where the beam is when VSYNC is turned off-- in particular, if you've put the instruction to turn off VSYNC near the end of a line.

 

Anyway, if you turn off VSYNC right after a WSYNC, and then draw 37 blank lines before starting the active (non-blanked) portion of your kernel, then Stella will number those 37 blank lines as lines 0 through 36, and your first active line will be line 37. This assumes you're drawing 37 *full* blank lines before turning off VBLANK. In other words, if you're setting TIM64T and then using an INTIM loop to wait until it's time to turn off VBLANK, but you forget to do a WSYNC after the INTIM loop ends, then you'll probably be turning off VBLANK somewhere in the middle of line *36*.

 

Michael

[The Electric Monk]

I'll stop worrying about the extra black line in The Battle of Midway. This appears to be a display bug in Stella. If I set it to start at the 34th scanline, it shows 2 full black scanlines at the top of the screen, which is expected. The first blue line for the sky is complete across the entire scanline, and looks fine. But, if I set Stella to start at the 36th scanline, it doesn't start with a smooth blue line like I'd expect. Instead it has 8 pixels of black (similar to an HMOVE comb), followed by blue sky. I double checked this in Z26, and the black line wasn't there.

Yes, it's a display bug in Stella. The bug was reported in another thread, and will hopefully go away when the TIA emulation is rewritten.

 

Wow, that's good to know. That had been driving me nuts! I knew it was an HMOVE 'thing', because I replaced the STA HMOVE instruction with a STA to another, unused, register and the black line went away. I thought perhaps I had a timing problem or was setting up the horizontal move wrong, but now I won't bother posting my code here.

 

Thanks for pointing that out.

 

Cheers,

Jason