Standard UI for PAL/NTSC Switching

[Christopher Tumber]

I'd like to start integrating NTSC/PAL switching support directly in my games (as opposed to two separate binaries which IMO is a bigger PITA). Specifically, the ability to switch between

• 262 and 312 scanlines (60Hz vs 50Hz)
• NTSC vs PAL colour palettes

 

The most obvious approaches would be either:

• A menu item (could be problematic if screen is rolling due to incorrect scanlines)
• Using the consoles switches (Difficulty, Colour/B&W, Game Select, Game Reset)

 

Additionally, about 20 years ago Eckhard Stolberg told me:

>There is no need for this. Most PAL TVs can handle 60 Hz VCS output
>quite nicely. The picture will be vertically centered with black
>bars above and below. It's only important that you do 3 uninterrupted
>scanlines of VSYNC. And it would be better, if you'd turn on VBLANK
>after the last line of display to make sure that the black bars really
>are black.
 

So it seems like offering scanlines and colour palette selection independently might be a good idea.

 

Before I go and do something off the wall - Has there been any standard established here? 

 

 

[+Andrew Davie]

I've done a fair few variations on this.  For example Boudler Dash (original) uses the left difficulty switch to toggle between NTSC/PAL.  This consistently confuses people because they don't realise that the switch exists, so depending on the switch the game will boot in the wrong mode. In my view that's the wrong way to do things, although it's "cheap" to implement.  My current preference is to offer on-screen indications via a menu.
The new version of Boulder Dash (experimental/not released) does console auto-detect, which I think all CDFJ/ARM games should try to achieve. The detection code is robust and freely available for use.  In this situation, game can boot to the best default for the detected console type (PAL/NTSC/SECAM).  I default PAL to 60Hz (I call this PAL60) mostly because it gives a better display.  I allow menu-choices to switch to other modes (SECAM/NTSC/PAL/PAL60) and include AUTO as the default mode which does the aforementioned auto-detect.
So, TL;DR - at the very least provide onscreen indication of the mode and how to change it. Otherwise, people simply assume the shitty colours/display are normal and never realise you need to flick a switch to get to their native format.

As to the issue with incorrect rolling/scanlines, always boot into a 60Hz mode - nearly all TVs will display a non-rolling picture.  One possible option would be to switch between PAL/NTSC/SECAM colours with "press button when display looks good" type of thing - and then use that mode for the rest of the game.

[Christopher Tumber]

Thanks!

So for anyone reading this later, my approach will be:

 

• Supporting 60HZ (262 scanlines one) only (good side effect of eliminating the supplemental decision of whether or not to adjust game timing)
• Adding a config/settings menus item to select between NTSC, PAL and SECAM (because why not?) colours

 

From a practical standpoint, this means that something like:

 

LDA #$24	;2 cycles - Red
STA COLUPF	;3 cycles - Set playfield to red

 

Becomes:

 

LDA PlayfiedlColour		;3 cycles - PlayfieldColur is a RAM variable
STA COLUPF			;3 cycles - Set playfield to red

 

Or if RAM is at a premium (or just lots of different colour elements):

 

LDX ColourSetting		;3 cycles - ColourSetting is a RAM variable 0=NTSC 1=PAL 3=SECAM
LDA PlayfiedlColour,x		;4 cycles - PlayfieldColur is a ROM table
STA COLUPF			;3 cycles - Set playfield to red

 

Or possibly more complex logic and tables or temporary buffers - especially if cycle timing is a priority (colour changes during scanlines)

 

 

[Dionoid]

On 2/25/2023 at 4:15 AM, Christopher Tumber said:

I'd like to start integrating NTSC/PAL switching support directly in my games (as opposed to two separate binaries which IMO is a bigger PITA).

What makes two separate binaries a PITA? I realize that it’s more convenient to just have a single, unified binary when burning the EPROMs, but as a European retro gamer, I personally prefer PAL versions of homebrew cartridges over those which are auto-detecting or menu-switchable PAL/NTSC. To me, owning a PAL-specific version of a game adds to the nostalgia. And even cooler if the top label of the cartridge shows the letter ‘P’, like the PAL versions of those original Atari 2600 games back in the day.

Edited March 1 by Dionoid

[+Gemintronic]

51 minutes ago, Dionoid said:

What makes two separate binaries a PITA? I realize that it’s more convenient to just have a single, unified binary when burning the EPROMs, but as a European retro gamer, I personally prefer PAL versions of homebrew cartridges over those which are auto-detecting or menu-switchable PAL/NTSC. To me, owning a PAL-specific version of a game adds to the nostalgia. And even cooler if the top label of the cartridge shows the letter ‘P’, like the PAL versions of those original Atari 2600 games back in the day.

 

For those who end up self publishing or work with people who make small runs this is more expensive and harder to keep track of. 

[+splendidnut]

14 minutes ago, Gemintronic said:

For those who end up self publishing or work with people who make small runs this is more expensive and harder to keep track of. 

Could you elaborate on that a bit more?  I'm curious about the details.

[+Gemintronic]

2 minutes ago, splendidnut said:

Could you elaborate on that a bit more?  I'm curious about the details.

 

Some can't go as far as ordering bare boards and soldering chips.  So, you need to order in batches from people who can.  Since bills and emergencies take priority this can be a burdensome investment.  Breaking even is an accomplishment and that can take time (or not happen at all.)

 

If you can split a run into both NTSC and PAL now you are trusting both to sell through.  And trusting international mail to go easy.  ..and trusting yourself not to accidentally mail a PAL customer NTSC.

[+splendidnut]

Ah, you're thinking about the general "pain of doing business" issues of selling multiple variants of the same product... in which not having to worry about the PAL vs NTSC issue would help alleviate.  I understand where you're coming from with that now.

 

I was thinking more from the software side.  With the projects that I've worked on, it would be more of a PITA to create a single binary to handle both PAL and NTSC.

[+Gemintronic]

I've been hoping someone would crack the code for detecting TV type on bog standard hardware.  Most people are OK with PAL60 and I'm OK with storing tables with NTSC and PAL color values.

[+Andrew Davie]

1 hour ago, Gemintronic said:

I've been hoping someone would crack the code for detecting TV type on bog standard hardware.  Most people are OK with PAL60 and I'm OK with storing tables with NTSC and PAL color values.

"please choose the green square to start playing" would work. Relies on a bit of trust, and non-colourblindness.

[+Gemintronic]

12 hours ago, Andrew Davie said:

"please choose the green square to start playing" would work. Relies on a bit of trust, and non-colourblindness.

 

This is the best I could come up with that satisfies NTSC/PAL60 in both color and black/white.  The correct TV type will show up in bold.  Hopefully someone else with better color science knowledge than me can improve upon it.

 

NTSCPAL60BW.zip

 

[+SpiceWare]

13 hours ago, Andrew Davie said:

"please choose the green square to start playing" would work. Relies on a bit of trust, and non-colourblindness.

 

Hmm, "any white options?"

• $EF for white YES if PAL
• $48 for red NO for NTSC

Could even support SECAM:

• $ED for white YES if PAL
• $7F for white YES if SECAM
• $48 for red NO if NTSC