SpriteV claimants
With the advent of video drivers which may extend the SpriteV operations in order to provide acceleration it is necessary to be aware of the order of vector registration. Ensuring the ordering of vector claimants ensures that the system can be modularly extended, and restarted.
The SpriteExtend module has been updated to issue a number of service calls in order to initialise extensions to the Sprite vector after it has claimed the vector itself. This allows those claimants to process the calls before SpriteExtend itself performs the usual software operations. Three classes of extensions are expected and are provided for :
Type 0 - software vector extensions
These are extensions, similar to SpriteExtend, which provide core software implementations of new vector calls. For example, should there be a sprite operation to render a sprite to a draw path, this would be where the implementation would register its vector.
Type 1 - accelerated vector extensions
These are extensions which accelerate existing operations. Hardware video drivers would fall in to this category, allowing them to accelerate the existing operations when rendering to their display device.
Type 2 - monitor, or vector augmentation
These are handlers which either monitor the calls passed through the vector for diagnostic purposes, or which modify the vector parameters in order to provide some different implementation. It is not expected that there be many handlers at this level.
Service_SpriteReregister (&E1)
On entry
R0 = registrant type :
0 = software vector extensions
1 = accelerated vector extensions
2 = monitor or vector augmentation
Others reserved
R1 = &E1 (service number)
On exit
R0, R1 preserved (must not be claimed)
This service is issued by SpriteExtend after it claims SpriteV in order that other clients may register themselves in the correct order. It will be issued 3 times, once for each of the registrant types, in ascending order. It must not be claimed.
|