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

Den Thu, 31 Aug 2017 23:58:48 +0200 skrev silverdr@wfmh.org.pl:
> 
> > On 2017-08-31, at 23:19, Mia Magnusson <mia@plea.se> 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.

Well, as long as you can store about one line you could tweak the clock
frequency of the computer so that it produces 624 lines every 1/25
second, and then just insert one extra line on every other field.

> > 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?

It would be interesting to see what you get with a test generator
compared with a C64. My experience is that composite video is good
on C64 but S-video is about two dot clock cycles off, with chroma
coming later than luma.

> > 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.

I would had assumed that they had two modes, "technician" and
"producer/audience", where "technician" would show all errors but
"producer/audience" try to show a good picture. (Of course the modes
would have other names).
 
> > 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?

Yes, about two pixeclock cycles judging by my eyes on my modern TV. I
should bring up the old CRT TV and see how it looks on that too.



-- 
(\_/) 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