Showing changes from revision #2 to #3:
Added | Removed | Changed
Offset | Contents |
---|---|
+0 | Size of entry in bytes (multiple of 4) |
+4 | Flags: |
Bit 0: Must be 1 | |
Bits 1-7: Block format | |
Bits 8-31: Additional format-specific flags |
For format 0, the rest of the block has the following format:
Offset | Contents |
---|---|
+8 | X resolution (in pixels) |
+12 | Y resolution (in pixels) |
+16 | Log2BPP value |
+20 | Frame rate (in Hz, to nearest integer) |
+24 | Mode name, null terminated, and then padded with nulls until it is word aligned. (For unnamed modes this will simply be a single word whose value is 0). |
For format 1, the rest of the block has the following format:
Offset | Contents |
---|---|
+8 | X resolution (in pixels) |
+12 | Y resolution (in pixels) |
+16 | NColour value |
+20 | ModeFlags value |
+24 | Log2BPP value |
+28 | Frame rate (in Hz, to nearest integer) |
+32 | Mode name, null terminated, and then padded with nulls until it is word aligned. (For unnamed modes this will simply be a single word whose value is 0). |
Block formats 2 and above are currently undefined.
Currently, no formats make use of the extra flags in bits 8-31 of the word at +4.
Block format 1, introduced with RISC OS 5.21, is an extended version of format 0 to allow the full range of pixel formats supported by the OS to be expressed. For backwards-compatibility, code which generates mode provider blocks should generate a format 0 block wherever possible. See Valid Mode Variable Combinations for a list of all pixel formats understood by various OS versions, and which formats can be expressed as a simple Log2BPP value (i.e. a format 0 block).
Note that as the Log2BPP value is already expressed in the main body of the block, it is invalid to also include it in the list of mode variables.
Software which processes mode provider blocks must be careful to check the low byte of the word at +4 and skip blocks with unknown or invalid formats.