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

From: Mia Magnusson <mia_at_plea.se>
Date: Thu, 31 Aug 2017 23:19:41 +0200
Message-ID: <20170831231941.00007d83@plea.se>
Den Thu, 31 Aug 2017 22:14:56 +0200 skrev silverdr@wfmh.org.pl:
> 
> > On 2017-08-31, at 21:26, Mia Magnusson <mia@plea.se> wrote:
> > 
> >>> 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. :)
> 
> The levels are off specs, the timings are off specs, the impedance is
> off specs, the sync pulses are off specs, the signal is
> non-interlaced, and so on :-)

:)

> Some time ago I was intensely brainstorming and pushing (even here)
> an idea to design an interface that would "legalise" all the above so
> that every piece of standard compliant (and expecting standard
> signal) piece of equipment could handle the video from the VIC-II
> equipped CBM machines. That is until I realised that it can't really
> be done.

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

> > 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.
> > [...]
> > 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.
> 
> Now, I might be missing something but to me the composite video is a
> way of 2to1 encoding/muxing so that two signals can be transmitted
> over one line rather than two. Unless I am now mistaken, there should
> be no differences (other than unintended) in the luma/chroma timing
> between the two. Now that you say about your CRT TV, I start
> wondering whether I am really missing something.. like time needed to
> decode composite.. hmm.. but that still shouldn't affect
> interrelation between the two. I always assumed that what I was doing
> in the studio was due to unintended differences caused by
> non-broadcast quality of the equipment used rather than inherent
> differences.

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.

> >>> 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.
> 
> Yes. Good oscilloscope will be fine.

Although cheap I find my Rigol rather good (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, but with my current setup it's obvious that there is mistiming.
> 
> Interesting. I tested my "colour bars" program on the real-hardware
> and s-video monitors and didn't notice anything obvious. Might it be
> that the reason is somewhere else? Like that your current s-video
> equipped display is not driven by analogue video circuitry anymore
> and therefore has problems with the non-standard-compliant signal
> from the 64?

My current setup uses a perhaps 10 year old 40" Samsung plasma flat
screen TV with it's s-video input. 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.

> > [...]
> > 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.
> 
> 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)?

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.

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 :) )

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

> Well - then I probably don't have anything clever to say on that. I
> might help with the measurement and comparison between a reliable,
> standard (CD32 might not count as such) signal source and the 64. BTW
> - which board version you have? There were big differences between
> the modulators and the resulting output. From tack sharp to fully
> soapy for example. So this also might affect in a way.

Currently I actually have a PAL C128 (not CR), the C64 that I had while
I used a CRT TV has been sold of long ago. Not sure which revision of
the C128, I haven't looked inside yet. :) I have another C128 waiting
for repair (starts up with correct background and border color but
screen is filled with incorrect characters, so it's actually good
enough to see this timing issue). Picture seems to be rather sharp, but
not as sharp as the 80 mode (using a simple resistor network to feed
the analogue rgb input of a scart socket on the TV). I would at least
say that the picture is sharp enough to make the two pixels wide stuff
in the characters unnecessary, the font just looks fat.

I have my old CRT TV and also a bunch of Commodore CRT monitors
somewhere (underneath behind...) so I could probably try them too. If
the CRT TV still works it would be interesting to chech the timing
thumb wheel. I don't have any perfect reference signal generator but
have a few different dvd player, digital set top boxes e.t.c. that I
could use as s-video "references".



-- 
(\_/) 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
Received on 2017-08-31 22:01:44

Archive generated by hypermail 2.2.0.