Screen Mode Types (changes)

Showing changes from revision #2 to #3: Added | Removed | Changed

Programmer's Reference Manuals

» Screen Mode Types

Screen Mode Types

The VDU drivers support several different types of screen mode. Mostly these different mode types are supported in order to provide compatibility with the BBC Micro range of computers.

Standard modes

These are the most common type of screen mode, capable of displaying both text and graphics. The VDU text font is 8×8 pixels.

When using a Mode Selector Block, the kernel will calculate the values of any unspecified mode variables as if a standard mode was selected. This means that care needs to be taken when attempting to select/describe other mode types – see each type below for details.

Gap modes

These are identified by the “gap mode” mode flag being set (bit 2).

Although the VDU font size is unchanged, the character cell which the font is rendered in is now 25% taller, resulting in gaps between the text rows.

To select a gap mode via a mode selector block, you must specify the “gap mode” mode flag, and a suitable value for ScrBRow.

Double-height modes

These are identified by the “Double height VDU chars” mode flag being set (bit 5).

In these modes, 2x upscaling will be used for the VDU font / character cells. By default this will result in characters that are 8×16 pixels in size.

To select a double-height mode via a mode selector block, you must specify the “double height VDU chars” mode flag, and a suitable value for ScrBRow. Currently the kernel only supports 1bpp double-height modes – using other colour depths may result in malfunction.

Hi-res mono modes

These are identified by the “Hi-res mono” mode flag being set (bit 4).

This was a special mode type created for Archimedes machines. The OS would treat the mode as a 1bpp mode (with the only restriction being that the palette is restricted to black and white), but the hardware would be programmed as if it was a 4bpp mode, with the pixel clock and horizontal timing parameters all divided by four. For the mode to be displayed correctly, suitable hardware would have to be fitted to the VED0-VED3 pins on the VIDC chip (and the analogue RGB output ignored).

Although modern RISC OS versions still contain the definition for mode 23, attempting to select it (or any other “hi-res mono” mode) is unlikely to yield useful results.

Teletext

These are identified by the “Teletext” mode flag being set (bit 1).

Under RISC OS, teletext modes provide a software emulation of the text-only teletext mode that was supported by the BBC Micro. The VDU driver will disallow graphics operations (the “non-graphic” mode flag will be set), but in reality it’s still a bitmap graphics mode.

In order to recreate the teletext font, teletext modes use either an 8×10 (“gap mode” mode flag set) or 16×20 font (“gap mode” and “double vertical” mode flags set).

To select a teletext mode via a mode selector block, you must specify both the “teletext” and “gap mode” mode flags. However, note that this is only supported on OS versions where the T, TX and TY Mode String attributes are supported (RISC OS Select and RISC OS 5.23+); attempting to select a teletext mode via a mode selector block on other OS versions may fail with an error or cause a bad mode to be entered.

Unlike with other non-standard mode types, specifying the correct ScrRCol and ScrBRow values is optional – the kernel will automatically clamp the values to the allowed range.

BBC gap modes

These are identified by the “BBC gap mode” mode flag being set (bit 3).

On the BBC Micro, gap modes had no video memory allocated to the gap rows. This resulted in the gaps always appearing black, and the hardware text cursor appearing white for any areas where it overlaps the gap. The lack of video memory in the gaps also meant that the MOS VDU driver disabled graphics operations.

Under RISC OS, BBC gap modes are both “gap modes” and “non-graphic”. The gap effect is created by restricting the number of palette entries that are available for use by the VDU font: for modes 3 and 6 (the built-in BBC gap modes), Log2BPP will be 1 (suggesting a 2bpp mode), but NColour will be 1 (suggesting only two colours available). The VDU font will be restricted to colours 0 and 1, while colours 2 and 3 are used for the gap (and gap cursor).

To select a BBC gap mode via a mode selector block, you must specify the “BBC gap mode”, “gap mode”, and “non-graphic” mode flags. Suitable values for ScrBRow and NColour must also be specified. Currently the kernel only supports gap modes where Log2BPP=1 and NColour=1 – using other values may result in malfunction.

Double-pixel modes

These are identified by the value of the Log2BPC mode variable being one higher than Log2BPP.

In double-pixel modes, each logical screen pixel (as addressed by the VDU) is actually two physical screen pixels, in a 2×1 formation. This has the effect of making the VDU text font appear to the user as if it’s twice as wide as normal.

Double-pixel modes are still graphics modes, with the VDU graphics routines correctly translating logical pixels to pairs of physical pixels. However other software which writes to screen memory directly may not be aware of the special nature of double-pixel modes, resulting in “half-pixels” being written, or graphics appearing in the wrong position / aspect ratio.

The double-pixel nature of the mode is also reflected in the fact that XWindLimit will be half its usual value – e.g. if the VIDC list specifies a horizontal display with of 640 pixels, XWindLimit will be set to 319. Typically adjusted eigen values will also be used: a mode which is physically 640×480 would typically use eigen values of 1:1. But the double-pixel version of that mode (with 320×480 logical pixels) would use eigen values of 2:1.

To select a double-pixel mode via a mode selector block:

• Specify Log2BPC as being Log2BPP+1
• Specify XWindLimit of (XRes/2)-1
• Specify a suitable ScrRCol value (default ScrRCol is (XRes/8)-1)
• Potentially specify XEig as being higher than normal

Implementing special mode types as numbered modes

For numbered modes, the correct values of all mode variables must be provided either by your Mode Workspace List or by the base mode.

Describing special modes using mode strings

Apart from teletext modes, there is no direct way of describing special modes using mode strings (due to the inability to directly specify the mode flags or Log2BPC).

You can include a mode number at the start of the mode string, however it’s unclear whether any OS versions will correctly copy over the attributes of the base mode.

Relationship to Service_EnumerateScreenModes

The Service_EnumerateScreenModes Block only returns basic information about each mode: Its width and height, pixel format, and framerate. This information should be treated as describing the physical properties of the mode, i.e. as if a standard mode type were to be used.

If Service_EnumerateScreenModes listed a 2bpp 640×480 mode as being available, you would translate that definition to a mode selector block as follows:

• X resolution (XRes) = 640
• Y resolution (YRes) = 480
• Log2BPP = 1
• Frame rate = value from Service_EnumerateScreenModes, or -1

With no extra mode variables specified, this will select the standard version of the mode (i.e. 2bpp 640×480). To select other mode types, you must add the correct mode variable values onto the end of the block, as listed below:

Relationship to Service_ModeExtension

When a Service_ModeExtension implementation receives a mode selector block and searches its internal mode database for a suitable VIDC list, it must do so by only paying attention to the physical properties of the mode. I.e. it should determine the dimensions of the mode by looking at the XRes and YRes values, not by looking for any XWindLimit or YWindLimit mode variables (as these are used to indicate the logical dimensions).

To determine the pixel format, the code must look at the Log2BPP value from the block header, and any NColour and mode flags value provided in the mode variable pairs, being careful to ignore irrelevant mode flags (e.g. double height, non-graphic). See Valid Mode Variable Combinations for details.

Relationship to Service_ModeTranslation

For the best user experience, Service_ModeTranslation implementations should attempt to find a replacement mode which matches as many of the attributes of the original mode as possible, including the mode type. However it may be necessary to consider the intent of the choice, e.g. if mode 2 is requested (double-pixel mode with 160 logical pixels per row), it would be sensible to return a non-double pixel mode which has 160 physical pixels per row, if the display hardware can support it and it’s likely to result in the desired aspect ratio.

See also

• Mode Flags
• Mode Variable Numbers
• Mode Selector Block
• Mode String
• Screen Modes
• Valid Mode Variable Combinations