nesdev.com

Some imported TVs worked around Telefunken's delay line patent by decoding sorta-NTSC-style, just inverting the V carrier's phase from line to line. These rely on the eye to do the chroma subsampling.

I'm sorry, but the video he posted does have a ton of subsampling, just not with gray, white or black.

I can tweak the option in any way, I just need some insight on what it should not do. If it's even known.

"Not doing subsampling against grey" means it's not doing subsampling at all. It can't be conditional: televisions from before the 1980s were too simple for such logic.

In any case, please point out what you see that makes you think it's selective. As near as I can tell, the capture card is doing something weird with how it calculates the phase of the colorburst, producing the weirdly different colors from scanline to scanline. (My best guess is that it's using a 1 scanline delay line instead of 64µs to calculate U/V phase ... or vice versa.)

Pictures like this:
download/file.php?id=1950&mode=view

I just thought, since black, white and gray are 0 chroma, merging them wasn't intended. However, there's now more evidence that it should be done in 100% cases, right?

Yes. It'll just produce out-of-gamut values when subsampling through pixels of white or black. (When you transform YUV with {Y=0, U=nonzero, V=nonzero} to RGB, you get some negative values for the result.)

Well, we're sliding down to what happens on devices, while my goal it simulating the effect. For maximum speed, I use lookup tables whenever I can, and for chroma presence in a color (by index) too. And then, by original chroma presence, I determine if I should blend or not. If I determine it on fly doing the conversion to RGB from YUV, fps will drop to 20- because of fractions.

Probably there lies a problem with too heavy blending clearly visible in some games if I blend RGB 50/50. If done at runtime only with U and V, maybe it'd look more accurate.

That could explain your problems... luma is not supposed to be subsampled at all.

It's not that simple. There's palettetranslate array in fceux, that contains values as for what RGB color to use per color index. I parse it all, convert to YUV, calculate subcarrier mask, apply it for where U or V are not zero, convert the results (16 variants per color) to RGB, and then at runtime decide what to pick by an index that comes from the main buffer (XBuf), figure out that moire phase should be used, and immediately pick the needed color. Can go up to 600fps on my old machine.

THEN, I precalculate an array of bools that tell me what color has chroma in it, and at runtime look that up too, and if there was no chroma in a color per initial conversion, I don't blend it.

Possible options: blend only if both have chroma, blend if at least on has chroma, blend always, blend never.

But as I said, blending by RGB values might be wrong compared to blending by YUV. Sadly, I can't make a lookup for that too, too many options. Or can I?

I would like to add to this topic a little bit of technical information. As you already know, PPU has no any palette, it generate NTSC or PAL signal natively. It is possible because of the fundamentals of coding those color systems. PPU generate 12 different subcarrier phases for color range (color number from x1 to xC). All next info will refer to the following picture (NES palette ROM) and PAL PPU (basically clone):

I would like to remind you that video DAC is resistor chain. It can generate only 11 voltage levels (include 0V), so luma variants are very limited. You can search this research in this forum, I don't remember what that thread was.

As you can see, there is only 6 types of signal. Each type has High and Low level. All except SYNC can oscillate between those levels. L10 connected to emphasise logic and don't will discussed here. So, I've look at oscilloscope and what I was discovered.

This is one screen capture. Legend:
Channel 1 (yellow) is composite signal.
Channel 2 (cyan) is -(B-Y) signal form PAL decoder, based on TDA3510.
Channel 3 (magenta) is -(R-Y) signal from PAL decoder.
So, each color row (for each luma) starts with H level (index x0), goes through 12 hues by oscillating between H and L (indexes x1 - xC) and ends with L level (index xD). 0x row has L level lower than black level, so you notice it on the screen (for example in Super Robin Hood game from Codemasters).

Important thing: oscillating between two levels creates new luma value, which is always average for H and L levels. It noticeable with notch subcarrier filter turned on or on the eye from a distance from TV. Since, subcarrier always has duty cycle 50% average level is (H+L)/2. This level will used for RGB calculating.

I has made many measurement of absolute levels by scope and got this preliminary results:

In order to facilitate the perception of the data I have built a graph:

Very noticeable that fact what luma0 very similar to luma3 and luma1 very similar to luma2. If I eliminate some possible measurement errors I've got this kind of graph:

So, it's a sine shaped signal. that is true: 12 phase is 30 degrees vectors. And also very noticeable that fact what R-Y shifted by 90 degrees to the B-Y. This is normal for PAL when you make linear shift subcarrier phase by 30 degrees.

In the end I able to measure phase of each color but I don't see meaning in it. You can synthesize any of R-Y/B-Y and luma levels, scale them (R-Y/B-Y scaling is saturation control and luma scaling is contrast control) and mix them up to result RGB values, with the simple addition and subtraction, as is done by electronics devices.

Discuss.

So you're simultaneously measuring the NES and the TDA3510. In order to eliminate the TDA3510's behavior from the equation, it might be best to take phase measurements directly on the composite signal. Particularly, I'd like to see phase of the composite signal during color burst and each color for odd and even scanlines. That way an emulator can choose to implement either Telefunken decoding (mixing chroma with that from a 64 us delayed signal) or the most common workaround for Telefunken's patent (taking into account the signaling in the burst and otherwise decoding each line independently, which is more subject to Hanover bars).

In TDA3510 case there is merging. It's very noticeable at neighbor scanlines with different color. Unlike NTSC, PAL subcarrier multiple to scanlines. That why PAL PPU has "dot crawl" but they don't crawl and stay steady. Full period is 6 scanlines:

So, there is 6 different phases of subcarrier relative to sync. Of course this doesn't matter to color decoding. Here 6 scanlines in a row:

Since it's related here, as my intent is to emulate it, I'll answer to this here:


Exactly. Now we have a proof that it even happens to white.

Here's a 2-color cloud the way the game renders it.


Here's a super detailed shot of it on TV:
http://i.imgur.com/HJHv6TM.jpg

Watch how red comes into play between white and blue (creating gray)!

403 Forbidden

Fixed.

Trying to make RGB->CVBS->CRT->RGB filter, to simulate CRT linked by composite video.

ATM made some SVideo part...
https://gist.github.com/realmonster/23a4232a37d50e859f09

Stucked on low-pass filters.
Can't figure out how to simulate low-pass filters
1) there are many of them, what exactly to choose? Ofc I need some of those that is comming in analog TV (CRT)
2) even if I have schematics, actually I don't need schematics or characteristics itself. For example for many filters there is bode diagram, step-response analysis, phase shift etc... But I need V-in - > V-out function. I saw for example V-out(s)/V-in(s) = f(...) where ... is capacitors, resistors.
For example for simple RC-circuit there is formulae V-out(s)/V-in(s) = 1/(1+jwRC). For me it looks like right side is constant for appropriate RC and w. When it comes to changing w, all messed up.

Best that I found was formulae from Wikipedia y[i] = x[i]*a + (1-a)*y[i-1]
but it's not enough for me too... I want non-discrete function, to be able integrate. This one is based on samples. Maybe I just don't understand something.

Also, from question that I need to solve... when TV decoding UV from composite signal...
1) does it decode UV straight from N (composite signal), or does it decode UV from N-Low_pass(N,3.5MHz), or maybe from High_pass(N,3.5MHz). (frequency is just some random chosen because I don't remember exact value)
2) Any analog low-pass filter introduces delay in signal, so does it synced after? (UV with Y)

I don't have CRT nor NES, so I can mistake everywhere