|
Display changes
The management of video within modern versions of RISC OS has changed significantly. Most graphics primitives may be accelerated by hardware and many operations have been changed slightly because of this. This document describes the changes in more detail and the changes which will be necessary to ensure that code continues to function within the new environment.
Memory management
With the advent of multiple display drivers the concept of a single 'screen memory' area is obsolete. This means that Dynamic Area 2, previously allocated to the screen memory, is no longer used. In order that clients which merely check this value do not fail the area is provided by the LegacyScreen module. The content of this area and its size have no relationship to the video system and are merely provided to ensure that applications which attempt to check video size by using this area do not fail immediately.
VDU variable 148 continues to provide the address of the screen as used by the VDU drivers, and variable 149 provides the address of the screen as used by the hardware. That is, the address pointed to by variable 148 is where data will be written, and the address pointed to by variable 149 is the currently visible data. VDU variable 150 contains the total size of the screen area as declared by the display driver. However this value cannot be relied on for selecting screen banks because of driver limitations.
Screen banks
Because memory management for video drivers may not be related to the total memory available to the video drivers - usually because of buffer alignment, or reserved memory - it is not sufficient to read the total size of the video memory and divide by the screen size to obtain the number of screen banks. New OS_ScreenMode reason codes have been created to ensure that these operations can be performed reliably within the constraints of the driver.
Because of driver configuration issues it is not guaranteed that any bank other than the display or driver bank will be mapped in to logical memory. Indeed, certain drivers may choose (at their discretion) to re-map logical memory in order to make banks available. Consequently, the arrangement of the logical addresses which correspond to screen banks may not match that of the previous versions of RISC OS. In particular banks may not follow on from one another in memory.
In order to inform the driver that screen banks are to be used the banks to be accessed should be selected (using OS_Byte 112 or 113). This will ensure that the driver assigns video memory to the bank and does not use the memory for its own purposes (caching, internal buffers, etc).
Shadowed modes
Shadowed modes are no longer supported by RISC OS. These modes are numbered 128-255 and would implicitly select the second bank of screen memory. With the advent of Arthur, these modes were of much less use. Attempting to select shadowed modes may result in undefined behaviour.
OS_Byte 114 (Write shadow/non-shadow state) now performs no action.
OS_Byte 117 (Read VDU status) will never return with bit 4 set.
The default bank for all modes (for OS_Byte 112 and 113) will always be bank 1.
Hardware acceleration
Hardware acceleration is provided by the display driver transparently from all user operations. Where hardware acceleration is not available software equivalent functions will be available. Direct screen access should be avoided where standard OS functions can be employed instead. In particular, video access may be significantly slower than normal memory. On certain hardware, the video memory may be marked as cacheable as was the case under RISC OS 4.
Screen mode limitations
In order to ensure that the system can be simplified and advance in a useful manner certain features have been dropped from screen modes. The shadowed mode selection has already been mentioned. In addition, modes which have different BPP and BPC values are no longer supported and will provide undefined behaviour. This means that modes 2, 4, 5, 10 are no longer available. These should not affect many applications as most should have been updated to be mode independent already.
Gap modes may be supported at the discretion of the video driver. This means that modes 3, 6, 7, 11 and 14 may not appear the same on different hardware.
Mode 23 was was defined in order to support monitors which were much higher resolution than the standard VGA monitors of the time. However, technology has made such systems obsolescent. In particular, this mode used 'double height characters'. These are may longer be supported and mode 23 may revert to being a standard 1 BPP mode with 8x8 pixel characters.
In addition, modes may be limited in the number of colours that may be displayed. Usually this affects modes with 16 or fewer colours as these are not supported by some modern graphics hardware.
Teletext mode
Teletext modes are no longer implemented as a 16 colour, low resolution mode. Any resolution and number of colours may now be used for a teletext mode, although obviously with less than 16 colours its usefulness will be limited. By default the resolution and colours selected by mode 7 is now equivalent to that of mode 28. Alternative teletext resolutions may be used, however. Consult the Teletext and OSScreenMode documents for details.
BBC style 6845 control
The BBC style 6845 video controller registers are now restricted to only two reason codes. VDU 23,0,10 (program cursor start) and VDU 23,0,11 (program cursor end) are the only operations supported by this VDU operation. In particular, this means that VDU 23,0,8 (set interlace) is no longer supported by RISC OS.
VDU 23,0,10,value|
This VDU sequence is used to program the cursor start position and its flash state. The value takes the form:
bits 0-4 = start line
bits 5-6 = flash state:
0 = always on
1 = always off
2 = fast flash
3 = slow flash
bit 7 = reserved, must be 0
VDU 23,0,11,value|
This VDU sequence is used to program the cursor end position. The value is the end line number.
Interlace
Whilst the 6845 control sequence for changing the interlace as an immediate operation is no longer supported, the interlace control for the next mode change through OS_Byte 144 (also through the legacy command *TV) remains supported. However, the driver may at its discretion ignore the value supplied by the user.
Text window scrolling
For compatibility with the BBC Master the VDU 23,7 operation allows horizontal scrolling to be performed within the text window in either character or byte steps. Horizontal text window scrolling is no longer supported in byte steps and all such scroll operations will only be performed for a single character.
OS_Word operations
Many OS_Word operations have been modified to be passed to external components (on WordV), rather than being handled directly by the Kernel. These should not be noticeable in general, but in particular OS_Word 22 (Write screen base) is no longer supported.
Poly-HLine operation
In order to take advantage of hardware acceleration where available, a new variable has been added to the VDU Variables to provide a callable function to plot a sequence of horizontal lines. The HLine function (VDU variable 166) provided a single horizontal line. Whilst this can be accelerated, it is usually more efficient for hardware to accumulate a number of these lines and issue a single 'Poly-HLine' operation. The PolyHLineAddr VDU Variable (193) provides this function pointer.
Service calls
The current display output may be changed by a call to OS_ScreenMode 11. Clients which track the registration of display devices may use a new service call (Service_DisplayStatus &DF) to track these changes. A service (Service_DisplayChanged &DE) will be issued to inform clients of the display driver change, as well as a 'switching output to sprite', if the current destination is the display.
VDU variable 192 (&C0) can be read to obtain the current display number.
Service_DisplayChanged (&DE)
On entry
R0 = 0 if display is in the process of being changed
1 if display has been changed fully
R1 = &DE (service number)
R2 = new display number
R3 = 0
On exit
R0, R1 preserved
This service is issued when the display is changed. It must not be claimed. The value in R0 indicates progress of the display change. This service is issued twice, once with R0 = 0, and then with R0 = 1. This separation is intended to allow components to update specific values, in particular the ScreenModes module must update its state on the first service call in order that the subsequent mode change is successful. R3 will be set to 0 to indicate that the mode has been reselected. Other values may indicate alternate behaviour in future.
Service_DisplayStatus (&DF)
On entry
R0 = reason :
0 = device deregistered
1 = device registered
R1 = &DF (service number)
R2 = display device number
R3 = display descriptor (for registration only)
On exit
R0-R3 preserved
This service is issued when the state of a display driver has changed. Although only two reason codes are used at present others may be added for related operations. The service is issued for deregistration and registration after the operation has been performed successfully.
VIDC Type 3 mode selectors
The VIDC type 3 mode selectors have been extended to allow additional facilities to be encoded within the control parameters. The full list of control parameters is :
1 LCD mode boolean
2 LCD dual-panel mode boolean
3 LCD offset register 0 0-255
4 LCD offset register 1 0-255
5 Hi-Res mode boolean
6 DAC control boolean (1 if unspecified)
7 RGB pedestal enables bit 0: R enabled
bit 1: G enabled
bit 2: B enabled
(%111 if unspecified)
8 External register bits 0-7 0-255
9 Reserved
10 Reserved
11 DPMS power saving bit 0: disable H sync
bit 1: disable V sync
(this is the standard DPMS mapping)
12 Vertical offset in scan lines -2047 - 2047
13 Interlace boolean
boolean values are 0 or 1 for disable or enable respectively. Values outside range for non-bitfields are undefined. Unspecified bitfields must be set to 0. Where not specified, all control items default to 0 when absent from the list.
Obsolete VDU variables
VDU variable 172 (VIDCClockSpeed) no longer has any meaning under RISC OS.
Circle limitations
The OS_Plot codes for circle fill, circle outline, arc, segment and sector have never supported the more esoteric modes which may be selected by RISC OS. Specifically, these operations do not perform as desired when highly rectangular pixel modes are selected. That is, modes where the eigen factors for X and Y differ by more than 1. Modes where the eigen factors are identical are square pixel modes and rendering of circles will be performed correctly. Modes where the eigen factors differ by 1 are rectangular pixel modes and rendering will be performed correctly. Modes where the factors differ by more than 1 are highly rectangular (for example EX0 EY2 would indicate a ratio of 1:4) and circles will not be plotted correctly.
This is not a change to the previous behaviour but was not previously documented.
OS_Plot 'move' modifier
Where possible the OS_Plot move modifier has been updated to be shortcut such that the 'no-operation' does not occur. In particular the fill line left and right operations will continue to perform driver memory access as this operation has side effects. It is not expected that this change will give a performance increase, as most operations will be performed as a simple move operation (OS_Plot 4) which was already optimised to avoid such memory access.
Acceleration of graphics primitives
In addition to the new operations already documented, many of the existing graphics primitives are candidates for acceleration through a new interface. All the primitives are provided with software implementations to ensure that a fallback operation is provided where acceleration is not present, and when acceleration is inappropriate (for example, when redirected to sprite).
The following operations are available for acceleration :
- Text character plotting
- Text cursor plotting
- Text region clearing (including CLS)
- Rectangle fill
- Triangle fill
- Parallelogram fill
- Block copy
- Circle outline
- Circle fill
- Circle arc
- Circle segment
- Circle sector
- Ellipse outline
- Ellipse fill
- Fill to condition, right
- Fill to condition, left and right
- Flood fill
- Multiple horizontal line (PolyHLine)
- Full screen scroll (as a hardware scroll operation)
- Screen bank copying
Additional primitive operations may be accelerated in future. Accelerated drivers may provide additional acceleration through the defined interfaces which RISC OS already provides.
Display selection
The display device in use can be selected using SWI OS_ScreenMode 11 (select display). The user interface for this is found on the DisplayManager menu. The display device to use can be configured with *Configure DisplayNumber, or through the BootMenu. During system startup the display device can be forced to the native device (display 0) by holding down the '0' key (see ResetTypes document). The VideoGuard module provides protection against being stuck in an invalid display.
|
![[Select]](../imgs/seldoc.png)
