Feature flags as VDU Variables

[stevesims]

We have test/feature flags in the VDP, which are essentially 16-bit identifiers, with 16-bit values.

RISC OS systems had "VDU variables" which would be changed by various commands, and could be read back to find the current VDU state

Our flags are essentially a form of "VDU variable", but right now they are only used for an incredibly limited set of feature switching, and are effectively, from a user-software point of view, currently write-only.

If our flags become read-write (see #263 ) then they become more like a true variable, and so we should consider more closely aligning our use of feature flags with how Acorn did VDU Variables. There are various other areas of VDP settings that could be useful to be able to expose, for instance #196.

[stevesims]

Documentation on RISC OS VDU Variables can be found here: https://www.riscosopen.org/wiki/documentation/show/VDU%20Variables

[stevesims]

RISC OS VDU Variables use an 8-bit identifier. We could, potentially, copy their setup, setting the high-byte to a fixed value

Most of the values that RISC OS exposes have equivalents within the VDP, often in the current graphics context, with the exception of those that are more hardware-specific.

In RISC OS, values are 32-bit words. None really need to be (except for variables that return an address, but those aren't relevant to us)

[stevesims]

the assertion that RISC OS variables use an 8-bit identifier is not quite right - there are variables numbered 256 and 257 which represent the width and height of "text window" in chars. there is a lot of space in the variable range, so these could easily be renumbered and placed elsewhere

[stevesims]

we can use the RISC OS VDU variables (including mode variables) as a guide to follow for exposing graphics system state via feature flags

as we are already using flag number 1 for the test flag for affine transform support, which would conflict with the RISC OS mode variable for "ScrRCol" (the number of text columns - 1), we cannot use identically numbered variables. the plan therefore is to have a consistent high byte for VDU variables within the flags block, which will likely be 0x02

RISC OS exposes as variables 4 and 5 the X and Y "Eigen factor", which is used to convert OS coordinates to/from pixel coordinates. owing to mistakes in how OS coordinates were built (see #65) we have ended up with floating-point conversion factors. as the eZ80 doesn't support floating point, we may need to express these values as fixed-point numbers. this may be best served using different variable numbers. these variables may, most likely, just be undefined. if/when we add support for a flag to indicate proper Eigen-factor scaling, and that flag is set, then these variables can return their proper results

another potential complication with the RISC OS variables is the mixing of OS coordinates (described as "external coordinates" in their documentation) and pixel coordinates ("internal coordinates" in their docs). for the most part, we store coordinates in the same formats within our contexts. the exception to this is the "origin" coordinates, which we store in pixel coordinates, whereas RISC OS variables expose them as OS coordinates. when the VDP is set to use pixel coordinates, we don't currently track OS coordinate values, so we would need to document this behaviour

[stevesims]

quick idea - expose audio system state via variables too, and so we could/should assign a block of the variable space for this purpose.

as we can have up to 32 channels active, assigning just a single 8-bit block of variables may be too small, as that only equates to 8 variables per channel. assigning a full 16-bit block may instead be more reasonable.

very rough thought - there may be opportunities to do interesting things here with exposing some details of envelopes