Future-proofing OS_SpriteOp
nemo (145) 2529 posts |
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):
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:
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. |
Stuart Swales (8827) 1348 posts |
+1 |
David J. Ruck (33) 1629 posts |
What code is using reserved/undefined bits? |
Rick Murray (539) 13805 posts |
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 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.
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. |
André Timmermans (100) 655 posts |
x = (R0 >> 10) |
nemo (145) 2529 posts |
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.
…had the wrong reason code next to R0 (fixed), but is otherwise OK I think. |
Rick Murray (539) 13805 posts |
<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.
Yup. If stuff is liable to blow up, we’re going to have to do it the hard way.
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. |
nemo (145) 2529 posts |
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:
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.
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] |