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?

  • Not a direct answer but some interesting info, Datel Electronics and some other manufacturers actually sold adapters for SNES that allowed you to bypass region block and also play NTSC games on PAL and vice versa. You plugged in the adapter then attached a PAL cartridge to the back of it (for region bypass) and attached the NTSC game on top. I had one and from memory, I never had any issues with the games I played. So, even though the SNES internals were as described in the answers below, that was a not a barrier to playing NTSC games.
    – NetServOps
    Commented Jun 19, 2021 at 2:44

5 Answers 5


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.

  • 3
    Another couple of differences in the timing relate to the fact that compared to an NTSC system, a PAL system allows the CPU more than three times as much time during each vertical blank to perform display memory updates without having to blank part of the normally-displayable area, but slightly less time to perform object attribute (sprite position/control) updates. Some PAL games would be essentially impossible to implement on NTSC because of this.
    – supercat
    Commented Jun 18, 2021 at 18:57
  • 17
    One small note: The 1/60 frame time on NTSC is smaller than the 1/50 frame time on PAL, looks like it got flipped around. Commented Jun 18, 2021 at 22:23
  • 7
    Calling the video controller in early game consoles a 'GPU' is a stretch. They didn't do much - if any - 'processing' of the graphics data. Commented Jun 20, 2021 at 1:12
  • The aspect ratio of most PAL and NTSC TV's was different as well. US movies designed for NTSC would usually be shown in "letterbox" on our TV's. Not sure if that would impact the display output from a console. Commented Jun 20, 2021 at 9:04
  • 2
    On older machines (like my Atari 800 XL back then) it was really usual to sync the code not only to the whole screen, but even to individual lines (which gave you the possibility to have all colors on the screen at the same time in the form of horizontal bars or pipes). Also often the time it took the electron gun to move from the right edge of the screen back to the left (while off) was put to good use. Things like sprites (aptly named "player & missile" system) were even implemented by not having them in video RAM at all, but "rendered" in real time, as the pixels came out. Ahh, great times!
    – AnoE
    Commented Jun 21, 2021 at 7:30

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.


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.


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.


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.


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.

  • 1
    The frequency of the power grid is irrelevant. For most computers, the electricity that powers them is converted into direct current long before it even reaches the device. (PC compatibles being a major exception, but those too are DC-powered.) Commented Jun 20, 2021 at 6:50
  • For computers manufactured now, yes. For cheep computers manufactured then, no. They used the frequency of the power grid as their clock. No joke. You can look it up. Better yet... youtube.com/watch?v=yBux0dERgJM Commented Jun 20, 2021 at 10:06
  • This had more to do with the refresh rate of the television set than the frequency of AC mains itself. Saying ‘it’s the power grid’ is at best a very misleading simplification. (The linked video doesn’t say much about it either.) Commented Jun 20, 2021 at 13:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .