The HAL only attempts to abstract the hardware controller aspects of the OS video. It does not (yet) consider pixel formats, framestore layout, hardware graphics acceleration. All these would affect a great deal of RISC OS graphics code that forms much of the value of the OS. This means that the envisaged HAL/RISC OS combination makes some specific assumptions about graphics framestore layout as follows:
| Bits | Meaning |
|---|---|
| 0-4 | Red |
| 5-9 | Green |
| 10-14 | Blue |
| 15 | Supremacy (0=solid, 1=transparent) |
| Bits | Meaning |
|---|---|
| 0-7 | Red |
| 8-15 | Green |
| 16-23 | Blue |
| 24-31 | Supremacy (0=solid, 255=transparent) |
| Bits | Meaining |
|---|---|
| 0-7 | Reserved (0), or Supremacy (0=solid, 255=transparent) |
| 8-15 | Red |
| 16-23 | Green |
| 24-31 | Blue |
Note that it is possible to support hardware where only some pixel depths are available, or only some fit the RISC OS assumptions. Also some hardware has some configurability for ‘arbitrary’ choices like RGB versus BGR ordering. Hence, the restrictions are typically much less severe than might first be thought.
Supporting a software only pointer/cursor is feasible (much less work than new pixel formats) but not yet considered.
Items marked ¶ are internal calls for OS use only; their functionality and availability is subject to change without warning. User programs interested in using these calls should instead use the equivalent RISC OS SWI call (if available).
Extended Framebuffer Format Specification – Proposal for extending RISC OS and the HAL to support additional framebuffer formats