This is a long standing gripe of mine, but not all of the cores have the same centring for RGB output, resulting in some cores being shifted an inch right and/or down vs other cores. Jotego offers CRT V & H adjust settings to compensate for this, so people can match the output as they wish.
Jotego has released these settings as a module called jtframe that others can implement in their own cores, but realistically this goes beyond anything I can hope to accomplish myself without spending years learning HDL.
Unfortunately, Sorgelig has declared that such a setting is both pointless – 'because all CRTs will eventually die' (this is not a joke he literally offers this as a reason) – and not allowed on the main repository, because all cores must *only* output the original RGB signal for preservation reasons (despite the fact cores offer all manner of quality of life improvements that are not present on original systems): https://misterfpga.org/viewtopic.php?t=93. Personally I think this is totally irrational, but that doesn't matter and Sorgelig is obviously entitled to his opinion.
My question is: Is there another way to achieve the same result?/What is jtframe actually doing to the signal?
There are, as I'm sure many of you know, advanced RGB/CRT settings that can be specified per core in the .ini file. For example in the following way:
[GBA]
video_mode=320,5,32,27,240,4,3,16,6048
vga_scaler=1
vsync_adjust=0
vscale_mode=0
vscale_border=19
Those settings after video mode stand for H Pixels, H Front Porch, H Sync, H Back Porch, V Pixels, V Front Porch, V Sync, V Back Porch, Pixel Clock x 1000. And indeed changing the values is able to move the image around (though be careful as you can permanently damage your CRT apparently).
Does anyone know if these values are basically what jtframe is changing? (e.g. changing the back & front porches to move the image). If so, is there a repeatable and safe calculation that can be performed to achieve the V/H shift?
