Compo returns

In my case the most powerful TX I experienced was when I (for a VERY brief time) I was at an old defence company working in a hanger. They had windows so the fluro tubes on the ceiling weren’t on during the day… except when the radar outside was running. When that was on the tubes lit up and went off in a ‘sweep’ across the ceiling with each rotation of the radar dish. 8-]

More generally, though, the sources we made and used in later years were all in the power levels of c 100mW or less, at or above 60GHz. Less of a worry.

Anyway, the puzzle I have wrt the above re compo is that 1.23c seems needed on my ARMX6+AemulatorPro ro do what 1.23a can do on RPCEmu. That said, t’werks, so a happy day!

> > Don’t think I’d understand much of that, unless pretty pictures…

That’s the point of the pictures! They can help people to understand such topics.

the puzzle I have wrt the above re compo is that 1.23c seems needed on my ARMX6+AemulatorPro ro do what 1.23a can do on RPCEmu

Perhaps 1.23a gets confused about the memory available?

Maybe. Certainly weird! It was encouraging that both the pre-existing compiled-from-C version and a recompile I tried then worked. That should mean I can write similar programs to generate more complicated patterns and they’ll run.

Ideally, though, I’m hoping someone (or a set of someones!) will tackle making an updated version of !Compo that can run on new machines/OS versions without any emulation, etc. Waaay beyond where my have-a-clue range reaches, though! So I can only be pleases that it now works using AP. Just need to simplify the process of setting things up so it works because it needs the helper/support apps as well. Also need to add my own old sidebar scriptlets to the ones that come with 1.23c.

I’ll also see if I can write some new “!Compo Clues” articles for Archive.

It wasn’t so much that the zips themselves wouldn’t open, but upon attempting to load the source files (zips inside zip etc) then any text editor I tried would crash. SparkFS would then report memory corruption.

Was this ever resolved? I have just downloaded a fresh copy of the Demonstration version C120Demo/zip from the iconbar website so I could see what all the interest was, and have had exactly the same problems as Andrew.

I tried just dragging !Compo out of the zip, and it aborted Data Transfer in Module Zip +&404C. Seems to be a LDR r1,[r6,#1] with r6 =&2A2788BC. This was using the latest SparkFS 1.56. After that I got SparkFS Memory Corrupted errors.

After re-starting all SparkFS, trying to edit files with SE from the zip gave obviusly wrong files, or aborts in SE.

Similar problems with other zips downloaded from the compo.iconbar.com pages.

So gave up. Cannot help any further.

RE: SparkFS v Compo.

SparkPlug unzipped C120Demo/zip and 123c/zip just fine here.

SparkPlug does come in handy every now and again when faced with old or “bad” archives. It can be found at the bottom of this page.

It is conceivable (not proven/tested yet) that there may be an issue with SparkFS 1.56. I say this because John B has been chasing a Clib memory leak issue this weekend and tracked it down to a semi-recent change (that may have been SFS related) – fixing that broke SparkFS. It is too early to say, but with both Martin and myself having issues on different OS versions… there’s cause for investigation I reckon.

Annoyingly, I ended up on 1.56 because my finger slipped and 1.46 got overwritten. I need to dig into my backups to do some side-by-side testing. I don’t recall ever seeing those issues on previous builds, but it is easy to wear rose tinted specs!

SparkPlug does come in handy

Gosh yes! So it does. I had forgotten that. Not really used it since DavidP himself said to me 9 years ago: SparkFS is vastly better than SparkPlug, everyone should use it.

FWIW I’m using SparkFS 1.46 and don’t get the problem with the Compo zips that Andrew then encountered. I’d checked the zips before I sent them to Andrew and they seemed fine here. So I was puzzled by his problem.

I’m using SparkFS 1.46 and don’t get the problem with the Compo zips that Andrew then encountered.

I can second that. SparkFS1.46 is OK with the Compo zips. That seems rather odd, what has changed to ‘break’ SparkFS 1.56.

John B has been chasing a Clib memory leak issue this weekend and tracked it down to a semi-recent change (that may have been SFS related) – fixing that broke SparkFS.

See here: for that issue. I tried a build of both a Titanium ROM and SparkFS 1.56 with that modification and SparkFS failed with the “not enough memoory (sic) for io buffer or the like” error.

SparkFS is vastly better than SparkPlug, everyone should use it.

That is correct but not exactly always.

SparkFS 1.46 is here at the bottom of the page

The comp/decomp of zip files is done by the zip module contained within the modules directory in !SparkFS. The zip module has certainly changed. SFS 1.46 has zip module v. 1.44 (8 Feb 2016), while SFS 1.56 has zip module v. 1.51 (29 Apr 2023). One could always try putting the 1.44 zip module in to SparkFS 1.56. Does that work on the Compo zips?

Another thought. From the SparkFS manual.

*Commands
*ZipUseCentralDirectory <1|0>
When used with a parameter of 1, this will make the Zip module use the Zip central directory on loading Zip files. The main advantage is that this is much quicker than scanning the distributed directory (or file headers). The disadvantage is that the Central directory must be both present and in agreement with the rest of the file. Using 0 for the parameter will revert to the extended catalogue.

In other words if you have problems with some Zip files it may be worth turning off the use of central directories.

It appears that recent versions of SparkFS default to central directories being on. Look at the zip obey file in !SparkFS.AutoRun to see if it is on in your version.

One could always try putting the 1.44 zip module in to SparkFS 1.56. Does that work on the Compo zips?

Using SparkFS app 1.56 Zip module 1.44 is indeed OK with the Compo zips.

ZipUseCentralDirectory <1|0>

Both SparkFS apps 1.56 and 1.46 use ZipUseCentralDirectory 1

Using SparkFS app 1.56 Zip module 1.44 is indeed OK with the Compo zips.

So something has changed in the zip module.

ZipUseCentralDirectory is set to 1 in AutoRun here, but when set to 0 SparkFS is better with C120Demo/zip, but still aborts on some files.

I think I’ve discovered what is happening with SparkFS here.

The C120Demo archive was created using the obsolete “Implosion” compression technique. The ability to create archives using this technique was removed in 1997 (SparkFS v1.31), but until v1.46 SparkFS could unpack such archives. This facility is no longer present from SparkFS v1.51 onwards, hence the failures.

So I was fortunate in being able to access what Rob sent to me! Simply because I went on using an ‘old’ version of SparkFS.

Age has its advantages. :-)

The C120Demo archive was created using the obsolete “Implosion” compression technique. The ability to create archives using this technique was removed in 1997 (SparkFS v1.31), but until v1.46 SparkFS could unpack such archives.

Sounds like opening in v1.46 and saving into a new archive with currently supported compression would be good idea

This facility is no longer present from SparkFS v1.51 onwards

The commit message for 1.51 doesn’t mention removing anything, so it’s probably best to assume that this is a bug.

Bug raised for the SparkZip problem.

Back to !Compo.
I don’t know if you followed this thread,

https://www.riscosopen.org/forum/forums/11/topics/19297

Version 123c was written to work on RISC OS 32b and it works very well.

For information, I also had problems with !Compo archives and
!SparkFS : SparkFS memory coruption.

I spoke too quickly… the scripting problem is resolved, but there are other bugs for example with the “Lightness” button.

FWIW I’ve only recently switched to using 1.23c and am still not familiar with all the changes and additions since the earlier version – which I think lacks the ‘lightness’ button. Hence as yet I’ve not ever used it!

OK, as a test I have put something here:

http://jcgl.orpheusweb.co.uk/Compo/JimPlot.zip

That is a zip containing the ‘JimPlot’ test of composcript with Compo 1.23c.
It plots the field pattern around a short ‘dipole’ element of an antenna. Here it plots well over 100,000 points in one or two seconds. Open the zip/dir and DND the “call-jimplot” file onto the compo canvas.

http://jcgl.orpheusweb.co.uk/Compo/Archive-1-6.pdf

http://jcgl.orpheusweb.co.uk/Compo/clues.html

FWIW The above are the old ‘clues’ series I did for Archive. IIRC I did some more articles for Acorn Publisher as well. I’ll see if I can find them.

The commit message for 1.51 doesn’t mention removing anything, so it’s probably best to assume that this is a bug.

However, the later module is over 4kB shorter than the earlier one!