I've tested dendy on 2 different PAL CRT TV-sets.
Here are palphase and palblend tests:
Dendy's UMC UA6538 PPU on SAMSUNG CK-5341TR PAL CRT
Dendy's UMC UA6538 PPU on SONY TRINITRON KV-21LT1K PAL CRT (looks like it has more significant phase offset)
The bottom-right square of "pal-chroma-merge test" looks yellow on KV-21LT1K,
but it really brown on CK-5341TR:
PAL chroma merging?
Moderator: Moderators
- HardWareMan
- Posts: 209
- Joined: Mon Jan 01, 2007 11:12 am
Re: PAL chroma merging?
Well, I fixed my monitor, replacing all dried up capacitors. Then made the chroma decoder setup procedure using a test signal generator and oscilloscope. The main problem was in the LC contour matching of the delay line. So here's what I've got:
[moderator: recovered from web.archive.org]
Despite the small jalousie effect in some colors (need to more accurately adjust the LC contour of delay line and the LC contour of color subcarrier) is still colors are the almost same. So the xx6538 Dendy's PPU color coding is correct.
Despite the small jalousie effect in some colors (need to more accurately adjust the LC contour of delay line and the LC contour of color subcarrier) is still colors are the almost same. So the xx6538 Dendy's PPU color coding is correct.
Re: PAL chroma merging?
OK, so you're saying that the systems output the correct phases/hues on each scanline, but each individual TV's decoding has some phase shift on alternating scanlines, relying on it to be averaged out after filtering? Seems like that would certainly make the most sense, given the different results we've seen from different TV sets when using the same console.
It's unfortunate that this would also mean that this artifact cannot be reliably exploited. Nevertheless, it might be useful to emulate it (with configurable phase shift).
It's unfortunate that this would also mean that this artifact cannot be reliably exploited. Nevertheless, it might be useful to emulate it (with configurable phase shift).
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
- HardWareMan
- Posts: 209
- Joined: Mon Jan 01, 2007 11:12 am
Re: PAL chroma merging?
Well, it's pretty logical. There's also a purely digital circuit and a set of frequencies is clearly limited. It does not matter that the frequencies are not multiples of the scanline frequency, the color burst is taken from the same frequency source.
I've been thinking. With regards to the PAL. The system uses a delay line. It is designed for exactly 64mks (15625Hz for PAL systems). Thus, if the frequency of the scanlines is slightly changed, the delayed scanline will not be exact to the desired phase, causing color artifacts.
I've been thinking. With regards to the PAL. The system uses a delay line. It is designed for exactly 64mks (15625Hz for PAL systems). Thus, if the frequency of the scanlines is slightly changed, the delayed scanline will not be exact to the desired phase, causing color artifacts.
Re: PAL chroma merging?
So I did some capturing with my Famicom AV and Pinnacle USB capture device (+iuVCS tool). And it appears chroma is very well merged at some level again, and again white and black aren't affected. Grey is weird, in the curcle test it's untouched as well, while the palphase test shows how it is merged with the colors.
Circle video (the device rescales to 640x480, and then applies some sort of interlacing, so I reduced it internally, let me know if it matters):
http://rghost.ru/8YkDyvGgJ
The images aren't deinterlaced though.
Does NTSC stuff even matter in this case anyway?
Circle video (the device rescales to 640x480, and then applies some sort of interlacing, so I reduced it internally, let me know if it matters):
http://rghost.ru/8YkDyvGgJ
The images aren't deinterlaced though.
Does NTSC stuff even matter in this case anyway?
Re: PAL chroma merging?
NTSC doesn't do any vertical chroma subsampling, if that answers the question...
Anyway, the bit where "black" and "white" appear to not suffer from chroma subsampling happens because the subsampling only happens on the U and V components, and out of gamut colors are clipped back into gamut.
Say you had a screen full of alternating scanlines of
- black (Y=U=V=0) and
- yellowish (Y=0.5, U=-0.5, V=0)
Chroma subsampling would turn those into:
- black (Y=0, U=-0.25, V=0)
- greyish-yellow (Y=0.5, Y=-.25, V=0)
Then when you convert those to RGB values to drive the (conceptual) electron beams with, you'd get
- black (R=0, G=0.098, B=-0.483) which is probably clamped to (R=0, G=0.098, B=0) (#001B00)
- greyish-yellow (R=0.5, G=.598, B=0.017) (#809804)
And I'm skipping gamma correction, because that's a pain. But it doesn't affect U and V values, just Y and the colorspace transformation.
I understand that you're trying to figure out how to do something equivalent given RGB input and lookup tables, and to first-order approximation is seems like white and black are just not affected, but I'm just not all that certain that you can do this accurately without converting back to YUV.
Anyway, the bit where "black" and "white" appear to not suffer from chroma subsampling happens because the subsampling only happens on the U and V components, and out of gamut colors are clipped back into gamut.
Say you had a screen full of alternating scanlines of
- black (Y=U=V=0) and
- yellowish (Y=0.5, U=-0.5, V=0)
Chroma subsampling would turn those into:
- black (Y=0, U=-0.25, V=0)
- greyish-yellow (Y=0.5, Y=-.25, V=0)
Then when you convert those to RGB values to drive the (conceptual) electron beams with, you'd get
- black (R=0, G=0.098, B=-0.483) which is probably clamped to (R=0, G=0.098, B=0) (#001B00)
- greyish-yellow (R=0.5, G=.598, B=0.017) (#809804)
And I'm skipping gamma correction, because that's a pain. But it doesn't affect U and V values, just Y and the colorspace transformation.
I understand that you're trying to figure out how to do something equivalent given RGB input and lookup tables, and to first-order approximation is seems like white and black are just not affected, but I'm just not all that certain that you can do this accurately without converting back to YUV.
Re: PAL chroma merging?
Does it mean the tuner does it on its own? It kind of allows to choose what it receives, several types for NTSC, PAL and SECAM, some of them are grey, some have clear moire even with composite output, I might assume it doesn't affect what it generally does to chroma. It doesn't seem to accept it losslessly though, YUY12 is the primary option, the only other being I420.lidnariq wrote:NTSC doesn't do any vertical chroma subsampling, if that answers the question...
Re: PAL chroma merging?
Yeah, a multi-standard receiver would have to do something substantially different between SECAM and PAL, so doing a third different thing for NTSC is plausible.feos wrote:Does it mean the tuner does it on its own? It kind of allows to choose what it receives, several types for NTSC, PAL and SECAM, some of them are grey, some have clear moire even with composite output, I might assume it doesn't affect what it generally does to chroma. It doesn't seem to accept it losslessly though, YUY12 is the primary option, the only other being I420.lidnariq wrote:NTSC doesn't do any vertical chroma subsampling, if that answers the question...
But people have applied NTSC, PAL, and SECAM color modulation to almost every underlying monochrome video standard:english wikipedia article with analog video standards table ( russian wikipedia article with same table ) ; many won't produce sensible (or any) colors for an arbitrary other-system and/or other-modulation color input.
NTSC's closest equivalent in the digital world would be YUV422, while PAL and SECAM are closer to YUV420. That it won't give you that is annoying :/
Re: PAL chroma merging?
Palette test roms mirror (*.nes binaries)