XRoar experimental CVBS branch

I've been working on a branch of XRoar with better composite video processing. The idea is to provide controls over various filters in the signal path so that I can come up with a good set of defaults for each system.

Linux (GTK+) users can try the 'cvbs' branch of the git repo:

git clone -b cvbs https://www.6809.org.uk/git/xroar.git

Windows users can try the snapshot builds here:

https://www.6809.org.uk/tmp/xroar/

(Sorry MacOSX+ users, no idea how to do your dialogs, also it's too hard to cross-build for you).

It's looking reasonable now. Rob CFG pointed out some older research into PAL behaviour, and tweaking enough controls gets things about right. At the moment it seems to require a slight hue adjustment, which implies the phase of the colourburst out of the Dragon relative to the chroma might not be quite what it's supposed to be.

https://archive.worldofdragon.org/phpBB3/viewtopic.php?p=14571#p14571

Here's what there is to play with. Bring up the video options dialog with View -> TV Options (or Control+Shift+V). From there you can:

• Adjust brightness, contrast, colour (saturation), hue - these will end up in the main branch whatever happens
• Change the pixel samplerate F_S, which happens to be the SAM clock:
  • 14.31818 MHz - NTSC machines, older Dragons
  • 14.218 MHz - newer Dragons
  • 14.23753 MHz - PAL CoCos
• Change the chroma subcarrier frequency, F_SC:
  • 3.579545 MHz - NTSC, PAL-M
  • 4.43361875 MHz - normal PAL
• Change the colour encoding method:
  • NTSC - modulate and demodulate chroma as I',Q'
  • PAL - mod/demod chroma as U',V' and average both over alternate lines
• Change how much V' is offset on "alternate" lines, with bias and scale. We thought the inverting op-amp arrangement in a Dragon didn't result in this being centred properly around CHB, but this might be fine left as it is.
• Modify the type of filter used at each stage of the signal path

If you pick "Custom X" for a filter (where X is the windowing function) you can continuously vary the cutoff point of the lowpass filter (highpass for Chroma decode) for that stage. You can also alter the "order" of the filter (higher order tends to lead to sharper cutoffs).

Note that changing F_S doesn't actually change the speed the emulator runs at, it's just used to change the pixel-to-chroma frequency ratio.

All this adds up sadly - as it stands, this now exceeds the CPU grunt my old 2015-era laptop had - mostly due to always convolving the maximum order (with extra terms zeroed). Once I hit on the right set of parameters, I can definitely optimise it a bit.

(It'll also be a good candidate to implement using GPU shaders, but first things first :)