C64: incorrect blanking

[sorgelig]

Since i've got hardware supporting scandoubler video, i've started to check cores in this mode.

C64 core in scandoubler mode is very very dark. Picture is barely noticeable. After checking source code, i've found this:

    hSync <= hBlanking;
    vSync <= vBlanking;

So, basically Monitor (and TV) has no blanking signals to adjust color gains and treat the border as a black level. Actually, it's true even for TV mode, but somehow other converter pick correct black level and picture is correct in PAL mode. I think, the picture depends on specific monitor/TV where some displays will show correct picture, while other may show very dark picture.

In general, core should be fixed to have blank level samples. The C64 core is quite complex and i'm not sure if i will be able to fix the problem. Can try to reduce hSync/vSync if there is a room.

[harbaum]

Is there a rule that sais a front and back porch must be present? Most home computers blank only during sync.

[ghost]

Monitors determine display levels from the r g b values present during the blanking period. I've not tried it in a real TV but I have observed this on vga signals of many resolutions

[sorgelig]

Yep, there is a rule for video signal. Front porch is used for black level adjusting. All home PCs i saw have these blank levels. Actually these porches were present also because old CRT TV couldn't display all pixels. So every retro computer and console had black border around picture to make sure whole picture is in visible area of CRT screen. Those computers which have large border with adjustable color (ZX Spectrum, C64) had additional outer black border. I've explored C64 code more and found that for TV mode uses special CSync signal formed by complex formula with blank (porches) insertion. That's why PAL/NTSC mode works fine.

[sorgelig]

I think, for HDMI there is no need to have blanking fields because it's digital. That's why there are special modes for HDMI for extra resolution. But VGA is analogue signal, so blanking should be present.

[ghost]

HDMI/Dvi seems to be a digital representation of VGA. Same signals just encoded on a faster carrier. It would good practice to keep things the same as some decoders/monitors may convert to analog internally. E.g an HDMI crt if anyone was crazy enough to make one of those

[sorgelig]

I will try remove scandoubler from where it is now. Then will add into top module as in other cores. There is some additional calculated blank signal, so may be i can use it.

[harbaum]

Typically a screen would adjust the blanking level within the horizontal sync period. On a tv signal the time before the hsync was used for the colour burst which allowed the tv to synchronize onto the colour subcarriers. The blank level adjustment then happened in the hsync. You can actually try that out with the mist. Just keep some signal above zero during hsync and watch the main image have wrong colours. This happened more than once to me. You can also force this to happen with atari st core ability to adjust the sync position.

And yes, hdmi is just like vga with all signals digitized. But hdmi specifies the exact timings and thus it lacks many of the auto adjustment capabilities of analog vga. I have yet to see a screen that is more tolerant with digitial inputs than with analog inputs. Actually hdmi requires you to pass lots of signal timing tests before you are allowed to sell a hdmi device. Hdmi unfortunately is not the cure for all video problems. It will solve some issues bit it will introduce new ones.

[sorgelig]

Ok, i've fixed this problem. I will push release to binaries.

[harbaum]

Wow. Unbelievable fast work. Thanks a lot.

[ghost]

Well done. :)

On Sat, Jan 9, 2016 at 4:18 PM, Till Harbaum notifications@github.com wrote:

Wow. Unbelievable fast work. Thanks a lot.

— Reply to this email directly or view it on GitHub https://github.com/mist-devel/mist-board/issues/17#issuecomment-170257135 .

Stephen Leary

[sorgelig]

Considered as fixed. Let me know if there are issues with VGA mode.