Showing changes from revision #5 to #6:
Added | Removed | Changed
Entry | |
---|---|
R1 | 81 (&51) |
R2 | Mode number, shadow bit clear |
R3 | Monitor type |
Exit | |
---|---|
R1-R3 | Preserved to pass on, else: |
R1 | 0 to claim service |
R2 | Substitute mode (mode number or mode Mode Selector Block) |
R3 | Preserved |
This service is issued by OS_CheckModeValid or a mode change when if the requested mode isn’t supported by the current monitor type is / unknown video by hardware.RISC OS, and the mode is not available with the current monitor type.
Implementors of Service_ModeTranslation should check to see if they recognise the input mode and monitor type, and then check to see if they know of any suitable substitute mode (e.g. with similar resolution and colour depth) which is supported by the hardware. If such a mode is found, they can claim the call and return the new mode in R2.
This call is only issued for mode numbers, not Mode Selector Blocks.
For monitor types 0-6 and 8, the kernel has built in logic for handling translation of the built in numbered modes. Prior to RISC OS 5.28, this logic was directly integrated into the VDU driver, limiting the ability for external software to utilise or override the logic (e.g. Service_ModeTranslation would not be called for mode+monitor type combinations which were capable of being handled by the kernel’s logic). In RISC OS 5.28, the logic was moved to a Service_ModeTranslation handler, placing the built in modes on an even footing with extension modes and other monitor types.