VDU things
© nemo 2018-2024
Here are various things that change the RISC OS VDU
VDUMode
The current version is 0.07 (17 Jan 2024) [32bit]
Forget MODE numbers – change to any size display with a single VDU sequence. For RaspberryPi, RPCEmu and VirtualRPC users this means any size mode can be selected thanks to the included AnyMode modules.
Change colour depth without changing dimension
Change Eigenfactors without changing anything else
NEW FOR RISC OS: Select double-height text characters in any colour depth!
Syntax
VDU23;22,flags,x;y;depth;
flags: b0 double-height text characters
b1 reserved
b2 fully programmable palette
b3 reserved
b4-5 XEigenFactor EOR 1 (ie 0 means XEig=1, the default)
b6-7 YEigenFactor EOR 1
x: pixels horizontally, or 0 to keep current width
y: lines vertically, or 0 to keep current height
depth: as SpriteType, or 0 to keep current depth
1 = 1bpp (2)
2 = 2bpp (4)
3 = 4bpp (16)
4 = 8bpp (256)
5 = 16bpp (32K)
6 = 32bpp (16M)
So you can change to a 16-colour version of the current mode with VDU23;22;0;0;3; or switch on double-height text characters with VDU23;22,1;0;0;0; and so on. Unlike Mode Selectors, VDU23;22 is captured by *Spool, can be included in files to *Print, and can be included in strings output through OS_WriteN. As such, it ought to have been introduced in 1994 when Mode Selectors were. Sorry about being 30 years late, all.
OSWrites
The current version is 0.01 (18 Jun 2024) [32bit]
Four new Kernel SWIs
Welcome our new best friends, OS_Write16, OS_Write32, OS_WriteAlpha and OS_WriteCtrl, joining the incumbent OS_ASCII as the newest official Kernel SWIs (that aren’t in the Kernel... at the moment).
This module implements the four new official OS SWIs – including their names via OS_SWINumberTo/FromString (looking at you, CallASWI). The included ReadMe documents them, plus an International Service Call you should be aware of. It also discusses the WrchV and OS_WriteC APIs, and describes best practice for WrchV claimants, all of which have been a source of great confusion.
The most important fact: Despite PRM descriptions, the meaning of R0 on entry to those APIs is defined by the current Alphabet. When the Alphabet is not 8bit, OS_WriteC and WrchV are not 8bit either. Consider the implications for your code carefully, as Alphabet is a user choice. "UTF16" and Unicode Alphabets exist, and other 'wide' character sets could conceivably be defined (though this is less likely since Unicode's ubiquity).
OS_Write16 (&AC)
=> R0 = null-terminated string of 16bit codepoints
<= R0 = after terminator
PSR preserved
R0 is aligned down and halfwords are extracted and passed to WrchV up to the terminating null (which is a 16bit zero).
OS_Write32 (&AD)
=> R0 = null-terminated string of 32bit codepoints
<= R0 = after terminator
PSR preserved
R0 is aligned down and halfwords are extracted and passed to WrchV up to the terminating null (which is a 32bit zero).
OS_WriteAlpha (&AE)
=> R0 = null-terminated string of codepoints whose width
is defined by the current Alphabet
<= R0 = after terminator
PSR preserved
R0 is aligned according to the codepoint size returned from Service International,&14C, and it then proceeds as OS_Write0, OS_Write16 or OS_Write32 as appropriate.
OS_WriteCtrl (&AF)
=> R0 = ctrl-terminated string of byte codepoints
<= R0 = after terminator
PSR preserved
For the purposes of this call, 127 is also considered a terminator.
Yes, these are officially allocated Kernel SWIs, before your very eyes. You should install ArthurASCII too, playmates. If you’re wondering where SWI &AB is, OS_Debug is an ancient SWI we shall speak no more of.
I thank yew.
ArthurASCII
The current version is 0.04 (18 Jun 2024) [32bit]
Fashionably late
Despite the BBC Micro having both OSWRCH and OSASCI, only the former was carried over into Arthur as OS_WriteC. Where’s OS_ASCII? 36 years late, it’s finally here.
OS_ASCII (&AA)
=> R0 = character code
<= PSR flags preserved
This does exactly the same as OS_WriteC, except for character code 13, when it does the same as OS_NewLine. This is surprisingly useful and I’ve lost count of how many times I’ve cursed its absence.
You’d think it’d be easy to implement... it is. But it’s not so easy to add an OS SWI with name support outside the Kernel, and hence 95% of this module is admin.
It also features a more complete understanding of the contents of R0 than any other “WRCH” code in RISC OS, but I’ll leave those gory details for the ReadMe.
Thanks to Stewart Brookes & Tom Seddon.
VDUTint32
The current version is 0.01 (01 Jan 2023) [32bit]
This is a silly little module to demonstrate how Basic’s TINT keyword is actually extensible.
Run the module and then type:
TINT32,1:PRINT"This is very silly!":TINT32,0
You know you want to.
VDUColour
The current version is 0.02 (11 Jun 2022) [32bit]
It should always have worked like this.
This module adds new control codes to allow 24bit colour to be specified through VDU, OS_WriteC etc.
VDU19,action,20-23,R,G,B
20 Text foreground (action ignored)
21 Text background (action ignored)
22 Graphics foreground
23 Graphics background
action is the usual GCOL plot action:
b0-2 Logical operation (ROP)
b3 Background is transparent
b4-7 0 (reserved)
That’s it. These sequences are captured by *Spool, can be embedded in text blocks or PLOT sequences, and included in Basic strings, and work in any mode from 2 colours to CMYK (if you have such an OS).
VDUVars160
The current version is 0.05 (24 Dec 2023) [32bit]
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,[11] 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.
VDUSwapColours
The current version is 0.02 (07 Aug 2024) [32bit]
Previously called VDU23_17_5X which was a terrible name.
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.
VDU23,17,5,flags,0,0,0,0,0,0
Where flags is defined to be:
b0 swap the text colours } if both clear, swap
b1 swap the graphics colours } the text colours
b2-b7 reserved
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.
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?!
BTW: in Basic you can use TINT5,flags tee hee.
VDUROP2
The current version is 0.01 (31 Mar 2020) [32bit]
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.
VDULarge
The current version is 0.03 (11 Aug 2019) [32bit]
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.