21

Most ROMs are labeled with "(Europe)" or "(USA)", meaning PAL or NTSC. However, some are labeled "(World)". At first, I didn't think twice about this, just assuming that that the game was released world-wide identically, with no changes between the regions.

But then I thought: "Wait a minute. This makes no sense. How can it be a single copy for both PAL and NTSC?"

Does a "(World)" NES cartridge really have both PAL and NTSC copies of the game on it, and somehow is able to automatically detect whether it's being played on a PAL (European) or NTSC (USAian) NES? I suppose that is reasonable, if the NES has such a "flag" that the game can check upon boot, but does it really have such a thing? Does "(World)" really mean this?

I can't remember any NES game which had a menu where you had to pick your region at start.

0

3 Answers 3

19

It means what it says: one game image for multiple regions, or 'the world'.

The 10NES lockout chip pairing between cartridge and NES is the main determinator of whether a cartridge will be allowed to boot on a given system. When omitted like on the NES-101, the USA NES and the European NES are almost identical except for some timings. If you put a European game into that US-only NES-101, it'd do its best to run it. See also: What are the differences between the Japanese Famicom and American NES?

I believe the main difference you'd encounter for a NES game, from the programmer's perspective, is the length of a game frame - how much calculation it's possible to accomplish in a single game frame. It is possible to design a game for use on multiple regions of a system, so that a frame completes in sufficient time no matter where it's used.

Care might be taken to ensure the game works identically to players' perceptions in different regions, or it might not. If it's possible to detect the region, then parts of the game that deal with time-based simulation may contain different routines simulating an NTSC 1/60sec frame and a PAL 1/50sec frame, and choose between them as necessary. A car that's supposed to accelerate from 0-60MPH in 4.5s will need different values for per-frame acceleration and so on. It doesn't need to have two entire games like you suggest, as for example a routine that reads the player's position from RAM and places some sprites at a specific pixel on screen is not dependent on the frame timing.

If this is ignored, the differences in clock speed are just accepted 'as is' when played on another system. When a 60Hz USA-designed 'World' game is played on a 50Hz European system, you might see the following effects:

  • Objects appearing to move slower on screen. The 60Hz game would appear to run at 5/6 the speed on a 50 Hz European console. You'd move the same speed per frame, but with fewer frames per second.
  • In-game clocks like in racing and athletics games would run at the wrong speed, as they're typically tied to frames occurring rather than any calibrated clock.
  • If the music engine is advanced once per frame, then the tempo of the song will become slower by the same ratio. The note pitches may be different but not necessarily proportionally so since the tone generator chip is fed a different clock derived from the master system clock than the one used for video display.

These effects are very obvious on Genesis games. Here's Sonic the Hedgehog being played alternating between two different regions. Another user will have to correct me if these observations don't hold for NES games. :)

6
  • 3
    It is indeed possible to detect the region; the easiest way is to count the number of cycles between frames at startup. See Detect TV System on the NESDev Wiki.
    – NobodyNada
    Oct 22, 2020 at 3:10
  • It's certainly also true for some n64 games like mario kart, there is even a formula speedrunners use to convert finish times between the systems.
    – eps
    Oct 22, 2020 at 13:12
  • Since you mention note pitches, would they really be tied to the frame rate of the console? And not to the CPU speed, or some wave generator? The length and timing of notes would be more likely to be tied to frames, of course.
    – ilkkachu
    Oct 23, 2020 at 16:00
  • Given the very tight timings in some games, I can imagine some PAL-native games just breaking completely if run under NTSC conditions if their horizontal-blanking-interrupt happened too soon, as the game-code would be an undefined-state. I wonder if any games have particularly cool glitches when that happens...
    – Dai
    Oct 23, 2020 at 19:04
  • 1
    @ilkkachu Yeah I didn't phrase that very well did I. The frame rate will determine the rate at which the music events advance; and the period of tones will be affected by the master clock speed - which will be different in different regions, but not necessarily proportionally to the frame rate.
    – knol
    Oct 23, 2020 at 22:25
9

This was very common on some platforms, e.g. the Amiga. Games often didn't use the lower part of the screen in PAL regions, so that they still fit onto NTSC screens with a lower vertical resolution. That also meant that the aspect ratio was different between the two regions, a purely cosmetic issue.

However most Amiga games did not run at the full frame rate or 50 or 60 FPS (PAL and NTSC respectively). PAL games have 20ms to complete a frame, NTSC games only have 16.6ms. PAL frames are larger too, having more vertical resolution. On consoles like the NES that isn't a big issue as the extra scanlines are rendered by the graphics hardware at very little extra cost in terms of processing time required.

Therefore it is entirely possible to make a "world" game. The easiest method is to develop for NTSC which has the tighter timing requirements and then add some vertical resolution in PAL mode. Timers may need to be adjusted to take account of the different frame rates, and without modifying movement and animation in the game the PAL version will run more slowly. Many games didn't bother.

One common method was to add an extra status area at the bottom of the PAL screen to use up the extra space. That way the gameplay area remained the same size and there was no danger of the player gaining an advantage or going out-of-bounds.

While it's tempting to think that some machines can switch between PAL and NTSC, in reality very few can. They usually just support switching the display frequency between 50Hz and 60Hz, but the timing for things like the colour signal remain in the format the machine was designed for. So for example a PAL machine producing a 60Hz signal will not generate NTSC compatible colour, but rather PAL colour at 60Hz. Sometimes this is referred to as "PAL60", e.g. by several Dreamcast games.

3
  • 2
    But it's not really an "issue" on the Amiga since most are switchable by software between PAL and NTSC. So it's an issue whether the monitor is regional, not the Amiga.
    – Brian H
    Oct 22, 2020 at 14:49
  • on amiga some games had "region protection" (psygnosis games mainly) to prevent that a ntsc version runs on pal hardware. Was it a legal protection or a way to avoid that the game behaves abnormally I don't know Oct 23, 2020 at 11:39
  • @BrianH They can't really. For a start on Fat Agnus (ECS) and later supported it, but the bigger issue was the clock frequency. The crystal in the machine is fixed so when an NTSC machine generates PAL the colour carrier is still at the NTSC frequency. Most monitors can cope with it but most TVs from the 80s and 90s would have struggled. Certainly no use for a commercial release.
    – user
    Oct 23, 2020 at 15:19
2

Apart from CIC (lockout) chip, which is easy to cut off, and obvious 50/60 Hz difference (incl. different number of scanlines), there is a truly interesting stuff that differ between NTSC and PAL NESes.

The first one is the different number of scanlines between frame-syncing /NMI and the moment PPU starts to draw the picture on the screen, that is, 20 lines in NTSC and 70 lines in PAL.

The second one is the different ratio between PPU and CPU clocks. NTSC has 3:1 ratio, while PAL has 16:5. This also includes different number of CPU clocks per scanline (113 1/3 and 106 9/16 clocks, resp.)

All that could make NTSC cycle-counting games to fail badly on PAL.

Interesting enough, that the so-called "Dendy" clone of the NES, that was very popular in Russia in 90ies, while being 50 Hz, was NOT made like PAL NES. Instead, it had the timings exactly like the NTSC NES (including PPU/CPU ratio, number of lines from NMI to start of picture, number of CPU clocks per scanline, etc.) except that the frame was lengthened further before the vblank (and hence NMI) to match 50Hz/312 lines.

This way almost all games were cheated to run on seemingly NTSC hardware, despite the frame rate was actually 50 Hz.

That is what I'd call a wiser engineering decision, the decision Nintendo failed to commit itself when building PAL NES.

You must log in to answer this question.

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