MiSTer FPGA Forum

Came across an Atermio video showing MiSTer color options for the recent palette work. Looking forward to see this land.

Interesting. My TG16 hardware is non-functional for a long time (one of the reasons I got a mister to begin with) so I've never done a direct compare.

You may achieve something similar by using an RGB to composite converter, and just let the NTSC decoder on your monitor process the colors in the same way that it would have for the original composite output of the OCE. The VGA2NTSC could be used for this conversion.

Peredonov wrote: ↑Tue Jul 21, 2020 4:28 am You may achieve something similar by using an RGB to composite converter, and just let the NTSC decoder on your monitor process the colors in the same way that it would have for the original composite output of the OCE. The VGA2NTSC could be used for this conversion.

No, that's not correct. The HuC6260 has a color lookup table for the conversion from RGB to Y/R-Y/B-Y which is not a direct translation.

The RGB had been considered as being a linear scale to apply each colour, but it turns out that there isn't enough space between some of the indexes to make a visible difference; this was the function of the Y/R-Y/B-Y conversion, which makes those less-visible transitions more visible.

This is a bit of an hardcore talk for me, but to contribute, on my first gen PCE RGB modded back in 1989, the colours were strikingly bright, even more than what the core displays currently (although different screen probably got a part in this too). This is why I enjoyed playing PCE games more in NTSC composite back then.

The issue is that RGB output - from emulators, FPGA systems, or modded hardware - are oversaturated for some colours. The index table used in the HuC6260 to transform into composite, makes for a more even spectrum of what the eye can discern.

Skin tones are too red on RGB, and there are also various other colour distortions, although to be fair, it's not an entirely different colour representation so many people have felt that the RGB output was basically the same colour set (although it's very different in some specific situations).

Ha ha, I totally remember the redskinned humans. I was striking as strange but whatever goes back then, and had totally forgotten about that.
I had no idea there were index tables and such. As a player, you take everything for granted, but it's funny to get glimpses of how the innards work.

dshadoff wrote: ↑Tue Jul 21, 2020 12:24 pm No, that's not correct. The HuC6260 has a color lookup table for the conversion from RGB to Y/R-Y/B-Y which is not a direct translation.

I didn't know this. In that case only the palette approach suggested by the original post would work. Fortunately this is not like the NES situation where no palette can accurately represent the NTSC colors fully, since the HuC6260's table values are known. So the PCE core would be able to give the best of both worlds, virtually the same colors as the original composite output but with the clarity of RGB (perhaps in combination with a gamma setting to further approximate the original picture via composite).

I went back to take a look at the progress on this. I see Kitrinx had a commit 15 days ago.

0x15e wrote: ↑Mon Sep 07, 2020 6:45 pm I did a build of that core and can definitely notice the difference. It's subtle but it definitely helps some details pop a little better.

What I'm curious about now is if / how the NTSC artifacting discussed here will be addressed.

Never say never.
But there's a lot to research before any effort is made toward such a thing.

0x15e wrote: ↑Mon Sep 07, 2020 6:45 pm What I'm curious about now is if / how the NTSC artifacting discussed here will be addressed.

Would you end up emulating the end result, or would you try to reproduce the composite signal being generated by the console (for analog output), and then try to reproduce decoding performed by televisions of the time (for HDMI output)?

I wish I had kept track of where, I think I had read about the NES outputting "tweaked" composite to take advantage of composite artifacting, too.

Whoa whoa whoa... first, I would need to understand exactly when the artifacts occur and specifically what causes them. Nothing will take place (at least from me) until I have that information, and the underlying root cause will almost certainly help define the appropriate response to be taken.

Right now, it's not even being looked at.

Instead, on Artemio's discord we are starting to look at how the digital values in the YPbPr lookup table affect the actual output signal, colour by colour. It's not so easy, since Pb/Pr are already modulated when they come out of the HuC6260 chip; also, they may have a non-linearity applied to them at various points along the way to the display, so there is a lot still to be understood.

dshadoff wrote: ↑Mon Sep 07, 2020 10:15 pm Whoa whoa whoa... first, I would need to understand exactly when the artifacts occur and specifically what causes them. Nothing will take place (at least from me) until I have that information, and the underlying root cause will almost certainly help define the appropriate response to be taken.

Right now, it's not even being looked at.

My reply was merely an "intellectual curiosity" response. I find what various hardware and software makers did fascinating.

dshadoff wrote: ↑Mon Sep 07, 2020 10:15 pm Instead, on Artemio's discord we are starting to look at how the digital values in the YPbPr lookup table affect the actual output signal, colour by colour. It's not so easy, since Pb/Pr are already modulated when they come out of the HuC6260 chip; also, they may have a non-linearity applied to them at various points along the way to the display, so there is a lot still to be understood.

Thank you for sharing. Very cool to see the work being done.

0x15e wrote: ↑Tue Sep 08, 2020 4:59 pm If nothing else, it should at least already be close enough that if people wanted to use one of the composite NTSC addons and connect it to a CRT, they would probably get something similar to the original intended effect.

The current expectation is that the artifacts somehow result from the modulation/demodulation approach on the signal. So the expectation is that simply using a composite modulator into a composite set (which then demodulates internally) would create those artifacts.

The questions are then whether there is any purpose for creating them artificially on non-modulated outputs, how they occur in the first place, and how to infer them. Of course, users would want them to be put "in desirable places but not in undesirable places", but that's a relative impossibility.

I've been wondering about this. So out of the two palette options, original and raw RGB, what is original supposed to be? The raw RGB palette seems to more closely match what my core grafx II outputs with HD Retrovision cables. Both are still a ways off though.

CMR wrote: ↑Fri Mar 25, 2022 1:57 am I've been wondering about this. So out of the two palette options, original and raw RGB, what is original supposed to be? The raw RGB palette seems to more closely match what my core grafx II outputs with HD Retrovision cables. Both are still a ways off though.

HDRV cables are probably just converting the RGB pins, so they would show the raw colors. The original consoles didn't really have any means of outputting rgb, only composite which went through a non-linear conversion table into a YUV color model before being output with the luma. "Original" represents what the colors would have been going through this table, as you would have seen on unmodified consoles. "RGB" is the raw rgb colors as you would see with a mod or other thing that does not take the conversion table into consideration.

Kitrinx wrote: ↑Fri Mar 25, 2022 4:25 am HDRV cables are probably just converting the RGB pins, so they would show the raw colors. The original consoles didn't really have any means of outputting rgb, only composite which went through a non-linear conversion table into a YUV color model before being output with the luma. "Original" represents what the colors would have been going through this table, as you would have seen on unmodified consoles. "RGB" is the raw rgb colors as you would see with a mod or other thing that does not take the conversion table into consideration.

The cables use the RGBS that comes out of the expansion port. Also I'm still not too sure about that conversion table. It looks to me It might have been intended to modulate the effects of NTSC encoding. Personally I think the raw RGB looks better. That's just my opinion though.

Does anyone know a way to adjust the component output on the mister analogue board? To me, even with raw RGB, the colors still look a little muted or under saturated. Maybe the cable I'm using is too long. The mono price cable I bought is about 8ft or 2.5 meters.

Color/gamma correction in the video processing menu does affect analog out. So you might try some higher gamma options for more saturation/contrast.

The ypbpr option in Mister reduces the 8-bit color depth on the I/O board to 6-bit, so that might dampen things a bit.

Many have also reported huge purple tint on component when using I/O boards from aliexpress.