Closed IanSB closed 1 year ago
Alpha 59C with support for commodore 64 PAL artifacts (toggle on/off with long press of SW2)
I am not really sure how this whole PAL color averaging should look like. I used my test pattern generator that displays diagonal stripes of all colors. And there all colors besides the grayscales and red/light red produce a more or less different color on every other line. I would have guessed that color averaging would just look solid in if the color does not change from line to line.
@c0pperdragon
I would have guessed that color averaging would just look solid in if the color does not change from line to line.
In a perfect world that would be correct but the VIC II is buggy and the V (R-Y) component of the PAL Chroma changes level on Odd lines (I think this is after phase reversal). The effect of this is that odd and even lines have slightly different colour shifts even after PAL averaging. (Note this is odd/even lines in a progressive frame, not odd/even fields)
This means that if you alternate two different colours to generate a new colour, the shade you get can vary slightly depending if the first line of each pair is odd or even. I have seen this on a retrotink and it is specifically emulated in Vice. There is some more info here: https://kodiak64.com/blog/non-standard-hues-PAL-NTSC-C64
Here are some screencaps from https://csdb.dk/release/?id=50556
Normal:
The colour blocks at 3 up 2 across and 3 across illustrate the two different colour shifts when using the same two colours as odd/even and even/odd.
(View images full size to avoid aliasing artifacts)
PAL Artifact colour on
PAL Artifact colour on + scanlines
Vice emulator with PAL artifacts and scanlines:
But don't you think this is taking it a bit too far? What is the real purpose of the digital upscaling approach when it again re-introduces all the insufficencies of the original analog output. I can very much understand why someone wants to have the color averaging to get access to mor colors. But what would be the actual use of emulating this bug in the VIC color generation. We wouldn't want to re-create the luma jailbars either, don't we?
@c0pperdragon
The colour mixing is used in some games and demos and emulating the defect is the only way to get the colours right. You can remove the defect but leave the colour blending by setting PAL Odd Line to 0 in the palette menu but then the two example colour blocks I mentioned above will be the same colour instead of different colours.
@c0pperdragon Here's a comparison of the defect on / off:
Defect off:
Defect on:
I didn't know that you already have the option to turn off the defect emulation. So everyone can get what they want.
@c0pperdragon
Here is Alpha 59D: RGBtoHDMI_Alpha59D.zip
This has a new option: "PAL ODD LINE" The settings are: Off: - No odd line level adjust (Same as setting PAL Odd Level to 0) Blended Colours: - The odd line is adjusted for blended colours only and the solid 16 colours do not get adjusted All Colours: All colours including solid colours get adjusted (default with previous beta)
Blended Colours is the default so you get the right shades and solid colours stay solid.
EDIT: Please check that C64 and Atari lumacode look OK to you with Alpha 59D and if so I will release a new beta
I have tested all 4 possibilities C64 and Atari, PAL and NTSC and they work with both YUV and RGB.
My new signal generator (https://github.com/c0pperdragon/LumaCode/tree/main/signalgenerator) is really convenient to quickly check such things, while my workbench is currently full with VIC 20 related stuff.
Alpha 59E: RGBtoHDMI_Alpha59E.zip
Add VIC20 lumacode Improve Amiga 2000 ECS support
Alpha 59F: RGBtoHDMI_Alpha59F.zip
Fix Commodore 128 calibration bug (was not ignoring flashing cursor) Update Commodore 128 profiles Update test profiles Fix autoswitch not working with 4K monitors
Alpha 59G RGBtoHDMI_Alpha59G.zip
Updated Commodore 128 profiles
Alpha 59A with initial support for Atari 800 Lumacode
RGBtoHDMI_Alpha59A.zip