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

From: HÁRSFALVI Levente <publicmailbox_at_harsfalvi.net>
Date: Sat, 2 Sep 2017 11:40:39 +0200
Message-ID: <c046c60a-0b61-8eb2-e569-dcc936a164c0@harsfalvi.net>
Hi!,


On 2017-09-02 04:20, Mia Magnusson wrote:
> Den Fri, 1 Sep 2017 10:03:53 +0100 skrev smf <smf@null.net>:
>>
>> On 31/08/2017 22:04, HÁRSFALVI Levente wrote:
>>> (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).
>>
>> Supposedly the monitor was tailored to the 64.
>>
>> commodore wouldn't have a problem selling you a monitor that would
>> only work properly with the c64, because they wanted a reason to sell
>> you another monitor.
> 
> I'd rather assume that Commodore just used the timing you got with
> signals ment for mixing to composite, as that ment the least extra
> effort to provide Y/C output on C64. There were no S-video stuff at
> consumer equipment at the time, so there were really no standard to
> follow.  .....

Composite video actually _is_ the simple sum of luma and chroma, with
the single requisite that both components be bandwidth limited according
to the respective standard. (That is, when someone sums Y' and C of
standard S-Video together to get a composite signal, the only incorrect
step he makes is not limiting Y's bandwidth, which can be as high as
8MHz and usually results in color artifacts due to the high frequency
components interfering with C .)

As I understand there are no specific ( --> different) luma-chroma delay
requirements for composite _and_ S-Video.

From the mentioned book, I get the impression that the general concept
of standard video, with regard to delays, is that these must be
addressed at the place where they're created. (Chroma quadrature
encoding already _does_ impose chrominance delay in any case; still,
standard composite is _required_ to have Y' and C coincide within a
rather narrow margin, effectively requiring composite generators to
correct chroma delays they produce).

Some more things that could possibly affect your case...

1.) The separation process of Y' and C might turn out somewhat different
in various consumer devices, as compared to a by-the-start separate Y'
and C case. Back in the days, manufacturers used notch filters for the
separation process, then they invented comb filters, and, today, who
knows ;-) . All in all - it's fully possible that in some devices, the
imposed group delays of the luma and chroma paths of the separator
filter are different. But this has nothing to do with standards; this,
if not addressed, is a flaw (or feature? ;-) ) of some particular device.

2.) In the VIC-II, AFAIK both the luma output and the chroma modulator
part are fed from the pixel shifter, directly. That means, that the luma
and chroma "pixels" are aligned by their "left edges", and not their
centers. Effectively, some chroma delay?... Whatever. (Would need to be
elaborated.)

3.) AFAIK the composite output of the C64 is produced in the RF
modulator. There must be a small lowpass filter in the Y' path (to limit
Y' bandwidth) which could affect group delay... but that's IMHO a
theoretical possibility, I'd doubt if that'd add anything significant.


I'd probably arrange a test where I'd try feeding the TV from a signal
source (a DVD player possibly, showing some purposely selected TV test
image), first from composite video and then from Y'/C output . That
could reveal if the TV (by itself) produced the extra chroma delay at
the first place, or if it just didn't. (I assume todays DVD players meet
these old analog standards pretty well, due to the incredibly common /
cheap / polished digital components they're built on).



Levente

       Message was sent through the cbm-hackers mailing list
Received on 2017-09-02 09:40:39

Archive generated by hypermail 2.2.0.