search

hoglet67 / RGBtoHDMI

Bare-metal Raspberry Pi project that provides pixel-perfect sampling of Retro Computer RGB/YUV video and conversion to HDMI
GNU General Public License v3.0
850 stars 116 forks source link

Interlace mode on Atari 8-bit #372

Open c0pperdragon opened 8 months ago

c0pperdragon commented 8 months ago

I got some feedback from users of the GTIAdigitizer and besides some other bugs they also reported that there is actually a way that the Atari can produce an interlaced image with some extremely strange hacks. At least it shows as interlaced on normal TVs. And my GTIAdigitizer did not support this.

After quite some reverse engineering, I can now also produce the same sync pulses as the original machine, but the RGBtoHDMI does not recognize this.
I made some signal screenshots of the vsync portion of both half-pictures. Yellow is the original Atari, Blue is the GTIAdigitizer. voltcraft1395_4 voltcraft1395_3

As you see, the second sync pulse pattern is extremely weird. Do you think there is any chance that the RGBtoHDMI can interpret this als interlaced?

IanSB commented 8 months ago

@c0pperdragon Can you do scope captures with both odd and even Vsync pulses but also Hsync pulses before Vsync and after Vsync.

Currently interlace or non interlace is determined by measuring the total time for two fields and dividing by the line length. If the answer is an odd number then it is interlaced. Which field is odd or even is determined by measuring the time from the end of the Vsync pulse until the first Hsync pulse. On one field the time will be about half a line and on the other field it will be about a whole line.

However I have found a couple of examples that don't work with these methods:

  1. Commodore 128: This can generate "interlaced" video with one field longer than the other by 1 line so the total for two fields is an even number. There is a setting in geometry Vsync Type which can be set to "Force Interlaced" to work around that and I think this also happens with some Atari 2600 demos. The determination of odd/even field still works with the above very non standard signal.

  2. PAL Ti presenter: This generates an odd number of lines but outputs several half line equalising pulses after Vsync but before the first Hsync pulse so although the difference is still half a line the overall time for both is greater than one line and at the moment it can't cope with that.

When the Atari is in interlaced mode, what is the lines per frame value in the source summary page? If it is still even then try the above 'Force Interlaced' setting.

c0pperdragon commented 8 months ago

The scope traces already show both the even and the odd frame and also the two adjacent hsync pulses (together with the color burst). Before and after everything is completely regular with a hsync pulse every 64us. Normally the GTIA just produces 3 long pulses (about 59,5 us) for vsync and everything else is just short hsyncs (4,5us).

This weird hack somehow interferes with the GTIA so it pulls the output line high during some part of the vsync without it knowing what it is doing. So there is no additional line for an odd frame or anything.

The RGBtoHDMI also just reports 312 lines as usual.

c0pperdragon commented 8 months ago

Setting "forced interlace" does no help. If just makes the image stutter terribly instead.

IanSB commented 8 months ago

@c0pperdragon

The scope traces already show both the even and the odd frame and also the two adjacent hsync pulses Before and after everything is completely regular with a hsync pulse every 64us.

I meant the next hsync after that which is cut off on the right hand edge to see if there was any difference in timing between the two fields but as you indicate above there isn't any difference.

It looks like the only effect of this 'hack' is to delay the start of the vsync pulse by half a line in one field and insert half line pulses in the vsync although the end time and the overall frame length remains the same. It should be possible to decode this but I think it would probably require a dedicated vsync handler to ensure that it didn't break anything for other systems.

c0pperdragon commented 8 months ago

I don't know if there are other possibilities to influence the vsync pattern, as this depends on what the ANTIC chip can be made to do.
Maybe the best course of action is to wait until one of the actual developers using this effect directly asks for RGBtoHDMI support. I will just redirect them to this issue thread if needed.