A Moogle  🏳️‍🌈 💻 🎮 🎶 🇸🇪

From what I can tell, the SRAM seems to be parasitically pulling a couple milliamps off of the the bus, which leads to cycles of voltage dropping (increased luma) across the raster, one per nametable square at the beginning - corresponding with nametable CIRAM fetch by the PPU.

Perhaps the most noninvasive strategy involving the output signal would be to introduce a comb filter instead of a notch filter, tuned in such a way to repeat the low-frequency luma component in the pre-bar zone in the raster but not the high-frequency chroma subcarrier.

I believe in fixing the issue at the source, by providing the ICs all the current they need even when they pump like crazy using carefully chosen capacitor values and placement?

Same opinion. I don't get how a filter on the final output would hide the problem without affecting the useful signal in some way or the other. What if a game wants to display something similar to the jailbars ?

If the premise is that my suggestion is shit and my knowledge is shit, maybe try to educate me rather than just humiliating me. As a leftist, this makes me understand how are baffled that the right don't just latch onto the left's brilliant ideas when you openly mock them.

I'm sorry if it seemed that way - it was entirely not my intent. I agree with you on that it is possible to do what you're asking, with a filter outside of the console. It's not the best way for all, but it reduces the impact for most with an inexpensive inline component.

However - to do what you recommend would be the better job for a comb filter, as the luma would be held across a respective bar, but changes in luma within a bar would not be affected - and, the slight variances caused by jailbars can be selected for.

I'm sorry to push the question, but is that the case though? If luma is being held constant across a given NTSC signal line, then the jailbars wouldn't happen at all, right? It seems like it happens pretty consistently within the line, for every line in the field.