Is NES/Famicom detection possible?

[Pokun]

My approach is to have all required settings as selectable options in an options menu. Then the player can for example turn on PAL speed and turn off PAL pitch if he has a Famiclone.

That isn't very user-friendly. You also can't detect 377 Famiclones.

It isn't, but it is necessary to have the options available in case the auto-dectection fails. You of course need to explain the settings in the manual or somewhere or people will have no idea what to set.

For Famiclones there are the clones of the CPU and PPU by Taiwanese Micro Genius which has the Famiclone behaviour I described above. Classic Dendy and Pegasus are based on these, and so are many (but not all) NOACs. I don't know what other Famiclones there are, but supporting Micro Genius' UMC clones should cover a large bunch of them and broaden your audience quite a bit.

[orlaisadog]

But you'd never see that on a commercial game in the 1980s . Probably because Nintendo wouldn't have liked it, but also because people would had no idea what it meant. Maybe you could detect these settings with help from the user?

[zzo38]

The only thing about AV Famicom is that the controller ports don't connect all of the pins, but this is probably unimportant.

Except in something like Zap Ruder that's designed for two Zappers. In addition, Famicom plays mapper audio; NES doesn't without a mod, and I don't know what 72-pin famiclones do.

Ah, yes, those are valid points. However, since you cannot connect two Zappers to the AV Famicom anyways, I do not really see the point if it won't work anyways; even if you have a NES you might not have two Zappers. It is better to detect what input devices are connected instead; the manual can describe what input devices are supported.

although if you are making a NES cartridge, maybe you can detect from the SYSTEM CLK pin if you need to tell the difference from NES and AV Famicom.

I'm not sure 72-pin famiclones even pass SYSTEM CLK.

I don't know either, but as mentioned on here you can't even detect the famiclones anyways.

However, you could use the audio pins to detect the Famicom vs NES too maybe, since on NES the audio from 2A03 is not received by the cartridge (so the cartridge cannot mute or tamper with it). On Famicom it can receive.

Probably it is helpful to have an option menu to change some settings if needed, although the default settings can be based on auto-detection. Emulators should try to act like the kind it emulates according to the user settings, in order that auto-detection is likely to work (although the user can still override it if necessary).

[tepples]

It is better to detect what input devices are connected instead

That's fine provided that reliable detection code exists. I've tried to include detection code in my controller test program. But without a Famicom console, Famicom controllers, and a Famicom-compatible flash cart, I can't test detection of Famicom controllers whose protocol differs from the NES counterpart. I could test in an emulator, but then how would I test the emulator?

the manual can describe what input devices are supported.

Should the manual for an NES game also describe what input devices would become no longer supported if the Game Pak is connected to a Famicom through a 72 to 60 pin adapter?

[zzo38]

It is better to detect what input devices are connected instead

That's fine provided that reliable detection code exists. I've tried to include detection code in my controller test program. But without a Famicom console, Famicom controllers, and a Famicom-compatible flash cart, I can't test detection of Famicom controllers whose protocol differs from the NES counterpart. I could test in an emulator, but then how would I test the emulator?

I have a RF Famicom but do not currently have any external input devices or the cartridges to write a test program with (although I wanted to acquire them, but have not yet done so). However, with the emulators, it may be possible to examine the schematics and the source codes of the emulator to see if it looks like it is matching. If you have not actually tried it, write what Knuth wrote: "Beware of bugs in the above code; I have only proved it correct, not tried it."

the manual can describe what input devices are supported.

Should the manual for an NES game also describe what input devices would become no longer supported if the Game Pak is connected to a Famicom through a 72 to 60 pin adapter?

It doesn't have to if it is not designed for that purpose (if the customer uses such an adapter then the customer should know), but it can, especially if it uses a custom input device then it should indicate if it is compatible or not, but otherwise it probably doesn't have to.

[bazza]

cartucho-duplo-slot-72-e-60-pinos-roger-rabbit-original-nes-D_NQ_NP_667582-MLB26596058497_012018-F.jpg

Has the photo of the another side of PCB?

[Fisher]

Has the photo of the another side of PCB?

Sorry, I don't own it now.

[lidnariq]

The board is "just" ANROM anyway, even using the same 74LS02 to invert R/W into an /OE signal for the ROM.

[Pokun]

But you'd never see that on a commercial game in the 1980s . Probably because Nintendo wouldn't have liked it, but also because people would had no idea what it meant. Maybe you could detect these settings with help from the user?

I only heard of one commercial game actually trying to detect NTSC and PAL and be dual compatible like that. And it's an unlicensed game.
I don't think any licensed games goes through the trouble of dual compatibility, it makes more sense for them to make separate NTSC and PAL versions. But many companies hardly changed anything in the PAL version. Most games are made for NTSC, and when released in PAL territories some companies changed speed and pitch and such, while other companies only changed it partly and yet other companies didn't touch it and released the game as is in PAL, which means the games runs very slow and the music is all wrong. This includes several first party games like certain versions of SMB. The music runs way too fast because they messed up when speeding it up.

Sometimes I wonder if the homebrew community doesn't have a better understanding of the Famicom than most developers had back in the day. But of course there are other explanations, like lack of time and resources.

the manual can describe what input devices are supported.

Should the manual for an NES game also describe what input devices would become no longer supported if the Game Pak is connected to a Famicom through a 72 to 60 pin adapter?

If it's relevant for the game I don't see any reason to not to explain it in layman language.

[rainwarrior]

I only heard of one commercial game actually trying to detect NTSC and PAL and be dual compatible like that. And it's an unlicensed game.

What game was that?

I don't think any licensed games goes through the trouble of dual compatibility, it makes more sense for them to make separate NTSC and PAL versions.

It makes a lot of sense to do it now, though, in an era where NES region locking has been thoroughly defeated and lots of people in the PAL region especially have NTSC units. A cart that works with both is a useful thing in this situation. (It's also good for the user who doesn't know the difference.)

The situtation for us here and now is a lot different than Nintendo in the 80s, where they controlled distribution pretty tightly and were actively working to maintain region locking (which was an important component of their business strategy). Multi-region detection is an anti-region-locking device; there would definitely be no encouragement from Nintendo for any licensed developer to do this.


PAL vs NTSC (vs Dendy) is something that is very reasonable to detect, IMO, and seems it can be done robustly across clones and emulators too. The test strongly correlates, and isn't particularly prone to error. (Mainly because CPU overclocking isn't much of a thing with NES and its clones, since it breaks so many games.)

Maybe worth pointing out though that the only thing typically done with a PAL/NTSC detection is directly related to the thing you detected. You measure the framerate, and you do something to compensate for that framerate. It's pretty much worthless for determining tangentially related things like language, for instance.

[tepples]

The Mega Drive/Genesis has two jumpers connected to (I think) GPIOs: "50/60" and "west/east". Japanese consoles are 60 east, North American consoles are 60 west, and PAL region consoles are 50 west. I imagine that if it had a China release, that would have been configured as 50 east.

The Neo Geo has different BIOS versions for east and west.

Some games for Genesis and Neo Geo detect the console version and run the North American or Japanese version, often with different title screen, different censorship, different legal notices (such as the "Winners Don't Use Drugs" ad campaign that appeared in AAMA-distributed arcade games in the 1990s), and different gameplay balance. Other games will display an error message if the jumpers aren't set how the game expects.

[TmEE]

The east/west is officially Overseas/Japan setting.
Official 50Hz asian machines use 50Hz+overseas setting, nothing uses the 50Hz+Japanese setting.

[SuperWill24]

I only heard of one commercial game actually trying to detect NTSC and PAL and be dual compatible like that. And it's an unlicensed game.

Several games (mostly unlicensed) have a feature like this. Supposedly Super Turrican (only released in PAL region, but supposedly a US prototype exists which is undumped) changes the music tempo depending on which region the NES is started up as. The unreleased US prototype game The Adventures of Dr. Franken has this feature depending on which mode the game is run in.
In terms of unlicensed games, the US Aladdin and EU versions of The Fantastic Adventures of Dizzy by Codemasters does the same. Almost all games produced by Ei How Yang attempt to detect NTSC and PAL and change the music tempo based on that on startup, but the PAL tempo is often not quite exactly the same tempo as in NTSC (the menu/storyline/Nightmare Buzz track of Toy Story sounds notably faster, for instance). Finally, Cony's World Heroes 2, on startup, prompts the user to set which TV mode the game is set on so there are no graphical glitches (it says to set which mode makes the logo look correct in rather broken English).

[Sumez]

The situtation for us here and now is a lot different than Nintendo in the 80s, where they controlled distribution pretty tightly and were actively working to maintain region locking (which was an important component of their business strategy). Multi-region detection is an anti-region-locking device; there would definitely be no encouragement from Nintendo for any licensed developer to do this.

Absolutely! Over the past few years I've been getting rid of my old PAL games and replacing them with NTSC versions, which are generally a lot harder to come by. If I buy European releases I always first make sure that the developers didn't adjust the timing in that particular game.
We really got screwed over royally in this part of the world.

I think it makes sense for new releases to fix the music by detecting the console's framerate, so you don't end up with a "PAL version" of your game where the game still plays slow, but the music is fast - like probably 50% or more of the original European NES releases do.
I wouldn't try adjusting your gameplay unless it's already designed in a way that lets you easily adjust these parameters. Usually you'd end up with a game that either stutters in one region, or just plays flat out differently.

Supposedly Super Turrican (only released in PAL region, but supposedly a US prototype exists which is undumped) changes the music tempo depending on which region the NES is started up as.

Really? I have that game (it absolutely sucks, btw) I gotta test this out!

[FrankenGraphics]

For me, there is no clear cut rule for PAL 50hz compensation. It has to be assessed game for game (homebrew for homebrew).

In Project Blue, even after we elected to make the acceleration/decelaration of the character a bit snappier after getting some feedback, running the game on PAL was initially still a bit too sluggish. Human reaction time is more or less a constant which the physics of a game are referenced to. In this case you wanted to react "too early". Then there's the absolute metric space in a level design. For a non-scrolling flick screen platformer with super mario physics using a level layout that for the most time emphasizes "one room at a time", all in all it just didn't click with a non-compensated PAL update rate. Toggle_switch did a great job making it work for both NTSC and PAL and i much rather prefer playing the compensated version on PAL than the original. There are tiny differences, but ultimately, the only practical effect is a tiny one: speed runs will have to be defined in NTSC and PAL categories. Which i just realized would be true in the non-compensated case, too. Except it could be seen as less glorious to score a record for a variant whose only difference is that it is a bit slower, so i think the compensation might make PAL runs a bit more attractive.

The interface to be playing NTSC or PAL versions is simple. Pop it in a NTSC or PAL unit depending on which you want to play. Or emulate it for whichever version you want to speed run practice.

In a game with simple on/off movement, such as castlevania, or one with or snappier acceleration than Project Blue, PAL compensation might be of lesser value.

Basically, i think:
automatic NTSC/PAL detection is good, but depending on case and implementation.
keeping NTSC version only is OK, provided both play decently on both systems.
keeping separate NTSC/PAL versions, in this day and age, is OK but also slightly questionable since you might get the weird case where a PAL only version is played in an NTSC unit.
keeping NTSC version only without testing PAL (at least in emulation*) to at least check if it plays well is below what i'd expect of anyone doing a physical release. This is hard to know for sure, and "Will it work on PAL?" is a question open to interpretation.

(*just don’t rely on their PAL master palette interpretations if colour definition is important. consult someone with a PAL unit and preferrably a couple of screens).