Best way to detect NTSC or PAL

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Best way to detect NTSC or PAL

Post by Dwedit »

If the Hong Kong famicom was generating an NTSC signal with a different number of scanlines, does that mean that it would generate a black and white picture on a PAL TV?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Best way to detect NTSC or PAL

Post by Fiskbit »

I know very little about video and especially color, but the region conversion chip also operates on the video and presumably makes it function well enough for PAL. I don't know if there are differences between the MK5060 and Nintendo's NPC26. I don't have any MK5060's yet and the NPC26 I have is damaged.

I believe the HK Famicom is the only official Dendy-like console, yes.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Best way to detect NTSC or PAL

Post by lidnariq »

MK5060 both adds the extra 50 scanlines and also transcodes NTSC to PAL.
User avatar
gravelstudios
Posts: 159
Joined: Mon Mar 13, 2017 5:21 pm
Contact:

Re: Best way to detect NTSC or PAL

Post by gravelstudios »

Thank you all for your feedback. I think now I'm leaning more strongly in the direction of making it a setting the player toggles. That seems like the easiest solution to me.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Best way to detect NTSC or PAL

Post by rainwarrior »

In my experience with releases, tepples' auto-detection routine has been appropriate in every case I've heard about.

If you have an options menu, I think allowing the user to choose AUTO / NTSC / PAL / DENDY is nice, and could theoretically account for a weird clone or emulator, but I haven't yet had a report where the option was ever actually needed.

So, unless you already have a convenient place to add another option, it also seems pretty valid to just rely on automatic detection.
User avatar
Individualised
Posts: 310
Joined: Mon Sep 05, 2022 6:46 am

Re: Best way to detect NTSC or PAL

Post by Individualised »

Yeah, to be honest I see no reason why they should make it an option. Timing is only going to be off enough to mess up automatic detection in extreme edge cases like super inaccurate emulators (that no one are using in 2023 for normal gaming circumstances), and in those cases you can't really do much to improve the gameplay experience anyway, inaccurate emulators will always be inaccurate emulators. At least with all known hardware revisions, including clones, there have been no cases of strange timing that would cause region detection algorithms to report a false value.

The only thing I could see being useful is having cheat codes to override certain settings that would normally depend on the region detected, this would be useful for clones and obscure hardware revisions where certain functionality varies. For example, duty cycle swapping (should probably be enabled by default if Hybrid region is detected, as the majority of Hybrid consoles are clones with swapped duty cycles), or colour tint behaviour (red and green should be swapped by default if PAL or Hybrid is detected, but cheat code should be able to swap them back, to allow compatibility with the Hong Kong Famicom and other Hybrid consoles that may use the NTSC colour tint arrangement, or maybe even the ability to disable them altogether for RGB consoles due to their broken colour tints)
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Best way to detect NTSC or PAL

Post by rainwarrior »

Individualised wrote: Tue Mar 07, 2023 3:56 pm Yeah, to be honest I see no reason why they should make it an option. Timing is only going to be off enough to mess up automatic detection in extreme edge cases like super inaccurate emulators (that no one are using in 2023 for normal gaming circumstances), and in those cases you can't really do much to improve the gameplay experience anyway, inaccurate emulators will always be inaccurate emulators. At least with all known hardware revisions, including clones, there have been no cases of strange timing that would cause region detection algorithms to report a false value.
I think it's fine not to have an option, but I disagree with "no reason". People absolutely do use a lot of inaccurate emulators into the present day, and while often it just isn't worth worrying about, if you have an options system already I do think it's a small plus to make the system more permissive if you can.

Failing the frame length timing test will not necessarily break anything else. Depends on what your game relies on, and the specific way that it's inaccurate. As a trivial example, "overclocking" an otherwise accurate emulation with extra scanlines will fail the tests but wouldn't be likely to cause any gameplay issue as long as the option exists to override the automatic test. (Probably not a lot of players use emulator overclocking features, but this makes it supportable. More relevant if your game has slowdown.)

The other two things were good to mention as well, since they're strongly correlated with the frame timing tests, but still don't 1:1 match its results. Both of them have no direct test, unfortunately, other than maybe having the game ask the user what they hear or see, which us probably more work than just making options for it.

Duty swap by default for hybrid is probably a good idea, but there are plenty of those that don't. Some people specifically want to hear the swapped duty sound for games, too.

The emphasis tint is also good to swap for PAL/Hybrid by default if you're using emphasis. RGB PPUs are kind of a niche thing, but again if you already have an options system, maybe it's pretty easy to just make an option for emphasis.

For both of these an "auto" default option can just defer to whatever frame timing was found/selected to guess whatever was most likely.
Individualised wrote: Tue Mar 07, 2023 3:56 pm...having cheat codes to override certain settings...
I'd rather just present an option to a user than obscure it as a cheat code. Why make it less accessible to them?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Best way to detect NTSC or PAL

Post by tepples »

I imagine that some devs are tempted to hide less used preferences, such as behind cheat codes or about:config, in part because each preference added to a list makes the others on the list harder to find. See "Choosing our Preferences" by Havoc Pennington.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Best way to detect NTSC or PAL

Post by rainwarrior »

I agree that adding more options is not always beneficial, but this is kind of a platitude? Yes of course, every option added is something you should think critcally about. I realize we're already very hypothetical here, but I don't really want to go to this extreme.

The question was whether this option is beneficial to obfuscate. Do you want to give it to more users who can find it passively, maybe even have it tracked by the game's battery save for them... or do you want it to be accessible to only users who are willing to do some research to find a cheat code, and are willing to do its weird inputs every time they play?

What I mean is that implementing a duty swap option and then intentionally hiding it is a strange effort vs. benefit tradeoff to me. I think I'd rather just not implement it?
User avatar
Individualised
Posts: 310
Joined: Mon Sep 05, 2022 6:46 am

Re: Best way to detect NTSC or PAL

Post by Individualised »

rainwarrior wrote: Tue Mar 07, 2023 5:38 pm
Individualised wrote: Tue Mar 07, 2023 3:56 pm Yeah, to be honest I see no reason why they should make it an option. Timing is only going to be off enough to mess up automatic detection in extreme edge cases like super inaccurate emulators (that no one are using in 2023 for normal gaming circumstances), and in those cases you can't really do much to improve the gameplay experience anyway, inaccurate emulators will always be inaccurate emulators. At least with all known hardware revisions, including clones, there have been no cases of strange timing that would cause region detection algorithms to report a false value.
I think it's fine not to have an option, but I disagree with "no reason". People absolutely do use a lot of inaccurate emulators into the present day, and while often it just isn't worth worrying about, if you have an options system already I do think it's a small plus to make the system more permissive if you can.

Failing the frame length timing test will not necessarily break anything else. Depends on what your game relies on, and the specific way that it's inaccurate. As a trivial example, "overclocking" an otherwise accurate emulation with extra scanlines will fail the tests but wouldn't be likely to cause any gameplay issue as long as the option exists to override the automatic test. (Probably not a lot of players use emulator overclocking features, but this makes it supportable. More relevant if your game has slowdown.)

The other two things were good to mention as well, since they're strongly correlated with the frame timing tests, but still don't 1:1 match its results. Both of them have no direct test, unfortunately, other than maybe having the game ask the user what they hear or see, which us probably more work than just making options for it.

Duty swap by default for hybrid is probably a good idea, but there are plenty of those that don't. Some people specifically want to hear the swapped duty sound for games, too.

The emphasis tint is also good to swap for PAL/Hybrid by default if you're using emphasis. RGB PPUs are kind of a niche thing, but again if you already have an options system, maybe it's pretty easy to just make an option for emphasis.

For both of these an "auto" default option can just defer to whatever frame timing was found/selected to guess whatever was most likely.
Individualised wrote: Tue Mar 07, 2023 3:56 pm...having cheat codes to override certain settings...
I'd rather just present an option to a user than obscure it as a cheat code. Why make it less accessible to them?
I agree with most of your points but I must say that I don't know of many emulators, even older and inaccurate ones, that would fail region detection. I feel like only the really early NES emulators on DOS would be relevant here.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Best way to detect NTSC or PAL

Post by rainwarrior »

Individualised wrote: Tue Mar 07, 2023 7:09 pmI agree with most of your points but I must say that I don't know of many emulators, even older and inaccurate ones, that would fail region detection. I feel like only the really early NES emulators on DOS would be relevant here.
Well, for my own releases I haven't had any reports of a problem with the frame time detection, though this doesn't mean it doesn't happen, just that it hasn't been brought to my attention if it has. Sometimes a release already doesn't work on various emulators for unrelated reasons (e.g. less common mapper) so I would say that there's a lot of "untested" potential still.

Other than the emulator overclocking option I mentioned, I do have a a portable emulator device in my possession that has wrong timings, which I think might benefit from a forcing option like this depending on the game.

It's probably not more than a marginal concern. I think cases do exist, but it's pretty OK to just ignore them. The vast majority of situations do seem to give valid results for tepples' frame timing test. It's very reasonable to just go automatic with it.

So, I don't have a concrete case where anyone has reported needing the option, but ultimately I'd rather my games have wider support than narrower, and I found this one was low effort to support. I wouldn't go out of my way to add it, but with multi-region support and an options menu already in place it was just a few extra lines of code.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Best way to detect NTSC or PAL

Post by tepples »

The "count cycles between NMIs" and "sample $2002 at two breakpoints" variants of my frame timing test routine distinguish NTSC/RGB systems, PAL NES, and Dendy-style PAL famiclone. The scenarios where it's most likely to fail involve modified hardware, such as Hi-Def NES configured to overclock the CPU. Such modifications, however, would cause problems with running any discrete logic game with raster effects. Explicitly measuring both scanline length and frame length, as in the "overclock" ROM that became the "CPU clock speed" activity of 240p Test Suite, may be needed if you want to fully support overclocked CPUs.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Best way to detect NTSC or PAL

Post by rainwarrior »

tepples wrote: Wed Mar 08, 2023 6:41 pmExplicitly measuring both scanline length and frame length, as in the "overclock" ROM that became the "CPU clock speed" activity of 240p Test Suite, may be needed if you want to fully support overclocked CPUs.
Incidentally, that test (or the earlier oc-r1a version) appear to just hang in Nesticle. I was trying to measure Nesticle, and I found it actually lets you configure its cycles per scanline and lines per frame... though I wasn't able to use the ROM to measure how well it works.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Best way to detect NTSC or PAL

Post by tepples »

I'm not set up to learn to use NESticle in DOSBox today, but I suspect that NESticle violates one or more of the assumptions that the test makes about when the 9 sprites flag and the sprite 0 flag turn on and off. The relevant routines in the test's source code are s0_rise_to_rise, sov_to_s0, and now_to_nmi.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Best way to detect NTSC or PAL

Post by rainwarrior »

I don't think NESticle has any implementation of the sprite overflow flag: source link

So a spinlock on that will hang, I suppose.

For reasons sort of related, when waiting for sprite 0 hit I tend to use BIT with a mask including the vblank bit as a backup in case sprite 0 is never hit for reasons of bug, poor CHR connection, etc. I'd rather the program keep executing at reduced speed and potentially be recoverable for the user, than just hang on a spinlock.
Post Reply