Why not try to buy like a cheaper CRT? Man, I really miss the CRT era.
Also, Pants, what can I use for the Genesis/MD shader and the PSX shader from your presets, sir? I forgot to asked that, I remember in the past you had one for GenesisGXPLus and BlastEm.
@beans I took a look at the Genesis schematic. The chroma filter is more narrow than the SNES, with a bandwidth of about 1.3 MHz. The bandstop looks like a pretty typical notch filter for NTSC video. Notice that the Genesis does not support S-Video while the SNES does. This is why the Gensis has a bandstop filter on its chroma path while the SNES does not. The low pass filters are also more narrow than the SNES, but still well beyond the horizontal resolution of SDTVs.
The poor quality of the Genesis output probably has less to do with the filter design itself and more to do with the fact that there is hardly any isolation. This design greatly exposes the video signals to noise and interference.
As for RF, any system is going to have a strong rejection past 4.2 MHz. Aside from FCC compliance, the audio signal must be free from video interference to work.
I attempted to simulate the Genesis filters here: New CRT shader - Any interest?
I was surprised at how little attenuation the chroma filter seemed to have, and how much the high frequency luma seemed to be attenuated. It seems less a notch filter and more of a low pass. But maybe I made a mistake?
Could you explain the high pass component of the chroma filter on the SNES? I expected it to be some sort of DC-blocking filter with a cutoff well below 15kHz to avoid affecting the chroma. It seems significantly higher than that, though.
Sure, it’s around 16 kHz. The chroma signal coming out of the video chip is already modulated on the subcarrier. The high pass blocks any unfiltered chroma and harmonics from the chroma mixer from being present at line frequency to prevent unwanted interference, and since the chroma bandwidth is supposed to be limited to 2.6 MHz, there should not be any information below 980 kHz or so. It also reduces any low-frequency noise that may have coupled on the chroma path, e.g. the beats from horizontal sync.
In video signals, even games, the vast majority of information is within the first 1 MHz from center.
To comment on your Genesis filters I would have to see how you are deriving these frequency responses.
I was thinking about the SNES, where the chroma is not modulated from (R-Y)O and (B-Y)O. At least my reading of the datasheet is that it is modulated afterwards.
When I use the standard equations with the values for R34 and C14, I get a high pass cutoff of 159 Hz. When do the same for the low pass filter formed by R35 and C14, I get a cutoff of 2.68 MHz. I actually tried to simulate the circuit with Qucs-S, though, and got a much higher cutoff for the high pass. I may have done something wrong in the simulation, though. I wasn’t sure if the two filters could be composed in that way without affecting each other.
The baseband chroma is still blanked like the luma signal, but lacks any sync information, so it doesn’t have any information below line rate. Even if you display a solid color, the horizontal blanking and colorburst between lines is going to make the signal periodic at line frequency.
The purpose of the high pass there is to prevent V-sync and power line energy, as well as any other possible noise, from crossing into the signal. Interference at these low frequency leads to a hum bar effect.
How are you terminating your circuits in simulation?
The way the circuits are cascaded directly into each other is fine. It does not affect the cutoff frequency. But it does change the impedance of each stage and you get resonance and a stronger roll-off. However, when you cascade a lowpass and high pass onto each other specifically, either in bandpass or bandstop configuration, the two filters don’t affect each other unless the cutoff frequencies are close (and the resistor values are far enough apart).
Cool beans. I seen your CRT shader in the CRT folders of RA. How much different is your Genesis filter from those?
The existing shader doesn’t have the NTSC composite simulation. I’m hoping to finish a sort of beta version of that next week or so.
You can probably hook up @PlainOldPants’s composite simulation with crt-beans (this is his thread, after all), but it would take some work getting the preset right.
edit: I find this https://www.reddit.com/r/crtgaming/comments/1lrv725/does_anyone_know_why_red_and_blue_usually_color/
Shouldn’t it work with RGB instead of YIQ? electron guns are RGB
anyway, Is it possible to refine and publish it?
I want to try using “overdriven electron guns” effect in my presets 
or maybe @PlainOldPants can publish “wearing electron guns smearing to the right” part of the patchy shader? as standalone shader that can be used in another crt shaders/presets
I was getting ready to apologize for my inactivity, until I realized my last post was only five days ago. It feels like an eternity with everything that I have going on.
I might have more to say later.
I still have no progress on this after over 3 weeks.
At first glance, it’s a simple problem: Just simulate the CRT’s colors directly, but in P3 or Rec.2020 space. While this works for simulating the signal alone, appending a CRT shader directly with it results in the phosphor mask being wrong. Because of things like glow and luminance weights, I can’t do a split prepend/append setup to defer the HDR color fix to the end. To make this make sense, I have to edit the CRT shader to output its RGB phosphors as the CRT’s phosphors’ colors. There is no other way. This will take some more effort than I first thought.
With HDR, it becomes possible to simulate CRT phosphors directly without compression. The only problematic one is the Toshiba FST Blackstripe CF2005 from 1985, whose blue phosphor is in Rec.2020 but not close to P3. Other CRTs won’t have any problems.
I don’t have any HDR monitor to test on, so I’ll have to just hope that everything looks correct on your end.
I’ve made a breakthrough in making RF noise more efficiently, to a point where it can probably be accepted into crt-advanced. Those 300 random sine waves can be replaced with just 2 manually controllable ones. Very fast. For my own shader, I’m willing to have a little bit higher performance overhead, so I loop that code section 20 times with randomization. I can post this tomorrow.
I should be able to do this tomorrow.
I don’t have a very good Genesis shader yet. I see that beans is working on simulating it more accurately. I can make a less accurate option in the meantime. Until I post that, the best option for Genesis is the one that I posted about a year ago in October.
For PSX, the “170m” 240p presets should be a good choice for now. In fact, this is probably good for most 32-bit consoles. It’s a generic preset that isn’t emulating any specific hardware, but it looks convincing to me.
I could do this and make it more efficient, but that effect was more of an eye candy, not as accurate as I would like today. I have just a bit of a hunch on how to improve it, but I don’t have 100% of the information that’s needed for accuracy with it.
It is also because the color carrier rate is close to the pixel clock (within 90% or 95% if I recall), resulting in a long “beat”. On NES and SNES, this is minimized by making the color carrier’s wavelength 1.5 pixels long.
As you said, capacitor aging can play a role too. I recall someone mentioning that replacing capacitors reduces the rainbow artifact. Somewhere else, I saw someone say that third party power supplies with the wrong amperage exacerbate the rainbow artifact as well, but I’m not quite inclined to believe this one.
That doesn’t explain why the rainbow banding pattern also appears on solid-color screens, with or without color. My own Genesis does this. My Genesis also has RF-like noise in the composite signal, which I only notice over video capture, and a weird issue that only occasionally happens where the scanlines start to shift horizontally slightly separately from each other. What could possibly be causing this?
I think I want to make sure this effect is simulated well enough before I finally replace the capacitors on my Genesis, assuming that the previous owner didn’t already replace them.
I believe it’s due to coupling of the subcarrier oscillator on the RGB input (particularly blue). It reinforces the chroma subcarrier in all signals, even black and white. Since the notch filter is not perfectly aligned on the subcarrier frequency, enough gets through to the final output to be visible.
My Genesis also has RF-like noise in the composite signal, which I only notice over video capture,
You’d have to rule out the video capture device and the transmission characteristics since it isn’t apparent on the TV. If it only happens with the Genesis for this video capture device, could be an impedance mismatch requiring more amplification leading to noise. On the other hand, the TV may have noise reduction, pointing back to the Genesis. If you increase the black level, you may be able to see it.
Scanline shifting sounds like your TV having issues syncing with this type of signal.
thanks
no problem if it not 100% accurate at start, since we dont have any shader that did that effect yet (so having something is better than nothing), and later if we got more info about it we can correct it or make another version of it
