Future-proofing the VDU drivers

As my port of the RISC OS VDU drivers (into C) progresses, one thing stands out…

When using VDU calls to plot things, many of the VDU calls use ‘limited size’ values for critical variables. The two best examples are:

Set a text window : a byte is used for the column / row positions. This limits the width / height of a text window to 255 × 8 = 2048 pixel wide screen modes;

Set a graphics window (or plot some graphics to the screen) – two (usually signed) bytes are used, giving a range of -32768 to 32768. Once eigenvalues of ‘1’ are used, this becomes -16384 to 16384 approx. Overall, we are limited to a maximum resolution of approx 16383×16383 before things begin to break down. With 4k and 8k displays becoming a thing, we are not that far from coming up against this (it gets worse because the VDU drivers also plot ‘offscreen’ (so you can draw a line that starts and ends outside the graphics window) – that would be the first functionality to ‘break’ as display resolutions increase.

On a more positive note, the VDU drivers, internally, use 32-bit variables for the most part (including for text and graphics windows etc), so the issue really is just ‘how to send larger values to the VDU drivers without breaking backward compatibility’.

OS_WriteC and OS_WriteI are used a lot to send data to the drivers at present. OS_Plot is a good thing when used for the graphics drivers though :)

I don’t know the answer to this, but it is something to think about – as the drivers themselves can handle larger screen sizes with few modifications, but the interface to the drivers (single or double bytes) limits the screen sizes available.

Unless I’m mistaken, OS_Plot sometimes just posts VDU codes.

I think we can assume that legacy software using VDU codes would have their minds blown by wall-sized 2000 pixel per inch display with billions of colours. They’d be happier being told they are working with a much less capable display. Give them a sandbox to play in and they will be happy.

If you’re writing a Wimp program, you don’t use VDU 4 plotting, do you?

OS_Plot does send VDU codes, but a benefit is that the ‘clamping to 16 bits’ happens internally; the user submit signed 32-bit numbers, so no major API change would be needed there

RE: VDU / sandboxing – true – although, currently (RISC OS 32), the drivers are used by the Wimp for pretty much everything – line drawing, sprite backgrounds, moving rectangles, setting display mode etc. Also, the VDU drivers are quite ‘advanced’ compared to many other platforms’ ‘basic display output’ functionality (Linux terminal etc).

In my rewrite, I am making sure that 32-bit signed values are passed throughout, so it really only is the passing of data to the drivers that is an issue – even OS_ReadVduVariables will return 32-bit values for window widths etc;

I will think about this more; even if RISC OS moves to compositing, it will still need to draw stuff to those composited windows, and the VDU drivers can handle huge displays internally, and it would be trivial to add 64-bit colour support, for example, if that became a thing!

In a way, this may overlap to some degree with the Unicode problem; if the solution there was to use ‘more than 8 bits to encode a character’, then a way to send >8bits at a time to (whatever is processing strings) will be needed. Desktop-wide Unicode support may well solve the issue (especially as you can switch off outline fonts for the desktop!).

“Unless I’m mistaken, OS_Plot sometimes just posts VDU codes.”

Am working on this bit of code again; and the specifics are:

The routine is SWIPlot, in Kernel.s.vdu.vduswis;

It has a direct entry into the ‘main code’ (BL EntryFromSWIPlot). However, it only gets there if
(OSByte vars WrchDest and SpoolFileH are zero)
(OSByte variable ‘VDUqueueitems’ is ‘not in queueing mode’)
VduDisabled is (not set)
ModeFlag_NonGraphic is (not set)

If it manages to get through all of that, then it sign-extends the X and Y values, and takes the ‘EntryFromSwiPlot’ path;

So, to fully future-proof OS_Plot would require some work. What is good is the sign extension – it uses 32 bit values throughout, so it really only is the interface layer that needs upgrading in the future :)

Until there’s a backwards-compatible PlotV, OS_Plot must pass through WrchV.

Currently all coordinates go via VDU25,lx,hx,ly,hy where hx and hy are technically 24b unextended values – so WrchV claimants can see the whole 32b value but JVec claimants would only get the whole of hy and the rest truncated to bytes in the VDU queue.

It is possible to get an initial X,Y plot coordinate to any 32b value via relative plots and use of the graphics Origin, but that won’t help with subsequent plots for operations such as Triangle and Ellipse.

My VDUExtend module provides wider coordinates:

24b coords go via VDU23,0,25,op,lx,mx,hx,ly,my,hy where hx and hy are signed and op is the Plot operation. The similar VDU23,0,24 is used for graphics origin and (in pairs) for graphics windows.

32b coords go via pairs of VDU23,0,30,type,0,op,h,u,m,l where type selects Plot, Origin and Window operations and op applies to Plot. &HhUuMmLl is the coordinate.

I also have a module that turns OS_Plots into Draw_Fill calls which effectively have ~24b coords (in OS units). This has the advantage of working with all existing Printer Drivers (which the new VDU sequences don’t, until implemented).

Why VDU 23,0 ? That’s semantically controlling how the display is displayed, not writing stuff to the display. There’s quite a few “action” VDU 23s available: VDU 23,19/20/21, VDU 23,17,n where n>7, VDU 23,27,n where n>1, VDU 23,1,n where n>3. See link.

Extensions to VDU 23,0 to control the display are recommended to be &80 upwards, for instance the Argon uses &A0+n.

There’s essentially the following available:
VDU &0117;n,m,nn1;nn2;nn3; n>7 eg &80+x
VDU &1117;n,m,nn1;nn2;nn3; n>7 eg &80+x
VDU &1317;nn0;nn1;nn2;nn3;
VDU &1417;nn0;nn1;nn2;nn3;
VDU &1517;nn0;nn1;nn2;nn3;
VDU &1B17;n,m,nn1;nn2;nn3; n>7 eg &80+x

We’re getting a bit close to the end of VDU23.

VDU23,0,a is (in RISC OS) a compatibility feature which only implements a=8,10 and 11 (though 9 does something stupid before RO6), and reserves only 0-11 and its echoes with any of b5-7 set.

All the rest are usable and I’ve been using them extensively – mainly to avoid standing on anyone else’s toes:

18: Cursor width (also BBfW)
22: Mode change
23: Tab stops
24: Extended graphics ops
25: Extended PLOT ops
26: Unicode/Locale etc
31: Extended text ops
111: Unicode UDGs
112: Panel mode

But all those are writing to the display, VDU 23,0 is semantically how the display is displayed.

all those are writing

No, but irrelevant.

VDU23,0,18 was first coined by RTR in BBC Basic for Windows, decades ago.

As for the display hardware (the “how”), VDU23,0,r was only defined to write to the Beeb’s 6845 registers (eg NAUG 13.1.1) for r[0:4]<18 (eg AUG 18.2) – in RISC OS it has been a highly limited compatibility feature which has always called UKVDU23V for r[0:4]>11.

VDU23 is a multibyte sequence and we can’t invent new ones (although WrchV/VDUQueueDepth enable other lengths, software will explode) and VDU23,n is crowded – beyond the traditional RISC OS definitions RO5 added VDU23,18, BBfW added VDU23,22 and VDU23,23 and I’ve coined a couple (where I’ve had no choice because of parameter length), leaving only seven for users and future use.

I am not comfortable with only having seven left.

VDU23,0,r however has not been much exploited, and though r[0:4]<18 were defined on the Beeb, 12-17 have always been passed to UKVDU23V in RISC OS, as have r[0:4]>17 (note that although r[0:4]<8 have not been simulated, and r[0:4]=9 does the wrong thing in all OSes except RO6, those ops and their reflections are not passed on via UKVDU23V).

Also note that for all r[0:4]>17 the full value of r is used – only the Kernel simulation of the 6845 regs 8, 10 and 11 implement the limited bit comparison. Hence the NOPs 0-7 also mask 32-39, 64-71 etc, as do the three simulated registers. All other r are passed to UKVDU23V in full.

I view VDU23,0,r as a safe way to extend the highly limited VDU23 space for all sequences where 7 parameter bytes are sufficient. This pragmatic necessity outranks nostalgia or ambitions of purity IMO.

[For the record, VDU23,1, VDU23,17, VDU23,18 and VDU23,27 are also subreasoned, so are also candidates for further expansion, subject to implementation details which may include strict vector claimant ordering]