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

Den Thu, 31 Aug 2017 21:03:18 +0200 skrev silverdr@wfmh.org.pl:
> 
> > On 2017-08-31, at 20:06, Mia Magnusson <mia@plea.se> 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.
> 
> Well, it doesn't comply to /any/ video standard if we want to tell
> the truth :-)

Yes, I know that the level for the chroma is a bit off and that the
output stages doesen't really have the correct impedance either, but
that usually works fine as it is. Almost (?) every TV has AGC for the
chroma, adjusted by the level of the color burst so it's probably not a
big problem. :)

> > 1: Compare the schematics of some TV sets with S-video input to the
> > schematics of a Commodore CRT monitor with "C64 S-video" input, and
> > figure out the difference
> 
> The differences may be rather big and please note that it might not
> be obvious where the timing difference is handled as well as that it
> might come from some analogue "tweaks" rather than a pure design
> difference.

Well atleast the CRT TV I modified had a "s-video" control signal that
just selected between two different delays. Selecting or not selecting
delays in a Commodore CRT would probably be easy to spot.

> > 2: Find some spec on S-video timing. I've googled but haven't found
> > anything.
> 
> There are "Rec."s about the video timings but I don't see how this
> alone could help. You still need to measure things.

Well, the composite video seems to have standard timing, and we know
that the modulator just mixes the luma and chroma signal (with a RC
filter which might change the timing slightly but that's easy to
measure), so we could probably assume that the wanted delay is the
difference between the specs for composite video and s-video.

> > 3: Measure colour bars from a C64 and a known S-video source (for
> > example CD32)
> 
> I just (few weeks ago) wrote a small proggy for the 64 to display the
> quasi-standard colour bars over the whole screen. I wrote it to
> measure some other aspects but can be used to measure the difference.
> Just connect the 64 displaying the bars to a good
> waveform/vectorscope measurement set and compare it to a known
> standard source (like the broadcast test signal generator). As I
> wrote a minute ago in another thread I once ran a studio and I still
> have all of those (scopes and generators) if needed.

I don't have that kind of equipment, just a (modern digital)
oscilloscope so I'd have to look at the waveform. The chroma-luma
timing should be visible that way too.

> > 4: Extrapolate from looking at a picture (the mistiming seems to be
> > approximately 2 pixels, so two cycles of the pixel clock would be
> > about the mistiming)
> 
> Chroma has lower resolution than luma so there will always be some
> mistiming when we talk one pixel for example. I remember doing those
> things (finding the best relation between luma and chroma using the
> studio equipment while looking at both the picture and the WFM. It
> was required especially when working with non-Betacam material.

Yes, but with my current setup it's obvious that there is mistiming.
And many modern color decoders can do tricks to detect a transient and
improve the bandwith of the transient, so it looks better.

> > 5: Experiment with different delays.
> 
> Until your WFM shows what you want it to.
> 
> > My idea is to figure out the optimal delay and then just calculate
> > what cable length gives such delay (afaik it depends on what kind of
> > insulation the cable uses so maybe a few different lengths could be
> > calculated for different common types of 75 ohm coax cable). Then
> > anyone who wants a perfect picture could just route the luminance
> > through a cable of the correct lenght.
> 
> I am not sure what you mean. The propagation times over properly
> matched line is close to negligible. You may get some
> quasi-impedance-matching by trimming the cable to a specific length
> but a) it's a mother of bad ideas when it comes to impedance matching
> and b) we talk relatively low frequencies here, where it doesn't work
> that well.

A 75 ohm coax shouldn't have any impedance matching problems if the
TV/monitor has a proper 75 ohm termination. (I've seen 82 ohms in many
cases, probably because that was cheaper, but it's rather close). As
long as the reciever has a correct match the transmitter might be a bit
off without any real problem.

> > If I'm not mistaken it would probably be a cable lengt of about 30
> > metres (100 feet) +/- 50% or so. That seems like a rather long cable
> > but it's not that bad to hide under a desk or behind a TV.
> 
> Ah... with tens of metres of length difference you might get some
> propagation time difference but you'd still need to do this mostly by
> trial and error and you'll get different results with different
> cables.

It seems like for most RG cables there are three different progagation
speeds, so it would be easy to have three different legnths for a user
to try:

https://cdn.shopify.com/s/files/1/0986/4308/files/Cable-Delay-FAQ.pdf

> Bear in mind that there is also attenuation.

Yes, but that could probably be ignored at such low frequencies.
Atleast TV aerial cables would only attenuate a few dB with tens of
metres and more than 100 times higher frequency, and the cables sold
for parabolic dishes would have even less attenuation.


> > The point is that it would be a simple thing anyone with a soldering
> > iron could do, without any need for some fancy electronics. Just
> > pick up a spool of enough tv antenna coax cable and solder it in,
> > and get a real picture improvement.
> 
> I think it's still better to make a small circuit for that :-) and
> you might get better connectors on the output side while you're at
> it ;-)
 
Well, the point of using a long cable is that the cable is available in
shops almost everywhere so you don't have to order stuff.


-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

       Message was sent through the cbm-hackers mailing list