How to make RGBtoHDMI detect interlace?

[c0pperdragon]

I am still working on the lumacode board for the C16/Plus4 machines and it is really tough. The TED chip allows direct modification of the vertical and horizontal counters and so people come up with the crazyiest hacks how to make weird TV signals. The last one I am struggling with is some non-standard interlace mode. My TV shows this just fine, but the RGBtoHDMI just flickers the two pictures without interlacing them. But even when I provide my own program that generates a completely standard interlaced PAL signal (according to https://martin.hinner.info/vga/pal.html), the RGBtoHDMI still does not like this. I know that the RGBtoHDMI is capable of doing that as it works with the Amiga, but could you tell me how to set this up specifically?

[IanSB]

@c0pperdragon RGBtoHDMI detects interlace by measuring the number of lines for two fields. If that number is even then it assumes progressive video, if that number is odd then it assumes interlaced video.

Odd and even fields are determined by measuring the time from the end of the vertical sync pulse to the first hsync pulse. This is approximately half a line in one field and a whole line in the other field because with interlaced video, vertical sync starts and ends half way through a line in one field only.

This works with standard video that has 312.5 lines per field, however there are many ways to get other video chips to produce an approximation of an interlaced signal which has non-standard timing and those tests then fail.

e.g. The C128 VDC chip can be made to produce non-standard interlaced video which has an even number of lines in two fields by just shifting the vsync pulse half a line in one field which results in 312.5 lines in one field and 311.5 lines in the other.

Similarly, some other demos (on Atari I think) can start the second Vsync pulse half way through a line but end it at a hsync pulse so the vsync is e.g. 2 lines in one field and 2.5 lines in the other. This makes the current way of determining the odd/even field fail.

It seems that the only way to determine interlaced and odd/even that would work under all these circumstances is to measure the time from the last hsync to the start of vsync and that is on my list of things to do.

There is currently a workaround for the even number of lines and that is to use the 'force interlaced' setting for vsync type in geometry but that still requires the vsync to end half way through a line in one field.

[c0pperdragon]

I am still not able to make interlace work. By now I have a test program that generates a CSYNC pattern that is absolutely identical to what the Amiga generates in interlace mode. But somehow I can not set up theRGBtoHDMI to accept it. I am sure there is something missing on my profile. Maybe you can give this a look? C16_312.txt

I faintly remember that I had the same problems with the VIC 20 and there I also needed your help.

[IanSB]

@c0pperdragon Try setting the Vsync type to Interlaced instead of force interlaced. That specifically sets it up for Amiga interlace by ignoring equalising pulses

[c0pperdragon]

Still no luck. The image just flickers between the two frames. Strangely, when I reboot the RGBtoHDMI while the video source already sends the interlaced image, my monitor then flashes and every second line is also shown in black.

Am Sa., 19. Okt. 2024 um 00:35 Uhr schrieb IanSB @.***>:

@c0pperdragon https://github.com/c0pperdragon Try setting the Vsync type to Interlaced instead of force interlaced. That specifically sets it up for Amiga interlace by ignoring equalising pulses

— Reply to this email directly, view it on GitHub https://github.com/hoglet67/RGBtoHDMI/issues/406#issuecomment-2423329289, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACTIHVAPZRAHZVOOAU2CU6LZ4GEMDAVCNFSM6AAAAABP5VPSNOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRTGMZDSMRYHE . You are receiving this because you were mentioned.Message ID: @.***>

[IanSB]

@c0pperdragon

Don't put equalising pulses in as the software doesn't need them and it might cause mis-identification. Maybe try to replicate BBC mode 7 interlace as that was the primary target for interlace detection: Also make sure the software is detecting interlaced in the source summary menu.

First field: Zoomed:

Second field: Zoomed:

Probably put vsync type back to auto for this also make sure double height video selected in geometry

In the longer term it is probably better to pass vsync unmodified from the TED chip and allow updated RGBtoHDMI software to decode interlace properly as that will mean it will be easier to update if there are any new sync waveforms created by demos.