PAL chroma merging?

[HardWareMan]

Any *.NES file?

[thefox]

Looks like you forgot to include the binary, tepples, so here it is.

[HardWareMan]

[MOD edit: fixed broken links]

[thefox]

Here's a really crappy photo of my CRT TV (2C07 PPU). From what I can tell, it looks like colors match up so that evenHue = oddHue+2 (with wrap around, of course). E.g. the even scanline of $15 is the same hue as odd scanline of $13. (Looking at the TV the colors match up better than in the photo.)

Which is funny, because in HardWareMan's cap it's quite clearly evenHue = oddHue+1.

[Eugene.S]

It's my Dendy on PAL CRT (UA6538 PPU)

[tepples]

Looks like you forgot to include the binary

Oops, my bad. There are two places I need to change the binary's filename when I import the project template: makefile and zip.in. I forgot the latter.

So it looks like Dendy does this aspect right and PAL NES does it half-@$$, just as with the CPU clock divider. Anything I need to add in a second version of this test?

[lidnariq]

Ok, so:
A PAL scanline is "supposed" to be exactly 1702.5 master clock cycles, or 283.75 chroma cycles.
The 2C07 (and it looks like UA6538 also, given HardWareMan's pictures) scanlines are 1705 master clock cycles long, or 284 1/6 chroma cycles.
We see the expected repetition of phase every 6 scanlines.

What's weird is, as far as I can tell, adjacent scanlines of all hues really shouldn't be ≈the same phase, and yet they seem to be.

Maybe a useful test would be to exchange the solid grey scanlines in tepples's test with some fixed color? That way we should be able to say that hue phase X on even/odd scanlines is the same as hue phase Y/Z on odd/even scanlines? Obviously will only be visible on the luma-only signal.

[tepples]

I'll take this as a feature request to let the user change the background palette between $00 and any color $11-$1C. Is that what you want?

[lidnariq]

Sure?
I guess that's not all that different from the original test I made, although it lets you compare more colors simultaneously.

[tepples]

Exchange this.

[HardWareMan]

Here we go.
[moderator: recovered images from web.archive.org]

[Sik]

Here's a really crappy photo of my CRT TV (2C07 PPU).

What did you use to take the photo? In my experience phone cameras tend to be good at taking photos of CRTs (apparently you need a crappy camera to take a good pic of a CRT, who would have thought)

[thefox]

Here's a really crappy photo of my CRT TV (2C07 PPU).

What did you use to take the photo? In my experience phone cameras tend to be good at taking photos of CRTs (apparently you need a crappy camera to take a good pic of a CRT, who would have thought)

iPhone 4

[Eugene.S]

I will upload new test pictures at evening today

[HardWareMan]

Well, I took out my old monitor, which is used in the 90's. Do not look at the geometric distortion - I'll fix them later. The main feature of this monitor is that it is PAL decoder built on a good old TDA3510. This "warm tube" analog PAL decoder that utilizes the 64mks delay line. Therefore, the result really depends on the content of neighboring scanlines. In the new digital decoders, each scanline can be processed separately, although Avermedia shows almost identical to TDA3510 results.
UMC UA6538:

5823602.jpg

HA6538:

5783665.jpg

5789809.jpg

[moderator: recovered images from web.archive.org]