Draw -> SVG

Converting the Png image to jpeg 100% – put file in a Drawfile – Fireworks now loads it.

So does Pipedream4 EasyWriter &
TextEase.

The largest test Sprite that I have here is 38.8Mb (7200×5400@8bpp), which loads into Fireworkz OK both when using Dynamic Area workspace (as would be used on RISC OS 4) and when using normal application workspace.

I think that the ChangeFSI supplied with RISC OS 5 could have a more generous upper WimpSlot limit these days to help convert the much wider images that the interwebs are full of these days ;-)

Out of interest, here’s a PNG that ChangeFSI (on RISC OS 5.29 at least) is unable to convert to 16bpp or 32bpp unscaled: https://www.learningcontainer.com/wp-content/uploads/2020/08/Large-Sample-png-Image-download-for-Testing.png

This is interesting -

A call to a oldish 5.66 CLib on RO4.02.

BLle CLib (strcpy)
Ble next_code

Bhi end
BL CLib
B next_code
.end

Seems to work.

But:

ADRle r14,next_code
Ble CLib

Crashes in CLib??

All done in a original Module – modified with !Zap.

The extra line squeezed in – ie the one with three instructions.
(Use of Procedure name -
space)

[Edit]

@Colin: If that code is in a module, is it running in 26-bit SVC mode at that point? If so, your ADR r14,... won’t set the PSR flags in R14 correctly for return (it’s using ADD r14,pc,#offset), so when your called procedure returns with either MOVS pc,lr or LDMIA fp,{...,pc}^ it will be in USR mode, with the wrong stack…

My RO 4.02 ROM contains SharedCLibrary 4.87 (23 Apr 1999). Are you trying to soft-load an archaic one???

Perhaps start a new thread somewhere as this is somewhat OT?

Am trying to 32bit the modules in ,!SVG converter -

Unless Gerf can be persuaded to do it from source.

Had a look the softload my mistake CLib was 5.66 (06 Dec 2011)

Now using 5.97 (11 Jun 2018) latest?

Not tried the test with it yet.

The code in a ‘C’ mod is in SVC so the code in the CLib presumedly stays the same.

The CLib call is ‘strcpy’

Other CLib calls seem to be ok – using the same method.

Is that CLib from the downloadable PlingSystem ZIP for use with pre-RISC OS 5 systems? The latest there is SharedCLibrary 6.09 (06 Feb 2021).

Which SWI is this module using to initialise the SharedCLibrary?

The effect is the same with CLib 5.97 which is flagged as 26bit.

Gone back to original Mod – and just changed the two instructions – still does it.

Bit of a puzzle :-)

No puzzle, though. The SharedCLibrary you are using on RISC OS 4 is compiled for 26-bit. 26/32-bit neutral clients can call library routines OK as those clients don’t care that library routines that they call have preserved flags – but they call them in an APCS-32 compliant way, using BL whatever or MOV r14,pc; MOV pc,r_whatever. Using ADR r14,... to create a return address will not put the PSR in r14 so will fail on return in non-USR modes: remember that ADD rd,pc,#offset presents the PC to the ALU with the PSR bits zero. You could use

MOV.cc  r14,pc ; This DOES put the PSR in r14
ADD.cc  r14,r14,#calculated_offset_to_desired_return_point
B.cc    whatever

Am trying to 32bit the modules in ,!SVG converter

Oh boy.

The 32 bit CLib won’t load 26 bit code. It requires 26/32 neutral. So in order to get things working, you’ll need to completely disassemble the module (Armalyser) and then either patch in the 32 bit library stubs, or a 32 bit aware StubsG (if it uses that), and then tidy up the mess (given that the 32 bit stubs are much larger, and the tables may have some things in slightly different places?).

To echo what Stuart has said, is the module linking itself with CLib using SharedCLibrary_LibInitModule or SharedCLibrary_LibInitModuleAPCS_32? Here, I’m talking about the former case, as would be expected for a 26 bit something-or-other.

It can be done, but after looking at the scope of what was involved I decided that I didn’t really need the module I was looking at that badly.

As Rick says it can be done, but its far more scary than re-stubbing application C code, as being in SVC mode any mistake results in a hang of the machine, and its very difficult to find out why.

It is certainly Fun & Games – and some entertainment :-))

I see the fix in the sources “Increase the max work area for internal images to allow 8k x 8k.” though with Cameras already offering 6960 × 4640 that doesn’t seem to future proof the update for long.

It appears that you could just change the value of max% in the BASIC source if you need to work with a larger image (for example, 1024*1024*1024 for a ‘16k’ image). But I haven’t tested this, and it may exceed a limit somewhere else if you make it too big.

I’ve discovered a silly bug in !XP1Dr2SVG: any paths with endcaps occurring in grouped objects lost their endcaps, unless there was another path with the same endcaps elsewhere that wasn’t in a group.

Now fixed: http://clive.semmens.org.uk/RISCOS/XP1Dr2SVG.html

If anyone else has already banged into this one, if they’d let me know it could have been fixed before…

Clive, that link leads to the download of a 16KB binary file of unknown type (NetSurf gives it ‘Text’ by default). Would you mind checking whether it’s correct? Ta.

that link leads to the download of a 16KB binary file of unknown type

It unpacks OK, provided that you follow the instructions on the website. These are sneakily placed below the download link, so can be overlooked :-)

Correct. Cheers, Stuart! Perhaps I should unsneakify it?

Oh, silly me. I must have unpacked Clive’s software that way in the past, and forgotten. Thank you.

What, by the way, is the advantage of self-extraction over zip when all distros include some version of SparkFS, and no unusual file type change is needed?

What, by the way, is the advantage of self-extraction over zip when all distros include some version of SparkFS, and no unusual file type change is needed?

I guess that it gets around people trying to unpack a zip when not in RISC OS.

All distros include a SparkFS unpacker but don’t (or didn’t when I last looked) include a SparkFS packerupperer, which I don’t have.

a SparkFS packerupperer, which I don’t have.

You could use InfoZip instead.

Cheers, Stuart – I’ll give that a try. If successful, I’ll upgrade the presentation of all those little apps of mine!

Success so far – will report when all updated.

Ah. Here’s the problem. I could give the self-extraction file its filetype if I was uploading it to my website from RISCOS, but I don’t have any direct way of doing that. I transfer it from the Pi to the Mac to upload to my website. Same problem exactly with the Archive file generated by InfoZip.

Same problem exactly with the Archive file generated by InfoZip.

All you need to do is put .zip on the end of the filename after transferring it to the Mac.