It is currently Wed Oct 18, 2017 3:03 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 15 posts ] 
Author Message
 Post subject: PAL detection?
PostPosted: Sun Jan 15, 2017 7:10 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
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.


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Sun Jan 15, 2017 8:14 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 800
Location: Sweden
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.


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Sun Jan 15, 2017 8:16 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
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.


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Sun Jan 15, 2017 11:15 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
Detecting many PPU writes with screen on might work for games like Asterix, but that's about it.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Sun Jan 15, 2017 11:23 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
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.


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Sun Jan 15, 2017 7:25 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
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.


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Sun Jan 15, 2017 7:51 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
rainwarrior wrote:
- The colour of the PPU emphasis bits swaps red and green on PAL, but I don't think any games exist where this matters.
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.


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Mon Jan 16, 2017 8:13 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 800
Location: Sweden
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.


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Mon Jan 16, 2017 10:02 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Let me rephrase you. 8-)
Pokun wrote:
By supporting NES 2.0 headers you can detect games that are dual compatible like some Codemaster games and some of our homebrew.

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 :lol:
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.


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Mon Jan 16, 2017 10:10 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19096
Location: NE Indiana, USA (NTSC)
Likewise, headers only mark the mapper.

It's as if Zepper wrote:
Is possible to detect if a certain game is UNROM/AOROM/MMC1/MMC3? No, I don't mean "use crc32" or "use NES database", but while running.
I'm interested in MMC detection 8/16/32kb.

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.


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Mon Jan 16, 2017 2:46 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
tepples wrote:
Likewise, headers only mark the mapper.

It's as if Zepper wrote:
Is possible to detect if a certain game is UNROM/AOROM/MMC1/MMC3? No, I don't mean "use crc32" or "use NES database", but while running.
I'm interested in MMC detection 8/16/32kb.

Oh? :shock: In that case, the answer is YES. 8-) 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.


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Mon Jan 16, 2017 3:41 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10052
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Mon Jan 16, 2017 5:59 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 800
Location: Sweden
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.

Zepper wrote:
Let me rephrase you. 8-)
Pokun wrote:
By supporting NES 2.0 headers you can detect games that are dual compatible like some Codemaster games and some of our homebrew.

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.

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


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Mon Jan 16, 2017 8:46 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Absolutely no need of fireworks... or your opinion.
Be quiet now.


Top
 Profile  
 
 Post subject: Re: PAL detection?
PostPosted: Tue Jan 17, 2017 5:20 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 800
Location: Sweden
Oh comon I was kidding!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: MottZilla and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group