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