[CSDb] - User Forums - Christopher Jam's composite video measurements

You are not logged in - nap

CSDb User Forums

Forums > CSDb Discussions > Christopher Jam's composite video measurements

2017-10-27 05:37

ChristopherJam

Registered: Aug 2004
Posts: 1408

Christopher Jam's composite video measurements

I spent a month or two back around the start of 2015 measuring the composite video output of a new luminance c64 using a 100MHz USB oscilloscope, then trying to reproduce the output waveform using a simple predictive model.

Before I started, I had this crazy idea that I could use the fragments of chroma signals from each pixel to manufacture new colours, on the assumption that each pixel would be a well defined slice of a sinewave. Ahahahaha. Nothing so simple. Chroma takes several pixels to start up and shut down again, and the luma signal rings visibly for four or five pixels.

I do now however have a pretty accurate model of the luma behaviour, and my chroma model is not far off.

Some pretty graphs and test images at http://jamontoads.net/p/lumachroma.html

Here's a teaser

and a palette :)

jampal=[000000, ffffff, 7d202c, 4fb3a5, 84258c, 339840, 2a1b9d, bfd04a, 7f410d, 4c2e00, b44f5c, 3c3c3c, 646464, 7ce587, 6351db, 939393]

... 11 posts hidden. Click here to view all posts....

2017-10-27 09:23

ChristopherJam

Registered: Aug 2004
Posts: 1408

Quoting Krill

Good job!

Thanks!

Quote:

Apart from the palette, can the model you deduced be (easily) included with emulators to improve render fidelity?

Nontrivial in its current state.

I'm pretty sure I can get the signal reproduction down to four table lookups per pixel, each one indexed by a run of three pixels (or one two-byte lookup indexed by the last five pixel indices), but that just generates a two sample per pixel composite signal that would still need converting to YUV, chroma averaged, then RGB converted.

The composite->YUV filters I'm using at the moment are several pixels wide, so a direct translation would be fairly slow. More maths to be done..

2017-10-27 19:31

lft

Registered: Jul 2007
Posts: 369

But graphics cards are fast. Sounds like a straightforward job for a pixel shader.

2017-10-27 19:35

Jammer

Registered: Nov 2002
Posts: 1335

Splendid! So this or Colodore? ;)

2017-10-27 20:37

chatGPZ

Registered: Dec 2001
Posts: 11350

did you actually use composite? and if yes, why? =)

it would also be interesting to know what video chip exactly you used... and then re-do the measurements on different chips. i am willing to bet there are quite some differences :)

2017-10-27 20:45

Oswald

Registered: Apr 2002
Posts: 5086

very cool you did that =) in some of the example pictures the "distortion" feels like those on true CRT.

2017-10-27 22:21

soci

Registered: Sep 2003
Posts: 479

View64's PAL/NTSC mode generates luminance and chrominance "signals" and feeds them it into a decoder. The signal generation part is a bit simplistic currently and this bothered me for a while.

Therefore these measurements are really interesting.

2017-10-27 23:46

chatGPZ

Registered: Dec 2001
Posts: 11350

the renderers i wrote for testing also work like this... i was lazy though and used some filter implementations i found somewhere on the net which are not really suitable for realtime signal processing so its all really slow =)

2017-10-28 03:13

ChristopherJam

Registered: Aug 2004
Posts: 1408

Quoting lft

But graphics cards are fast. Sounds like a straightforward job for a pixel shader.

Yes I've been wondering about that. Attempting one has been on my todo list for over 18 months now though, so I should just release a slow reference implementation and let someone else have a bash at making it faster..

Quoting Groepaz

did you actually use composite? and if yes, why? =)

haha yes! Um, I wasn't getting any signal at all from the chroma pin on the c64 in question. Besides, composite's the only input on the front of my nicest CRT, so it's how I view things anyway..

Quote:

it would also be interesting to know what video chip exactly you used... and then re-do the measurements on different chips. i am willing to bet there are quite some differences :)

Yes, differences seem likely. This was a nine luminance one in an assembly where I'd need to unscrew the keyboard to even get to the heatsink/shielding that's covering the chips.. And that c64 has stopped working properly sometime since I took the measurements.. (powers up and displays " OUT OF MEMORY ERROR IN 0" I'm a bit scared to plug my MMC reader into it..)

Quoting soci

View64's PAL/NTSC mode generates luminance and chrominance "signals" and feeds them it into a decoder. The signal generation part is a bit simplistic currently and this bothered me for a while.

Therefore these measurements are really interesting.

Ah, nice. Ok, I will try and finish bundling up the code and data for release.

2017-10-28 16:07

pepto
Account closed

Registered: Nov 2004
Posts: 35

Quoting ChristopherJam

I do now however have a pretty accurate model of the luma behaviour, and my chroma model is not far off

These sloppy signal observations are interesting... congrats on finally publishing the results of your experiments. :)

Quoting Jammer

Splendid! So this or Colodore? ;)

It doesn't really matter that much, as colodore isn't really ONE EXCLUSIVE palette. You may tune it by altering the brightness, contrast and saturation sliders, just like on real equipment. This way you should be able to match captured palettes (there are small lot-to-lot variations). For example here's a quick attempt to tune colodore (47/85/66 - top) by eyesight to somewhat match Christopher's palette (bottom).