Were the classic game consoles *technically* able to play both NTSC and PAL games, if ignoring artificial region lock-in?

Question

I'm not asking if they were region-free; I know they weren't generally.

I'm asking if, given an NTSC-supporting PAL TV, an NTSC game cartridge, and a PAL NES/SNES/N64/whatever, and also given some sort of "workaround"/hack to bypass the region locking, was the PAL console technically able to run the NTSC game just as well as an NTSC console would, and was an NTSC console perfectly able to run PAL games in the same manner?

In other words: did they have the same exact hardware (besides the outer shell/chassis, and branding) with just one small bit deliberately "crippled" per region? Or were they fundamentally different on the hardware level with custom NTSC/PAL signal output chips which were simply not present for the other TV format?

Answer 1

They were different.

You probably already know that NTSC is 60 Hz and PAL is 50 Hz. The video generation hardware was much more 'bare metal' than today (the NES color palette implementation was so bare metal that one of the colors you could select, referred to as 'blacker than black', could mess up some TVs due to the way the NES simply fed the color bits directly into voltage regulation chips to generate a signal) and so instead of being able to run with any monitor the GPU was clocked to match the output which in turn meant the CPU was usually clocked to match the GPU in some way. On a hardware level this means a PAL console contained at a minimum a different timing crystal than the one in the NTSC version.

Using the NES again the NTSC GPU is 5.37 MHz while the PAL version ran at 5.32 MHz so that they would correctly sync with their respective televisions. The CPUs in turn ran at 1.79 MHz and 1.66 MHz respectively.

This already creates the first problem for running an NTSC game on a PAL console which is that it runs the game at a different speed. Remember that this was before games had a real time clock to measure behavior, instead Mario's speed had to be defined in how many pixels he moved each frame. To be fair this was actually accepted for many games (though many PAL region gamers didn't like getting these sloppier ports) and is noticeable in things like the tempo of the music being wrong. It's also why things like PAL Mario Kart track records are different from NTSC ones, because the physics code in the game is running at the wrong speed even though the time displayed has been modified to reflect the 50 Hz/60 Hz difference.

But there's a bigger problem. Many games of this era relied on cycle accurate timing to achieve certain effects or even just to run without glitches. For example in the original Super Mario Bros there are rare situations where the amount of computing required can exceed the time available in the NTSC's 1/60 timespan. This results in the score bar glitching because it's position hasn't been set before the beginning of the next frame being sent to the TV. The longer 1/50 time span per frame of the PAL console meant that games had to have their code adjusted to account for this or they wouldn't work correctly.

Real time manipulation of the GPU, used for many split screen effects and other enhancements, also required especially good timing since you had to send signals to the GPU on exactly the right cycle (pixel) for them to work. On the NTSC NES there are exactly 3 GPU cycles (1 GPU cycle = 1 pixel) for every 2 CPU cycles, a useful ratio and one which many developers wrote code to exploit. The PAL ratio however is 3.2:2 which means those pixel counting algorithms were all out of sync when run on a PAL console.

These differences were of course repeated in various ways across other consoles and early micro computers. It was only when you had real time clocks and TV independent frame buffers that games became reliably region free.

Answer 2

Basically the difference between PAL and NTSC consoles is the frame rate, 50 vs 60 Hz. The consequence of that is that PAL and NTSC mostly differ in number of cycles available for the CPU per frame, with NTSC numbers being significantly smaller.

More subtle differences might be number of cycles per scanline, position of visible screen area related to the frame interrupt and different ratio between CPU and video clock frequencies. Example here is the C64, where there are 63 clocks per scanline in PAL and 65 clocks in NTSC. Ratio between CPU and video clocks is different in NTSC NES/Famicom (1:3) and PAL NES (5:16).

Now back to the games. Simple games that are happy with NTSC timings might run flawlessly in PAL, for example "Super Mario Bros." on NES, which runs just fine on PAL NES, not to mention slower gameplay due to slower rate of frame interrupts. The opposite might be problematic – for example, there were more games for PAL C64 than for NTSC one, and there was a game cracking/adaptation scene on C64 in 80ies and 90ies, which basically ported PAL games to NTSC machines. That required many hackings such as revise game timings, optimize algorithms, etc. as to fit execution into the NTSC frame.

Some timing-sophisticated games for NTSC NES, that do ingenious and perfectly timed tricks to the PPU, might be completely unable to run on PAL NES due to different CPU/PPU clock ratios.

Answer 3

Technically, no, because usually hardware was fixed to generate the TV signal in a fixed way, instead of being programmable. Many systems had separate video chips for different TV systems, and due to the difference in the video timing or color encoding, also the clocks available in the system to run the CPU or audio chips varied.

So basically, taken a NES as an example, the console has dedicated hardware to output 60 Hz NTSC or 50 Hz PAL video signal with CPU and audio system clocks derived from these TV system and color encoding clocks. So an NTSC hardware will output NTSC video, PAL hardware will output PAL video. The game cannot change the video system. An NTSC game will expect to run on an NTSC console and it may not work on a PAL console due to timing differences. Same goes for running a PAL game on a NTSC console. It is also possible to make a game that detects which hardware it runs on and adapt the program to run on both hardwares, so it is a single worldwide release game.

Differences are in the

• TV system, either 525 lines at 60 Hz, or 625 lines at 50 Hz

• Color encoding used with the TV system, such as NTSC, PAL or SECAM

• RF modulation used for TV antenna connection

While PAL is usually used with a 625-line 50 Hz TV systems and NTSC with 525-line 60 Hz TV systems, there are exceptions to that. Also some countries with the 50 Hz TV system used SECAM color encoding instead of PAL, and while the black&white portion of the signal is compatible, the color is not.

So obviously the console video chips need to generate the video signal with the correct 50Hz or 60Hz timing, then apply the correct color encoding method.

If the console had a built-in RF modulator to connect to the TV via the antenna connector, the RF modulator also needs to be compatible with the local TV channel setup depending on the used broadcast system. For example, PAL/B, PAL/I and PAL/D were all using 50 Hz video signal with PAL color encoding, but the audio was modulated with different carrier frequency, so you would have video, but no audio, or hear parts of the video signal as audio.

Answer 4

These answers are contradictory basically because none of them are getting down to the real meat of the issue.

That is, it depends if the programmers accounted for it or not. The ease of doing this will also vary by console, as well as how severe the consequences if programmers didn't.

Here are a few examples.

(To simplify things I will generally assume that PAL is synonymous with 625 line (576i) @ 50Hz systems, and NTSC with 525 line (480i) @ 60Hz systems, but I am fully aware that there are a few exceptions around the world that use one colour standard with the other resolution/frequency standard.)

Atari 2600

The video chip on this console works on an incredibly low level. However, running an NTSC game on a PAL console or vice versa will often technically work; but it will produce a signal that is technically not either a standard PAL or standard NTSC signal, though some TVs will take it (if you're curious, it'll produce PAL colour but at 60Hz/525 lines with an NTSC cartridge in a PAL console, or NTSC colour but at 50Hz/625 lines with a PAL cartridge in an NTSC console). This is because the vertical blanking intervals — the signals that tell the TV "that frame's over, time for the next one" — are generated by the game code, and usually Atari 2600 code is so time-constrained that the authors wouldn't bother adding time-consuming checks for PAL and NTSC (I don't even know if such checks are technically possible).

In addition to the timing issues, the colours will also be wrong, as again the hardware uses a very primitive means of generating colours in either PAL or NTSC, and they don't exactly line up with each other. The PAL versions of some games might choose to correct this, or they might not. SECAM colours are so complicated that Atari just gave up and produced an incredibly reduced colour palette for the SECAM world (France/USSR and allies); so some games are unplayable without special SECAM versions thanks to this reduced palette.

8-bit home computers

The 8-bit home computers, as popular in the UK and Europe but less popular in the US, usually had little thought of compatibility put into them. So it can be very hit or miss whether a game will play flawlessly, play OK but with glitches, or not play at all, when transferred from region to region. Again, differences in the video timing are to blame; while with these computers generally the video signal is not generated in code like on the Atari 2600, code of this era was still heavily timing dependent, and so certain parts of the picture generation taking longer or shorter than the code expects can wreak havoc.

NES/Famicom

By this era, the problems of incompatibility from a logistical standpoint were starting to be recognised. Especially with the NES often having two ROM chips per game, wouldn't it be easier if those chips were the same everywhere, with the only difference inside the cartridges being the region lock-out chips? So with this console, many (not all) games will now "work" on both NTSC and PAL, and the same code will be shipped in both regions. However, usually this involves some severe compromises — the PAL version, often considered as an afterthought thanks to the enduring popularity of the 8-bit home computers and little appetite from the public to move onto console gaming at the time, would run "letterboxed" (with coloured bars on the top and bottom of the screen), due to not making use of the extra visible lines (576 vs 480) available in most PAL territories, and the game itself would run noticeably slower (synchronised with the 50Hz as opposed to the 60Hz TV signal).

Mega Drive/Genesis

By this era, games were not only more likely to use the same ROM chips in PAL and NTSC territory, but were also starting to have checks programmed to change the timing and the resolution to try to provide the same experience on both systems. This is in part due to this console generation being the first to really make a sizeable dent in Europe; the 8-bit computers were long in the tooth by now and many people hadn't upgraded to the 16-bit computers of the era. Not every game does this — perhaps most infamously for European customers, Sonic the Hedgehog would run slowly and letterboxed on PAL systems.

Nintendo 64/PS1 and beyond

By this point, there was usually very little reason not to code the game to be compatible in both regions; the amount of extra space and time used on a given copy of the game was negligible compared to the savings of having one codebase to run in all regions. However, this was the era when we started to really see large numbers of games come with translations into many of the most popular European languages. As such, things were really starting to diverge again in terms of what got shipped to each region — but this is now for cultural/social reasons rather than technical ones.

Answer 5

Generally, no. But some games could "run" if you bypassed the region lock. Thing is they would be faster or slower than they were supposed to be due to the different frequencies of power grids across the world. TLDR; back then a game made for a 50 hrz country had to be made to run on that frequency.

If you take a game from a country with the same power grid frequency as you, it should work just fine if you bypassed the region lock via a modchip or whatever.

If you took a game from a country with a different power grid frequency and tried to run it, it would either run slower/faster, and this can/will cause many odd behaviors which could make the game unplayable.

There's some youtube vids of hackers playing with this to see what happens. Check them out.