Scanlines and Colors

[Hornpipe2]

Let me make sure I have this right.

 

NTSC: 262 scanlines (3 vsync, 37 vblank, 192 picture, 30 overscan)

PAL60: 262 scanlines (3 vsync, 37 vblank, 192 picture, 30 overscan - same as NTSC)

PAL50: 312 scanlines (3 vsync, 37 vblank, 242 picture, 30 overscan)

 

Color chart: http://www.qotile.net/minidig/docs/tia_color.html

 

So by careful selection of colors, it would be possible to make an NTSC/PAL60-compatible cart with no other changes?

 

Also, is there an easy way to check if I have the 'right' number of vblank, overscan and picture lines? I get my linecounts from Stella's debugger and I use VERTICAL_SYNC macro so I assume that's right, but I don't know for certain if I'm turning off and on the vblank at the right times. What rules do you follow?

[SeaGtGruff]

Let me make sure I have this right.

 

NTSC: 262 scanlines (3 vsync, 37 vblank, 192 picture, 30 overscan)

PAL60: 262 scanlines (3 vsync, 37 vblank, 192 picture, 30 overscan - same as NTSC)

PAL50: 312 scanlines (3 vsync, 37 vblank, 242 picture, 30 overscan)

 

Color chart: http://www.qotile.net/minidig/docs/tia_color.html

Yes, but not necessarily.

 

The total lines is somewhat flexible, although PAL needs to have an even number, and it's always best to just draw the exact ideal number of lines.

 

The vsync lines are much less flexible, I believe you need at least 3 for NTSC, and at least 2.5 for PAL (usually rounded up to 3)-- I'm not sure if you can get away with just 2, and you probably wouldn't want to go any higher than 4, so again it's best to just stick with no more or less than 3.

 

The overscan (read "vertical front porch"), the vblank (read "vertical back porch"), and the picture (read "active video") are much more flexible. If you want to get an ideal vertically-centered picture of 192 lines, then I think the numbers might should be 28 overscan (VFP), 3 vsync, 39 vblank (VBP), and 192 picture-- but the "Stella Programmer's Guide" uses the numbers 30-3-37-192, so that's what a lot of people use.

 

If you increase or decrease the picture height, then you can increase or descrease the VFP and/or VBP as desired-- plus, you don't have to make the picture vertically-centered.

 

And for 312-line PAL (or "PAL/50"), you could draw a 192-line picture with bigger porches if you want.

 

So the numbers are a bit flexible to some extent, but you've got it.

 

So by careful selection of colors, it would be possible to make an NTSC/PAL60-compatible cart with no other changes?

Yes, I think so-- possibly a few very minor changes in timing or sound frequencies if you want to be precise, due to the difference in the clock rates-- but you could just ignore the differences.

 

Also, is there an easy way to check if I have the 'right' number of vblank, overscan and picture lines? I get my linecounts from Stella's debugger and I use VERTICAL_SYNC macro so I assume that's right, but I don't know for certain if I'm turning off and on the vblank at the right times. What rules do you follow?

If everything adds up to 262 or 312, and if the entire picture is visible on the screen, then I'd say you've got the right number of lines.

 

Michael

[Cybergoth]

I get my linecounts from Stella's debugger and I use VERTICAL_SYNC macro so I assume that's right, but I don't know for certain if I'm turning off and on the vblank at the right times. What rules do you follow?

 

I usually just blank the screen outside the "picture" as you call it, i.e. enabling it is first thing I do when the picture is drawn and disabling it is the last thing before actually drawing the picture.

 

It just turns the beam on and off, some tricks even do it in the middle of a scanline to hide something underneath.

 

What I'm not sure about is wether it has to be enabled during VSYNC. I think TJ once tracked something like that down as the source of screen rolling, when his splatform game didn't write to the VBLANK register at all for the 1K contest version.

[Nukey Shay]

Regarding palettes...it's easy enough to store both of them in most games (classic games did this already regarding color/B&W switching). Since it's extremely unlikely that somebody would opt to use a B&W television, just throw the PAL color table in there instead. Having the program detect specific ram values when powering up from a 7800 console solves the hardware issue of using the switch. That would give you NTSC and PAL60 without needing to confine yourself to values that produce similar hues.

 

However, it's true that this solution won't work for games that require cycle-specific timing and loading static values (unless the routine can be edited to allow it).

[DEBRO]

What I'm not sure about is wether it has to be enabled during VSYNC. I think TJ once tracked something like that down as the source of screen rolling, when his splatform game didn't write to the VBLANK register at all for the 1K contest version.

Yes, you should disable the TIA (i.e. enable VBLANK) before doing VSYNC. This was the source of the problem with Splatform. Well...that combined with the 9 byte VERTICAL_SYNC macro.