HAL Video API (changes)

Showing changes from revision #7 to #8: Added | Removed | Changed

Hardware Abstraction Layer

» List of HAL APIs

» HAL Video API

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:

• Memory mapped framestore
• Expected to be contiguous physical memory, can be specific memory (eg. VRAM)
• Mapped as contiguous logical memory
• Progressive raster scan in logical memory from top left pixel to bottom right
• Start of each raster row must be word aligned
• Number of pixels in a row should be such that row is a whole number of words
• Spacing between start of each row is a constant number of words, possibly greater than row length (via mode variable, LineLength)
• 1,2,4,8,16 or 32 bits per pixel (bpp)
• Little endian pixel packing for 1,2,4 bpp (least significant bits are leftmost pixels)
• Presence of palette assumed for 1,2,4,8 bpp (8-bits per r,g,b component in each entry)
• 16 bpp format:

• 32 bpp format:

• Palette words are 32 bits:

• Pointer/cursor is assumed supported in hardware, 32×32 pixels, each pixel either transparent or one of 3 paletted colours
• Support for physically interlaced, logically progressive framestore via MMU tricks and use of LineLength mode variable, currently not fully integrated into kernel

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.

Entry points

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

• HAL_VideoFlybackDevice ¶
• HAL_VideoSetMode ¶
• HAL_VideoWritePaletteEntry ¶
• HAL_VideoWritePaletteEntries ¶
• HAL_VideoReadPaletteEntry ¶
• HAL_VideoSetInterlace ¶
• HAL_VideoSetBlank ¶
• HAL_VideoSetPowerSave ¶
• HAL_VideoUpdatePointer ¶
• HAL_VideoSetDAG ¶
• HAL_VideoVetMode ¶
• HAL_VideoPixelFormats ¶
• HAL_VideoFeatures ¶
• HAL_VideoBufferAlignment ¶
• HAL_VideoOutputFormat ¶
• HAL_VideoRender ¶
• HAL_VideoIICOp ¶
• HAL_VideoFramestoreAddress ¶
• HAL_VideoStartupMode ¶
• HAL_VideoPixelFormatList ¶

Integration with GraphicsV

Starting with RISC OS 5.21, on startup the OS will issue a call to HAL_VideoPixelFormats to detect if the HAL video API is implemented. If this call returns non-zero then the OS will register a “HAL” driver with GraphicsV and map GraphicsV calls to HAL calls as follows:

For VSync events, the OS will use HAL_VideoFlybackDevice to determine the IRQ device number to respond to, and will call GraphicsV 1 as appropriate whenever the interrupt fires.

Note that HAL_VideoSetPowerSave is currently not available via GraphicsV.

Prior to RISC OS 5.21, any calls made to GraphicsV which were for driver zero and were not handled by a driver module would be forwarded onto the HAL. Additionally, some HAL video calls were required to be implemented for module-based drivers to operate correctly.

Information source: Kernel.Docs.HAL.HAL_API in CVS