OS_SpriteOp 3 MODE check issue

When performing the check to see if a MODE change is required, OS_SpriteOp 3 is comparing the resolution of the sprite instead of the resolution of the sprite’s MODE:

 1120:         LDR     R1, [WsPtr, #XWindLimit]
 1121:         ADD     R1, R1, #1
 1122:         CMP     R1, R0
 1123:         LDREQ   R1, [WsPtr, #YWindLimit]
 1124:         CMPEQ   R1, R3
 1125:         LDREQ   R1, [WsPtr, #Log2BPP]
 1126:         CMPEQ   R1, R2

I believe step 1 should read XWindLimit/YWindLimit from the sprite’s MODE, which should then be checked in step 2 instead of using the sprite resolution that’s in R0,R3

What problems are you seeing?

The problem with checking the width/height of the sprite’s mode is that SanitizeSGetMode (which is responsible for creating the mode word for *ScreenSave and friends) was changed to try and convert RISC OS 3.5 sprite mode words to mode numbers if there’s a match on BPP & eigen values – so the width and height of the mode number may have no relation to the width and height of the sprite. This all happened during RiscPC development (1, 2), so it’s only likely to be pre-RiscPC software which will hit any issues because of it.

What problems are you seeing?

When in MODE 12 and trying to Screenload a MODE 12 sprite that’s not full screen height, it fails to recognize it’s in the correct mode, so tries a mode specifier with the resolution of the sprite – which obviously fails. It then falls back to mode 15 and at no point attempts to go to mode 12 that the sprite wants.

Watching the MODE values passed to Service_PreModeChange, I see

1. <MODE specifier> (sprite width, height …)
2. 15

I’m not sure where 15 is coming from, as MODE 12 is a valid MODE when ADFFS is running. I can only guess that as the initial MODE specifier is invalid it’s somehow being translated to 15 and succeeds, when it should be falling back to step 3 attempting to change to the sprite’s MODE #

Going back through the source changes, it looks like the behaviour changed in 4.2.2.6, prior to this I’d expect the behaviour to be:

1. Not attempt to change mode when already in the same mode as the sprite
2. If in the wrong mode, use the mode resolution from the sprite mode (if it exists)

Hmm, your example seems to work OK for me (testing on a BB-xM). If the mode selector fails it will try the mode number from the sprite header

If you consult the flowchart you’ll see that the only thing that can cause Service_PreModeChange to see a different mode number to the one that was passed in is if the kernel thinks the driver doesn’t support the indicated BPP. This check is performed here, by calling GraphicsV 8 against the current driver.

Going back through the source changes, it looks like the behaviour changed in 4.2.2.6, prior to this I’d expect the behaviour to be

IIRC any behaviour changes that came out of 4.2.2.6 only occurred because the previous implementation was completely broken.

Thanks for the info, now that I know the change is intentional and with your pointer about where the check is performed, I’ve figured out a workaround. I sat staring at your flowchart for hours yesterday, trying to work out at which point RISC OS was deciding MODE 12 wasn’t valid!