PAL detection?

Is possible to detect if a certain game is NTSC/PAL? No, I don't mean "use crc32" or "use NES database", but while running.
I'm interested in PAL detection 50/60hz.

I guess you meant to post in NESdev or NESemdev?

For emulators to detect ROM region don't you detect it via the iNES or NES 2.0 header? Not sure how many PAL ROMs are properly using those bits though. Other than that I don't think it's possible to detect a NES ROM's intended region. Especially since there are several PAL games that was never optimized for PAL machines, and use the exact same mask ROM as their NTSC counterpart.

For ROM development, I've seen a few threads about detecting the hardware's region. There is one method in a wiki entry.

Probably not with any certainty. Assuming you mean in emulation, and by behavior.

Seems it would have to use some kind of heuristics. What comes to mind would be something like looking for "too many" PPU writes outside of hblank and vblank during one, or a few frame(s). This would probably be enough information if the game used a lot of raster effects (or does a lot during vblank), but just for a split-screen, probably not useful. You could maybe look at sound register values used for note frequencies and see if they are closer to NTSC or PAL tuning (but also requires knowing if it's really a note or a sound effect). Either of these could be defeated, though the I think PPU write timing detection would work pretty well at least for stuff like racing games that change the scroll every scanline.

Detecting many PPU writes with screen on might work for games like Asterix, but that's about it.

For anything that uses tonal DPCM samples, perhaps you could check if the dominant frequency (FFT and maybe fiddle~) is in or out of tune with the square and triangle channels.

FCEUX just looks for (E) on the filename, which is a funny way to do it. (Obviously not a runtime solution, or even a good one.)


Things that might be different for PAL games:

- Only Famicom games need to read the expansion controller bits. Most games I've seen that fail to do this were developed in Europe (e.g. Rare, Codemasters). Doesn't really weed out NTSC from North America, but it's at least a hint.

- The DPCM controller read glitch doesn't affect PAL systems. Not sure if any games actually take advantage of this. A lot of european games don't seem to use DPCM anyway.

- PAL systems have a longer vblank. You could take Dwedit's suggestion to check for out-of-vblank PPU writes, but this is a positive test for only a couple of games, I think, and it'll probably have false positives on buggy games like Commando.

- There is a need to do sprite OAM early in the extended vblank on PAL systems, but NTSC games will do that anyway.

- Raster timings will break on the wrong system, obviously. How to detect this, though? You'd need to know what timing was intended. Maybe detecting for failed sprite hits and lag frames or something, but you might get false positives on glitchy games again (e.g. TMNT's status bar goes crazy during slowdown).

- DPCM tuning is different, as lidnariq mentioned. I dunno how well you could really test for this, though-- the bass is harmonically related, it's not just a matter of identifying and comparing its fundamental. Also some of the notes in the relevant games are still pretty out of tune anyway even on the correct system.

- The colour of the PPU emphasis bits swaps red and green on PAL, but I don't think any games exist where this matters.

- A lot of NTSC games will run "fine" on PAL, just slower and at a lower pitch. Not sure there's anything at all that you could try to detect in this case.


I can't really think of any heuristic that would be even slightly reliable/useful.

Also, these things don't usually happen until gameplay has started, or maybe not until a ways into the game even. Are you proposing to automatically switch the region for the user without their input when you detect some condition during the game? Wouldn't that be a lot more annoying than just requiring them to manually change the region setting?

I find that CRC or filename conventions do work, in practice. CRCs are useless for hacks and homebrews, though. The real problem is it was never a standard part of the iNES header, but that's its own battle. I'd just say support the iNES 2 extension for homebrew that might need to specify a region, and do whatever you need to for the regular case.

Our wiki points out that several of the Aladdin games turn on red emphasis. There's a bunch of Dendy users who now remember the game with a weird green tinge as a result.

Figuring out anything from this sounds even more intractable than automatically detecting which 2C04 PPU the game is using.

Yeah and the FDS version of Bubble Bobble exists as a pirated cartridge, Dendy players might be used to it as having a green tint for the same reason.


Both iNES and NES 2.0 uses a region flag in the header, but it's byte 9, bit 0 in iNES and byte 12, bit 0 to 1 in NES 2.0.
By supporting NES 2.0 headers you can detect games that are dual compatible like some Codemaster games and some of our homebrew.

Let me rephrase you.

By using NES 2.0 headers, you can mark games that are NTSC, PAL or dual compatible (like some Codemaster games), and some of our homebrew.

It's offtopic. /koitsu
Headers only set a flag for NTSC, PAL or... dual(???), but it's NOT "detection" of a PAL game, since the header can bring anything. So, nope, headers only can mark the region.

Likewise, headers only mark the mapper.


One could plausibly argue that a header that doesn't indicate the correct CIC soldered onto the board is as incorrect as a header that doesn't indicate the correct mapper soldered onto the board.

Consider the Super NES, where the SuperCIC can detect the inserted Game Pak's region and (I assume) flip the PPU's 50/60 switch appropriately. That's the model that the late iNES header and the NES 2.0 header assume: the console (the emulator) reads the key chip (the region bit) from the board (the header).

That leaves games that rely on PAL famiclones' longer post-render period, as there's no Dendy bit, and 60-pin cartridges have no key chip.

Oh? In that case, the answer is YES. Assuming you do not break the cartridge board rules, each mapper has a certain pattern and/or specific registers. Needless to explain each case, but it's pretty easy to check the data about MMC1, MMC3, MMC5 etc.. ^_^;;

Currently, I'm not doing any research on PAL x NTSC diffs, but will do eventually.

The problem with NTSC vs. PAL is that there's nothing different about the hardware (besides the CIC, which's not used by the game itself), as is the case with mappers, it's all in the software. Hardware differences are more objective, but the software depends completely on what the programmer thought was correct to do and produced the desired results. I don't think you can easily make a program to analyze whether the emulation results are "correct" for one type of console or the other. Better stick with using the information in the header.

Yeah and if the dumper didn't set the header correctly and just zeroed out the last bits, it will at least default to NTSC which should be correct in most cases.


Yes, maybe you could make your emulator shoot fireworks everytime it detects a dual region game!

Absolutely no need of fireworks... or your opinion.
Be quiet now.

Oh comon I was kidding!