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 agoPokun 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.
Is NES/Famicom detection possible?
Moderator: Moderators
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: Is NES/Famicom detection possible?
Re: Is NES/Famicom detection possible?
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. 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 agoPokun 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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Is NES/Famicom detection possible?
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.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.
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.)
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: Is NES/Famicom detection possible?
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. 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.
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. 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.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Is NES/Famicom detection possible?
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:-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 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:-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..
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.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.
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.)
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.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.
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.
- orlaisadog
- Posts: 166
- Joined: Thu May 31, 2018 11:12 am
- Location: Bristol, England
Re: Is NES/Famicom detection possible?
This went from a technical question about NES/Famicom detection to a debate/discussion about emphasis bits.
Re: Is NES/Famicom detection possible?
Welcome to the forums!
Re: Is NES/Famicom detection possible?
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.orlaisadog wrote:This went from a technical question about NES/Famicom detection to a debate/discussion about emphasis bits.
Re: Is NES/Famicom detection possible?
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?
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?
Re: Is NES/Famicom detection possible?
Haha couldn't have said it better myself (jk, I'm a culprit myself here)!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.orlaisadog wrote:This went from a technical question about NES/Famicom detection to a debate/discussion about emphasis bits.
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.
Re: Is NES/Famicom detection possible?
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.
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.
- orlaisadog
- Posts: 166
- Joined: Thu May 31, 2018 11:12 am
- Location: Bristol, England
Re: Is NES/Famicom detection possible?
I think offtopic discussion is good.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 need to do that.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.
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: Is NES/Famicom detection possible?
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.rainwarrior wrote:Though actually I think most modern RGB mods implement emphasis correctly.
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.
Me neither, that needs to be worked on.rainwarrior wrote: I'm not sure how I'd describe this particular set of problem hardware succinctly.
Agreed. Especially if they are popular among people who use emulators to play games, rather than develop them.It also really sucks that some commonly used emulator palettes don't make these colours distinct from $00 and $10.
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.rainwarrior, regarding hue compensation ntsc/pal wrote:and the NES is hardly able to produce "natural" looking colours even in the best conditions.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Is NES/Famicom detection possible?
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.FrankenGraphics wrote: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.rainwarrior wrote:Though actually I think most modern RGB mods implement emphasis correctly.
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.
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. 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.
Re: Is NES/Famicom detection possible?
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.