Re: Difference in luma-chroma delay of C64/C128 compared to standard S-video

Ps.


In the Poynton book (Digital Video and HDTV: Algorithms and Interfaces)
one can find the following sentences about the NTSC standard (and also
for a couple of other references, including PAL ).

"...The Y’ and C components should be time-coincident
within ±25 ns. Error in chroma timing is known as
chroma-luma delay. "

(2003 edition, page 514)

So, to answer one of the original questions, the luma-chroma delay of
standard composite and separate Y/C video should be 0 ns within a +-25
ns margin.



On 2017-08-31 23:04, HÁRSFALVI Levente wrote:
> Hi!,
> 
> 
> On 2017-08-31 20:06, Mia Magnusson wrote:
>> Hi!
>>
>> As many people already know, C64 is older than the consumer S-video
>> signal format, and doesen't comply completely to that standard.
>> ...
> 
> I don't know all the answers, but I might add something (or what)...
> 
> - In a TV set / composite monitor, group delay between luma and
> demodulated U' and V' components is inevitable, due to the need of
> separating two signals of different bandwidth first (chroma from luma),
> and then the need of demodulating the color difference signals (whilst
> luma, by itself, doesn't need to be demodulated). To compensate for
> that, the devices usually have a small, some-10 ns analog delay line in
> the luma signal path. How well this compensation works depends on analog
> components and setup in earlier PAL TV sets and monitors. (Later models
> might have that integrated into some chip, just as the earlier 1H glass
> electroacoustic delay line has made it to a form of sampled mixed-signal
> integrated circuits later, and suffer less from the degradation and/or
> variance of analog component values).
> 
> - I've never noticed this unusual color delay problem on C64s on late
> (high resolution, small pixels mask) CRT tvs and monitors myself. (On
> the other hand, it was long ago when I played around with a C64 the last
> time). Nor did I ever notice such delay with 264 series machines. I
> definitely did notice the problems that originate from the unusually
> high pixel clock and luma bandwidth of the C64 (--> pseudo-colors and
> color artifacts as a result), but that one might be unrelated to the
> color shift problem you're describing.
> 
> - Some years ago, I had a long (and still not finished :-) ) fight
> fixing and correcting a PAL Commodore 1702 monitor (a 1702-T / a Toshiba
> CRT version, to be precise). All I can say that the luma delay was
> anything but perfect after that many years, or by design, or I don't
> really know how-why. The delay even differed for composite and separate
> luma-chroma input mode; nevertheless it was way off for both modes
> (about 1...1.5 pixels difference on the screen), both with Commodore
> machines, a recent DVD player that I used to generate test signals, or a
> standard TV picture generator instrument that I purchased and used
> later. I've never noticed that problem on my other "old style"
> (composite / separate luma-chroma / large raster mask) Commodore color
> monitor (a 1801, that is). All in all: I'd say, if the question was some
> strange luma-chroma delay value of some particular Commodore display
> make, I'd much rather suspect a by-design poor luma delay circuit than
> some third-party supplier purposely tailoring the luma delay value of
> their product to the task.
> 
> (As a side-note, AFAIK basically all Commodore monitors have been
> manufactured by contractors... JVC, Sharp, Philips, Samsung, and so on;
> and also, the picture of the C64 would need to be consistently
> differently shifted on standard CRT TVs and early Commodore displays if
> Commodore had had the manufacturers tailor the luma delay value of their
> products; which AFAIK has not been confirmed).
> 
> - For the 1702 fix, I think I found something promising: some
> manufacturers offer tapped analog delay lines (that is, usual, coil-type
> delay lines with many taps). With that I think I can replace the
> original delay line in the display, and select a tap that provides
> optimal delay. I'll definitely calibrate the thing against some standard
> signal source, and not a Commodore machine (but as said, ATM I don't
> expect significant differences). Such delay line might also be a
> suitable base component for your case (or, I don't know... with that,
> impedance matching might become difficult).
> 
> 
> Best regards,
> 
> Levente
> 
>        Message was sent through the cbm-hackers mailing list
> 


       Message was sent through the cbm-hackers mailing list