Teletext

Introduction

Acorn systems have, traditionally, always included a teletext mode. When RISC OS was introduced this was no longer provided by a hardware controller but was instead provided by a software implementation within the Kernel. This implementation has now been removed and is provided by a new module, 'VideoTTX'. This provides, through the same vectored interface as the other graphics abstractions, an independent implementation of the teletext mode.

With this abstraction it is now possible to provide a greater range of teletext-like modes and higher quality within those modes. The VideoTTX module provides a simple implementation of the teletext system. Other claimants of the vector may provide more advanced, or more efficient implementations.

Technical Details

Special characters

Within Teletext mode the following character sequences are interpreted specially, affecting all characters that follow them :

CodeMeaning
&80-&87Characters are text and are coloured according to the low nibble
&88Flash characters
&89Non-flash characters
&8A,&8BNot implemented
&8CDouble height
&8DNormal height
&8E,&8FNot implemented
&90-&97Characters are graphics and are coloured according to the low nibble
&98Concealed characters (cancelled by text colour change)
&99Graphics characters are solid
&9AGraphics characters are separated
&9CReset background colour to black
&9DSet background colour to current foreground colour
&9ESet graphics character hold mode
&9FClear graphics character hold mode

The colours within teletext mode are based on the primary and secondary colours created by the binary addition of the red (bit 0), green (bit 1) and blue (bit 2) components. The following colours are therefore available :

ValueColour
0Black
1Red
2Green
3Yellow
4Blue
5Magenta
6Cyan
7White

Double height characters are usually represented by the same character being present in both the upper and lower cells of the double height character. If the two characters are not the same, or the colours of those characters differ, the display will have undefined results. Graphics characters cannot be double height.

Differences in character set

The text character codes differ in their representation from the more commonly used ASCII character set. The following changes should be noted :

CodeDisplay
[is displayed as a left arrow (actually an arrow-head under the current implementation)
\is displayed as a 1/2 symbol
]is displayed as a right arrow (actually an arrow-head under the current implementation)
^is displayed as an up arrow (actually as a dagger under the current implementation)
_is displayed as a long hyphen
`is displayed as a pound (£)
{is displayed as a 1/4 symbol
|is displayed as a vertical equals symbol (actually as a single bar under the current implementation)
}is displayed as a 3/4 symbol
~is displayed as a division symbol
127is undefined (actually as a cross symbol under the current implementation)

Characters with bit 7 set are almost identical to those with bit 7 clear (with the exception of the codes above which will be treated specially). The following changes should be noted for the related characters with bit 7 set (differences from the above) :

CodeDisplay
#is displayed as a pound (£)
_is displayed as a hash (#)
`is displayed as a long hyphen

Graphics characters

Graphics characters are composed of parts of the character set. Each graphic symbol is a 2x3 grid, constructed from the bits of the characters :

+---+---+
| 0 | 1 |
+---+---+
| 2 | 3 |
+---+---+
| 4 | 6 |
+---+---+

Graphics character processing is only applied to codes in the range &20-&3F and &60-&7F. This means that the block of characters in the range &40-&5F, which includes the upper case text characters, are rendered as text. By default, graphics characters are non-separated and are rendered as solid, joining to the character beside them. After the 'separated graphics' have been selected, the cells of the character will be separated from the surrounding cells by the background colour of the character.

The control characters described above are usually rendered as if they contained a space character. In 'hold mode', however, the last graphic character rendered will be used in place of the control character.

Selecting a teletext mode

Only a single teletext mode is defined by default - mode 7. This provides the standard 40x25 character teletext mode as expected by most applications. However, specialist applications may select any mode they wish to use as a teletext mode through a mode specifier block with the mode flags set to 6 (gap mode and teletext). If a particular number of characters is required within the teletext mode these can also be passed within the mode specifier to as mode variables 1 (ScrLCol) and 2 (ScrBRow). If the number of characters specified cannot be met, the closest number which can will be selected. Whilst any colour depth is possible for teletext modes, it is not necessary to select more than 256 colours. Usually only 16 colours would be necessary, but the restrictions on most modern graphic hardware means that 16 colour modes are unsuitable. By default, mode 7 now uses 640x480 in 256 colours (under earlier versions of the operating system it used 320x250 in 16 colours).

The mode string parser used by OS components has been extended to allow teletext modes to be selected (although these are obviously not usable within the Desktop). The new TX and TY parameters can be used to change the number of characters in the display. The T parameter selects a teletext mode with a given number of colours. Consult the OS_ScreenMode changes document for more details.

Controlling the teletext mode

The features of teletext mode can be controlled by VDU commands. Only a limited feature set is currently controllable, although a number have been reserved for future expansion. VDU 23,18 is reserved for teletext control operations. The following operations are available, and are described in the VDU Codes section :

VDU VDU 23,18,1, VDU VDU 23,18,2 and VDU VDU 23,18,16 are described in the VDU Codes section below.

Limitations

The only limitation imposed by teletext mode is that RISC OS may no longer be configured to start in such modes. If MODE 7 is configured for startup the system will default to a suitable mode for the configured monitor type.

VDU Codes

VDU VDU 23,18,1
Set the display update flags
VDU VDU 23,18,1VDU 23,18,1,flags|
None

Sets the update flags for the display. Two bits are currently defined :

Bit(s)Meaning
0Suspend all automatic display update
1Update display after every character

It is expected that teletext modes will be slower than regular modes. These options allow the configuration of alternate display update methods. When both bits are cleared, the update of the display will happen periodically when the system is idle (that is, on a transient callback). This improves performance in general use but may be unsuitable for animations or for behaviour which expects to be outside transient callbacks for a significant period of time. Setting bit 1 will cause the display to update after every character is output. This has a significant performance impact, but ensures that output is immediately reflected on the display. Setting bit 0 will cause no updates to be issued for any character output. This can be used to ensure that display updates are instantaneous. Flashing teletext states will not be updated whilst the updates are suspended.

VDU VDU 23,18,2
Set the reveal state flags
VDU VDU 23,18,2VDU 23,18,2,flags|
None

Sets the reveal state flags for the display. Only a single bit is currently defined :

Bit(s)Meaning
0Reveal concealed text
VDU VDU 23,18,16
Set the display quality flags
VDU VDU 23,18,16VDU 23,18,16,flags|
None

Sets the display quality flags for the display. Only a single bit is currently defined :

Bit(s)Meaning
0Render high quality text
VDU VDU 23,0,8
Previously controlled the interlace modes
VDU VDU 23,0,8VDU 23,0,8,...
None

This will now be passed to the Unknown VDU23 vector. Previously this controlled the interlace modes for the current mode.

VDU VDU 23,0,9
Previously programmed the cursor end position
VDU VDU 23,0,9VDU 23,0,9,...
None

This is now passed on to the Unknown VDU23 vector. Previously it would erroneously attempt to program the end position of the cursor, when it should have been programming the scanlines per character (through the 6845 controller chip).

For reference, the VDU 23,0 codes implemented in the current version of RISC OS are:

CodeMeaning
10Set cursor start (VDU VDU 23,0,10): bits 0-4 are the start line; bits 5-6 select the blink state (00 = No blink (cursor on), 01 = No blink (cursor off), 10 = Fast flash, 11 = Slow flash)
11Set cursor end (VDU VDU 23,0,11)