RISC OS Open
A fast and easily customised operating system for ARM devices
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account

Extended Framebuffer Format Specification

category: Specification

Introduction

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

Mode variables

These should be all the necessary combinations of mode variables:

NColour ModeFlags Log2BPP Result Introduced
bit 7 bits 12-15
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 1 24bpp 8:8:8 BGR New
16777215 0 4 6 1 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 2 32-bit YCrYCb 4:2:2 New
420 0 2/6/10/14 7 2 48-bit CrCbYYYY 4:2:0 New

1 These aren’t really 2^6^ = 64 bpp. They can’t be addressed by a simple bitshift operation.

2 These aren’t really 2^7^ = 128 bpp. They can’t 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.

Sprite formats

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
  • s = shadow mode bit
  • m = BBC – RISC OS 3.1 mode number
  • p = pointer
  • w = wide mask flag
  • t = sprite type (only types 0-15 available in old 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 – –
  • f = duplicate of bits 8-15 of ModeFlags
  • x,y = compact resolution specifier:
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)
  • h,v = horizontal/vertical dpi: allowed values are 180, 90, 45, 23 and 22

As always, when creating sprites, you should always use the most backward-compatible representation 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.

Mode strings

These are used in *WimpMode. Note that BASIC’s MODE <string> merely calls *WimpMode. A new BASIC syntax, MODE OF <string> is proposed to set the mode without affecting the WimpMode – to facilitate this, implement OS_ScreenMode 15 (such that it is compatible with RISC OS Select).

The following new variants of the colour parameter are required:

  • “C4K” / “C4T”: 16bpp 4:4:4:4
  • “C64K” / “C64T”: 16bpp 5:6:5
  • “G16M”: 24bpp 8:8:8 packed – note C16M is already taken, and there’s precedent for a “G” prefix indicating an alternate version of a mode

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.

It is proposed that the available options be controlled by the new “L” parameter, and distinguished by listing the colour components in big-endian order, leading to the following possible parameters:

  • “LTBGR”: the default, unless not supported by the hardware
  • “LTRGB”
  • “LABGR”
  • “LARGB”

For example, to set up a TV output on an OMAP design, you could use:

*WimpMode> X720 Y576 C16M LTRGB

I can’t see any need to support CMYK or YCbCr formats for Wimp use.

BASIC parameterised MODE statement

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

It is difficult to elegantly extend this syntax, beyond perhaps adding 12 and 24bpp options.

Bearing in mind the new MODE OF <string> syntax proposed above, extension may not be required.

HAL/GraphicsV interface

When changing screen mode, the existing HAL/GraphicsV interface only specifies the Log2BPP of the target mode, as part of a VIDC List Type 3. Under this new system, the NColour value and the relevant ModeFlags bits will also need to be specified. For reasons of compatibility and simplicity, these items will be stored as control list items, using two new control list item IDs that are yet to be allocated.

For the NColour control list item, the NColour value can be stored as-is. For the ModeFlags control list item, only the bits specified in the above table should be stored, and at the right position in the word, i.e. bit 7 of ModeFlags in bit 7 of the control list item. By limiting the flags to just the ones important for the driver to know about, drivers can implement checks for unknown flags or invalid combinations and fail VetMode calls as appropriate.

Current status

Mode variables

The proposed changes have been adopted, see Valid Mode Variable Combinations. Most/all bits of OS code which deal with colours have been updated to add support for all the new RGB colourspace formats, which allows (for example) the desktop to be rendered correctly in all the new RGB modes.

Sprite formats

The kernel, SpriteExtend, and various other pieces of code have been updated to understand the new sprite mode word format, for RGB colourspace at least. See Sprite Mode Word. Support for rendering of and OS_SpriteOp-level manipulation of RISC OS Select alpha mask sprites has also been added.

Mode strings

Handling of mode strings has been extended as specified, see Mode String. New RISC OS Select compatible OS_ScreenMode reason codes have been implemented for easy conversion of mode strings to and from mode specifiers.

BASIC MODE

In BASIC 1.70:

  • MODE <string> has been changed to use OS_ScreenMode 15, since having it use *WimpMode was deemed to be sufficiently useless that it might as well be changed rather than introduce MODE OF <string>
  • A new variant of the parameterised mode statement, MODE <x>,<y>,<modeflags>,<ncolour>,<log2bpp>[,<hz>] has been introduced to allow the three key mode variables to be specified.

HAL/GraphicsV interface

VIDC control list items 15 and 16 have been allocated for indicating the NColour and ModeFlags values. The mode provider format used by Service_EnumerateScreenModes has also been extended to allow NColour, ModeFlags and Log2BPP to all be specified.

At the GraphicsV layer, GraphicsV 17 has been added to allow drivers to provide a full list of the pixel formats the support.

A corresponding call has not yet been added at the HAL layer; HAL video drivers are therefore still limited to RISC OS 3.5-era modes.

Printing system

PDriverDP and PDriverPS, which both intercept SpriteV amongst other vectors, have been updated to ensure the enhanced sprite format capabilities can be passed through the printing system. 12/15/16bpp are upsampled as appropriate in the existing printing framework so none of the backend dumpers needed changing.

Other

Handling of CMYK, CrCbY, and 24bpp packed RGB modes is missing or incomplete.

The display manager, screen setup plugin, and ScreenModes module have all been updated to support the enumeration and selection of the new modes.

Revised on July 18, 2018 08:57:16 by Sprow (202)? (109.176.200.50)
Edit | Back in time (12 revisions) | See changes | History | Views: Print | Source | Linked from: Individual specifications, OMAPVideo, Proposed GraphicsV enhancements

Search the Wiki

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Navigation

  • Home Page
  • All Pages
  • Recently Revised
  • Authors
  • Feeds
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Instiki theme is based on Insitki's default layout

Valid XHTML 1.0  |  Valid CSS

Instiki 0.19.1(MML+)
This site runs on Rails

Hosted by Arachsys