That helps a lot, thanks!
Also- I’m assuming the default is RF? What’s the best way to adjust the artifacting? I’ve been playing with the comb filters a bit, but any tips?
That helps a lot, thanks!
Also- I’m assuming the default is RF? What’s the best way to adjust the artifacting? I’ve been playing with the comb filters a bit, but any tips?
My shader is just doing composite for now. I removed the RF lowpass because it was working badly. I am experimenting with fast noise now, though. (Edit: I just thought, S-Video could take maybe 1 minute for me to add.)
There is a lot of reading that I need to do about adaptive comb filtering still. What I have implemented is only an educated guess, made by guessing several random ideas and seeing what sticks.
The code currently does a mix of notch and comb filtering. The idea is that the lowest frequencies of the signal contain very little chroma, so we can just notch filter that and get near-perfect luma there. The rest of the signal is then adaptively comb filtered, and it always tries to comb filter without falling back to a plain notch filter.
For my settings, “Sharpness” affects the strength of that luma notch filter. “Comb filter sharpness” directly multiplies the comb-filtered region by a factor. There are some other modes in there that I experimented with too, if you want to try them out, but I like the defaults that I set already. But, whatever you do, don’t demodulate at the narrowband bandwidth, as the baseband bandwidth is needed for the adaptive filter to compare lines effectively. (Edit: One of the modes allows you to compare the comb-filtered region of luma instead of the demodulated/lowpassed chroma, allowing you to use the narrowband bandwidth while still comb filtering kind of decently, but I didn’t like how it looked.)
From my experience, the way to figure things out are from chip datasheets, CRT service manuals, schematic diagrams, and, most importantly, actually getting real CRTs and consoles to try for myself. I have a Panasonic CT-36D30B from 2000 with an adaptive comb filter, with a Genesis, NES, PS1, Wii, and cheap composite-to-HDMI convertor for testing out the comb filter. (Edit: Occasionally, patents can be helpful. There are some research papers too that include measurements of CRTs.)
If we’re gonna do RF and are modelling a CRT TV, there’s gotta be an AFT circuit.
There are likely an hundred different ways to implement an adaptive comb filter. I’ve seen filters that look at the lines, look horizontally, look across fields, look across frames, detect correlation, lock in the peak luminance frequency, lock into some other frequency, mix with notch, not use a notch at all, different notch designs, whether to bandlimit the output luminance, different weights, differential feedback, bypass comb filtering entirely on certain signals, etc. There are plenty of patents, with little information about what was actually implemented.
It may be better off either implementing one thing very well that you have enough information for, or focusing on the technique you feel gives the best result for the application at hand (mainly 240p 2D games).
Pictures of my Panasonic CT-36D30B which has a comb filter, with games on the Genesis, NES, and PS1. The test patterns are from the Genesis 240p test suite. https://drive.google.com/drive/folders/1balfWcYBL6im2w12awlIAT2biAaXSP2K
can you please share more Pictures from PS1 bios? also videos if you dont mind
Fantastic idea. That screen is like an absolute explosion of dot crawl artifacts, even on video capture. I’ll get it by tomorrow, I hope.
Edit: Here’s a video capture, if curious https://youtu.be/warPE1-WLGU the PS1 bios is at the end
Just beware, none of my consoles are confirmed to have replaced capacitors (which can impact things like black/white level, saturation, and amount of Y/C blurriness and interference), and my CRT itself is showing signs of aging and might benefit from getting serviced.
good point, but my main intention was to see how interlace appears, especially to know if there is a big effect of phosphor persistence that help with it
anyway, thanks in advance 
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.