Thanks for the word of caution. The things to be careful of are the equations and such- I didn’t verify those, but everything detailing the processes involved looks good to me and matches what I’ve read elsewhere- or is there something specific that looked wrong?
I assume @guest.r knows to be cautious with answers provided by ChatGPT 
Yeah, it can be on shrooms or worse, no worries.
Soooooo, with this new code addition, giving us more accurately modeled NTSC signaling and resultant colour, how would it affect what Grade does to the colour?
Would there be some sort of over, under or double correcting taking place?
I don’t think there’s any conflict (double correction, etc), you just want to avoid anything that’s doing it’s own YIQ conversion
EDIT: so, definitely leave “Signal Type” set to RGB in Grade
Thank you for this addition!
Looks great - can you verify this:
Do you need to add separate desaturation for I and Q to emulate strict NTSC (4.2/1.3/0.4 MHz)?
No.
- Pass 2 already implements this via:
dx1offsets scaled byntsc_cscaleiandntsc_cscaleq→ wider for Q, narrower for I.- FIR taps per channel → I retains more high-frequency content, Q is more blurred.
- Pass 3 only adjusts I/Q locally at edges , it does not override the main asymmetric bandwidth .
Optional tuning:
- You could tweak
ntsc_cscaleiandntsc_cscaleqto fine-tune I/Q bandwidth to match exactly 1.3/0.4 MHz.iqdesatcan apply a small overall chroma roll-off but is not necessary for strict NTSC emulation.
Also, had some doubts creep in regarding this. Can you confirm?
The idea here is to use the existing “saturation” parameter (not NTSC saturation) to compensate.
Incorporating changes from crt-guest-advanced-2025-10-18-release1 (rev 5).
Built on top of:
Image Adjustment (2024.02.07) by hunterk
crt-guest-advanced-2025-10-18-release1 (rev5) by guest.r and Dr. Venom, based in part on Themaister’s NTSC shader
Sony Megatron Colour Video Monitor (2023.10.09) by MajorPainTheCactus
with additional functions based on or inspired by Grade by Dogway
All included “CRT Megatron” presets are currently tuned for the LG C1 and other similar displays (WRGB subpixel layout, with approximately 800 nits Peak Luminance).
The included version of Image Adjustment has been modified to allow for finer control of the effects as i found appropriate.
GPGX MS color fix
Corrects Genesis Plus GX’s Master System color output, which includes minor errors i discovered while implementing the Sega MS Nonlinear Blue Fix.
Sega MS Nonlinear Blue Fix
An implementation of the behavior described in Notes & Measures: Nonlinear Blue on Sega Master System 1 & Other Findings by bfbiii.
This setting automatically adjusts to work with the GPGX MS color fix settings.
Sega MD RGB Palette
An implementation/approximation of the Mega Drive/Genesis RGB palette as discussed here.
Downsample Pseudo Hi-Res
As i understand it, 15KHz CRT displays would treat double-horizontal resolution modes (512x224, 640x240, etc) as tho they were not doubled, resulting in a blending effect, called pseudo hi-res. A number of SFC/SNES games are known to have used this behavior for transparency effects, including Breath of Fire II, Jurassic Park, and Kirby’s Dream Land 3, and as far as i know it is the correct behavior for any device originally meant to be displayed on a 15KHz CRT TV/monitor.
1 = off
2 = Triggers the blending effect whenever the horizontal resolution is more than twice the vertical resolution. This works well with cores that either always output a pseudo hi-res image for compatibility (such as bsnes-jg), or cores that only use pseudo hi-res for pseudo hi-res content (such as SwanStation). True high-resolution/interlaced content is not effected.
3 = Triggers the blending effect whenever the horizontal resolution is 480 or higher. This is needed for cores that display pseudo hi-res content in a true high-resolution container (such as Mesen-S and a number of bsnes variants). Unfortunately, this halves the resolution of true high-resolution/interlaced content, as there is no way to differentiate pseudo hi-res and true high-resolution/interlaced content in these cores.
Internal Resolution
Modified to allow up to 1/16th downsampling. (It’s a surprise tool that will help us later.)
HDR: Content Color Gamut
Out of the box, RetroArch and Megatron clamp colors to the Rec. 709 gamut (Expand Gamut set to Off in RetroAtch, or HDR: Original/Vivid set to Original in Megatron), or stretch that Rec. 709 gamut to an unusual non-standard gamut created by someone at Microsoft (?Chuck Walbourn?) called Expanded 709 (Expand Gamut set to On in RetroArch, or HDR: Original/Vivid set to Vivid in Megatron).
Obviously, this is undesirable, as all of the major “retro” color gamuts include colors that fall outside of Rec. 709.
Serendipitously, i found that it was possible to turn this problem into it’s own solution by simply adding additional color gamuts to the “HDR: Original/Vivid”, renaming it “HDR: Content Color Gamut” to better reflect it’s newfound purpose.
When using this setting, Colour System should be set to 0/r709, and Phosphors should be set to 0/NONE.
Options are as follows:
Gamut Overshoot Fix
A fix MajorPainTheCactus came up with to deal with the color errors i noticed using lilium’s HDR analysis shader. (Sony Megatron Colour Video Monitor)
He decided not to implement it at the time, as he didn’t think it wouldn’t make a perceptible difference, but a friend and i both came to the conclusion that it makes certain test pattern colors look more like they do with no shaders applied, so i have continued to use it. There should be no downside. (Sony Megatron Colour Video Monitor)
Scanline Multiplier/Divisor
Multiplies or divides the number of scanlines.
Useful for cases like DOS games meant for 31KHz displays, which output 320x200 that was then double scanned to 640x400.
The divisor options are handy for displaying increased internal resolution output from 3D cores that don’t include a good downsample option, such as PPSSPP. I strongly recommend using this setting in conjuction with crt-guest-advanced-ntsc’s Internal Resolution setting to reduce shimmering.
I think the NTSC saturation parameter is more akin to the automatic color control (I may have gotten some terms swapped/confused, there’s also an automatic gain control, I think we’re still ok). The regular Saturation parameter is like the TV knob to make “artistic” adjustments.
Also, is this currently only working for 3 phase?
The Safe Voltage Desaturation setting appears to be working identically for all five phase settings using crt-guest-advanced-2025-10-18-release1 (rev5) or the decoupled version in AzMods20251018.
Yep, got my files jumbled up, I should go to bed
I did some chroma signal inquries regarding different consoles:
Modern captures and scope measurements of front-port NES (USA) units show:
Some units drift hotter or colder depending on aging and motherboard revision.
| Console | Chroma boost vs burst | Comment |
|---|---|---|
| NES (NTSC) | 1.5–2.0× | Very hot |
| SNES | 1.25–1.4× | Mildly hot |
| Genesis / Mega Drive | 1.3–1.5× | Similar strategy |
| PS1 | ~1.2–1.3× | More broadcast-legal |
| PS2 | ~1.1–1.2× | Tends more legal, esp. late revisions |
100% legit or not, it’s most appropriate to add this parameter option as the main “safe voltage” control knob.
New Release Version (2025-10-19-r1):
Notable changes:
Download link:
https://mega.nz/file/B0J3gaiI#aUib5-55gs20UyFE2zCKMiwFW9NB3TchIzN5Ji9YxU0
Was this buried somewhere on NesDev or system11 or?
The only things i’m seeing on google for (“450–600 mV” nes) are an unrelated technical paper on monitoring soil condition and an also unrelated German dissertation.
NesDev is the primarily source ofr NES measurements, yes.
seems “safe voltages” is the right fix for this
with safe voltages set to 2.0not fully fix it but it’s way better
Thanks @guest.r, all of these developments seem to further highlight the importance of “console specific” presets or parameter setups for those seeking higher levels of discernment.
I’ve always felt that NES and PS1 needed less added saturation than SNES and that if you used a preset Optimized for SNES, it would make NES colours oversaturated.
I hope you’re having fun with the new dials. Are we going to see safe voltage recommendations for other systems published as well, for example PC-Engine/TurboGrafx-16/Turbo Duo?
I wouldn’t want to use the wrong values arbitrarily.
With the previous implementation I was expecting an On/Off switch so when I saw a safe voltage desaturation knob, I wasn’t sure about what to so I first turned up to 1.0 and things looked unpleasantly desaturated and would have required an immense of NTSC Saturation…err…“colour boosting” to make it look right again.
I think I ended up settling on 0.50.
Random thought. An AGC circuit/switch/knob might be cool. Is this the same concept that we’re seeing implemented in the latest release?
Could you have gotten the same result by eyeballing the loss of detail and simply lowering the Saturation?
in fact the old fix was the opposite, which
BTW, for this I think it’s better if libretro output more metadata, especially since there are cases like this
AGC is tricky here, since “RF signal strength deviations” are pretty predictable with home devices (consoles, home computers). Some readings state, that it’s very usable for broadcast input sources.
I read about “circuits” which also affect luma strengths if input signal is too boosted, for example better Sony monitors. I found some old docs stating that safe voltage was regulated with Philips TVs and some ITU stuff.
The issue is also that today’s “standard CRT TV circuit solutions” didn’t apply to vintage engineers, they had the freedom to solve problems with different means and different companies did things differently. Some stuff was also patented (like delay line from SECAM, trinitron…), so there was motivation to innovate.
I would definitely be interested in taking a look at any links along these lines that people find, tho i do wonder if these deviations are due to decisions made in hardware design, or just aging hardware?
It’s hard not to notice the exact inverse correlation with how old the console is, with even the PS2 apparently getting closer to “correct” the newer the specific console being tested is, which is part of why i was looking for the source posts last night.
My suspicion is that the PS1 and PS2 in particular may have originally been more or less bang on, given that, at the time, the PS1 made waves due to actually being designed to adhere to display standards.
(For example, before the PS1, it is my understanding that the US versions of literally every single Japanese-designed console still used the NTSC-J 0 IRE black level, resulting in crushed blacks on essentially all non-NTSC-J NTSC displays, which were nominally factory calibrated for a black level of 7.5 IRE. Whereas the PS1 and PS2 actually had regional IRE.)
No.
Optional tuning:
