The video system was traditionally been part of the RISC OS Kernel. However, this overly complicated the assembler portion of the Kernel, made new hardware harder to support, and meant that providing more flexible and faster rendering was significantly impeded. In RISC OS Select 3, the video system was moved out of the Kernel and became a set of regular modules.
There are a number of parts of the video system which were handled by the RISC OS Kernel, and which have been made available through a standard RISC OS vector. These parts are, from lowest level to highest level:
This separation makes the maintenance of the video system much easier, and allows runtime modifications to its behaviour. In additioon, the video system has been extended to allow for multiple displays by allowing a separate driver to take over the graphics system. Although in RISC OS Select this was a limited operation, allowing only a single active display at any time, the framework provided allows for greater flexibility in the future.
The graphics system has been split up in modern versions of RISC OS. The intention of the division of the system is to allow for accelerated graphics drivers. Graphics operations will be passed to drivers using the new VideoV vector (&2C). The operation to be performed is passed in a fixed register to the vector.
The reason codes for the vector are grouped into the major regions that they cover:
Text and graphics operations are provided by the VideoSW module on the VideoV vector. Should there be no accelerated handler earlier on the vector the VideoSW driver will provide the operation.
Text operations may be accelerated by the driver, or if no implementation is provided they will be provided by the VideoSW module. Drivers should pay attention to the current display start as set with VideoV 18 in order to know whether their display, or a sprite output has been selected.
Graphics operations may be accelerated by the driver, or if no implementation is provided they will be provided by the VideoSW module. Drivers should pay attention to the current display start as set with VideoV 18 in order to know whether their display, or a sprite output has been selected.
All coordinates passed to the functions have taken account of the eigen-factors for the output. They describe the pixels from the bottom left corner of the output. Many interfaces will require that these coordinates be inverted by subtracting them from the screen height to get the offset from the top of the screen. Coordinates are signed.
The graphic operations may use a special values in R6 to indicate the type of colour operation being performed. Whilst these may be a fixed 'OR-EOR' pattern (see VideoV 16 and VideoV 17 for more details), they may also take one of 4 special values. Clients may use these values as a short hand notation to remove the need to check on every graphic operation the whether the operation can be accelerated or not. The values are :
| Value | Meaning |
|---|---|
| 0 | No effect - the operation can just return |
| 1 | Use the last set Colour 1 |
| 2 | Use the last set Colour 2 |
| 3 | Invert destination |
Any value other than these special values is a pointer to an ECF. If either of bit 0 or 1 is set on these pointers it should be ignored by the driver. This allows for future expansion.
The graphics operations may use a block in R7 to determine the current graphics context. This contains a number of values which may vary between calls. Clients should check these against each operation.
| Offset | Contents |
|---|---|
| +0 | Graphics clipping window x-min (inclusive) |
| +4 | Graphics clipping window y-min (inclusive) |
| +8 | Graphics clipping window x-max (exclusive) |
| +12 | Graphics clipping window y-max (exclusive) |
| +16 | Function to call to render a bounded horizontal line |
| +20 | Function to call to render a unbounded horizontal line |
| +24 | Function to call to render a bounded point |
| +28 | Function to call to render a unbounded point |
The functions for bounded and unbounded point rendering have the same interface, but the bounded entry points should clip the rendering to the supplied clipping window.
Pointer operations are generated by the OSPointer module. The hardware driver should provide an implementation which does not affect the screen buffer (for example, by hardware overlay).
The mode operations are generally only handled by hardware drivers. Each driver will usually decide whether to handle the operation based on the display number. The only exception to this is the display selection entry point which must be handled by all clients in order to determine whether the display is selected.
Teletext operations are provided as a software supported device driver. Once a teletext mode has been selected, the teletext operations will be passed through the vector in place of the standard text operations. A few of the operations have been modified in order to provide more specialised operations in the teletext modes. Only a single teletext mode is ever in use at any time. Sprite redirection does not allow for teletext within sprite images.
Display devices should register themselves with the Operating System using OS_ScreenMode 255, and deregister when they have been terminated with OS_ScreenMode 254.
The order of operations for a display driver on initialisation should be along the lines of:
During finalisation it is important that the device shut itself down safely. The following sequence is recommended:
During the reset sequence, Service_PreReset will be issued. As with other hardware drivers, the hardware should be placed into a quiescent state, and interrupts disabled where necessary. The driver should place itself in a state similar to that of finalisation, except that the VideoV vector may be called and operations on the display buffer may still be performed by other components. Hardware may not have any reset lines asserted or similar within the system and it must be possible for the initialisation sequence to successfully start the hardware from the state which Service_PreReset placed it.
Details of OS_ScreenMode 255, 254 and the display device descriptor can be found in the OSScreenMode documentation.
| R0-7 | = | Dependant on reason code |
The vector should be claimed when it is handled entirely within the driver.
| R0 | = | pointer to the base of the destination (DisplayStart) |
| R1 | = | line length for this destination (LineLength) |
| R2 | = | maximum height in text lines (ScrBRow) |
| R3 | = | destination log2bpp depth (Log2BPP) |
| R4 | = | mode flags for destination (ModeFlags) |
| R8 | = | 0 (reason code) |
| R0-3 | corrupted | |
This vector is called a new destination has been selected for output. In particular, it will be called on mode change and sprite redirection. Clients should initialise any variables which are necessary for their operation. Clients wishing to handle the entire Text interface may claim this call point, but it is strongly recommended that the call be passed on.
The mode flags will indicate any special features which are present in the mode specified. In particular:
| Bit(s) | Meaning | |
|---|---|---|
| 2 |
'Gap mode', indicating that characters will be spaced 9 rows apart, rather than 8 - leaving a single line which will not be written to. This flag is deprecated and support is not required of any clients. | |
| 3 | 'BBC gap mode', should be treated as identical to Bit 2. This flag is deprecated and support is not required of any clients. | |
| 5 | Double height-VDU characters, indicating that characters should be written 16 units high, rather than 8 This flag is deprecated and support is not required of any clients. | |
This vector should never be claimed.
| R0 | = | the character to define (32-255) |
| R0 | = | pointer to word aligned 8 bytes to use as the character |
| R8 | = | 1 (reason code) |
| R0-3 | corrupted | |
This vector is called to define a character. Clients should normally make a note of the changes and pass this call on.
| R0 | = | foreground screen colour |
| R1 | = | background screen colour |
| R2 | = | BPP of the current mode |
| R8 | = | 2 (reason code) |
| R0-3 | corrupted | |
This vector is called whenever the text colour has been changed and text output is about to be performed. It is expected that clients initialise any cached data they require in order to render characters in the new colours. The colours supplied are values to be written to the screen for that pixel, for example, in 2 BPP modes, a foreground colour of 3 would be used to indicate that all pixels set for that character would use the value 3 in memory. Clients may need to replicate these bits across a word in order to perform operations more rapidly, however implementation details are left to the client's discretion.
| R0 | = | character to write (32-255) |
| R1 | = | pointer to address of top left pixel to write (word aligned) on the screen |
| R2 | = | character x (origin top left) |
| R3 | = | character y (origin top left) |
| R8 | = | 3 (reason code) |
| R0-8 | corrupted | |
This vector is called to render a character on the screen at a text position. Characters are 8x8 pixels in all modes and should be rendered in the colours specified by VideoV 2. Unset pixel data for the character should use the background colour, and set pixel data for the character should use the foreground colour. Registers R2 and R3 are provided for clients which require the actual pixel position to render the character.
| R0 | = | composite cursor position (&SS0000EE) |
| R1 | = | pointer to address of top left pixel for the character (word aligned) on the screen |
| R2 | = | character x (origin top left) |
| R3 | = | character y (origin top left) |
| R4 | = | offset of start of the cursor, from R1 |
| R5 | = | offset of line after the end of the cursor, from R1 |
| R8 | = | 4 (reason code) |
| R0-8 | corrupted | |
This vector is called to render a 'cursor' at a text position. This should be an inverted rectangle which spans the lines of the character requested by R0, or R4 and R5. The composite cursor mask is provided for clients which use the pixel position of the character to render the shape. The cursor should be rendered at the character specified by inverting the current contents of that location. The vector will be called repeatedly in order to 'flash' the cursor. In 'split' editing mode, the vector will be called to render whichever cursor requires redrawing.
The composite cursor position indicates the start and end lines of the cursor by the SS and EE values. The EE value is the last line that should be drawn. Thus, SS=6, EE=7 would invert lines 6 and 7 within the character. Similarly, SS=8, EE=9 would invert lines 8 and 9 within the character. Line 8 and 9 are only applicable to gap-modes.
| R0 | = | pointer to box description
| ||||||||||||||||||||||
| R8 | = | 5 (reason code) |
| R0-8 | corrupted | |
This vector is called to clear a region of the text window. The supplied description block gives the character positions, and the memory positions which require clearing. The clear operation should be performed using the fill words given in +36 and +40. These words will be the same unless the user is in a BBC-style gap mode. Such modes are not expected to be used by clients in the future and support may be omitted from accelerated modules. The software implementation provides support for all combinations.
As with other text operations, the character positions are specified with their origin at the top left.
| R0 | = | action type, for information purposes | ||||||||||||||||||||||||||||||||||
| R1 | = | pointer to OR-EOR pattern to use
| ||||||||||||||||||||||||||||||||||
| R8 | = | &10 (reason code) |
| R0-3 | corrupted | |
This vector is called to set the primary colours to use for plotting graphics operations. Clients should record the details. They may pre-cache the values after determining whether they can handle the operation type.
Lines are measured from the top left of the screen and should be ANDed with 7. Consult the example VideoSW code for more details (s/GrafPoint gives an obvious use).
Whilst many store and invert operations will be simple to accelerate within drivers, the more complex operations may be deferred to the software driver where necessary. In particular, drivers should be aware that the operation pattern may not correspond directly to any PLOT reason code. Users may manually select different colour operations for different bit regions or lines.
| R0 | = | action type, for information purposes |
| R1 | = | pointer to OR-EOR pattern to use, as for VideoV 16 |
| R8 | = | &11 (reason code) |
| R0-3 | corrupted | |
This vector is called to set the secondary colour used for graphics operations. This is commonly called the 'background colour'. The operation is identical to that of VideoV 16.
| R0 | = | pointer to context information
| ||||||||||||||||||||||||||||
| R1 | = | 0 if the destination is the screen, otherwise the destination is a sprite | ||||||||||||||||||||||||||||
| R8 | = | &12 (reason code) |
| R0-3 | corrupted | |
This vector is called whenever the output changes destination, usually due to a mode change or sprite redirection. Drivers should cache the context information for use within other calls. This vector should never be claimed.
| R0 | = | pointer to base of the buffer |
| R8 | = | &13 (reason code) |
| R0-3 | corrupted | |
This vector is called when the output destination base address has changed. It may be called under a number of circumstances, including sprite deletion, mask changes and hardware scrolling. Drivers should make a note of the new address and base all their calculations from it.
| R0 | = | pointer to where to store HLine handler (r12, function) |
| R1 | = | pointer to where to store Point handler (r12, function) |
| R2 | = | pointer to where to store VLine handler (r12, function) |
| R8 | = | &14 (reason code) |
| R0 | = | new pointer to where to store HLine details at |
| R1 | = | new pointer to where to store Point details at |
| R2 | = | new pointer to where to store VLine details at |
| R3 | corrupted | |
This vector is called to read the primitive operations which can be used to render a horizontal line, a point and a vertical line. Since these operations are expected to be called regularly it is important that they be fast. Rather than using the vector dispatch for every line or point to be rendered, a single function dispatch can be used - obviating the need for a SWI call, and subsequent vector dispatch. Consult the Graf_ReadPrimitives source for more details of the operation.
| R0 | = | pointer to coordinate block:
| ||||||||||
| R6 | = | Colour operation | ||||||||||
| R7 | = | pointer to Graphics context | ||||||||||
| R8 | = | &15 (reason code) |
| R0-3 | corrupted | |
This vector is called to fill a rectangle. Clients should bound the coordinates if necessary and then plot the rectangle.
| R0 | = | pointer to coordinate block:
| ||||||||||||||
| R6 | = | Colour operation | ||||||||||||||
| R7 | = | pointer to Graphics context | ||||||||||||||
| R8 | = | &16 (reason code) |
| R0-3 | corrupted | |
This vector is called to fill a triangle. Clients should plot the triangle, bounded by the coordinates given.
| R0 | = | pointer to coordinate block:
| ||||||||||||||
| R6 | = | Colour operation | ||||||||||||||
| R7 | = | pointer to Graphics context | ||||||||||||||
| R8 | = | &17 (reason code) |
| R0-3 | corrupted | |
This vector is called to fill a parallelogram. Clients should plot the parallelogram, bounded by the coordinates given. The coordinates given are in no particular order. The fourth verex can be calculated from the other three.
| R0 | = | pointer to coordinate block:
| ||||||||||||||||||
| R6 | = | Colour operation | ||||||||||||||||||
| R7 | = | pointer to Graphics context | ||||||||||||||||||
| R8 | = | &18 (reason code) |
| R0-3 | corrupted | |
This vector is called to copy a rectangle from part of the display elsewhere. No context or colour operation is provided. The region has already been bounded to the screen and graphics window (both the source and destination are guarenteed to be within the buffer). The source data, where not overwritten, should be unaffected by the copy operation.
| R0 | = | pointer to coordinate block:
| ||||||||||
| R6 | = | Colour operation | ||||||||||
| R7 | = | pointer to Graphics context | ||||||||||
| R8 | = | &19 (reason code) |
| R0-3 | corrupted | |
| R0 | = | pointer to coordinate block:
| ||||||||||
| R6 | = | Colour operation | ||||||||||
| R7 | = | pointer to Graphics context | ||||||||||
| R8 | = | &1A (reason code) |
| R0-3 | corrupted | |
This vector is called to fill a circle. Clients should plot the circle, bounded by the coordinates supplied if necessary.
| R0 | = | pointer to coordinate block:
| ||||||||||||||
| R6 | = | Colour operation | ||||||||||||||
| R7 | = | pointer to Graphics context | ||||||||||||||
| R8 | = | &1B (reason code) |
| R0-3 | corrupted | |
This vector is called to draw an arc. Clients should plot the arc, bounded by the coordinates supplied if necessary. The coordinate order and meaning is identical to that used by the PLOT arc operation. That is, first coordinate pair indicates the centre of the circle, the second pair provides the start position on the edge of the circle, and the final pair provides the end position as a point on a line that intersects the circle. The arc should be drawn anti-clockwise.
| R0 | = | pointer to coordinate block:
| ||||||||||||||
| R6 | = | Colour operation | ||||||||||||||
| R7 | = | pointer to Graphics context | ||||||||||||||
| R8 | = | &1C (reason code) |
| R0-3 | corrupted | |
This vector is called to draw a segment. Clients should plot the segment, bounded by the coordinates supplied if necessary. The coordinate order is the same as VideoV 27. A segment fills the arc shape, closing it with a line from the start position to the intersection of the end position line and the circle.
| R0 | = | pointer to coordinate block:
| ||||||||||||||
| R6 | = | Colour operation | ||||||||||||||
| R7 | = | pointer to Graphics context | ||||||||||||||
| R8 | = | &1D (reason code) |
| R0-3 | corrupted | |
This vector is called to draw a sector. Clients should plot the sector, bounded by the coordinates supplied if necessary. The coordinate order is the same as VideoV 27. A segment fills the arc shape, closing it with a pair of lines from the start position to the centre of the circle, and from the intersection of the end position line and the circle to the centre of the circle. The shape is often known as a 'pie' from the common shape produced by removing sections from pies.
| R0 | = | pointer to coordinate block:
| ||||||||||||||
| R6 | = | Colour operation | ||||||||||||||
| R7 | = | pointer to Graphics context | ||||||||||||||
| R8 | = | &1E (reason code) |
| R0-3 | corrupted | |
This vector is called to draw an ellipse. Clients should plot the ellipse, outline bounded by the coordinates supplied if necessary. The coordinate order is the same as the equivilent PLOT ellipse operation. That is, the first pair gives the centre position of the ellipse, the second pair gives the width of the ellipse at centre line (the y coordinate is ignored), and the final pair gives the position of the top-most, or bottom-most limit of the ellipse.
| R0 | = | pointer to coordinate block:
| ||||||||||||||
| R6 | = | Colour operation | ||||||||||||||
| R7 | = | pointer to Graphics context | ||||||||||||||
| R8 | = | &1F (reason code) |
| R0-3 | corrupted | |
This vector is called to draw an ellipse. Clients should plot the solid ellipse, bounded by the coordinates supplied if necessary. The coordinate order is as for the VideoV 30 operation.
| R0 | = | x start | ||||||
| R1 | = | y start | ||||||
| R2 | = | delimiting colour | ||||||
| R3 | = | delimiting condition:
| ||||||
| R6 | = | Colour operation | ||||||
| R7 | = | pointer to Graphics context | ||||||
| R8 | = | &20 (reason code) |
| R0 | corrupted | |
| R1 | = | right x position where fill ended |
| R2 | corrupted | |
| R3 | = | 1 if anything was filled, 0 if nothing was filled |
This vector is called to fill a line right until a given condition is met (denoted by R2 and R3).
| R0 | = | x start | ||||||
| R1 | = | y start | ||||||
| R2 | = | delimiting colour | ||||||
| R3 | = | delimiting condition:
| ||||||
| R6 | = | Colour operation | ||||||
| R7 | = | pointer to Graphics context | ||||||
| R8 | = | &21 (reason code) |
| R0 | = | left x position where fill ended |
| R1 | = | right x position where fill ended |
| R2 | corrupted | |
| R3 | = | 1 if anything was filled, 0 if nothing was filled |
This vector is called to fill a line left and right until a given condition is met (denoted by R2 and R3).
| R0 | = | x start | ||||||
| R1 | = | y start | ||||||
| R2 | = | delimiting colour | ||||||
| R3 | = | delimiting condition:
| ||||||
| R6 | = | Colour operation | ||||||
| R7 | = | pointer to Graphics context | ||||||
| R8 | = | &22 (reason code) |
| R0-3 | corrupted | |
This vector is called to perform a flood fill operation, stopping at a given condition (denoted by R2 and R3).
| R0 | = | pointer to buffer of horizontal line segments:
| ||||||||||||
| R6 | = | Colour operation | ||||||||||||
| R7 | = | pointer to Graphics context | ||||||||||||
| R8 | = | &23 (reason code) |
| R0-3 | corrupted | |
This vector is called to perform many horizontal line fill operations as a single step. The block supplied must be copied if the driver is intending to buffer these operations. Because this call is always issued through the vector, clients should try to ensure that it is worthwhile calling using this interface rather than the direct HLine interface (see OS_ReadVduVariables).
| R0 | = | width |
| R1 | = | pointer to pointer data |
| R2 | = | height |
| R6 | = | pointer number to define (0-3) |
| R7 | = | display number |
| R8 | = | &200 (reason code) |
| R0-3 | corrupted | |
This vector is called to define one of the 4 pointer shapes. Pointer shapes are pre-compensated for the 'active' position.
| R0 | = | pointer number |
| R7 | = | display number |
| R8 | = | &201 (reason code) |
| R0-3 | corrupted | |
This vector is called to select one of the pointers for use. Only one pointer is ever displayed at a time.
| R0 | = | height of the pointer |
| R1 | = | y coordinate |
| R2 | = | x coordinate |
| R3 | = | screen height |
| R7 | = | display number |
| R8 | = | &202 (reason code) |
| R0-3 | corrupted | |
This vector is called to update the location of the pointer on the screen.
| R3 | = | screen height |
| R7 | = | display number |
| R8 | = | &203 (reason code) |
| R0-3 | corrupted | |
This vector is called to remove the pointer from the screen.
| R0 | = | colour number to update |
| R1 | = | colour number in form &00BBGGRR |
| R7 | = | display number |
| R8 | = | &204 (reason code) |
| R0-3 | corrupted | |
This vector is called to set the colour of the pointer.
| R0 | = | pointer to a VIDC type 3 table |
| R1 | = | memory required for the mode |
| R7 | = | display number |
| R8 | = | &300 (reason code) |
| V flag | If set, indicates an error. The usual error pointer may be supplied in R0, or if R0 is set to 0 this indicates that a generic error will be returned. If clear, indicates the mode is acceptable. | |
| R7 | = | -1 if handled |
This vector is called to check the validity of a mode prior to selecting it. Drivers should reject modes which they are incapable of displaying.
| R0 | = | pointer to a VIDC type 3 table |
| R1 | = | memory required for the mode |
| R7 | = | display number |
| R8 | = | &301 (reason code) |
| R0 | = | Pointer to base of screen area |
| R7 | = | -1 if handled |
This vector is called to select a screen mode for use. It has already passed the vetting procedure above so should be able to be selected.
Drivers should perform the following actions on a mode change:
| R0 | = | number of scanlines to move down by (may be negative to scroll up) |
| R1 | = | number of bytes to which this equates |
| R2 | = | background colour (word) to fill lines with |
| R3 | = | background colour (word) to fill 'gaps' with |
| R7 | = | display number |
| R8 | = | &302 (reason code) |
| R0 | = | address of screen base, or 0 if hardware scroll is not supported. The address may be the same as the current base if the operation can be performed with acceleration (ie a 'move' operation). The address should be in the lower mapping of the screen buffer if a doubly mapped area is in use. | ||||||
| R1 | = | State of exposed region:
| ||||||
| R2-3 | corrupted | |||||||
| R7 | = | -1 if handled | ||||||
This vector is called to request a hardware scroll of the device. The scroll may be a change of the base of the area, as used by the VIDC driver, or an accelerated copy operation. Drivers can just ignore this operation, or return 0 for both R0 and R1 to indicate that the hardware scroll is not supported. The Kernel can perform the necessary operations if they are not supported by the driver.
Note: (R0 AND NOT 7) lines should be filled with R2.
(R0 AND 7) lines should be filled with R3.
This allows the system to provide gap modes in the same manner as the BBC did.
| R0 | = | 0-255 for regular palette entries |
| R1 | = | colour in form &0sBBGGRR, where 's' indicates a supremacy nibble which may be used for hardware masking operations. Its default will be 0. |
| R7 | = | display number |
| R8 | = | &303 (reason code) |
| R0-3 | corrupted | |
| R7 | = | -1 if handled |
This vector is called to change the displayed colours. The operation of regular palette entries is defined within paletted modes only. Drivers or hardware not supporting the screen 'border' colour should ignore the operation. Drivers which cannot provide the full 24bit colour specification should make best effort to match the colours requested. The colours should be transformed by any RGB tables specified in a separate call if the hardware does not support any specific transformation configuration.
Where RGB tables are not supported by the hardware, it will be necessary to take a copy of the palette entries.
| R7 | = | display number |
| R8 | = | &304 (reason code) |
| R0-3 | corrupted | |
| R7 | = | -1 if handled |
This vector is called to enable the display hardware. This operation is intended to allow components to restart the display hardware for client defined reasons. The Portable module may use this to control the power to the hardware when requested.
| R7 | = | display number |
| R8 | = | &305 (reason code) |
| R0-3 | corrupted | |
| R7 | = | -1 if handled |
This vector is called to disable the display hardware. This operation is intended to allow components to shut down and restart the display hardware for client defined reasons. The Portable module may use this to control the power to the hardware when requested.
| R0 | = | power saving state:
| ||||||||||||||||
| R7 | = | display number | ||||||||||||||||
| R8 | = | &306 (reason code) |
| R0-3 | corrupted | |
| R7 | = | -1 if handled |
This vector is called to select an immediate power-save mode should be entered. Regardless of whether this call is handled or not, the palette will be set to black. Drivers should expect to get palette operations whilst blanked. They may wish to ignore these.
The state values (with the exception of -1) are directly modelled after the DPMS states. -1 can be treated as equivilent to 0 for the purposes of H/V sync control.
If mapping directly to HSync and VSync lines, these values are:
| Value | Meaning |
|---|---|
| 0 | HSync On, VSync On |
| 1 | HSync Off, VSync On |
| 2 | HSync On, VSync Off |
| 3 | HSync Off, VSync Off |
Hardware may promote or demote these settings as it sees fit, but this should be documented in hardware documentation as appropriate.
| R0 | = | pointer to 768 byte table of R, G, B mappings |
| R7 | = | display number |
| R8 | = | &307 (reason code) |
| R0-3 | corrupted | |
| R7 | = | -1 if handled |
This vector is called to modify the RGB mapping tables, through which the palette entries will be transformed. The palette should be affected immediately. Where the hardware does not support RGB mapping tables it will be necessary to translate all palette operations through the tables. It is expected that unpaletted modes (16bpp, 32bpp) support this operation, even though they do not use palette entries.
| R0 | = | configuration flags, or -1 to read current state:
| |||||||||||||||||
| R1 | = | automatic screen cleaning level, 1-3 or -1 to read current state | |||||||||||||||||
| R7 | = | display number | |||||||||||||||||
| R8 | = | &308 (reason code) | |||||||||||||||||
| R0 | = | new or current flags, modified to acceptable values |
| R1 | = | new or current automatic cleaning level |
This vector is called to control the generic acceleration options provided by the video driver. The core acceleration options are to provide a CPU cached screen. One effect of CPU cached screen is an undesirable delay on data being written to the physical screen memory from the processor. This data should be flushed by the driver regularly, if it detects that data has been written to the screen. It is usual to use abort trapping, domain mapped dynamic areas to manage this process (consult the example VIDC driver).
Bit 0 and 1 can be used to suspend this operation until the next mode change. Clients will probably use this for specialised tasks to ensure that their output is immediately visible, such as within games or high responsiveness applications.
Bit 2 is intended to allow clients to disable all hardware acceleration. Whilst this is generally not desirable, it may be useful to clients who either believe there to be faults within the hardware acceleration or who wish to determine the difference made by hardware acceleration. Hardware acceleration is should not be re-enabled by a mode change as the client may wish to examine mode change timings, or it may be believed that mode change acceleration is faulty.
This vector call is triggered by OS_ScreenMode 4.
| R0 | = | operation:
| ||||||||
| R1-6 | = | dependant on reason code | ||||||||
| R7 | = | display number | ||||||||
| R8 | = | &309 (reason code) |
| R1-6 | = | dependant on reason code |
| R7 | = | display number |
This vector is called to cause the screen to be made up to date if necessary such that the data written to it is visible to the user. It is likely that these operations will be used by games. The WindowManager will use this call at the end of a series of redraw operations.
This vector call is triggered by OS_ScreenMode 5 and 6 at present.
| R7 | = | display number |
| R8 | = | &30A (reason code) |
| R7 | = | display number |
This vector is called to inform display device drivers of a device selection. Drivers should claim VSync interrupts when they are enabled and begin generating VSyncs through the VSync dispatch entry point returned when they registered with OS_ScreenMode 255. Drivers should release the VSync interrupts when another device is selected.
| R0 | = | size of current mode, in bytes |
| R7 | = | display number |
| R8 | = | &320 (reason code) |
| R0 | = | number of banks available (1 if only a single bank available) |
| R1-3 | corrupted | |
| R7 | = | -1 if handled |
This vector is called to request the number of screen banks that can be supported by the current configuration of the display. The driver should return the maximum number of banks that may be supported at the instant that the request was made. Subsequent driver operations may cause this value to change.
| R0 | = | bank to display (0 .. max-1) |
| R1 | = | size of current mode, in bytes |
| R7 | = | display number |
| R8 | = | &321 (reason code) |
| R0 | = | bank we are displaying |
| R1 | = | pointer to address of bank |
| R7 | = | -1 if handled |
This vector is called to request a change of display bank. The display bank is presented to the user. Both display and driver banks should be available in memory simultaneously once selected and may both be written to directly. They may be coincident. Once requested (and the request honoured), the Driver should maintain the memory allocated for that bank until the next mode change. Drivers are not required to page all available, or used, banks into logical memory at any time. At the drivers discretion it may remove mappings a bank which is not the driver or display from logical memory. Clients are not expected to access banks which are not selected. Drivers are not expected to support hardware scrolling of any bank but the display bank. Selection of a pre-existing bank should not clear its contents.
| R0 | = | bank to update through VDU drivers (0 .. max-1) |
| R1 | = | size of current mode, in bytes |
| R7 | = | display number |
| R8 | = | &322 (reason code) |
| R0 | = | bank we are displaying |
| R1 | = | pointer to address of bank |
| R7 | = | -1 if handled |
This vector is called to request a change of driver bank. The driver bank is presented to the video drivers for writing to. Both display and driver banks should be available in memory simultaneously once selected and may both be written to directly. They may be coincident. Once requested (and the request honoured), the Driver should maintain the memory allocated for that bank until the next mode change. Drivers are not required to page all available, or used, banks into logical memory at any time. At the drivers discretion it may remove mappings a bank which is not the driver or display from logical memory. Clients are not expected to access banks which are not selected. Drivers are not expected to support hardware scrolling of any bank but the display bank. Selection of a pre-existing bank should not clear its contents.
| R0 | = | source bank number (0..max-1) |
| R1 | = | destination bank number (0..max-1) |
| R2 | = | size of current mode, in bytes |
| R7 | = | display number |
| R8 | = | &323 (reason code) |
| R2-3 | corrupted | |
| R7 | = | -1 if handled |
This vector is called when a client requests a copy of a screen bank be made. If the destination bank has not yet been allocated it should be allocated. The banks requested need not be paged in to logical memory. Drivers which require the banks to be paged in to logical memory for the copy to take place should take the necessary steps to achieve this. This operation must not affect any other bank by the destination. Clients are expected to perform a bank switch to update the display bank, rather than a bank copy.
| R0 | = | requested maximum text columns (ScrRCol) |
| R1 | = | requested maximum text rows (ScrBRow) |
| R2 | = | maximum horizontal pixel coordinate (XWindLimit) |
| R3 | = | maximum vertical pixel coordinate (YWindLimit) |
| R4 | = | x eigen factor |
| R5 | = | y eigen factor |
| R7 | = | display number |
| R8 | = | &400 (reason code) |
| R0 | = | acceptable text columns |
| R1 | = | acceptable text rows |
| R2-8 | preserved | |
This vector is called to initialise teletext mode. The values supplied in R0 and R1 are the requested number of columns and rows for the mode. The driver should either fit those values within the graphics limitations of the mode, or modify the values to be acceptable before return. The frame buffer does not need to be initialised.
| R0 | = | left char x |
| R1 | = | bottom char y |
| R2 | = | right char x |
| R3 | = | top char y |
| R7 | = | display number |
| R8 | = | &401 (reason code) |
| R0-8 | preserved | |
This vector is called to clear a region of the display. It is used after mode selection and for CLS operations. The frame buffer does not need to be updated.
| R7 | = | display number |
| R8 | = | &402 (reason code) |
| R0-8 | preserved | |
This vector is called to update the frame buffer with the previously applied changes. This is the primary point at which the frame buffer should be modified.
| R0 | = | character |
| R1 | = | x position |
| R2 | = | y position |
| R7 | = | display number |
| R8 | = | &403 (reason code) |
| R0-8 | preserved | |
This vector is called to change the character at a given position. The frame buffer does not need to be updated. The change of the character may change not only the representation of the character at that position, but also all subsequent character on that line and (potentially) the characters on the line below.
| R0 | = | left char x |
| R1 | = | bottom char y |
| R2 | = | right char x |
| R3 | = | top char y |
| R4 | = | change in x position (negative = left, positive = right) |
| R5 | = | change in y position (negative = up, positive = down) |
| R7 | = | display number |
| R8 | = | &404 (reason code) |
| R0-8 | preserved | |
This vector is called to scroll a region of the teletext buffer. The frame buffer does not need to be updated. The change of the region may also result in surrounding characters being changed in their representation.
| R0 | = | Flags:
| ||||||||
| R7 | = | display number | ||||||||
| R8 | = | &405 (reason code) | ||||||||
| R0-8 | preserved | |
This vector is called to update the state of the display with respect to flashing characters. The frame buffer does not need to be updated. This entry point may be called under interrupts.
| R0 | = | x position |
| R1 | = | y position |
| R7 | = | display number |
| R8 | = | &406 (reason code) |
| R0 | = | character read |
| R1-8 | preserved | |
This vector is called to read a character from the display at a position. It is used during the character copying routines, via the OS_Byte mechanisms.
| R0 | = | composite cursor position (&SS0000EE) |
| R2 | = | x position (origin top left) |
| R3 | = | y position (origin top left) |
| R7 | = | display number |
| R8 | = | &407 (reason code) |
| R0-8 | preserved | |
This vector is called to invert a cursor on the screen. It is used to flash the cursor whilst updating the display. It may be called under interrupts.
| R0 | = | Flags:
| ||||||||
| R7 | = | display number | ||||||||
| R8 | = | &408 (reason code) | ||||||||
| R0-8 | preserved | |
This vector is called in response to VDU23,18,16,flags| to set the quality of the display. Display drivers may use it to provide a higher quality (and potentially slower) implementation.
| R0 | = | Flags:
| ||||||||
| R7 | = | display number | ||||||||
| R8 | = | &409 (reason code) | ||||||||
| R0-8 | preserved | |
This vector is called in response to VDU23,18,2,flags| to change the reveal state. Display drivers may update the hidden characters to be visible immediately or defer this until an update.
| R0 | = | X left coordinate |
| R1 | = | Y coordinate |
| R2 | = | X right coordinate |
| R3 | = | Colour operation |
| R7 | = | pointer to Graphics context |
| R0-7 | preserved | |
This entry point is provided as part of the graphics context. It may be used by any of the operations called by VideoV to effect a horizontal line. This allows a VideoV claimant who has been requested to draw a shape to render without knowing the specifics of how to access the screen.
The VideoV system will pass the request to draw the line to the registered drivers as a primitive rendering operation.
The functions for bounded and unbounded line rendering have the same interface, but the bounded entry points should clip the rendering to the supplied clipping window.
| R0 | = | X coordinate |
| R1 | = | Y coordinate |
| R2 | = | Colour operation |
| R7 | = | pointer to Graphics context |
| R0-7 | preserved | |
This entry point is provided as part of the graphics context. It may be used by any of the operations called by VideoV to effect a single point. This allows a VideoV claimant who has been requested to draw a shape to render without knowing the specifics of how to access the screen.
The VideoV system will pass the request to plot the point to the registered drivers as a primitive rendering operation.
The functions for bounded and unbounded point rendering have the same interface, but the bounded entry points should clip the rendering to the supplied clipping window.
| Maintainer(s): | Gerph <gerph@gerph.org> | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| History: |
| ||||||||||||||||
| Disclaimer: |
© Gerph, 2006-2023. |