Break away from 1280x1024 OS resolution

[stevesims]

The VDP firmware uses OS coordinates of 1280x1024, which was based on Acorn's OS coordinates system on the BBC Micro.

Where this falls down is that none of our screen modes have native resolutions of our screen modes that are clean multiples of these OS coordinates. This makes some code hard, and it's tricky to do pixel accurate drawing.

One way around this is to use "native" coordinates, and we already have a VDU command sequence to switch to using them. (Using "native" coordinates tho loses some of the advantages of the OS coordinate system, such as being able to move code written for one resolution to another and have it still work as intended without needing extensive reworking.)

Another option (which I prefer) would be to follow what Acorn did. The Beeb used 1280x1024 as those values could be easily converted to/from using multipliers of 2, 4 or 8. On later computers they added in new screen modes that used different OS resolutions, but remained consistent with using multipliers of 1, 2, 4 or 8. For consistency, they generally aimed to get OS coordinates that were at least 1280 wide and 800 tall.

For the resolutions we have, this would mean that the vast majority of our screen modes would get OS resolutions of 1280x960 or 1280x800. Our native 800x600 mode would get an OS resolution of 1600x1200. As for 1024x768, we'd either just use a 1:1 on that, or 2:1 giving us 2048x1536 (Acorn went with 2:1 on their closest equivalents).

Legacy OS coordinates can still be made accessible in much the same way as we maintain access to legacy screen modes.

[stevesims]

NB it's only the PAL versions of the BBC Micro that had OS coordinates resolution of 1280x1024. the US version of the BBC Micro had OS coordinates resolution of 1280x800, and its screen modes had less vertical resolution, using only 200 lines vs the 256 lines on PAL systems

this ship however has sailed - the time to do a proper OS resolution system that works with integer scaling amounts was before the Quark 1.04 release

there is however still scope to allow the user to select integer resolution scaling.

the non-integer scaling we have can be problematic. the underlying drawing system is written to assume that pixels are either square or 1:2 rectangles - so curves and circles are drawn using that assumption.

porting programs written for the BBC Micro or RISC OS machines you can as a result occasionally see strange artefacts that rely on the OS coordinate to pixel coordinate ratios being integer (power of 2) scales.

[stevesims]

support for "proper" OS resolution handling can potentially be added via a feature flag

we currently have "test" flags - those could instead be feature flags. the existing "OS/pixel resolution" flag could/should also be changed to use feature flags