Showing changes from revision #7 to #8:
Added | Removed | Changed
Entry | |
---|---|
R1 | 80 (&50) |
R2 | Mode Specifier (number or selector, NOT a Sprite Mode Word) |
R3 | Monitor type, or -1 for ‘unspecified’ |
R4 | Bandwidth limit (bytes/sec) 1 |
R5 | Memory limit (bytes) 1 |
Exit | |
---|---|
R1-R4 | Preserved to pass on, else: |
R1 | 0 to claim service |
R2 | Preserved |
R3 | Pointer to VIDC List |
R4 | Pointer to Mode Workspace List (if a mode number was provided in R2 on entry) |
Else zero (if a Mode Selector Block was provided on entry) |
This service is used by the kernel to look up information about a mode which the kernel does not recognise. Most significantly, it is the mechanism by which the ScreenModes module communicates mode timings to the kernel when a anMDF is in use.
For numbered modes, the contents of the mode workspace list must be identical no matter the monitor type selected. Only the contents of the VIDC list may differ by monitor type.
Under RISC OS 5, implementers of Service_ModeExtension handlers are expected to ensure that any VIDC list returned has been validated against the current GraphicsV driver.
For monitor types 0-6 and 8, the kernel has several built in tables of mode timings and workspace parameters that describe the built in numbered modes. Prior to RISC OS 5.28, these tables were effectively private to the kernel, limiting the ability for external software to generate its own VIDC lists by calling Service_ModeExtension. In RISC OS 5.28 and later this has been rectified, by adding a Service_ModeExtension handler to the kernel which is able to query those tables and return a VIDC list which is valid for the current GraphicsV driver. The kernel’s Service_ModeExtension handler supports mode lookup by either mode number or (sufficiently accurate) Mode Selector Block. The addition of the Service_ModeExtension handler to the kernel also allowed for removal of some special-case logic that existed for handling those numbered modes during mode vetting (OS_CheckModeValid) and mode setting (e.g. OS_ScreenMode ). Now Now, those code paths are fully reliant on Service_ModeExtension for generatingVIDC lists.
Mode workspace lists and VIDC lists returned by this call may be in a temporary buffer and at risk of being overwritten by the next call to this service call – when calling Service_ModeExtension, care should be taken to copy them to your own buffer ASAP.
1 The R4 and R5 parameters were added to the service call specification in RISC OS 3.5. They allow ScreenModes to filter the MDF entries by the VRAM size and memory bandwidth limit of the machine.
ScreenModes 0.33 and above (RISC OS 5.20+) ignores R4, and instead relies on GraphicsV_VetMode to check for any relevant bandwidth limits. This is because on modern systems, the video driver is in a much better position to determine any bandwidth limitations than the kernel.