VDULarge 0.02 (17 Jun 2018)  nemo 2018
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*** THIS IS A PROOF OF CONCEPT, not the final product ***

Problem
~~~~~~~
VDU28 (text window) and VDU31 (text cursor position) take 8bit unsigned
coordinates; VDU24 (graphics window) and VDU29 (graphics origin) take 16bit
signed coordinates. Both are problematic when using large screens or
outputting to big sprites, as it limits text to two thousand pixels and
graphics to sixteen thousand pixels, typically.

Solution
~~~~~~~~
A new API is required that enables at least 16bit text coordinates (half
a million pixels) and at least 24bit graphics coordinates (four million
pixels, typically).

Proof of Concept
~~~~~~~~~~~~~~~~
This module implements four SWIs, called "VDU_24", "VDU_28" etc, that take
32bit signed parameters and pass them direct to the VDU code.

This seems to work with various versions of RISC OS, as of mid-2018. Feel
free to play with it to confirm it works with your version of the OS.

However, this is not a complete solution as there is no mechanism to allow
printer drivers to implement these calls. It also does not address the 16bit
limit on OS_Plot (it could have, but doesn't).

The main use for this module is to discover other coordinate limitations
within the VDU code, which has never had to deal with >16bit coordinates
before  lots of things work fine, but some don't. I haven't explored this
in any detail. (Although OS_Plot and VDU25 are limited to 16bit coordinates,
the graphics origin is not, so it is possible to plot at large coordinates)

A better solution for the future
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have another module (VDUExtend) that replaces OS_Plot with code that
removes its 16bit limit and allows negative 'plot' opcodes. The codes -24,
-28, -29 and -31 are used instead of the SWIs in VDULarge. It pays attention
to the size of the coordinates and, where possible, uses the existing VDUs.
Otherwise it uses new VDU23 sequences that feature 16bit text and 24bit
graphic coordinates (this could be extended to 32bit coordinates if necessary,
though that would be rather slow).

Printer drivers already trap WrchV, so they can support extended coordinates
without needing some new OS interface.

It also implements those new VDU sequences, passing the extended coordinates
to the existing VDU code. Note that this does not remove any internal VDU
limitations such as those in the flood-fill code.

I have not yet made VDUExtend multi-OS compatible, so VDULarge will have to
do for now.

Footnote
~~~~~~~~
VDU29 - graphics origin - is badly neglected in RISC OS, and should probably
be deprecated. Both VDU and the Draw module pay attention to the graphics
origin but SpriteOp doesn't, and FontManager is even worse - if a character
is cached, it will be plotted like a sprite, ignoring the origin, but if it's
too large to cache it is plotted using Draw... so does honour the origin. This
makes it rather hard to predict where FontManager is going to put text if the
origin is not at 0,0. As for other rendering modules... well, who knows.

Twitter: @nemo20000
email: nemo@20000.org