| |
pepto
Account closed
Registered: Nov 2004
Posts: 35 |
colodore is the new pepto
Hey guys, I remeasured the video-signals of my VIC-II's and slightly updated my 15 year old attempt at calculating an rgb-clone. While at it, I also measured VIC & TED and made a little website about it, that allows you to adjust brightness, contrast and saturation as you like and then save your own custom palette to a png-file.
http://www.colodore.com
I took extra care to make sure, that the brightness, contrast and saturation sliders behave the same way as my 1084s.
While closely comparing my LCD to the 1084s, I found that making the transparency of scanlines dependent on YUV's Y (so they are less visible for brighter colors) looked a lot more like the real thing. I also noticed that the phase-shift on odd-lines happens for YUV's V only and there's even a name for it in video-lingua: hanover bars.
After implementing this, I'm happy to say that the images on my LCD and 1084s are remarkably close.
I will write a more detailed article about it in January, but seriously need a christmas-break first...
Cheers,
pepto |
|
... 97 posts hidden. Click here to view all posts....
|
| |
pepto
Account closed
Registered: Nov 2004
Posts: 35 |
Quoting Groepazdoes joes "play with colors" work correctly with your stuff?
This is really interesting! I didn't know about this test before.
I would say 90% of the fields look correct (I'm comparing colodore to the real C64 on the 1084s) and this is because of delayline-style chroma-blending.
A few adjacent fields however, which only differ by one color being on even lines in one field and on odd lines in the other, blend differently on the 1084s compared to colodore.
Which means the color-generation described on http://www.pepto.de/projects/colorvic/ works just fine and also the delay-line on colodore, but the way I do hanover bars doesn't seem to work 100% yet, even though it looks like a perfect match on solid colored fields, so it definitely is the phase-shift on v, just like it should be.
I'm puzzled for the moment and need to get some sleep.
At which point do you guys inject hanover-bars into the signal in Vice? I do it after the delayline, that's why a field with (lgrn/yel) looks the same as (yel/lgrn) before the hanover bars are added. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
VICE uses two yuv palettes, one for odd and one for even lines, and both go into the delay line stuff. this is pretty much required to get those mixed colors 100% right (hence my question before)
you could also use this little test image, it shows all the mixed colors - the important bit is that some of them are different depending on what colors are in odd and even lines. |
| |
ilesj
Registered: Jun 2012
Posts: 27 |
Quoting peptoAt which point do you guys inject hanover-bars into the signal in Vice? I do it after the delayline, that's why a field with (lgrn/yel) looks the same as (yel/lgrn) before the hanover bars are added.
Should it be the other way around? Your article links to this Wikipedia article https://en.wikipedia.org/wiki/Hanover_bars that says
Quoting wiki
To suppress Hanover bars, PAL color decoders use a delay line which repeats the chroma information from each previous line, and blends it with the current line
|
| |
pepto
Account closed
Registered: Nov 2004
Posts: 35 |
Quoting wiki
To suppress Hanover bars, PAL color decoders use a delay line which repeats the chroma information from each previous line, and blends it with the current line
You are correct, a delay-line would be the weapon of choice to suppress hanover bars, but they are a clearly visible artefact, along with delay-line style vertically blended chroma.
Something doesn't seem to add up in the crt-emu/video-signal portion (e.g. detached from the general palette color generation). I came to the same conclusion originally, but unfortunately reality still differs.
Quoting GroepazVICE uses two yuv palettes, one for odd and one for even lines, and both go into the delay line stuff.
Hmm, but shouldn't this cancel out hanover bars completely?
I have a first idea on how to get "play with colors" to blend right. I have a feeling it's something simple. I will try to find some time this weekend to investigate. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
Quote:Hmm, but shouldn't this cancel out hanover bars completely?
apparently not... they are only completely gone if the phase difference between odd and even lines is exactly 180 degr. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quoting wiki
To suppress Hanover bars, PAL color decoders use a delay line which repeats the chroma information from each previous line, and blends it with the current line
You are correct, a delay-line would be the weapon of choice to suppress hanover bars, but they are a clearly visible artefact, along with delay-line style vertically blended chroma.
Something doesn't seem to add up in the crt-emu/video-signal portion (e.g. detached from the general palette color generation). I came to the same conclusion originally, but unfortunately reality still differs.
Quoting GroepazVICE uses two yuv palettes, one for odd and one for even lines, and both go into the delay line stuff.
Hmm, but shouldn't this cancel out hanover bars completely?
I have a first idea on how to get "play with colors" to blend right. I have a feeling it's something simple. I will try to find some time this weekend to investigate.
Keep me informed so that I can update the webgl-port. (will release soonish). |
| |
pepto
Account closed
Registered: Nov 2004
Posts: 35 |
Quoting JackAsserKeep me informed so that I can update the webgl-port. (will release soonish).
Cool! No worries, I will keep you updated... |
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
Great work!
There is another effect that was mentioned in an old demo, I think it was made by Crest when they introduced NUFLI or something similar:
The video chip is slower at changing the voltage level from black to white than the other way round. This means that a sequence of for example black and white pixels appears darker than one would expect (even when considering gamma level effects on a slightly blurred output). This effect also is less prominent on later video chips, probably because their internal transistors work faster.
I didn't find this being mentioned in this thread before, so I just thought I'd mention it.
Also, is the phase of the chroma carrier fixed? If I remember correctly it's chosen randomly on every power cycle. But I totally understand that this one would be a bit nasty to emulate, but I still wonder how much this affects the appearance of pictures. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
the so called black bleeding is NOT caused by the VIC as suggested in that crest demo - it completely disappears when removing the modulator, so its basically the result of the shitty video circuit. |
| |
pepto
Account closed
Registered: Nov 2004
Posts: 35 |
Quoting peptoYou are correct, a delay-line would be the weapon of choice to suppress hanover bars, but they are a clearly visible artefact, along with delay-line style vertically blended chroma.
Oh snap, the 1084s seems to have a delay-line for YUV's U only. This explains a lot of things, especially why the phase-offset for YUV's V still is perfectly visible on screen after passing the delay-line and why more modern TVs manage to hide the hanover bars so much better, as they delay-line both YUV's U & V...
Quoting peptoI have a first idea on how to get "play with colors" to blend right. I have a feeling it's something simple. I will try to find some time this weekend to investigate.
The solution is simple indeed. I have an internal version of colodore.com now, that renders every single field of "play with colors 2" precisely like the real VIC II and solid single-colored fields still look identical to the original version... \o/
I will try to find time tomorrow to tidy up my code, update the website and tell you how it appears to work tomorrow. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
