| |
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....
|
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
scanlines are too strong imho |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
delay line only for U is interesting. i think 1701 does the same....
perhaps that finally explains why so many ppl complain about scanlines being too strong - they are used to displays that have delay line for U and V? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Quote: 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.
Not only is the rise slower than the fall (even without using the RF modulator), but luma changes overshoot then continue to oscillate for around four pixels. More later this week; Pepto's most excellent posts here have reminded me I've a post of my own I've been meaning to write for a while now.
And yes, sadly the chroma phase is random every power cycle :( |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Quote: 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.
Regardless of which circuit causes it, it's still worthy of emulation, no? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
sure... unfortunately however, its not practical (read: slow like hell) when done in software - pretty much needs shader support (micro64 can do it). it will still take a while until VICE is ready for this :) |
| |
Slajerek
Registered: May 2015
Posts: 63 |
Great work! And source is clean too.
Funny though that in the demo graphics selection there's no standard C64 Basic screen after kernal reboot :-) |
| |
Copyfault
Registered: Dec 2001
Posts: 474 |
Great investigations! Never thought that pepto would pop up again one day to continue with his video emulation stuff. Don't find any proper words for it, I'm just happy seeing this happening right now;)
Wondering if this quest for the perfect colour representants could be sensefully connected to the CIELab-colour model which was brought up by Ghostrider (iirc) some month ago. As far as I understood the CIELab approach is to model the colours as they are perceived under (configurable) circumstances (like i.e. kind of light, viewing angle, ...). The investigations posted here seem to aim at the same, with the difference of sticking to the YUV colour scheme whereas the CIELab model uses its own calculation components. Maybe I'm all wrong but for me it seems it could be a good idea to "port" the insights of this thread to the CIELab model. |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
Noticed a small bug with the delay line stuff as far as U only goes. I have a 1084S and solid colors display hanover bars, but when mixing luma pairs they get pretty much eliminated.
So in Joe's "Playing With Colors 2", the light red/green mixes look nothing like that on a real 1084S, they are much more uniform, pretty much like with the "on U only" thing off. |
| |
pepto
Account closed
Registered: Nov 2004
Posts: 35 |
Quote: Noticed a small bug with the delay line stuff as far as U only goes. I have a 1084S and solid colors display hanover bars, but when mixing luma pairs they get pretty much eliminated.
So in Joe's "Playing With Colors 2", the light red/green mixes look nothing like that on a real 1084S, they are much more uniform, pretty much like with the "on U only" thing off.
Thanks for noticing!! This really gave me some sleepless nights, since mid-june... ;P
I have a fix coming... \o/ it really only affects hanover-bars for certain color-combinations (like the red/green you mentioned) when not having delayline for both U and V).
"Play With Colors 2" is by Ed of Wrath Designs btw, not Joe...
I spent the whole day comparing the 1084S to the output of experimental colodore-versions and I think that I finally found a solution that looks very similar to the real thing. It seems that the "transparency" of the effect that the delayline of the V signal creates, is dependant on the phase of the color-angle.
I'm not sure how this translates to electronics though... O_o ...like U has a solid delayline-effect in monitors like the 1084S, but V's delayline-effect is only visible the more you get away from the center of the V-axis? It certainly looks like it, but where's the logic in that? Is this some weird way to multiplex two signals into one delayline or some signal-bleed crosstalk?
This is basically what I have now, in pseudo-code:
delayLine_v[ x,y ].alpha = parseInt( Math.abs( Math.sin( screenPixel[ x,y ].colorAngle ) * 0xFF ) );
My current implementation is full of debug-output in weird places though. I will tidy this up and write a small section about it on the website before the year is over (unfortunately I'm a lil' busy at work right now)... just wanted to give you a heads-up... |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
Nice, glad to be of help :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
