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:

Mode and frame buffer initialisation. These are handled by a hardware driver such as VideoHWVIDC, VideoHWVF or VideoHWPL110. Pointer operations. These are usually handled by the hardware driver. VDU 4 text. These are, by default, handled by the software driver, VideoSW, but may be accelerated. Graphics operations. These are also handled by the software driver. Sprite operations. These are still handled by the Kernel, but are already vectored through SpriteV. Teletext operations. These are handled by the VideoTTX module.

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 vector (&hex;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:

&hex;000 - &hex;00F - Text (VDU 4) operations &hex;010 - &hex;1FF - Graphics (OS_Plot and similar) operations &hex;200 - &hex;2FF - Pointer operations &hex;300 - &hex;3FF - Mode and display driver operations &hex;400 - &hex;4FF - Teletext operations

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 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 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 and 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 :

No effect - the operation can just return Use the last set Colour 1 Use the last set Colour 2 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.

Graphics clipping window x-min (inclusive) Graphics clipping window y-min (inclusive) Graphics clipping window x-max (exclusive) Graphics clipping window y-max (exclusive) Function to call to render a bounded horizontal line Function to call to render a unbounded horizontal line Function to call to render a bounded point 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:

Set private display number variable to -1. Initialise any video hardware to a functioning, but disabled state. This may include setting up a display buffer. Claim VideoV vector. Construct a display device descriptor for the hardware. Call OS_ScreenMode 255 to register the display. If an error was returned, release all resources and exit with the error. Set private display number variable to the value returned. Store the VSync dispatcher and its workspace pointer for use later If R3 was set to 1, issue OS_ScreenMode 11 to select the display number supplied. If an error was returned from the display selection, attempt to select a known supported mode with OS_ScreenMode 0. If a further error is returned, release all resources and exit with the error. Complete initialisation and return with no error.

During finalisation it is important that the device shut itself down safely. The following sequence is recommended:

Set the private display number variable to -1, such that no vector calls will be interpreted and that VSyncs will no longer be triggered by the driver. Release the VideoV vector to prevent any other calls being serviced. Disable VSyncs for the hardware. Call OS_ScreenMode 254 to deregister the display. Release other hardware resources, shutting the hardware down to its most quiescent state. Release any other claimed resources. Complete finalisation and return with no error.

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.

Dependant on reason code Display number (where relevant)

Reason code

 Dependant on reason code

The vector should be claimed when it is handled entirely within the driver.

 Only teletext calls are issued by the graphics system. pointer to the base of the destination (DisplayStart) line length for this destination (LineLength) maximum height in text lines (ScrBRow) destination log2bpp depth (Log2BPP) mode flags for destination (ModeFlags) 0 (reason code)

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:

'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.

'BBC gap mode', should be treated as identical to Bit 2.

This flag is deprecated and support is not required of any clients.

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.

the character to define (32-255) pointer to word aligned 8 bytes to use as the character 1 (reason code)

This vector is called to define a character. Clients should normally make a note of the changes and pass this call on.

 foreground screen colour background screen colour BPP of the current mode 2 (reason code)

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.

 character to write (32-255) pointer to address of top left pixel to write (word aligned) on the screen character x (origin top left) character y (origin top left) 3 (reason code)

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 . 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.

composite cursor position (&hex;SS0000EE) pointer to address of top left pixel for the character (word aligned) on the screen character x (origin top left) character y (origin top left) offset of start of the cursor, from R1 offset of line after the end of the cursor, from R1 4 (reason code)

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.

pointer to box description

left char x bottom char y right char x top char y top left address to start at (might be byte aligned) number of bytes to fill per line (might be byte aligned; usually will be the same as LineLength) number of lines to fill character line size (8, 10, 16, 20) fill word for first 8/16 lines of each character fill word for subsequent lines (gap fill)

5 (reason code)

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.

action type, for information purposes

pointer to OR-EOR pattern to use

Value to OR in word for line 0 Value to EOR in word for line 0 Value to OR in word for line 1 Value to EOR in word for line 1 Value to OR in word for line 2 Value to EOR in word for line 2 Value to OR in word for line 3 Value to EOR in word for line 3 Value to OR in word for line 4 Value to EOR in word for line 4 Value to OR in word for line 5 Value to EOR in word for line 5 Value to OR in word for line 6 Value to EOR in word for line 6 Value to OR in word for line 7 Value to EOR in word for line 7

&hex;10 (reason code)

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.

 action type, for information purposes pointer to OR-EOR pattern to use, as for &hex;11 (reason code)

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 .

pointer to context information

Mode flags Text screen width-1 Text screen height-1 Number of colours X-eigen factor Y-eigen factor Line length Total output size Base of the output buffer Log2 Bits Per Pixel Log2 Bits Per Addressable Pixel (hang-over from double-width pixel modes) Graphics screen width-1 Graphics screen height-2

0 if the destination is the screen, otherwise the destination is a sprite &hex;12 (reason code)

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.

pointer to base of the buffer &hex;13 (reason code)

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.

pointer to where to store HLine handler (r12, function) pointer to where to store Point handler (r12, function) pointer to where to store VLine handler (r12, function) &hex;14 (reason code) new pointer to where to store HLine details at new pointer to where to store Point details at new pointer to where to store VLine details at

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.

pointer to coordinate block:

x-min (inclusive) y-min (inclusive) x-max (exclusive) y-max (exclusive)

pointer to &hex;15 (reason code)

This vector is called to fill a rectangle. Clients should bound the coordinates if necessary and then plot the rectangle.

pointer to coordinate block:

x0 y0 x1 y1 x2 y2

pointer to &hex;16 (reason code)

This vector is called to fill a triangle. Clients should plot the triangle, bounded by the coordinates given.

pointer to coordinate block:

x0 y0 x1 y1 x2 y2

pointer to &hex;17 (reason code)

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.

pointer to coordinate block:

source x0 source y0 source x1 source y1 destination x0 destination y0 destination x1 destination y1

pointer to &hex;18 (reason code)

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.

pointer to coordinate block:

x centre y centre x edge y edge

pointer to &hex;19 (reason code)

pointer to coordinate block:

x centre y centre x edge y edge

pointer to &hex;1A (reason code)

This vector is called to fill a circle. Clients should plot the circle, bounded by the coordinates supplied if necessary.

pointer to coordinate block:

x centre y centre x start y start x end y end

pointer to &hex;1B (reason code)

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.

pointer to coordinate block:

x centre y centre x start y start x end y end

pointer to &hex;1C (reason code)

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 . 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.

pointer to coordinate block:

x centre y centre x start y start x end y end

pointer to &hex;1D (reason code)

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 . 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.

pointer to coordinate block:

x centre y centre x width ignored x limit point y limit point

pointer to &hex;1E (reason code)

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.

pointer to coordinate block:

x centre y centre x width ignored x limit point y limit point

pointer to &hex;1F (reason code)

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 operation.

x start y start delimiting colour

delimiting condition:

fill to delimiting colour fill to non-delimiting colour

pointer to &hex;20 (reason code) right x position where fill ended 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).

x start y start delimiting colour

delimiting condition:

fill to delimiting colour fill to non-delimiting colour

pointer to &hex;21 (reason code) left x position where fill ended right x position where fill ended 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).

 x start y start delimiting colour

delimiting condition:

fill to delimiting colour fill to non-delimiting colour

pointer to &hex;22 (reason code)

This vector is called to perform a flood fill operation, stopping at a given condition (denoted by R2 and R3).

pointer to buffer of horizontal line segments:

number of horizontal lines to draw 1st horizontal line segment: x left position 1st horizontal line segment: y position 1st horizontal line segment: x right position Subsequent horizontal line segments

pointer to &hex;23 (reason code)

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).

width pointer to pointer data height pointer number to define (0-3) display number &hex;200 (reason code)

This vector is called to define one of the 4 pointer shapes. Pointer shapes are pre-compensated for the 'active' position.

pointer number display number &hex;201 (reason code)

This vector is called to select one of the pointers for use. Only one pointer is ever displayed at a time.

height of the pointer y coordinate x coordinate screen height display number &hex;202 (reason code)

This vector is called to update the location of the pointer on the screen.

 screen height display number &hex;203 (reason code)

This vector is called to remove the pointer from the screen.

 colour number to update colour number in form &hex;00BBGGRR display number &hex;204 (reason code)

This vector is called to set the colour of the pointer.

 pointer to a VIDC type 3 table memory required for the mode display number &hex;300 (reason code)

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.

 -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.

 pointer to a VIDC type 3 table memory required for the mode display number &hex;301 (reason code) Pointer to base of screen area -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:

Default to the first screen bank for display and driver Release any claimed memory for alternate screen banks Clear the palette to black

number of scanlines to move down by (may be negative to scroll up) number of bytes to which this equates background colour (word) to fill lines with background colour (word) to fill 'gaps' with display number &hex;302 (reason code) 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.

State of exposed region:

the exposed region has been cleared to the requested background the exposed region has not been cleared and must be cleared by the OS

-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.

0-255 for regular palette entries
256 for 'border'

 colour in form &hex;0sBBGGRR, where 's' indicates a supremacy nibble which may be used for hardware masking operations. Its default will be 0. display number &hex;303 (reason code) -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.

display number &hex;304 (reason code) -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.

 display number &hex;305 (reason code) -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.

power saving state:

D0 DPMS state - Normal operation, display enabled D0 DPMS state - No DPMS but display disabled if possible (rest of the system will blank palette in this state; VIDC will disable disable refresh and DMA in this state) D1 DPMS state - 'Standby' D2 DPMS state - 'Suspend' D3 DPMS state - 'Active off' DPMS state supplied in modes VIDC type 3 table (ie 'default') will not be used

display number &hex;306 (reason code) -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:

HSync On, VSync On HSync Off, VSync On HSync On, VSync Off 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.

pointer to 768 byte table of R, G, B mappings

 display number &hex;307 (reason code) -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.

configuration flags, or -1 to read current state:

suspend cached screen until mode change suspend automatic screen cleaning until mode change disable all hardware acceleration reserved, must be 0 must be set

automatic screen cleaning level, 1-3 or -1 to read current state display number &hex;308 (reason code) new or current flags, modified to acceptable values 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.

operation:

clean cache immediately, if necessary and not suspended clean cache immediately, if necessary reserved

dependant on reason code display number &hex;309 (reason code) dependant on reason code 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.

display number &hex;30A (reason code) 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.

 size of current mode, in bytes display number &hex;320 (reason code) number of banks available (1 if only a single bank available) -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.

bank to display (0 .. max-1) size of current mode, in bytes display number &hex;321 (reason code) bank we are displaying pointer to address of bank -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.

bank to update through VDU drivers (0 .. max-1) size of current mode, in bytes display number &hex;322 (reason code) bank we are displaying pointer to address of bank -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.

source bank number (0..max-1) destination bank number (0..max-1) size of current mode, in bytes display number &hex;323 (reason code) -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.

requested maximum text columns (ScrRCol) requested maximum text rows (ScrBRow) maximum horizontal pixel coordinate (XWindLimit) maximum vertical pixel coordinate (YWindLimit) x eigen factor y eigen factor display number &hex;400 (reason code) acceptable text columns acceptable text rows

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.

left char x bottom char y right char x top char y display number &hex;401 (reason code)

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.

display number &hex;402 (reason code)

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.

character x position y position display number &hex;403 (reason code)

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.

left char x bottom char y right char x top char y change in x position (negative = left, positive = right) change in y position (negative = up, positive = down) display number &hex;404 (reason code)

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.

Flags:

Flash characters visible

display number &hex;405 (reason code)

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.

x position y position display number &hex;406 (reason code) character read

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.

composite cursor position (&hex;SS0000EE) x position (origin top left) y position (origin top left) display number &hex;407 (reason code)

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.

Flags:

High quality requested

display number &hex;408 (reason code)

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.

Flags:

Concealed characters visible

display number &hex;409 (reason code)

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.

X left coordinate Y coordinate X right coordinate pointer to

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.

X coordinate Y coordinate pointer to

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.

© Gerph, 2006-2023.

Released as part of the Video SDK Transferred content to PRM-in-XML format Updated with details of compatibility Fixed some validity problems