This document is a proposal on how to extend the VDU system and sprite formats to handle the most common framebuffer formats and uncompressed bitmap layouts in use today. It is hoped that this can be achieved in full compatibility with developments to the RISCOS Ltd fork of the OS. Settings are defined as orthogonally as possible, in order to simplify their implementation.
Where applicable, colour components are consistently described in a big-endian format – for example modes with a colour number format of &TTBBGGRR is described as “TBGR”.
These should be all the necessary combinations of mode variables:
NColour | ModeFlags | Log2BPP/ | Result | Introduced | |
bit 7 | bits 12-15 | Log2BPC | |||
1 | 0 | 0 | 0 | 1bpp paletted | Arthur |
3 | 0 | 0 | 1 | 2bpp paletted | Arthur |
15 | 0 | 0 | 2 | 4bpp paletted | Arthur |
63 | 0 | 0 | 3 | 8bpp semi-paletted | Arthur |
255 | 1 | 0 | 3 | 8bpp paletted | RISC OS 3.5 |
4095 | 0 | 0 | 4 | 16bpp 4:4:4:4 TBGR | New |
4095 | 0 | 4 | 4 | 16bpp 4:4:4:4 TRGB | New |
4095 | 0 | 8 | 4 | 16bpp 4:4:4:4 ABGR | New |
4095 | 0 | 12 | 4 | 16bpp 4:4:4:4 ARGB | New |
65535 | 0 | 0 | 4 | 16bpp 1:5:5:5 TBGR | RISC OS 3.5 |
65535 | 0 | 4 | 4 | 16bpp 1:5:5:5 TRGB | New |
65535 | 0 | 8 | 4 | 16bpp 1:5:5:5 ABGR | New |
65535 | 0 | 12 | 4 | 16bpp 1:5:5:5 ARGB | New |
65535 | 1 | 0 | 4 | 16bpp 5:6:5 BGR | RISC OS 6 |
65535 | 1 | 4 | 4 | 16bpp 5:6:5 RGB | New |
16777215 | 0 | 0 | 6 (*) | 24bpp 8:8:8 BGR | New |
16777215 | 0 | 4 | 6 (*) | 24bpp 8:8:8 RGB | New |
-1 | 0 | 0 | 5 | 32bpp 8:8:8:8 TBGR | RISC OS 3.5 |
-1 | 0 | 1 | 5 | 32bpp 8:8:8:8 KYMC | RISC OS Select |
-1 | 0 | 2 | 5 | 32bpp CrCbY 601 full | New |
-1 | 0 | 4 | 5 | 32bpp 8:8:8:8 TRGB | New |
-1 | 0 | 6 | 5 | 32bpp CrCbY 601 video | New |
-1 | 0 | 8 | 5 | 32bpp 8:8:8:8 ABGR | New |
-1 | 0 | 10 | 5 | 32bpp CrCbY 709 full | New |
-1 | 0 | 12 | 5 | 32bpp 8:8:8:8 ARGB | New |
-1 | 0 | 14 | 5 | 32bpp CrCbY 709 video | New |
422 | 0 | 2/6/10/14 | 7 (**) | 32-bit YCrYCb 4:2:2 | New |
420 | 0 | 2/6/10/14 | 7 (**) | 48-bit CrCbYYYY 4:2:0 | New |
(*) – These aren’t really 2^6^ = 64 bpp. They can’t be addressed by a simple bitshift operation.
(**) – These aren’t really 2^7^ = 128 bpp. They can be addressed on a pixel-by-pixel basis at all.
ModeFlags bits 12-15 are really now made up as follows:
Bits 12-13 | Family | Bit 14 | Bit 15 | Meaning | Example uses |
0 | RGB | 0 | 0 | TBGR | VIDC; OMAP with chroma-key and no TV out |
1 | 0 | TRGB | Iyonix DVI cards at 16bpp | ||
0 | 1 | ABGR | OMAP with video blending and no TV out | ||
1 | 1 | ARGB | OMAP with video blending and TV out | ||
1 | Misc | 0 | 0 | KYMC (CMYK little-endian) | Printer driver bitmap |
1 | 0 | reserved | |||
0 | 1 | reserved | |||
1 | 1 | reserved | |||
2 | YCbCr | 0 | 0 | ITU-R BT.601, full range | JPEG (JFIF) |
1 | 0 | ITU-R BT.601, video range | ITU-R BT.656; MPEG standard definition | ||
0 | 1 | ITU-R BT.709, full range | |||
1 | 1 | ITU-R BT.709, video range | MPEG high definition | ||
3 | reserved | 1 | 0 | reserved | |
1 | 0 | reserved | |||
0 | 1 | reserved | |||
1 | 1 | reserved |
When NColour 420 or 422 are in use, proposed ModeFlags bit 9 is used to describe the process used to perform horizontal chroma subsampling. Often, video plane hardware will only support one or the other of these.
Bit 9 | Meaning | Examples |
0 | 0th chroma samples colocated with 0th luma sample | ITU-R BT.656, MPEG-2, MPEG-4 |
1 | 0th chroma samples located between 0th and 1st luma samples | JPEG (JFIF), MPEG-1 |
Vertical chroma subsampling only applies to NColour=420. It is assumed to be always be such that the 0th chroma row is located between 0th and 1st luma rows. There are a cases where other possibilities arise, but these are probably rare enough not to worry about. Note that when converting to/from a 4:2:0 format, you also need to take into account the setting of ModeFlags bit 8 (the interlace bit).
The word at offset +12 of a mode selector block probably ought to be extended as follows:
Value | Result | Introduced |
0 | 1bpp | RISC OS 3.5 |
1 | 2bpp | RISC OS 3.5 |
2 | 4bpp | RISC OS 3.5 |
3 | 8bpp (defaults to semi-paletted) | RISC OS 3.5 |
4 | 16bpp (defaults to 1:5:5:5 TBGR) | RISC OS 3.5 |
5 | 32bpp (defaults to 8:8:8:8 TBGR) | RISC OS 3.5 |
6 | 24bpp (defaults to 8:8:8 BGR) | New |
All the other modes can be selected by overriding ModeFlags and NColours at the end of the mode selector block.
In sprites, all this extra flexibility has to be squeezed into the 32-bit sprite mode word. RISCOS Ltd have reassigned bit 31 of the sprite mode word to indicate the use of an 8-bit “greyscale alpha” mask rather than the traditional 1-bit “binary alpha” mask. This means that the sprite type field, for which we now have many more settings, has been squeezed down to 4 bits and is far too small for our requirements. We require an alternate definition of the sprite mode word, and for backwards compatibility, it needs to be distinguishable from the defined alternatives. This is proposed to work like this:
000000000000000000000000smmmmmmm -> mode number pppppppppppppppppppppppppppppp00 -> pointer to mode selector w1111ttttttt0000ffffffffyyxx0001 -> new style sprite mode word wttttvvvvvvvvvvvvvhhhhhhhhhhhhh1 -> RISC OS 3.5-style sprite mode word
t | Result | Implied ModeFlags 12-15 in old style sprite mode word | Introduced |
0 | reserved for identifying mode numbers | – | BBC micro |
1 | 1bpp paletted | – | RISC OS 3.5 |
2 | 2bpp paletted | – | RISC OS 3.5 |
3 | 4bpp paletted | – | RISC OS 3.5 |
4 | 8bpp, NColour/ModeFlags set according to size of sprite palette | – | RISC OS 3.5 |
5 | 16bpp 1:5:5:5 | 0 (TBGR) | RISC OS 3.5 |
6 | 32bpp 8:8:8:8 | 0 (TBGR) | RISC OS 3.5 |
7 | 1 (KYMC) | RISC OS Select | |
8 | 24bpp 8:8:8 | 0 (BGR) | New |
9 | JPEG data, allocated but not used | – | – |
10 | 16bpp 5:6:5 | 0 (BGR) | RISC OS 6 |
11-14 | reserved | – | – |
15 | reserved for identifying new style sprite mode words | – | New |
16 | 16bpp 4:4:4:4 | – | New |
17 | 4:2:2 | – | New |
18 | 4:2:0 | – | New |
19-127 | reserved | – | – |
x/y | Meaning |
0 | 180 dpi (like EX0/EY0 modes) |
1 | 90 dpi (like EX1/EY1 modes) |
2 | 45 dpi (like EX2/EY2 modes) |
3 | 22.5 dpi (like EX3/EY3 modes) |
As always, when creating sprites, you should always use the most backward-compatible respresentation possible. If your sprite can be expressed as a mode number then do so, else if a RISC OS 3.5 sprite mode word can be used then do so, and only if both of these fail should you use a new sprite mode word.
These are used in *WimpMode. Note that BASIC’s MODE <string>
merely calls *WimpMode.
The following new variants of the colour parameter are required:
The user may wish to select between different variants of 16, 24 or 32bpp modes. For example on OMAP-based designs, selecting alpha rather than transparency will enable blending with the video plane, or switching the red and blue components will enable use of the TV output. However, both of these come at the cost of application compatibility, which is why I think they should be a user option.
Since the “T” prefix has been used by RISCOS Ltd, I suggest the available options be distinguished by listing the colour components in little-endian order, leading to the following possible parameters:
For example, to set up a TV output on an OMAP design, you’d use:
*WimpMode</notextile> X720 Y576 C16M BGRT
I can’t see any need to support CMYK or YCbCr formats for Wimp use.
The multi-parameter MODE
statement in BASIC is a front to SWI OS_ScreenMode 0
, not to *WimpMode
. Since the majority of the time when you use MODE
you’re running a full-screen application rather than reconfiguring the desktop, this is the call you’ll want to use (unless you’re happy with a RISC OS 3.1-compatible mode number).
BASIC’s HELP
is famously terse. The <bpp>
parameter is currently interpreted as
bpp | Result |
1 | 1bpp |
2 | 2bpp |
4 | 4bpp |
6 | 8bpp, semi-paletted |
8 | 8bpp |
16 | 16bpp 1:5:5:5 TBGR |
32 | 32bpp 8:8:8:8 TBGR |
I’m not certain of the best way to extend this. Possibilities include
<bpp>
, but it’s a shame to have yet another arbitrary enumeration.<framerate>
, distinguished by it being top-bit-set, though this doesn’t have much precedence in BASIC syntax.MODE <width>,<height>,<bpp>[,<framerate>] [VDU <variable>=<value> [...]]
To be defined