Input sought on Service_ModeExtension & Service_ModeTranslation
Jeffrey Lee (213) 6048 posts |
The work I’ve been doing on improving the mode selection/substitution code has made me realise that the current specification for Service_ModeExtension & Service_ModeTranslation is a bit lacking. So I’ve got two questions which could do with being answered:
Note that the new usage of Service_ModeTranslation deviates from the old usage that’s documented on the wiki – it’s now used for all numbered modes where Service_ModeExtension fails to return a VIDC list (or the VIDC list is rejected by the driver). So whenever you ask for a numbered mode that isn’t directly supported by the hardware (e.g. 16 colour mode on a Pi), Service_ModeTranslation will be invoked to try and find a substitute. I think for question one the answer has to be “yes”, otherwise if you had two implementations which both wanted to provide the same mode, if one of those implementations fails to vet the VIDC list before deciding whether to return it then it could prevent the other implementation from getting a look-in. For question two, I’m thinking that having one generic default Service_ModeTranslation implementation is probably the way ahead, even if it makes things a bit more complex than they currently are. At the moment the kernel & ScreenModes implementations are only capable of translating to the modes which the kernel & ScreenModes Service_ModeExtension implementations can return – which is OK because they both deal with different monitor types. But it does result in duplicate code, and it does mean that any softloaded modules which provide their own modes via Service_ModeExtension will only have those modes returned by Service_ModeTranslation if they also provide their own Service_ModeTranslation handler. And then you’d have the problem that the softloaded Service_ModeTranslation implementation may be making a worse choice than the kernel/ScreenModes Service_ModeTranslation implementation, because the softloaded module only knows about the handful of modes that it provides. |
Jon Abbott (1421) 2651 posts |
Without intimate knowledge of the whole mode change process, its not easy to offer an opinion. I wouldn’t expect Service_ModeExtension handlers to vet modes they’re going to return. I’d expect the OS to vet the mode returned and continue passing Service_ModeExtension along until it either get a mode that vets okay, or it runs out of Modules. Service_ModeTranslation, I don’t see an issue with multiple implementations. The kernel has build it modes so needs to translate modes that don’t vet, same goes for ScreenModes. If ScreenModes provides modes on the Screen Modes list should they not be moved into the kernel…or the kernel provided modes moved into ScreenModes? I don’t understand why there’s two sources of build in modes. A block diagram of what order services/GraphicsV are called would definitely help. |
Rick Murray (539) 13850 posts |
Is that not inefficient? Plus, if the handler doesn’t reject unsupported modes, what’s to stop that specific module returning the same results each time? |
Jeffrey Lee (213) 6048 posts |
I wouldn’t expect Service_ModeExtension handlers to vet modes they’re going to return. I think Jon’s suggesting that the service call dispatch is modified so that after each module returns, the result is validated. So if a module returns a bad VIDC list then the kernel will continue passing the request on down the service call chain. The idea of having Service_ModeExtension vet modes was first introduced in RISC OS 3.5, where the requirement was added that the handlers should check the memory limit & bandwidth. Under RISC OS 5 this is slowly being replaced with the requirement that they must vet via GraphicsV. For handlers which have multiple candidate modes available (e.g. differing in framerate or interlace setting), vetting is going to be important, since not all versions may work at all colour depths.
The kernel is the only place (in the ROM) that provides definitions (i.e. the different mode variable values) for numbered modes. But any Service_ModeExtension implementation can attempt to provide VIDC lists for those modes (and any Service_ModeTranslation implementation can attempt to provide a fallback mode). Unless a module is overriding things, the kernel provides the VIDC lists (and fallback mode selection) for the old-style monitor types, while ScreenModes provides the VIDC lists (+ fallback selection) for MDF & EDID monitor types. The logic for this could be merged together, if that’s what you’re suggesting? (e.g. convert the kernel’s VIDC lists into MDFs/EDID blobs that ScreenModes can load)
https://www.riscosopen.org/forum/forums/3/topics/3135?page=3#posts-86408 |
Chris Hall (132) 3558 posts |
There are screen modes, identified by number, specific to Computer Concepts. They are in colour depths that RISC OS understands but at resolutions not supported except by an extension module. With a sprite such as this embedded in a document it won’t render unless the mode extension module is available. When creating a sprite the horizontal width and vertical height can be any length, greater than the nominal screen mode it derives from. Can such a sprite be rendered automatically, using a known screen mode number (rather than the one in the sprite) taking its colour depth from the other embedded data? In other words to have an option, set externally, to ignore the embedded mode number? |
Rick Murray (539) 13850 posts |
Yes, no, maybe, sort of. :-) There is no embedded data, other than with, height, and sprite data length. You may be able to make educated guesses from that. Ovation came with a similar set of custom modes. Like an idiot I designed some sprites in those modes, only to find out that RISC OS has not a clue because it is the mode number that determines colour depth and eigen. Did the CC modes work with 15kHz or multisync or what? So, work out the size of the data actually used by the sprite and then divide it by the geometry. That should tell you how many bits are used to represent a pixel. Then substitute an equivalent mode. You may come unstuck if it’s a choice between say 12,15 (2:4) or 27,28 (2:2), but it’s better than nothing. If you know what the CC module worked with, you can make better guesses. Don’t mode numbers allocated to third parties need to be registered? I think ROOL ought to release the specifications of known additional modes (if they have them) so at least we will know that mode X is 2:4 16 colour, etc. Don’t need the target size, it’s all very far (decades!) out of date, but would be nice if Paint or something could make on the fly substitutions for normal modes. |
André Timmermans (100) 655 posts |
I found this document which references a list of screen modes for the CC card (page 24 & 25) with size, nr of colours (even some 32K ones!) and aspect ratio. They are in range 88-123 and mode numbers 96 or above are supposed to be user defined instead of centrally allocated, so I guess we cannot add the to the official mode list as there could be some conflicts with modes from other sources. I am pretty sure that a few years back someone posted on the forums on the forum a link to the complete list of custom mode numbers provided by various third parties but I did not manage to find the post. Edit: I found the post . It was not quite a link, just a list of modes conflicts for the G8, PCATS and CC cards. |
Chris Hall (132) 3558 posts |
Yes, no, maybe, sort of. :-) Rarely do I get such a clear and concise answer. Sprite data has a width value (measured in words) but no separate pixel width value. Some sort of lookup table from unsupported modes (like CC) to mode numbers that are understood seems to be the way forward? Perhaps configurable by the user? |
Rick Murray (539) 13850 posts |
Just trying to be helpful. ;-)
Ah. Well that’s a pretty big pothole in the road…
That’s probably the simplest way. Does anybody have info on the modes module that came with the original Ovation? Or any other mode modules? |
Clive Semmens (2335) 3276 posts |
It wouldn’t be beyond the bounds to reverse engineer a lookup table to get the sprite width values for unsupported modes given some samples of sprites – there aren’t that many ways to divvi up 32 bits into pixel values. Getting the colours right if there’s a palette might be a tad harder. |
Chris Hall (132) 3558 posts |
If there’s a palette, it allows the width in pixels to be inferred, as the palette size is one bit per pixel. |
Clive Semmens (2335) 3276 posts |
And for others, the width in pixels can be found from a lookup table of mode numbers, reverse engineered from some sample sprites. Do we have some samples? |
Steffen Huber (91) 1953 posts |
I think you are confusing a few things. First of all, the palette is either 16 entry or 64 entry or 256 entry. All you can really say is that – if palette data is there – the sprite is either 1bpp, 2bpp, 4bpp or 8bpp. I guess you are referring to mask data, but then it is only correct for “new format sprites” that don’t rely on screen mode numbers anyway. For old format sprites, the mask data is the same amount of bits per pixel as the pixel data itself (although only “mask on or off” is actually used). |
Chris Hall (132) 3558 posts |
I stand corrected. |
Clive Semmens (2335) 3276 posts |
I think I could write a little app that would convert sprites from non-supported modes to supported modes if you dragged the sprite files onto the icon bar icon, if once I’d reverse engineered a look-up table of the unsupported modes, which I could do if I had a few sample sprites of the unsupported modes. If anyone can let me have some of the offending sprites, I’ll give it a shot. Obviously I can only reverse engineer modes of which I have at least one sample sprite. I might need more than one if the sprite in question is an odd sort of sprite that looks so odd that it’s no odder when rendered with a different divvying up of pixels from words! Email: cliveksemmens@gmail.com |
Rick Murray (539) 13850 posts |
There’s the thing – there’s no magic. All of these extension modes (that I’ve ever seen) provide different screen geometries. The pixel data remains the same sort of thing that RISC OS and the VIDC have always handled. |
John Williams (567) 768 posts |
Is this an opportunity for a bit of Artificial Intelligence? Pattern recognition? Probably not – just an idea! |
Clive Semmens (2335) 3276 posts |
That’s precisely how I was expecting to reverse engineer things to work out a look-up table for my little app. As long as the same number hasn’t been used for different modes, such an app can handle sprites in any mode it already knows about. Better than having the poor user having to try a dozen different pixel patterns to find the right one. |
André Timmermans (100) 655 posts |
Too bad as see post . There are modes conflicts for the PCATS and CC cards. |
Clive Semmens (2335) 3276 posts |
Cheers. I hadn’t seen that. So the best that could be done would be an app that produced multiple copies of some sprites for the user to pick the right ones. But at least you wouldn’t have to go through all twelve possibilities – except I suppose for any modes that I’d never had samples of, or as a fallback alternative if a sprite was identified by my app as a mode that it turned out not to be. |