Is it possible to programmatically tell the difference between a NES and a Famicom?
I have no idea what any of that means.
Yes. Ask player 2 to press all buttons on the controller, if start and select are missing, it's a Famicom.
Seriously though, there are a few characteristics that can only be found in Famicoms, such as the inability to read from OAM, but that's just because the Famicom is older and the earlier units used older revisions of the PPU and CPU, but after the NES was introduced, they probably shared the exact same chips.
Another difference between the NES and the Famicom is that the Famicom doesn't reset the PPU when the console resets... Not sure how that could be used, but asking players to reset the console isn't much better than asking player 2 to press all the buttons...
What about what lidnariq said?
That link described polling the controller devices and other things to detect the connected buttons/hardware etc. in a similar way, just without user input.
There is a caveat to this in that there are a lot of clone devices out there. If your software is trying to do something differently based on "NES" or "Famicom" you can probably with some effort identify those two machines specifically, but it gets a whole lot harder to cover all the bases. (Also... didn't Everdrive or PowerPak end up messing with the results of these tests in some way too?)
Well, considering
A) We can't include every clone
and
B) Most people wouldn't have clones
I think this is fine to use for default language settings and controller pictures.
Also, can someone explain that post simply please?
orlaisadog wrote:
Also, can someone explain that post simply please?
This isn't like translating a sentence from one language to another. It's a complex technical topic, and there's a whole lot of required knowledge. I made an attempt to simplify it for you in my last post, but apparently you were unsatisfied because I removed too much in that simplification. Sorry that's not good enough, but explaining it in the way you need is probably far too much work for you to reasonably request all at once.
Like, the simple answer to your question is more or less "yes", though a better answer might be "it's probably a good idea to have the user choose directly, instead". If you want to learn the prerequisites for the "how" part, maybe start by learning something small first. Small questions are easier to answer.
orlaisadog wrote:
Most people wouldn't have clones
I think there's
far more clones than original systems out there at this point. This forum, though, does tend to be slightly biased toward the official Nintendo hardware, though there is a notable Dendy faction here too.
I'll make it simple: the answer is yes, it can be done with accuracy for detecting a true NES vs. a true Famicom, with user involvement (asking the player to press buttons on controllers).
However: this may not work correctly (read: the detection may not be accurate) on some clone consoles (i.e. not true Nintendo-made NES or Famicoms).
Simple enough?
It isn't a very useful thing to do because Famicom and NES cartridges don't fit into each other's slots...
orlaisadog wrote:
Most people wouldn't have clones
Even though clones didn't use to be particularly prevalent in most developed countries, they were in several parts of the world. Brazil, Russia and many other countries had Famiclones almost exclusively. But nowadays, even in the US, the old hardware is constantly failing, and since the patents for the console already expired, several companies are coming up with their own take on the system and cashing in on nostalgia.
pubby wrote:
It isn't a very useful thing to do because Famicom and NES cartridges don't fit into each other's slots...
Unless designs like
this become more common. Double-ended carts were normally used to put two games on the same cartridge, but it'd be really cool if someone decided to make dual NES-Famicom carts.
The pressing Start on controller 2 method won't distinguish an NES from an AV Famicom. The technique used by allpads will.
rainwarrior wrote:
There is a caveat to this in that there are a lot of clone devices out there. If your software is trying to do something differently based on "NES" or "Famicom" you can probably with some effort identify those two machines specifically, but it gets a whole lot harder to cover all the bases.
If it's just setting the default value for language selection so that the user doesn't have to go to Options as often, the stakes aren't quite that high.
rainwarrior wrote:
(Also... didn't Everdrive or PowerPak end up messing with the results of these tests in some way too?)
PowerPak has pullups on data lines, while the NES grounds the lines in question. This can be detected and worked around. EverDrive behaves more like an authentic cartridge with respect to open bus behavior.
tokumaru wrote:
it'd be really cool if someone decided to make dual NES-Famicom carts.
Do you mean something similar to the "almighthy"
Hydron?
Attachment:
File comment: Hydron
2.jpg [ 50.82 KiB | Viewed 2485 times ]
It's a little bizarre and kind of messy...
But works fine!
Attachment:
cartucho-duplo-slot-72-e-60-pinos-roger-rabbit-original-nes-D_NQ_NP_667582-MLB26596058497_012018-F.jpg [ 243.9 KiB | Viewed 2485 times ]
Untested code, condensing the results of
Riding the open bus:
Code:
; The PPU is mapped at $2000-$3FFF. (Addresses $2000-$2007 are
; unique; $2008-$3FFF are mirrors.) The PPU contains a dynamic
; latch called "io_db" in Visual 2C02 and "PPUGenLatch" in FCEUX,
; which holds the last value written to any PPU port. Reading a
; write-only PPU port, such as the VRAM address ($2006), returns
; the value of io_db.
lda #$FF
sta $3F16 ; Fill $3F16 (i.e. $2006) and io_db
sta $3F16 ; write twice because that's conventional for $2006
cmp $3F16 ; read io_db
bne io_db_not_supported ; NOAC clones may implement io_db wrong
; The next read is tricky. When doing an indexed read that crosses
; a 256-byte boundary, 6502 adds the index to the low byte mod 256
; and then fixes it up next cycle if there was a carry.
; Thus $3FF6 + $20 reads $3F16 then $4016. The $3F16 read
; precharges the data bus with io_db. Then the $4016 read changes
; only those controller port bits that are connected to something.
; CAUTION: Open bus works differently on some flash cartridges.
; The PowerPak has pull-up resistors that continuously precharge
; the data bus with $FF. But because this is the same value we
; stored in io_db, it will not change the test result.
ldx #$20
lda $3FF6,x ; reads $3F16 then $4016
; Bits 3-4 are open bus on a Famicom but driven on an NES based
; on two wires of controller port 1, and usually driven low.
; They probably won't both be true on an NES unless a Zapper is
; plugged into port 1 and the trigger is half-pulled.
and #$18
cmp #$18
beq is_famicom
is_nes:
Fisher wrote:
Do you mean something similar to the "almighthy"
Hydron?
I should've imagined that something like this existed here in Brazil, where all kinds of Famiclones coexisted, some with 60-pin cartridge connectors and other with 72-pin ones (
and some even had both).
I thought it was to do with the controller? How do flashcarts affect that?
controllers go through the data lines, which are naturally connected to a lot of things, including cartridges.
edit: citing nesdev wiki instead*:
Quote:
When the CPU attempts to read from an address which has no devices active, the result is open bus behavior. The value that results from a read in such a region is undefined, but on specific hardware predictable results may appear.
Clone versions of the hardware, and flash cartridges like the PowerPak or Everdrive may differ in their open bus behavior from a standard NES.
Lastly, tepples wrote earlier that PowerPak is using pullup resistors.
*
https://wiki.nesdev.com/w/index.php/Open_bus_behavior
orlaisadog wrote:
I thought it was to do with the controller? How do flashcarts affect that?
All external data that the CPU can read and write, including the controller ports and cartridge, are all physically connected together sharing the same 8-bit data bus. External hardware will only output data when you access within a certain address range, otherwise they'll be in a high-impedance state (AKA tri-state, or hi-z), which allows other hardware to output data on the bus. When you read the controller port, it doesn't actually use all 8-bits, those unused bits are not forced to 1 or 0 state. What will happen with those unused bits is it will see the last value that was output on the bus (this is known as open-bus behaviour). Normally then, reading $4016 means the last thing on the data bus was the high byte of the address, $40. If the PowerPak then had resistors on the data bus pulling the unused (undriven) bits to '1', then the CPU will surely be seeing a value other than $40.
I'm really curious here. What's the purpose of testing wether a game is run on an NES or a Famicom? And does it make a difference (to you) if said Famicom is a classic model, a Twin Famicom, or an AV Famicom?
Three possibilities:
- If your game contains both English and Japanese text, you might want to have the menu default to Japanese when running on a console sold in a Japanese-speaking country or to English when running on a console sold in an English-speaking country.
- If your game is running on a console without player 2 Select and Start buttons, you might want to display a workaround for the missing buttons without cluttering the display on consoles that do have the buttons.
- If your game is running on a console with a DA15 port and supports controllers other than the standard controllers, you might want to optimize controller detection for the protocol that those controllers use, which often differs from the one that NES expansion controllers use. The Famicom versions of the Power Pad and Arkanoid controller, for example, behave differently.
#1 was my initial thought, but this is completely a marketing issue, and the normal approach would be to make a Famicom cart that defaults to Japanese, and an NES one that defaults to English. If you're running an NES cart on a Famicom using an adapter there's probably a good chance you aren't even in Japan.
#2 and #3 are relatively valid reasons and a good example of why I asked, as both facilitate more direct solutions that makes sense in the context. For example, if you are able to detect inputs inputs on the DA15 port, I would dynamically change this implied setting that prioritizes reading inputs from it at the moment I detect that it has been used.
There's probably a good all-encompassing term for this approach that I don't know of, but it's similar to when designing responsive websites that work on multiple devices, instead of detecting if the client is using a mobile phone, and then adjust the layout to look better on one, you want to to approach the more direct issue, and just react to the resolution that the client is running at, and adjust to that.
I think it was called object detection vs. user agent sniffing.
I've often wondered if it's possible to programmatically tell the difference the NES-001 (the Front Loader) and the NES-101 (the Top Loader) or at least if a heuristic exists that might statistically be able to guess the environment correctly most of the time.
Most of the time? Just assume it's a normal NES, which is most common! Simple!
NES-001 vs. NES-101 is easy: NES-001 drives $4016 D2 low, while NES-101 leaves $4016 D2 as open bus. The same io_db-precharging method can detect it.
What is your hypothetical distribution situation where you are mass distributing cartridges all over the world but don't know where/whom you are sending them to?
If you're making and selling carts, there's not much reason they couldn't specify which language they'd like for the ROM at this point too. Nobody's making mask ROMs, there's no compelling reason why you would have to use the same ROM across different form factor of carts.
If you're releasing a ROM... just release two and let the user pick?
Or a simple menu on power-on is pretty inoffensive. (Infogrames did this with a 5-language release of Asterix, for example.) It's just 2 extra button presses. You could even skip it on reset with a RAM signature, if you needed a quicker reset.
With all those options... I really don't even understand why you'd want to do this by detecting the console type. Have already mentioned clones, which you'd need detection stats for each clone you want to account for. If played in an emulator, NES and Famicom emulators typically don't even have a setting to distinguish NES from Famicom, and most probably wouldn't properly emulate the stuff for this detection routine anyway. Nowadays clones are very common, but also it's common for people to have Famicom in English speaking countries and vice versa. Similarly lots of people have an NTSC NES in Europe. We're long past the days where this was uncommon.
Why do you want to go to all this trouble to make a decision about language for someone else, whom you know nothing about other than maybe what specific brand of console they used? It's intentionally picking one of the least reliable options you could for this.
On a Famicom, you probably don't want to display "Press player 2 Start to join in" or "Connect two Zappers for more fun!" because the console isn't wired to support them.
tepples wrote:
On a Famicom, you probably don't want to display "Press player 2 Start to join in" or "Connect two Zappers for more fun!" because the console isn't wired to support them.
So you're making a game cart that's intended to run in both NES and Famicom release but you've decided to choose the one button that doesn't exist on the Famicom to select 2 player mode? Why would you do that? With all the design options in the world, you choose the one that doesn't work on one of the systems you support instead of one that works on both.
Two zappers is its own bizarre left field thing, but sure I'm bored let's go down this hole: don't hide the existence of this feature from the user. Lots of people have access to other consoles besides the one they're playing on. Maybe they have friends, maybe they own more than one, etc. If you hide this because their current system can't handle it, they'll probably never think to try it elsewhere, and might miss out on this thing that they would have had a lot of fun with, even if only on rare occasions. Even worse, misdetection will hide the feature on systems that would support it. I don't think this is any good at all.
...and I'm not saying there's no utility at all in detecting it. Maybe there's a good case (allpads.nes seems a pretty good case), but I don't think these two are. My main point was that language choice very much isn't a good fit for this. There really are better options.
I was just wondering and it might be useful to someone (me?)
tokumaru wrote:
that I go through an entire post without understanding a single word of it! Seriously, it could just as well be written in Polish and I would have gotten just as much information from it.
I seem to have a habit of using quotes from you, tokumaru...
By the way, I mean the one lidnariq linked.
You did but it was 5 years ago and in a different context:
viewtopic.php?p=122051#p122051
Well done on finding the post
I'm with Rainwarrior. Tepple's system detecting program is very cool and I like it very much, but I'm also not sure how it could be useful for normal homebrew. Defaulting the language wouldn't be very useful since so many people have Famicoms outside Japan, and PAL systems and Famiclones are in all sorts of countries. This is a case when computer programs are trying to be "smart" and end up irritating the user because it doesn't work as it should.
Things like controller II START and SELECT buttons, microphone and double zappers are problems that are probably best avoided by never assuming the user have access to all that. If a game is using the microphone, just make sure there are another way to do the same thing without the microphone (like in Takeshi no Chousenjou: Press DOWN and A buttons on Controller II and after that the A button on Controller II will act as shouting into the mic).
NTSC, PAL, Famiclone and RGB PPU detection is probably far more useful as it could default some necessary settings that may not be clear for the user. But that would also require access to adjust these settings manually in case of being "smart" doesn't work. Personally I made settings for PAL pitch, PAL speed, PAL tint, duty cycle swap and RGB tint so the user can mix and match those settings depending on needs.
tokumaru wrote:
Seriously though, there are a few characteristics that can only be found in Famicoms, such as the inability to read from OAM, but that's just because the Famicom is older and the earlier units used older revisions of the PPU and CPU, but after the NES was introduced, they probably shared the exact same chips.
Famicom's with the earlier APU (without looped noise mode) are seemingly quite rare since Nintendo took back most of the earliest square button systems. The PPU where $2004 being write only is probably more common though. Most Famicoms I've seen are HVC-CPU-05 or later, and they usually have the newer CPU but maybe about half have the newer PPU.
orlaisadog wrote:
Most of the time? Just assume it's a normal NES, which is most common! Simple!
Not a chance! 60-pin systems (non-Nes) are far more common.
Pokun wrote:
Famicom's with the earlier APU (without looped noise mode) are seemingly quite rare since Nintendo took back most of the earliest square button systems. The PPU where $2004 being write only is probably more common though. Most Famicoms I've seen are HVC-CPU-05 or later, and they usually have the newer CPU but maybe about half have the newer PPU.
To spell this out explicitly:
1- 2A03letterless has no tonal noise
2- 2A03E,G,H, 2A07 and 2A07A have tonal noise
3- 2C02A,B,C,D,E, 2C03, 2C04, 2C05 cannot read from $2004
4- 2C02G can, but writes to $2003 corrupt sprite memory
5- 2C07, 2C07A can both read and write to $2004, writes to $2003 work as intended, but sprite memory is inaccessible sometimes, regardless of whether a picture is being drawn
6- 2C02H - who knows
Pokun wrote:
Not a chance! 60-pin systems (non-Nes) are far more common.
Over the years, there
might be comparable numbers of 2C02-based and cartridge-accepting famiclone systems. Wikipedia claims 62M authentic NESes/Famicom, of which more than half are in the US, more than a third are in Japan, and the remaining 1/7th are probably the authentic PAL consoles.
On the other hand, we know of more than
377 famiclones, and I bet none sold fewer than 50k units. 377·50k=18M all by itself, comparable to the number of authentic Famicoms.
Yeah, so in other words it's not very simple at all.
Pokun wrote:
PAL systems
What do you mean? How does that affect it? Personally I'd set PAL language to English, but I live in England so I might be biased.
Pokun wrote:
orlaisadog wrote:
Most of the time? Just assume it's a normal NES, which is most common! Simple!
Not a chance! 60-pin systems (non-Nes) are far more common.
I meant NES-001 vs NES-101. Also that was a joke.
Also, if we're so concerned about these clones (more than the originals) should we call this site "NesCloneDev"?
It's just that there are many people growing up with clones and still use them, and their behaviour is well known, so there is really no reason not to support them and limit your audience.
I'm not talking about languages, as I said that is very hard to guess for the user (generally using simple English in menus and such should be fine I think, that's what early Famicom games did anyway despite Japanese not being good at English). I'm talking about hardware differences that you as the programmer needs to consider if you want your game to behave the same on all systems.
Some of the basic differences are:
-PAL systems runs in 50 Hz (so you have to make your game run faster, including music tempo or it will sound different on PAL systems).
-PAL system has different sound frequencies (so you have to use a separate pitch table for your music notes or your sound will sound different on PAL systems).
-PAL swaps green and red color emphasis (so you have to consider this if you use the emphasis feature).
-PAL has longer vblank (just don't use the extra vblank time if you want your game to be NTSC-compatible)
-PAL requires OAM-DMA to happen early in vblank (just do your OAM-DMA early and you are good to go for all systems).
-UMC-based Famiclones has a mix of NTSC and PAL settings. For example they use PAL speed and NTSC pitch.
-UMC-based Famiclones swaps duty cycle 25% and 50% settings for pulse channels (so you have to make your sound engine swap these automatically if swapped duty cycle option is checked).
-RGB PPU uses color emphasis differently (so you might not want to use it the same way if the user has a Famicom Titler or other RGB-PPU machine).
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. If he has a PAL NES he would turn on both, and turn off both if he has NTSC and so on.
orlaisadog wrote:
Pokun wrote:
orlaisadog wrote:
Most of the time? Just assume it's a normal NES, which is most common! Simple!
Not a chance! 60-pin systems (non-Nes) are far more common.
I meant NES-001 vs NES-101. Also that was a joke.
I see.
I am not sure why you need to tell the difference between NES and AV Famicom, but telling the difference from NES and RF Famicom would be more useful, because RF Famicom has a microphone and does not have player 2 START and SELECT button.
The only thing about AV Famicom is that the controller ports don't connect all of the pins, but this is probably unimportant.
The fact that the cartridge doesn't fit also seems unimportant (an adapter will be used if needed), 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.
Pokun wrote:
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.
zzo38 wrote:
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.
zzo38 wrote:
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.
orlaisadog wrote:
Pokun wrote:
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.
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?
tepples wrote:
zzo38 wrote:
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.
Quote:
zzo38 wrote:
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).
zzo38 wrote:
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?
zzo38 wrote:
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?
tepples wrote:
zzo38 wrote:
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."
Quote:
zzo38 wrote:
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.
Fisher wrote:
Attachment:
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?
bazza wrote:
Has the photo of the another side of PCB?
Sorry, I don't own it now.
The board is "just" ANROM anyway, even using the same 74LS02 to invert R/W into an /OE signal for the ROM.
orlaisadog wrote:
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.
tepples wrote:
zzo38 wrote:
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.
Pokun wrote:
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?
Pokun wrote:
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.
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.
The east/west is officially Overseas/Japan setting.
Official 50Hz asian machines use 50Hz+overseas setting, nothing uses the 50Hz+Japanese setting.
Quote:
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).
rainwarrior wrote:
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.
SuperWill24 wrote:
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!
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).
Honestly, my opinion is just that no NES game should ever be played on a PAL console.
Compensating for PAL systems is and will always be a makeshift hotfix, and doing it for people who don't have much of a choice is a nice gesture, but I wouldn't go out of my way.
That's just as valid a viewpoint, and i get the wink. But in practice, it is only sustainable for a small group of very serious NES collectors (with deep enough pockets) out of the broader pool of PAL NES gamers to maintain that ideal.
If you ask the rest of your potential customer base in the PAL region to pay 30-45$ for a cartridge, 12-17$ shipping, and ~10$ import duty, you'd better either
-put a few hours into validating or having someone validate that it plays well enough on PAL
-be upfront about it not being tested properly
-provide a sample ROM (demo maybe) for the potential customer to validate
and if you found your test results a bit on the troublesome side (chances are it’s fine), again:
-see if you can look into it. also the sooner, the better. you can save yourself most of the sweat if you planned for it from the get go.
-be upfront about it.
for downloadables, it's not much of a problem. Less or no financial involvement, ease of distributing versions.
and of course, at that price point you’re bound to filter out a good deal of casual NES owners unless the game really hits a string within that demographic.
The PAL region might be maybe 10-20% (guesstimate) of your cartridge market, which isn't all that much, but it aint getting bigger if you ignore it. And it's a lot less work than doing a famicom release (where the thread started).
FrankenGraphics wrote:
That's just as valid a viewpoint, and i get the wink. But in practice, it is only sustainable for a small group of very serious NES collectors (with deep enough pockets) out of the broader pool of PAL NES gamers to maintain that ideal.
Exactly. No one would buy an NTSC console and maybe compatible TV just to play your game. Imagine this:
(sorry for the terrible editing)
FrankenGraphics wrote:
-put a few hours into validating or having someone validate that it plays well enough on PAL
-be upfront about it not being tested properly
-provide a sample ROM (demo maybe) for the potential customer to validate
Timed code is of course an issue, and I agree you should definitely take that into account!
Aside from the sheer concept of the game working or not working though, I don't think you should trouble yourself more than it's worth to make the game run 20% faster for the PAL territories, which is what I thought we were talking about. Anyone who lives in PAL-land and don't own an NTSC NES is already used to 80-90% of their NES game collection running slower than intended.
orlaisadog wrote:
Exactly. No one would buy an NTSC console and maybe compatible TV just to play your game. Imagine this:
(sorry for the terrible editing)
See above. I agree that an NTSC system shouldn't be required to make the game work. But if you want to play your NES games at the correct speed, you get an NTSC NES. "Retro gamers" for whom it matters have known this for decades. For the rest, they don't care anyway.
The ironic thing is you live in a PAL region but you still don't seem to like PAL console owners.
By the way, I don't own a console.
sumez wrote:
Timed code is of course an issue, and I agree you should definitely take that into account!
Aside from the sheer concept of the game working or not working though, I don't think you should trouble yourself more than it's worth to make the game run 20% faster for the PAL territories, which is what I thought we were talking about.
Then i think we're basically in agreement. Timed code is a main culprit to look out for. Emphasis bits is another, since someone thought it was brilliant to switch red and green. I explored ways to make palette animations smoother for a horror game for Orab. Just using all bits, and/or just the blue bit in tandem with palette compensations works great for lights on/off.
But if i wanted to use the red bit for sunset coming through a window or warning signals, that'd require a region detection feature.
For game speed compensation, see the Project Blue case. Games are variably better or worse at the slower PAL speed. Most are fine/good enough. Castlevania works because of on/off movement. Super Mario Bros. works because of open space, relatively free range movement, scrolling, and that the player is mostly either at max running speed. Project Blue has a *lot* of roadblocks, turns of direction, wait for the right moment tricks, no scrolling, screen switching - that you're riding the de/acceleration curve far more than SMB. They're kind of in opposite ends in that matter. Note that both these games initially had the exact same acceleration curve before PB got snappier + got the physics tweaked to fit both NTSC and PAL. SMB feels alright, but PB was initially more noticeably slow.
btw it's not all that dark for PAL. Whenever a game runs out of Vblank on NTSC is a moment where PAL excels.. provided the software doesn't forcibly cancel updates under the assumption of the Vblank being "NTSC narrow". Again in project Blue, you sometimes run out of bandwidth during the boss fights on level 1A & 1B, due to the numerous bullets, causing some visual artifacts. Not so on PAL; it's stable as a rock.
FrankenGraphics wrote:
btw it's not all that dark for PAL. Whenever a game runs out of Vblank on NTSC is a moment where PAL excels.. provided the software doesn't forcibly cancel updates under the assumption of the Vblank being "NTSC narrow".
True, but the update buffer might be sized for NTSC. In my experience, a buffer spanning the unused part of the stack page, such as $0108-$01BF, happens to be about the right size to fill NTSC vblank, and there isn't a lot of RAM in the system to store a bigger buffer. So a bigger buffer would likely need to be stored either in ROM (such as copying uncompressed tiles) or in WRAM at $6000. Where are you storing the source data for an update buffer bigger than 192 bytes?
Some updates don't need a buffer, such as patterns that go straight from the ROM to VRAM. Things that are constantly animating, such as the player and the background, will most likely not use compression, so you can copy them directly, instead of wasting time and space copying them to a buffer first.
Another example is my raycaster, which renders columns as fast as it can, and during vblank, as many columns as possible are copied to VRAM. The bigger is larger than what can be copied in one NTSC vblank, so the renderer doesn't need to be stalled, which would cause slowdown. PAL consoles can make even better use of the larger buffer by uploading more data (the whole buffer, in fact) to VRAM each frame.
My VRAM update system keeps track of how much buffer space is left, as well as how much time is left. Space is the same for NTSC and PAL, but the time is significantly increased for PAL, so that updates that don't need much buffer space can take advantage of it.
I'm honestly not quite sure what makes the PB boss fights on level 1 solid on a PAL NES, or what nmi/main topology it is using. I have never bothered asking for a look at the source. I'm just assuming that since NMI strikes less frequently, game logic manages to finish up all the metasprite handling before the OAM buffer is uploaded, even in more crowded scenarii. Mostly, rooms are designed to avoid sprites flashing up in the wrong places on NTSC, but there are a few exceptions where other goals were prioritized. This game doesn't need to update the nametable frame for frame since it doesn't scroll, and all bg animations are palette based.
Tokumarus' example sounds like the ideal NTSC/PAL-aware implementation for NT updates, though.
Else, wRAM isn't costly (~1$?), and might be an option if you're thinking about blowing the internal RAM budget anyway or about having battery saves (~1-2$ for battery and battery clip?).
OP: aren't you glad you started this thread?
orlaisadog wrote:
The ironic thing is you live in a PAL region but you still don't seem to like PAL console owners.
I don't think I ever implied that I have anything against anyone. I just don't like the PAL consoles.
Doesn't that make sense, too? As a European, I've been shafted hard by the concept of PAL games and consoles all the way up to the 6th console generation.
FrankenGraphics wrote:
btw it's not all that dark for PAL. Whenever a game runs out of Vblank on NTSC is a moment where PAL excels.. provided the software doesn't forcibly cancel updates under the assumption of the Vblank being "NTSC narrow"
I guess that bears mentioning - PAL itself is actually great. The issue here isn't the PAL standard, but the fact that PAL was always second fiddle to NTSC on the video games market. If PAL had been the international standard, we'd have 288p games with less slowdown.
Instead we got European releases running too slow, with huge black borders on the top and bottom of the screen.
Sumez wrote:
If PAL had been the international standard, we'd have 288p games with less slowdown.
I'd hunch that in that alternate history, second and third generation consoles probably would have drawn 256 visible scanlines, for memory addressing reasons. (In comparison, most of the 2nd generation NTSC consoles only drew the 192 scanlines in the title-safe area; 256 out of 269 scanlines isn't too badly underscanned; and the costs of complexity memory to go above 256 is a lot bigger than to stay a little below 256 )
For 8 bit consoles, absolutely.
rainwarrior wrote:
Pokun wrote:
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 think it was that Dizzy game, I saw it being mentioned on the wiki, I've never played it myself.
I didn't knew there were any licensed games doing it though. As you said it was partly a region lockout thing, so I don't think Nintendo would want it normally.
rainwarrior wrote:
Pokun wrote:
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.
I fully agree!
Although I think it may be a good idea to give the user options to manually set the flags you use to compensate these things, in case the user is using a setup not covered by the detection routine somehow. For example can you test things like emphasis flags? I don't know if all UMC-based Famiclones are using PAL emphasis or if only the PAL ones (like Dendy and Pegasus) do. Then there is the RGB PPU that I'm not sure if it can be detected at all.
If the game isn't using any way to save it might get tiresome to set the options every time you start the game though.
FrankenGraphics wrote:
Timed code is a main culprit to look out for. Emphasis bits is another, since someone thought it was brilliant to switch red and green. I explored ways to make palette animations smoother for a horror game for Orab. Just using all bits, and/or just the blue bit in tandem with palette compensations works great for lights on/off.
But if i wanted to use the red bit for sunset coming through a window or warning signals, that'd require a region detection feature.
On a Famicom Titler (or other RGB PPU setup), instead of dimming the screen it will just become all white when you set all the emphasis bits though.
Edit: Oops I somehow missed that you were setting the blue flag, not all flags at once.
Pokun wrote:
For example can you test things like emphasis flags? I don't know if all UMC-based Famiclones are using PAL emphasis or if only the PAL ones (like Dendy and Pegasus) do. Then there is the RGB PPU that I'm not sure if it can be detected at all.
If the game isn't using any way to save it might get tiresome to set the options every time you start the game though.
I'm not sure how reliable using the frame vs CPU timing stat is to determine emphasis color. NTSC NES, Famicom, PAL NES and Dendy seem to be mostly consistent, though there are some rarer but official RGB variations of the PPU which implement emphasis in a very different manner too. Other clones, who knows, and also a
lot of emulators don't have different emphasis colour for PAL. (I suspect there are quite a few emulators that don't implement emphasis at all, actually.)
Since there's no direct feedback of this information from the PPU itself, I agree the most appropriate thing is to ask the user. It's very common in modern games to do gamma correction configured by the user on first play. "Adjust the brightness until (something) is barely visible."
Since flash ROM is common, you might be able to use this to save settings, though you have to give up a whole block to that save ability (depends on flash type, maybe 4k).
Pokun wrote:
On a Famicom Titler (or other RGB PPU setup), instead of dimming the screen it will just become all white when you set all the emphasis bits though.
I think it's pretty safe to ignore compatibility with Famicom Titler, Famicom TV, vs. system and playchoice. I also think modders should understand they're making their console off-spec. My rationale is basically that i'd rather make practical effects that show what the NES can actually do, than limit myself to make it work with obscure collector curiosities. If you have a Famicom titler, you likely have another NES/famicom too. Besides, I find the $2d and $3d colours very versatile in many situations, so that boat has sailed long ago
FrankenGraphics wrote:
Pokun wrote:
On a Famicom Titler (or other RGB PPU setup), instead of dimming the screen it will just become all white when you set all the emphasis bits though.
I think it's pretty safe to ignore compatibility with Famicom Titler, Famicom TV, vs. system and playchoice. I also think modders should understand they're making their console off-spec. My rationale is basically that i'd rather make practical effects that show what the NES can actually do, than limit myself to make it work with obscure collector curiosities. If you have a Famicom titler, you likely have another NES/famicom too. Besides, I find the $2d and $3d colours very versatile in many situations, so that boat has sailed long ago
And it's also possible to test for RGB PPU (I think it doesn't have the missing pixel) so you could display a warning and/or change the behavior. I believe I wrote a test for this but I can't remember if anybody ever got around to running it in an RGB PPU setup...
FrankenGraphics wrote:
I think it's pretty safe to ignore compatibility with Famicom Titler, Famicom TV, vs. system and playchoice. I also think modders should understand they're making their console off-spec. My rationale is basically that i'd rather make practical effects that show what the NES can actually do, than limit myself to make it work with obscure collector curiosities.
Why ignore compatibility when you can make it an option and actually be compatible, though? Yes you can say "it's your fault that you modded your system", but if you're already supporting RG swap it's probably not that much effort to have a third option to disable emphasis too. At least, I think I would want to put that small amount of work not to just throw away that minority of potential users.
It wouldn't look ideal with emphasis disabled, but the point is that it would still be playable that way.
(Also that "obscure collector" may be a minority, but I suspect that same kind of person is more likely to be a vocal supporter too. In my view not a good trade to ignore, at least for something like this where I think the effort required is low.)
It's a good idea.
Some thoughts:
-an RG swap will look the part on both NTSC and PAL, so i feel this is the easiest, totally straightforward case.
-i'm interested in looking into if hue compensation between NTSC/PAL is warranted. Are even there cases where hue is so unevenly shifted that another colour entry is more 1:1 between the systems?
-missing $2d (especially) and $3d colours can't be easily replaced by 00 and 10, if you're intentionally using $2d and $3d for specific techniques where 00 and 10 won't do as good. I use $2d a lot more than $00, it is overall more useful to me. It is for example a really nice blend together with $0x colours to get a washed out effect or smooth blending artifacts in a dithery texture. 00 is often too bright for both these purposes; it stands out which is good in other cases, but not always here. $3d mostly gives a little extra highlight that stands out a little better when next to certain colours, but the small difference makes the compromise more acceptable. And of course, they'll "suffice" better than unintentional black holes in the graphics, so..
-for dimming, a technique i'm sometimes using is to use it in order to get a more desaturated palette (you need to compensate by moving some palette slots up a brighness level). This can't be portrayed at all on the listed systems.
-i also use dimming to get a smoother grayscale. This screen below is using both the $2d that is missing on RGB PPU:s, and dimming. The plastic casing would be plain white without dimming. You can't really compensate for the lack of dim with other colour choices, which is even worse. Dimming + $2d is the only way to make it as life-like as possible.
Attachment:
File comment: Work in progress. Dimmed.
controllerconfig_wip.bmp [ 30.12 KiB | Viewed 1894 times ]
Basically, sometimes it just won't look right no matter what you do for these quirky fringe variants. Making it work better is, well, better, but it's definitely in the nice gesture/extra mile territory someone was mentioning before. I'd still probably stick something like an "doesn't look as good on with RGB PPU mod. Use an unmodified console for the best experience." disclaimer somewhere. It won't be as satisfying playing on these systems, so it'd be best to be upfront about it.
FrankenGraphics wrote:
-i'm interested in looking into if hue compensation between NTSC/PAL is warranted. Are even there cases where hue is so unevenly shifted that another colour entry is more 1:1 between the systems?
This was definitely done routinely on some later consoles. For NES though, I don't think there is enough hue resolution to really get the same colours anyway, and the NES is hardly able to produce "natural" looking colours even in the best conditions. I don't know the technical specs, but it the difference doesn't really seem to be equivalent to something simple like just a hue shift, it's a whole distortion of the colour space. I think it'd be hard to improve on the fidelity of just leaving it as-is, at least with the palette approximations I've seen?
FrankenGraphics wrote:
-missing $2d (especially) and $3d colours can't be easily replaced by 00 and 10, if you're intentionally using $2d and $3d for specific techniques where 00 and 10 won't do as good. I use $2d a lot more than $00, it is overall more useful to me. It is for example a really nice blend together with $0x colours to get a washed out effect or smooth blending artifacts in a dithery texture. 00 is often too bright for both these purposes; it stands out which is good in other cases, but not always here. $3d mostly gives a little extra highlight that stands out a little better when next to certain colours, but the small difference makes the compromise more acceptable. And of course, they'll "suffice" better than unintentional black holes in the graphics, so..
This one's harder to compensate for. It also really sucks that some commonly used emulator palettes don't make these colours distinct from $00 and $10. However, the minimum you have to do is just make the error cases where they appear black, or the same as the other greys, not make the game critically unplayable. (Much less of a problem than the 3 emphasis bits whiting out the whole screen.)
FrankenGraphics wrote:
-i also use dimming to get a smoother grayscale. This screen below is using both the $2d that is missing on RGB PPU:s, and dimming. The plastic casing would be plain white without dimming. You can't really compensate for the lack of dim with other colour choices, which is even worse. Dimming + $2d is the only way to make it as life-like as possible.
There's a point where you might be using a colour distinction that is too small to be reliable even on the majority case. How much can you e.g. adjust the gamma on the image before the subtle balance you're relying on doesn't work anymore? TVs vary a lot on this.
Though at least graduations of grey should be monotonic, their relative distinction from each other is going to be less reliable. (Probably far less of a problem than trying to use horizontal hue relationships in the palette for relative brightness, though, as
discussed in the past).
...though maybe this particular case is fine. I'd say the most important thing to do is just test things out in different conditions as much as you can. Use NTSC simulators with the settings in different extremes, etc. (I really wish we had more available PAL simulation.)
FrankenGraphics wrote:
I'd still probably stick something like an "doesn't look as good on with RGB PPU mod. Use an unmodified console for the best experience." disclaimer somewhere. It won't be as satisfying playing on these systems, so it'd be best to be upfront about it.
Absolutely. Though actually I think most modern RGB mods implement emphasis correctly. I'm not sure how I'd describe this particular set of problem hardware succinctly.
The main thing I meant about compatibility is just that
unplayable is a
very bad error case. Obvious graphical glitches that don't stop you from playing the game is almost insignificant compared to that (the ubiquity of sprite flicker is a testament to this). The graphics not quite looking their best is even less significant, relatively speaking. So... to me the amount of effort I'd want to spend mitigating these different cases would probably be proportionate to that. If it's not hard to prevent unplayability, for sure I'd try to do so.
This went from a technical question about NES/Famicom detection to a debate/discussion about emphasis bits.
orlaisadog wrote:
This went from a technical question about NES/Famicom detection to a debate/discussion about emphasis bits.
Now you understand why earlier I said "aren't you glad you started this thread?" People on this forum being unable to stay focused on the topic at hand is a recurring problem. You never really get used to it -- instead, you learn to filter out all the unrelated/irrelevant tripe, while facepalming and drinking hard liquor.
The original question was answered:
Q. How do you distinguish an authentic NES from an authentic Famicom from within a program intended to run on either?
A. NES drives bits 4 and 3 of $4016. Famicom leaves them open bus. Check whether bits 4 and 3 of $4016 are open bus by (ab)using the 6502 page wrapping quirk and the 2C02 io_db quirk.
The rest of the topic so far is just increasingly elaborate ways to ask "Why would you want to do that?". But did anyone get a chance to try the answer that was provided?
koitsu wrote:
orlaisadog wrote:
This went from a technical question about NES/Famicom detection to a debate/discussion about emphasis bits.
Now you understand why earlier I said "aren't you glad you started this thread?" People on this forum being unable to stay focused on the topic at hand is a recurring problem. You never really get used to it -- instead, you learn to filter out all the unrelated/irrelevant tripe, while facepalming and drinking hard liquor.
Haha couldn't have said it better myself (jk, I'm a culprit myself here)!
But yeah the question was answered at the beginning of the thread. Although it's probably not easy to understand unless you learn more about the NES, so OP go on and study more and come back to it when you are wiser. It will pay off.
Actually I think this thread managed to stay much closer to the topic than usual. The discussion went on with that things like PAL, RGB PPU, clones and such may normally be more beneficial to distinguish between than just Famicom and NES.
Yeah, I do think "why would you want to do that" is actually an important question to further discussion of almost any programming/design question.
From work experience, I often see people coming in with a solution in their head, but backtracking to the actual issue they are trying to solve and trying to think "outside the box", usually results in a much better approach.
koitsu wrote:
Now you understand why earlier I said "aren't you glad you started this thread?" People on this forum being unable to stay focused on the topic at hand is a recurring problem. You never really get used to it -- instead, you learn to filter out all the unrelated/irrelevant tripe, while facepalming and drinking hard liquor.
I think offtopic discussion is good.
Pokun wrote:
Although it's probably not easy to understand unless you learn more about the NES, so OP go on and study more and come back to it when you are wiser. It will pay off.
I need to do that.
rainwarrior wrote:
Though actually I think most modern RGB mods implement emphasis correctly.
If that's the case, then automatic RGB PPU detection might actually deteriorate the experience unnecessarily for some RGB PPU mod users. An configuration screen where you either can a) set compatibility modes manually or b) disable automatic compatibility measures sounds like a good measure in this specific case.
Would RG emphasis still be flipped if an RGB mod with functioning emphasis was applied to a PAL console? That'd be a somewhat tricky situation.
rainwarrior wrote:
I'm not sure how I'd describe this particular set of problem hardware succinctly.
Me neither, that needs to be worked on.
Quote:
It also really sucks that some commonly used emulator palettes don't make these colours distinct from $00 and $10.
Agreed. Especially if they are popular among people who use emulators to play games, rather than develop them.
rainwarrior, regarding hue compensation ntsc/pal wrote:
and the NES is hardly able to produce "natural" looking colours even in the best conditions.
Yeah, it wouldn't be any sort of correction in the photographic sense. But just maybe there might be some cases where the semantic connotations of a colour trips over a threshold in some context. Basically, the colours may broadly represent different things. The problematic $22 is one such case. The problem isn't so much the hue variance in itself as what semantic connections we make. I don't think there's a general ruleset you can apply. Any hue changes probably needs to be evaluated case-for-case. The question i'd be asking in those cases would be: "If a colour looks bad/wrong for its intended use on PAL (or RGB PPU:s i guess), what would be the less offending alternative? Is there one?" This is a low priority, of course. Just like you said, game breaking features are more important than experience varying ones.
FrankenGraphics wrote:
rainwarrior wrote:
Though actually I think most modern RGB mods implement emphasis correctly.
If that's the case, then automatic RGB PPU detection might actually deteriorate the experience unnecessarily for some RGB PPU mod users. An configuration screen where you either can a) set compatibility modes manually or b) disable automatic compatibility measures sounds like a good measure in this specific case.
Would RG emphasis still be flipped if an RGB mod with functioning emphasis was applied to a PAL console? That'd be a somewhat tricky situation.
I'm not entirely sure what thefox's suggested method for detecting an RGB PPU is (counting cycles per frame a few times to catch that .5 cycle difference?), but I don't think the test would detect newer mods which leave the original PPU intact and generate a whole new picture signal in tandem. I'm not sure though, this seems like an open research survey question to me. I think the test would at least be good enough to distinguish 2C02 from the PC10/Sharp/etc 2C03/2C05 PPU replacement mod. Clones and emulators might be a lot more difficult problem.
There's some info on mods here:
http://retrorgb.com/nesrgb.htmlThe main culprit for emulator palettes that get the greys wrong is that awful FCEUX palette, I think, which is unfortunately way too popular. It made its way into both the AVS and the Hi-Def NES firmwares. Some info:
http://rgbsource.blogspot.com/2016/10/a ... sited.htmlFWIW I don't think people are really doing the PC10 mod any
more, since the newer RGB mod seems to be wholly better and cheaper, and doesn't rely on old parts. However... there's still lots of PC10 mods in the wild, and I doubt they'd get replaced under normal circumstances. (I wouldn't assume that someone who has a modded system or a titler would automatically have another system for back-up, either. Some would, but I'm sympathetic to a person who can't afford to acquire a second machine, or even would just rather play it on their favourite. There really aren't that many games that the titler emphasis breaks anyway, and the titler was popular enough in Japan to get a warning on some game boxes about the problem.)
Even the swapped RG emphasis thing... there's a problem because
no games actually relied on it, so emulators getting it wrong for PAL really didn't have much consequences. This is also relatively new knowledge and didn't even hit the Wiki until
a small footnote in late 2014, so even the "new" RGB mod isn't something I'd assume will get this right for PAL by default. (AVS and Hi-Def NES I would assume have done their homework here, though.)
Maybe it would be useful to extend the
$0D games article to include the other D column colours too. I actually have no idea which games used them, but I think it's similarly rare.
In short: those things in particular (emphasis and column D greys) are reliable hardware features on the original thing, but really iffy everywhere else because there just weren't any games to nail that stuff down for emulators or clones.
If I was going to rely on emphasis colours, I'd definitely make it a user configurable option just because the swapping was poorly known for so long. My naive idea of how to implement that would just be with 8 byte lookup tables, so it would be really easy to add a 3rd table of 0s to disable emphasis for the other case (that's what I mean about it probably being low effort to gain compatibility here). As for the extra greys... I don't think any code compensation is very useful, but just as long as those colours dropping out or being the wrong shade of grade doesn't stop the user from being able to play, they're probably alright to use.
...though I suppose you could implement a grey simulation mode that alternates $00-$0F every frame in lieu of $2D, and $10-20 for $3D.
That seems like going way over the top though. Then again,
Macbee took that concept to its extreme for Lucky Penguin, and then there's that Batman game or Alien Syndrome, etc. that use alternating frames for a blend too.
...and deciding that caring about the inaccurate/modded/Titler cases is too much effort is a valid way to look at it anyway, just for me I don't think I'd ever take that attitude except for maybe a tech demo. I want as many people to be able to play my games as I can manage, and that shapes my opinion on this.
The practical problem with user configurability is that users would find reconfiguring everything every time the system is turned on tedious. To atttempt to avoid that, you'd have to 1. make your mapper self-flashable, 2. exhaustively test that your configuration saving won't overwrite the game, and 3. hope the user doesn't regularly use two or more consoles or TVs with different characteristics.
Or just use save RAM? Why do we need to do that?
If a game doesn't already use RAM at $6000, you're adding the complexity and slowdown of using (say) MMC1 instead of UNROM, as well as a larger PCB and SRAM to the bill of materials. If a game already uses RAM but doesn't battery back it, you're adding a battery, passives, and an
SRAM power controller IC to the bill of materials. And you're still not handling the case of multiple consoles or multiple TVs.
tepples wrote:
The practical problem with user configurability is that users would find reconfiguring everything every time the system is turned on tedious.
Is it really, though? I think you may be overstating this problem.
How tedious was SMB / Duck Hunt's menu?
How tedious is Asterix's language select?
How tedious is selecting 2 players in Contra?
How tedious is selecting Easy mode in Lizard?
I don't know what you're envisioning, but there's little reason a simple option menu can't be a snap to operate, and this kind of thing was done in all sorts of NES games already.
orlaisadog wrote:
Or just use save RAM? Why do we need to do that?
If your game already has a save feature planned (either through SRAM or Flash), there isn't even a theoretical issue here.
tepples wrote:
And you're still not handling the case of multiple consoles or multiple TVs.
Come on, you're really arguing that we need multiple saved option profiles on an NES cart because it's too "tedious" to change them? They already have to physically pull the cartridge out of that machine, put it in another, switch TV hookup etc. you think spending 2 seconds changing an option is a problem???
Edit: was too slow in my edit, moved to a subsequent reply.
rainwarrior wrote:
tepples wrote:
The practical problem with user configurability is that users would find reconfiguring everything every time the system is turned on tedious.
Is it really, though? I think you may be overstating this problem.
How tedious was SMB / Duck Hunt's menu?
The menu in
SMB/DH has two steps: 1. which game, and 2. how many players (or how many ducks). Full configurability for a game like this would involve setting scanline count (262 or 312), NMI scanline (241 or 291), DPCM glitch compensation (on or off), CPU:PPU ratio cycle ratio (3 or 3.2), emphasis (NTSC BGR, PAL BRG, or 2C03 none), and probably a bunch more differences mentioned previously. That's a lot more than two steps.
tepples wrote:
The menu in SMB/DH has two steps: 1. which game, and 2. how many players. Full configurability for a game like this would involve setting scanline count (262 or 312), NMI scanline (241 or 291), DPCM glitch compensation (on or off), CPU:PPU ratio cycle ratio (3 or 3.2), emphasis (NTSC BGR, PAL BRG, or 2C03 none), and probably a bunch more differences mentioned previously. That's a lot more than two steps.
Too quick for me to edit more into my previous post.
Yes, I started to wonder that maybe maybe you're thinking about like a full 240p suite of calibration or something, but even if you thought that was necessary and it was necessarily a tedious process, they only need to do that once/occasionally as a means to discover the correct settings. They don't need to do that every time once they know what settings they want. Or whatever, this is getting a bit theoretical, but there are a lot of ways to not make this "tedious", IMO.
If we're discussing real games with actual needs, I doubt there's a practical need for more than 1 or 2 settings. Maybe 3 if you're pushing it. You're really planning to make a game that relies on
all of these things at once?? Why would you even want to do that? It sounds like you're making the game specifically about the "problem" of making the most problem out of the options.
The concrete use case I have in mind is rhythm games, which will become practical once key patents start to expire a year from now.
- Controllers that would be useful for some music game concepts, such as the Power Pad and Arkanoid Controller, differ in their protocol between NES and Famicom.
- The note chart in Guitar Hero is drawn like a road, and drawing barlines needs a raster effect like in 3D WorldRunner. This depends on CPU:PPU clock ratio, which differs between 2A07+2C07 and everything else.
- In a game centered around music, the player might reasonably expect thicker instrumentation than nsf_classic (BotB's term for 2A03 without the DPCM channel) alone can provide, and if compatibility with an unmodified NES is expected, this means samples. Reading an Arkanoid Controller requires carefully working around a quirk of the 2A03's DPCM DMA. A workaround to avoid this quirk by using OAM DMA is available, but it should not be used on 2A07 because the 2C07 requires OAM DMA to occur early (finishing within 20 lines after NMI).
- Music tempo depends on the PPU scan rate.
- Relative pitch between samples differs between the 2A07 and everything else.
- PAL has more vblank time. If not a lot of vblank time is available, the game might fall back to simpler background animations.
- The method to unlock this extra vblank time differs between PAL NES and PAL famiclones.
Just to reiterate, I think that detecting between NTSC, PAL and DENDY timings for the purpose is can be very practically automated. I don't think this is error prone, or even really needs a user option as long as you're only adjusting timings with it. There are enough games out there that have ensured that almost all emulators and clones get that much right enough to use. That covers most cases of raster effects, music adjustment, etc.
All this stuff about configurable number of scanlines, length of vblank, somehow needing an Arkanoid controller for a rhythm game, etc. whatever. If you want to make Configuration Hell: The Game, fine. I'm not trying to give advice to the person who's determined to create an intractable compatibility problem.
For another thought about designing around the idea that the options are tedious. You could even make it part of the game somehow. How about a room early on in your game where you're instructed to "walk toward the red light" and there's a light that comes on, enabling red emphasis as you get close, and a second one that's the same but green?
That idea could actually work as a game- simple 3D graphics like that where that is the first level.
tepples wrote:
The practical problem with user configurability is that users would find reconfiguring everything every time the system is turned on tedious. To atttempt to avoid that, you'd have to 1. make your mapper self-flashable, 2. exhaustively test that your configuration saving won't overwrite the game, and 3. hope the user doesn't regularly use two or more consoles or TVs with different characteristics.
Other possibility: Add switches into the cartridge. One switch controls auto/manual, and the other switches select the settings in manual mode.
That's actually a very good idea!
Yeah only the cartridge needs a bit more work than normally, and emulation would get more complicated since you modify a standard mapper.
rainwarrior wrote:
All this stuff about configurable number of scanlines, length of vblank, somehow needing an Arkanoid controller for a rhythm game, etc. whatever. If you want to make Configuration Hell: The Game, fine. I'm not trying to give advice to the person who's determined to create an intractable compatibility problem.
Hahaha
I don't know so much about Famiclones but I think there are several UMC clones and not all of them swaps duty cycle settings for example, so simply having a "Dendy mode" probably only catches the classic Dendy and Pegasus based on Micro Genius IQ-501 and IQ-502. Also I heard Dendy and Pegasus are somehow modified for PAL no? I mean Micro Genius is Taiwanese, an NTSC country.
I think the tediousness is worst for quick or simple games that does not save. Like "I feel like going for a quick round of Tetris! Oh crap all these options again, now where did the manual go?".
Pokun wrote:
I don't know so much about Famiclones but I think there are several UMC clones and not all of them swaps duty cycle settings for example, so simply having a "Dendy mode" probably only catches the classic Dendy and Pegasus based on Micro Genius IQ-501 and IQ-502. Also I heard Dendy and Pegasus are somehow modified for PAL no? I mean Micro Genius is Taiwanese, an NTSC country.
I think the tediousness is worst for quick or simple games that does not save. Like "I feel like going for a quick round of Tetris! Oh crap all these options again, now where did the manual go?".
Yes, duty swap is something that's known to be inconsistent across clones, and I don't think it's possible to test for without human interaction. ...though at the same time, swapped duty isn't something that would make a game unplayable
* either, so it's not necessarily a problem you need to solve. If you've got an options menu, maybe not too tough to throw in, but automatically swapping duty for Dendy-style timings I think is going to have many false positive cases. (Sort of funny counterpoint, but many Dendy owners who were used to the music sounding a certain way had requested being able to intentionally swap duties in NSFPlay, so maybe also consider that sometimes the "wrong" thing is still desirable.)
When I said NTSC / PAL / DENDY, I meant the three timing styles. I've never heard of a clone or emulator that doesn't fall into one of these 3 timing categories, aside from some experimental overclocking.
Dendy is a 50hz machine intended for PAL regions, but very compatible with games made for NTSC assuming the 17% slowdown is acceptable. (Has same cycles per scanline as NTSC NES, just compensates with extra blank scanlines at the end of the frame where they will rarely do harm.) It was made for pirating NTSC region games, not the official PAL games.
* Please don't contrive some silly example of using inverted channels to completely cancel phase on some sound effect that is somehow mission critical.
rainwarrior wrote:
Yes, duty swap is something that's known to be inconsistent across clones, and I don't think it's possible to test for without human interaction.
Actually maybe you can test it if you really wanted to; if it is a Famicom cartridge then the audio goes through the cartridge, so it may be possible to detect.
I guess that would require some special hardware in the cartridge though, but yeah I guess.
Well if duty cycle really is the only thing that's inconsistent it may not be such a big problem. It's not like the duty cycle swap makes the song go out of tune or anything, I guess that's why the cloners didn't notice the mistake in the first place. Regarding people growing up with the wrong duty, it wouldn't really apply to a newly produced homebrew though. If I made a song I may want people to remember it with the qualities I choose, preferably as consistent as possible for all players. I included a "tuning fork" in the options menu that plays a square channel at 440 Hz and with 50% duty cycle so the user can check pitch and duty of his machine himself. Now the problem is how to explain how 50% vs 25% duty sounds in the manual.
rainwarrior wrote:
* Please don't contrive some silly example of using inverted channels to completely cancel phase on some sound effect that is somehow mission critical.
That's Tepple's job.