© nemo 2018-2021
Here are various things that change the RISC OS VDU
Only 34 years late, a full implementation of OS_Byte,160!
BYTE160 was the method for reading VDU Variables on the Beeb and Master, and like the whole of the rest of the OS this was carried over into Arthur... except for some reason only the first 16 Vars were implemented. There’s no good explanation for this beyond speculation about the rushed and in some cases unfinished state of Arthur. The stuff of legend.
Apart from a number of duplications that are better read using OS_ReadModeVariable or OS_ReadVduVariables, this omitted some Vars for which there was no other API, such as the VDU writing direction set by VDU23,16.
[In fact, from Arthur 0.3 to the most recent RO5 I’ve checked, the writing direction along with the rest of CursorFlags can be read using OS_Word,10, but that is an undocumented side-effect (til now!), whereas BYTE160,&66 was the documented API.]
The zip contains documentation of the additional 112 Vars (which, because some changed between the Beeb and the Master and I’m such a pedantic completist that I’ve implemented both, actually means 123) and a test program that displays the contents of all of them.
This module represents the consequences of striding confidently far beyond the Pareto Principle in search of Peak Pedantry.
Yes, that’s a terrible name for a module, but what would you call it?
This module extends the VDU23,17,5 sequence with a flags parameter. In addition to the default behaviour of swapping the text colours, this allows both the text and graphics colours to be swapped independently.
Where flags is defined to be:
If both b0 and b1 are clear, the default behaviour of swapping only the text colours applies. Otherwise you can choose what to swap.
The zip contains a little demo program and no other documentation.
This is a Beta – it has been shown to work in RO4 and RO5, and ought to work elsewhere too. But as ROOL are prone to changing things unnecessarily without announcement, never mind a significant version number change, all bets are off with that OS. (For example, the location of foreground and backgrounds ECFs 6 changed by 16 bytes between version 5.22 and 5.24, despite not having moved since their introduced in RO3.0 literally 30 years ago. I have long given up trying to get people to understand the ramifications of their fiddling. They simply don’t care. I come not to praise Acorn but to bury it.)
Also note that Printer Drivers don’t know about this sequence, so probably best not to use it when printing. Not that you’ll be using GCOL when printing anyway, are you? ARE YOU?!
This module adds the missing eight ROP2s to the standard PLOT actions.
b7 of the GCOL action number adds to bits 0-2 to enable all 16 ROPs to be selected.
The zip contains a little demo program, which also documents the action numbers and the mapping to Windows ROP2 names.
This module provides SWIs that allow VDU24 (graphics window) and VDU29 (graphics origin) to surpass the VDU’s 16bit limit, and for VDU28 (text window) and VDU31 (text cursor position) to surpass the 8bit limit.
This is not a full solution as it doesn’t address the 16bit OS_Plot limit directly (though it can be bypassed by altering the origin) and, more seriously, does not allow any mechanism for printer drivers to implement the API.
The full solution is called VDUExtend, and I’m working on it.