Future-proofing OS_SpriteOp

Despite the headroom, the SpriteOp reason code is resolutely 8bit and can’t be retrospectively expanded into b10-31 now. There’s too much code that knows better.

The SOPs are also grouped (though you may not have noticed):

• 00-07 have neither Area nor Sprite
• 08-17 have Area but no Sprite
• 18-3B have Area and Sprite
• 3C-3E have Area and optional Sprite
• 3F+ seem to be Area and Sprite (though 3F & 40 are moot)

The 08-17 group in particular is congested. So I’m proposing explicitly defining these ranges (as that helps SpriteV claimants understand what R1 and R2 are supposed to be) and reserve four SOPs now for sub-reasoned expansion:

• 04 Subreasoned with neither Area nor Sprite
• 14 Subreasoned with Area but no Sprite
• F8 Subreasoned with Area and Sprite
• FC Subreasoned with Area and optional Sprite

In all cases the subreason would be in R3, starts from 0, and because the above codes encode the meaning of R1 & R2 the subreasons can be ungrouped and incremental. You’ll note that even with b8:R1=Area and b9:R2=Ptr the above four are integer constants.

I realise I’m the only one coining new SpriteOps but.

+1

What code is using reserved/undefined bits?

What code is using reserved/undefined bits?

The OS has a mechanism that assumes sprite actions will fit into a byte, and it uses bits 8 and 9 to change how the call is interpreted.

SpriteOp number = do the action on the system sprite area, referencing the sprite by name
SpriteOp number + 256 = do the action on a user-supplied sprite area, referencing the sprite by name
SpriteOp number + 512 = do the action on a user-supplied sprite area, referencing the sprite by address

I could see maybe setting the SpriteOp low byte to some sort of dummy eight bit value (like &FF?), setting bits 8 or 9 accordingly, and then having the upper 16 bits give the extended code. What would that muck up? Surely anything that does muckery with SpriteOps ought to ignore things that they don’t recognise.

(though 3F & 40 are moot)

Hmm, not in the PRM. Don’t seem to be your metadata extension…? Something else? ROLtd?

By the way, whoever added the 23/&17 description to the wiki looks like it’s a copy-paste of the original version… I’d fix it, but I’m using NetSurf.

x = (R0 >> 10)
opcode = (R0 AND &FF) + (x << 8)

Thank you for your thoughts. No, in typical Acorn fashion (because the documentation was not clear about what R0 means) there is code that manipulates b0-7 and b8-31 separately. So code on SpriteV that needs to find the sprite named in R2 may alter bits 0-7 to &18 while keeping the rest of R0 the same… this will go badly wrong if anything new is put in b10-31.

This is, unfortunately, non-negotiable. So there has to be a subreason rather than an expansion of interpretation of R0, sorry.

For the record, &x3F and &x40 were reserved for “calibrated” plots, but since all other Acorn colour code was spectacularly wrong, it’s very difficult (and rather pointless) to speculate what they intended for that. And why would you want an “uncalibrated” one? In any case, MetaSprite affords far more sophisticated solutions, such as my AutoGamma module.

the 23/&17 description

…had the wrong reason code next to R0 (fixed), but is otherwise OK I think.

there is code that manipulates b0-7 and b8-31 separately.

<facepalm> Typical futureproofing, like assuming filenames would fit into 10 characters or that you could make assumptions about the opaque value returned by GPBP’s catalogue scanning.

This is, unfortunately, non-negotiable.

Yup. If stuff is liable to blow up, we’re going to have to do it the hard way.

And why would you want an “uncalibrated” one?

Perhaps regular plotting was just dumping pixels to the screen, while a calibrated plot would try to colour-match some sort of profile, like a printer or whatever in order to present a more realistic representation? Like the difference (on Windows) between actual calibration and just assuming everything is sRGB?

But, yeah, somebody did once have an interesting/amusing rant about how ColourTrans was… lacking.

Typical futureproofing

The BBC Micro era of forward-thinking was fading. I often think of VDU19 as the epitome of future-thinking or as a great project manager put it, “Reserve the right to get smarter”.

And it isn’t third-party code that made these assumptions – SpriteExtend explicitly checks only the bottom eight bits. This would only disqualify those values from “extended” reason codes (eg my extensive extension of VDU23,0…) but the division of R0 was established – I have seen code that does:

BIC   Rn, R0, #&FF
CMP   Rn, #&100
BHI   HavePtrInR2
BLCC  GetSystemArea
...   ; find named Sprite

or similar. Too late now by several decades. My reason for this rare thread was to justify allocating four SOPs for subreasoning – as that preserves the semantic grouping that defines the meaning of R1 & R2, which is crucial.

colour-match some sort of profile

Yes, the point I was alluding to was that you CAN’T know the colourspace of some unadorned sprite so cannot “calibrate” that. And if you have a sprite containing an ICC profile or at least a documented gamma (AutoGamma) then why would you want to plot that one incorrectly? And therefore why would you need an API that says “Don’t get this wrong”.

AutoGamma spots a GAMA MetaData chunk and if present, colour-manages the plot. Similarly for ICC-adorned Sprites. You don’t label them thus in order to plot them incorrectly so the API distinction is unwarranted.

[There is an argument to be had about the plotting of calibrated sprites INTO a calibrated sprite – and how would one know that was happening and what the calibration was other than watching out for Service &72 – but this is not that argument]