GraphicsV 8 (changes)
Showing changes from revision #14 to #15:
Added | Removed | Changed
GraphicsV
» GraphicsV 8
Graphics Vector (42)
| Entry | |
|---|---|
| R4 | Bits 0-15: 8 (reason code) |
| Bits 16-23: Head number | |
| Bits 24-31: Driver number |
| Exit | |
|---|---|
| R0 | Feature flags: |
| Bit 0: Supports hardware scroll | |
| Bit 1: Supports hardware pointer | |
| Bit 2: Supports interlace with progressive framestore | |
| Bit 3: Uses |
|
| Bit 4: No VSyncs generated | |
| Bit 5: Framestore address changes on mode change (bit 3 must be set) | |
| Bit 6: Rectangle copies (via GraphicsV 13 op 1) are faster than RAM to VRAM transfers using CPU | |
| R1 | Mask of supported pixel formats: |
| Bit 0: 1bpp |
|
| Bit 1: 2bpp |
|
| Bit 2: 4bpp |
|
| Bit 3: 8bpp |
|
| Bit 4: 16bpp RGB (C32K LTBGR) | |
| Bit 5: 32bpp RGB (C16M LTBGR) | |
| R2 | Display buffer alignment requirement in bytes (power of 2) |
| R4 | 0 |
| - | All other registers preserved |
Use
The kernel issues this to determine the available features of a driver. The appropriate driver should respond by setting R4 to 0 to claim the call, and setting R0-R2 to the appropriate values.
Notes
Bit 2 of R0 indicates whether a full-resolution interlace mode (VIDC List Type 3 sync/pol bit 4 set) or a half-resolution one (i.e. 2x upscaling). If the bit is set, the driver is indicating that full-resolution interlace is supported directly. If the bit is clear, the driver is indicating that full-resolution interlace is only possible with additional software support (e.g. the NCOS Interlace module, which would use the MMU to remap screen memory so that two independent “odd” and “even” physical framebuffers can appear as a single interlaced framebuffer by software).
Using this call to read the supported pixel formats is deprecated. Instead, software should prefer to use GraphicsV 17 to read the supported formats, only falling back to this call if that call is unimplemented.
Additionally, bits 4 and 5 of R1 should reflect the availability of those exact formats indicated – bit 4 should only be set if traditional VIDC20 32K colour modes are supported, and bit 5 should only be set if traditional VIDC20 16M colour modes are supported.
See GraphicsV 5 for details on the handling of bit 1 of R0.
Bit 6 of R0 is used by OS_SpriteOp 65 to determine whether to accelerate rendering using GraphicsV (specifically, OS_Plot rectangle copy) or whether to render all the sprites manually.
See also
Social
and
ROOL Store
Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.