ChangeFSI on Risc OS 3.1

I don’t know if anybody else is interested in this, but I was playing with ChangeFSI on RISC OS 3.11 and I discovered if you remove the OS version check it now works.

I discovered if you remove the OS version check it now works.

Er, kinda sorta.

Testing with ArcEm in mode 27, I created a 16-colour sprite in Paint and loaded it into ChangeFSI, but it was displayed – and saved – in greyscale. I had to switch to mode 28 (256 colours) for it to display the correct colours.¹

Trying to display a JPEG file gave “Bad drive”. I strongly suspect a PNG file would also fail. The JPEG and PNG output options don’t work, for obvious reasons.

It’s probably OK if you just want to convert certain foreign file formats (TIFF, PCX etc.) to sprites, but claiming “it works” may lead to user disappointment.

¹ I recall a limitation with 256 (and higher) colour sprites being displayed in greyscale if you were in a 16-colour mode at RISC OS 3.6, but I thought 16-colour sprites did display OK.

but it was displayed – and saved – in greyscale

Digging up an ancient memory, I think you might have needed to apply a suffix to get CFSI to better map the colours in a 16 colour mode. Mode 27r or something? Read the docs…

Trying to display a JPEG file gave “Bad drive”. […] The JPEG […] output options don’t work

Then either something has been broken, or it has been changed to use the OS’ internal routines. Given the version check, my money is on the latter.

ChangeFSI on 3.10 is more than happy to load and save JPEGs. —> http://riscos.com/ftp_space/310/files/supp.zip

but claiming “it works” may lead to user disappointment.

It does work, but you’re trying to use a 2022 version on a 1992 OS which will be suboptimal; IIRC native JPEG support wasn’t even built in until 3.6 (with a softload for 3.5), and even that was “patchy” due to the patent issue with progressive JPEG.

You know, one could even suggest that the OS version check is there precisely to guard against situations such as this.

Use the appropriate version, link above.

Definitely suboptimal, quite slow, and no colour but I was able to view a JPEG file.

I didn’t know there ever was a version for 3.1 so thanks for that. It seems to work just the same as the new one for JPEG input but without the non-functioning JPEG output option.

I discovered if you remove the OS version check it now works.

Er, kinda sorta.

The version check is there for several good reasons, specifically (but probably not limited to):

• When the assembler colour space converters were 32 bitted they use MRS/MSR to preserve state, which requires an ARM6 or later. Indeed, prior to this change in 2012 it would fall over unless your copy of BASIC was new enough to accept those opcodes. They execute as NOPs on ARM3 and ARM2 so there may be some unexpected V set error returns.
• JPEG output relies on the OS’ built in display routines in SpriteExtend which isn’t in RISC OS 3.10
• Various options expect dynamic areas, and while there are fallbacks to not need them I doubt they’ve been exercised much recently!
• There’s an assumption 16bpp and deeper sprites are allowed, again requiring the OS to support them for display in the desktop

For JPEG input it should be fine – ChangeFSI attempts to use the OS’ routines in SpriteExtend first and if they fail uses the slower disc based decompressor djpeg.

For JPEG output you can do this at the command line, which avoids needing the OS’ display routines. The CompressJPEG module is in the main disc image and runs on RISC OS 3.10. See ‘CmdBasUse’ for details of the incantation to output JPEG or JPEGMONO.