Graphics on the ARM
Roger Amos

Appendix 3 - Colour in RISC OS

Despite the very attractive graphics that can be produced on the ARM machines, examples of which appear in the colour plate section, RISC OS is in fact quite limited in its colour capabilities. The VIDC which handles output to the screen can only handle 12-bit colour. That is to say, it recognises 16 levels (defined by 4 bits) of each of the primary colours red, green and blue, giving a total of 16 x 16 x 16 = 4096 possible different colours. But no conventional screen mode allows as many as 4096 colours on screen simultaneously. So colour, so far as the monitor display is concerned, is yet another matter of compromise.

The screen modes provided in RISC OS offer a maximum of 2, 4, 16 or 256 simultaneous on screen colours. And there is a fundamental difference between the 256-colour modes and those offering fewer colours. In modes having less than 256 colours you can redefine the palette to include any selection from the 4096 available. In 256-colour modes, however, you have no such choice; you are restricted to a fixed set of 256 colours.

Note that output to a colour printer is not subject to the same restrictions. If the application stores its colour data in 24-bit format, as most vector graphics and DTP packages do, the full 24-bit colour data will be sent to the printer driver. If the printer is capable of handling 24-bit colour, your graphics will be printed in the full colour stored by the application: this is entirely independent of the monitor display. If your printer is more restricted, then. like the screen display, it will use the closest available approximation to the specified colour.

2-, 4- and 16-colour modes

In screen modes that offer 2. 4 or 16 different colours you may use the sliders in the system palette to adjust any of the current palette colours to any of the 4096 colours of which the system is capable.

However, the colours in the palette are not completely independent of each other. Colour 0 (white by default) is assumed to be the background colour and colour 7 (black by default) is assumed to be the current foreground colour. For the purposes of text anti-aliasing any adjustment to either colour 0 or colour 7 will automatically cause colours 1 to 6 to be set up as six intermediate shades between the new colours 0 and 7. So, if you wish to redefine colours 0 to 7 for your own purposes, adjust colours 0 and 7 first and then colours 1 to 6. Subsequent adjustment of colour 0 or colour 7 may upset your carefully formulated colours 1 to 6.

A 16-colour mode may sound restrictive, but with careful choice of colours and judicious use of dithering, it can produce very attractive graphics-indeed graphics which the casual observer would regard as using a much broader palette. ArtWorks includes a carefully contrived 'primary palette' which is supposed to reproduce in 16-colour modes the colours available from full colour ink-jet printers; it gives excellent results although a little deficient at the purple end of the spectrum.

Remember that 16-colour sprites take only half as much memory as 256-colour sprites and this can make a big difference to the size of sprite collections, such as sprite-based animations. To save precious memory further I have used 4-colour and even 2-colour sprites as part of the background in 16-colour animations. For example, if you need a brick wall as the background, you may well find that with care you can create a sufficiently realistic one using just four colours. Similarly pavements and roadways can often be represented using only two colours, probably two contrasting shades of grey, and skies can be created from cyan and white alone. When shown in conjunction with 16-colour sprites, the fact that part of the scene uses only two or four colours is not at all obvious. Note, however, that colour translation tables will be needed if you wish to display 2- or 4-colour sprites from user applications in 16- or 256-colour modes-see Appendix 2.

256-colour modes

In 256-colour modes you cannot redefine the colours in the palette; you are restricted to the 256 colours which RISC OS offers. If while in a 256-colour mode you drag the sliders on the 16-colour system palette, you will change the currently selected colour, usually at three points on each slider, but only to another of the 'legal' 256.

Although the 256 colours offered form a selection that may seem strange at first, there is a sound technical reason for its content. The selection is made up as follows. The colours are numbered 0 to 255, in binary 00000000 to 11111111. Two bits are allocated to each of the primary colours red, green and blue, giving four levels of each and therefore 4 x 4 x 4 = 64 basic colours. Remember, however, that the operating system recognises 16 levels of each primary-the interval between these primary-colour levels is in fact equal to four operating system levels-the four steps are equivalent to 0, 26, 53 and 80% of full colour. They are quite coarse steps. These 64 basic colours are indeed the same 64 colours that are obtained using basic's COLOUR statement in 256-colour modes.

This leaves us with 2 spare bits and these are used to add 0%, 6%, 13% or 20% of white, i.e. of red plus green plus blue, to the base colour. These fine shades are steps at the operating system level of 16 steps per colour. And they correspond to basic's TINT keyword. So white in a 256 colour mode consists of 2 bits each of red, blue and green giving 80%, plus 2 bits of white which add 20% to each of the primaries giving 100%, or pure white.

This selection does have the advantage that it encompasses the full range of values of each of the primary colours. So, by dithering it ought to be possible to simulate almost any colour. It also has the advantage that an equal number of bits are available for each primary; this helps to maintain hue consistency.


Dither patterns are patterns in which two or more colours alternate in order to simulate a third colour that is not available in the palette. There are two soils of dither pattern: dispersed dot dither and clustered dot dither.

In dispersed dot dithers the dots are pixel-sized and colour density is controlled by the concentration of the dots. These are used primarily on screen, e.g. by RISC OS 3 in Draw and many other applications. RISC OS 5s dispersed dot dithers are based on a four-pixel matrix. For a dither involving two colours-let's call them dark and light-this allows three intermediate shades: 25% dark + 75% light, 50% dark + 50% light and 75% dark + 25% light. RISC OS 3 also supports a dither pattern using three colours within the matrix of four pixels. Dither patterns of this sort work best when the colours used are similar. Using the small square pixels of modes 18-21 or 25-28, dither patterns are often unobtrusive and could be mistaken for solid colours.

Clustered dot dithers in contrast use much larger dots and at a fixed pitch; the strength of the colour is varied by changing the size of the dots each of which is made up of several pixels, e.g. 36 (6 x 6). They are generally unsuitable for use on screen as the dots would be too obtrusive, but are ideal for use with printers working at 300 dpi or higher resolutions. They are often used by scanner driver software to render intermediate tones encountered in photographs.

24-bit colour

Professional image processing equipment and software uses 24-bit colour, i.e. the colours are represented by 8 bits of red, 8 bits of green and 8 bits of blue giving a total of 16,777,216 colours. In fact Draw and most other vector graphics/ object-based software for the ARM machines stores its colour information in 24-bit format and so is compatible with 24-bit hardware. It is only the hardware in current Acorn computers that is not capable of displaying 24-bit colour on the screen and therefore replaces shades that are unavailable by the nearest shade (or dither pattern) that is available. It is widely believed that future Acorn computers will handle 24-bit colour on screen. A 640 x 480 pixel screen mode in 24-bit colour would require 900 Kbytes of screen memory.

previousmain indexnext

© 3QD Developments Ltd & Roger Amos 2015