Atari NTSC vs PAL vs SECAM

The console is what determines the colors that can be displayed. In looking at the TIA Color Chart, it becomes readily apparent that the colors on each system are different. If a game displays something using color $68, it gets the following color when displayed on the television:

As such, a cartridge needs to know what system it will be used on so it can select the correct color numbers. If you want to draw a green tree, an NTSC cartridge could use $C2, a PAL cartridge could use $52 while a SECAM cartrdige could use $x8(x could be any hexadecimal digit, 0 thru F).

If a cartridge is used on a system it was not designed for, the colors will appear incorrect. I used Stella, an Atari Emulator, to create the following screenshots of what the NTSC and the PAL versions of my game, Medieval Mayhem, would look like when plugged into different consoles.

	NTSC Cartridge	PAL Cartridge
NTSC Console
PAL Console
SECAM Console

There is a TV TYPE switch on the Atari that lets the user pick between a Color or a Black & White TV. The switch by itself does nothing, the game program must read the switch position and selected different colors based on the value. A lot of later games ignore the switch, or use it for something else like Engine Control in Space Shuttle and the pause switch in Lady Bug. Medieval Mayhem ignores the switch as there is insufficient CPU time left over for selecting different colors.

The other issue we are concerned about is TV standards differ in size and update frequency.

• NTSC - 525 interlaced scanlines, 60 frames per second¹
• PAL - 625 interlaced scanlines, 50 frames per second
• SECAM - 625 interlaced scanlines, 50 frames per second

Because of the way the Atari is designed, the cartridge, not the console, determines the number of scanlines sent to the TV. The Atari sends a progressive scan signal, so the scanline counts are half the interlace count. Cartridges typically use 262 for NTSC and 312 for PAL/SECAM.

Not all TVs can handle scan line counts other than those close to what it was designed for. A PAL cartridge will typically cause an NTSC display to roll, and an NTSC cartridge may cause the same when used on a PAL display. Some displays are more forgiving and may show a stable picture.

When a game is converted from NTSC to PAL/SECAM, the frames per second can impact the way the game plays. If the game is converted with no regard to the different frame rates, the PAL/SECAM version will be slower. For example - if a player is moved 1 pixel per frame, in 1 second it will have traveled 60 pixels on NTSC but only 50 pixels on PAL/SECAM. This is quite a bit slower and would make the PAL/SECAM version of a game easier to play. Conversely, a game converted from PAL/SECAM to NTSC would result in the player moving faster, making the game more difficult.

For Medieval Mayhem I used what's known as fractional(or subpixel) positioning where different speed tables² are used to compensated for the different frame rates. By doing this, Medieval Mayhem will play at the same speed on all 3 systems. If you look in the Source Code, you'll find sections that look like this:

 IF COMPILE_VERSION = NTSC
 ...
        .byte #<  634; speed: 3.5 direction: 28
        .byte #<  742; speed: 3.5 direction: 29
        .byte #<  826; speed: 3.5 direction: 30
        .byte #<  878; speed: 3.5 direction: 31
 ELSE 
 ; PAL speed/direction tables 
 ...
        .byte #<  760; speed: 3.5 direction: 28
        .byte #<  890; speed: 3.5 direction: 29
        .byte #<  991; speed: 3.5 direction: 30
        .byte #< 1054; speed: 3.5 direction: 31
ENDIF         

• NTSC = 634 / 256 * 60 = 149 pixels per second
• PAL = 760 / 256 * 50 = 148 pixels per second

¹ Technically it is 59.94 fields/29.97 frames per second, but that's beyond the topic of this article. You can find more information about this by reading the WIKI entries on NTSC, PAL and SECAM.

² I ran out of time and did not make a PAL/SECAM version of the Dragon Animation tables, so the dragon flies slower on those systems.

© 2007 Darrell Spice Jr.