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.

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.

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.

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.

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).

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.

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.

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.