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

Date: Thu, 31 Aug 2017 23:58:48 +0200
Message-Id: <>
> On 2017-08-31, at 23:19, Mia Magnusson <> wrote:
> Well, the slightly off sync frequencys (and being non interlace) would
> require a TBC to correct but the levels, impedance and the timing
> difference between chroma and luma could easily be corrected. Also any
> improper sync signal (lenght of pulses, wafeform e.t.c.) could be
> corrected.

When I was pushing that, I was almost sure everything could be handled and corrected. The eventual show-stopper was when I realised that odd and even fields are actually of different duration and there is no way to make VIC-II generate make every other field longer/shorter.

> But as the sync frequencies is non-standard there is
> probably not much use for such correction, as all the non-standard
> stuff anyway works on most displays (except that the chroma-luma delay
> gives a worse picture quality than what is possible to achieve).

The non-standard C64 signal works on analogue displays as they are both analogue driven and also (in big part because of that) accommodate much wider differences. The current circuitry rarely works acceptably well with strongly non-standard signals like those from the 64.

> For some reason the decoding process in a TV anyway needs a delay. It's
> likely that the s-video standard were set to make a S-VHS player as
> simple as possible, i.e. bypassing any delay that's needed for a VHS to
> do composite -> separate chroma/luma -> FM modulate luma and frequency
> shift chroma -> record to tape, playback from tape -> FM demodulate
> luma and frequency shift chroma -> combine luma and chroma.
> So therefore it makes sense that the signals could have different
> timing specs for composite v.s. s-video in general.

I /think/ the difference in the delays in the decoders are caused by different signal paths, not by the difference in the specs of CVBS vs. Y/C. The delay lines are needed for other reasons.

To make sure (I believe so but am happy to verify) I can take a test signal generator (still should have a higher-end Fluke somewhere) and put both on the scope to see if there is any noticeable difference. You said you estimated the delay you wanted to introduce. What would that be? In other words - for what time difference am I supposed to look?

>> Yes. Good oscilloscope will be fine.
> Although cheap I find my Rigol rather good

I used wrong wording. For that purpose, virtually any working oscilloscope will be fine. By "good" I meant more something like "working correct", which is not always the case with some old ones. And - BTW - I also use Rigols for some good time. They are good value for money IMHO. But they could be less noisy for sure.

> (even better than what I
> remember from digital scopes that we had at a previous job about 15-20
> years ago, even though those were HP and other "good brands"). I've
> successfully used the "view one line" on the composite output from a
> VIC-20 and were able to identify where on the screen it says "READY.",
> so it seems to work with Commodore semi-non-standard signals :)

Yes, oscilloscope will always work with that :-)

> [...]
> My current setup uses a perhaps 10 year old 40" Samsung plasma flat
> screen TV with it's s-video input.

Normally, I would easily bet the problem on this one, but then you write:

> But I remember that the timing issue
> were the same when using a CRT TV and I especially remember that the
> timing were different on a C64 and a CD32, and that the C64 did fit a
> Commodore CRT monitor while CD32 fit the CRT TV, but using CD32
> on a Commodore CRT monitor or C64 on the CRT TV also gave the wrong
> timing.

... and that's the confusing part.

>> I see. But still your "obvious" timing problem smells somewhat fishy
>> to me. Never really noticed that kind of issues when using analogue
>> s-video displays. Including the truly hi-res, broadcast studio types
>> of. My bet is that yours is not analogue, is it? And if it is - might
>> it be miscalibrated somehow?  OTOH you say you did this before for
>> the same reason..
> Could it maybe be that the professional displays compensate for timing
> issues (by looking at the timing of the color burst v.s. the sync
> pulses)?

No, the exact opposite is more true. They show things "as they are". That's the one of the main reasons for using them in studios in the first place.

> It might also be that my digital TV set tries to do something with the
> timing but as the C64 timing is a bit too off the TV takes an incorrect
> guess and displays an even worse picture than on most other displays.

As before - that would be my first bet. And it really is a hit'n miss game with which one of the TVs/adapters will produce acceptable result and which not. More often it is "not" than "yes".

> In practise the light green border on the C128 default screen has a
> white stripe right next to the right edge of the visible area, and
> there is corresponding bleed from the green border onto the text area
> to the left of the visible area. The white stripe is about as wide as
> two pixels, which is why I'm guessing about 30 metres cable delay would
> probably make the picture better. (Sorry if I'm writing the same stuff
> all over, I tend to forget what I've already told or not :) )

Ah, now I forgot what you already wrote before - so that's the timing difference you're looking at - two pixelclock cycles of a C64 PAL signal, right?

> I assume from your e-mail adress that you too live in the 50Hz/PAL
> area :)

I do. Although there is hardly any PAL left outside of the retro stuff circles.

> Currently I actually have a PAL C128 (not CR)

I don't know that much about the 128 modulator differences but with C64s the differences were really big.

SD! -

       Message was sent through the cbm-hackers mailing list
Received on 2017-08-31 22:02:04

Archive generated by hypermail 2.2.0.