Is NES/Famicom detection possible?

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

Moderator: Moderators

User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Is NES/Famicom detection possible?

Post by FrankenGraphics »

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 :lol:
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Is NES/Famicom detection possible?

Post by thefox »

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 :lol:
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...
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Is NES/Famicom detection possible?

Post by rainwarrior »

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.)
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Is NES/Famicom detection possible?

Post by FrankenGraphics »

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.
Work in progress. Dimmed.
Work in progress. Dimmed.
controllerconfig_wip.bmp (30.12 KiB) Viewed 3564 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.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Is NES/Famicom detection possible?

Post by rainwarrior »

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.
Last edited by rainwarrior on Wed Jul 25, 2018 3:55 pm, edited 2 times in total.
User avatar
orlaisadog
Posts: 166
Joined: Thu May 31, 2018 11:12 am
Location: Bristol, England

Re: Is NES/Famicom detection possible?

Post by orlaisadog »

This went from a technical question about NES/Famicom detection to a debate/discussion about emphasis bits.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Is NES/Famicom detection possible?

Post by lidnariq »

Welcome to the forums!
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Is NES/Famicom detection possible?

Post by koitsu »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Is NES/Famicom detection possible?

Post by tepples »

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?
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Is NES/Famicom detection possible?

Post by Pokun »

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.
User avatar
Sumez
Posts: 919
Joined: Thu Sep 15, 2016 6:29 am
Location: Denmark (PAL)

Re: Is NES/Famicom detection possible?

Post by Sumez »

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.
User avatar
orlaisadog
Posts: 166
Joined: Thu May 31, 2018 11:12 am
Location: Bristol, England

Re: Is NES/Famicom detection possible?

Post by orlaisadog »

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.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Is NES/Famicom detection possible?

Post by FrankenGraphics »

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.
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.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Is NES/Famicom detection possible?

Post by rainwarrior »

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.html

The 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.html

FWIW 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. :P 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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Is NES/Famicom detection possible?

Post by tepples »

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.
Post Reply