PlingSystem and RISC OS 3.1

Inspired by the news that the self-extracting SparkFS will now unpack at RISC OS 3.1, I tried installing ROOL HardDisc4 and PlingSystem under RISC OS 3.11 (using ArchiEmu). To avoid any possible HostFS issues, I installed everything on an emulated 64MB ST506 drive.

Things didn’t go well.

Firstly, boot-up failed with “Undefined instruction at &01822994”, leaving me at the Supervisor prompt. Entering *Desktop only got me so far, as it quickly became apparent that !System hadn’t been “seen” properly. Opening a filer window on !Boot.Resources caused another “Undefined instruction” error to appear.

I gave up trying to boot from the new !Boot and switched to examining the contents of !System.310.Modules. Three problems stood out:

• CallASWI fails to load (error message “Undefined instruction”). My personal stash of PlingSystem archives only goes back to March 2019, but even the earliest one failed in the same way. The WayBack Machine had an April 2015 PlingSystem from which CallASWI does load successfully: this narrows down the time period during which the bug appeared to only 4 years :-(

• SSound fails to load (error message “nager:Sprites24”). I recognised that as an instance of “the real error message got trampled on by a bug in the error handler”. This problem was also exhibited by SSound in the April 2015 PlingSystem archive. This may be something of a red herring (perhaps SSound expects other modules to be loaded before it starts).

• CLib loads successfully, but with it loaded a wide range of other programs won’t work. The error message is “Undefined instruction” quoting an address some 86K from the start of SharedCLibrary, but as I don’t know how to establish the in-memory size of SharedCLibrary I am not sure if it was inside or outside the module. I need to do a bit more digging on this one to come up with a proper repro, but the number of diagnostic tools I have for RISC OS 3.11 is precisely zero. Any suggestions?

Emulated system: RISC OS 3.11 under ArchiEmu 0.55.0 (17 June 2018)
Host system: Pi4B (RISC OS 5.28, December 2020 build).

Firstly, boot-up failed with “Undefined instruction at &01822994”

I’d be inclined to get Debugger to output memory at that point to see what instruction is actually there.

Keep in mind that, IIRC, the MSR/MRS instructions were carefully chosen to be NOPs on older processors. However, an emulator might behave differently and (incorrectly) report an undefined instruction.

An emulator bug would also be my first guess, since I’m fairly certain I would have tested at least CallASWI and CLib fairly recently (albeit under emulation)

I figured I’d give things a quick test in Arculator (since I’ve recently been using that as my preferred Arc emulator), but that wasn’t as straightforward as I’d hoped:

1. ROOL issue: The newly RISC OS 3.1-friendly self-extracting SparkFS is useless for bootstrapping a clean system, because it needs you to have a !System available containing modern CallASWI/CLib/etc.
2. Arculator issue (presumably?): I fished out an old copy of the self-extracting SparkPlug (2.26). It extracts OK, but it fails to load to the icon bar. After patching the !Run to comment out the “System resources not found” error (an issue that’s plagued SparkPlug for years), running it from HostFS appears to just lock up the machine somewhere. Seems to affect Arculator 2.0 & 2.1 (I haven’t properly tried 0.99 yet – for some reason ArculFS was read-only when I tried doing a quick test, but the readme suggests it should be read-write in that version)
3. Fine, I’ll go back to RedSquirrel (which runs SparkPlug just fine): Nope, on my current Windows machine it’s too unstable and throws random errors within the emulator. SparkPlug will load and extract the disc image + !System, but it’s too unstable to actually test it.
4. Also for anyone tempted to try ArcEm, I’m fairly certain there’s an emulation bug there which is causing modern-ish versions of CLib to fail when trying to start the application part of C modules, causing them to get stuck in a foreground loop somewhere (Escape can quit out of them). My notes say this affects both APCS-26 and APCS-32 builds of the DDE examplemod sample (built using any modern DDE version), running against CLib ~6.16 or newer. But I haven’t yet plucked up the courage to try and debug it. (there are a few other known bugs in ArcEm, but this one seems to be the most serious)

Thanks for leading us towards another can of worms, I guess!

Ironically I just tried it all out on ArcEm 1.50 and… everything worked! It booted to a desktop with a background pattern, SparkFS started up cleanly, and I was able to unpack and create archives. I didn’t give it much of a workout but it certainly seems better-behaved than ArchiEmu.

So it looks like the errors I was seeing are all due to an ArchiEmu bug.

Update:

The SparkPlug issue on Arculator appears to a bug in SparkPlug. You just need to make sure HostFS is selected as the current filesystem before running SparkPlug (assuming you’re running it from HostFS); I was running it from HostFS with nothing in ADFS (no hard disc, empty floppy drive) and that seemed to be responsible for triggering the failure.

If I extract everything under RPCEmu, then manually merge in the new !System (make sure the HardDisc4 version is writable and then copy the PlingSystem version over the top), then copy everything over to Arculator & configure to booth from HostFS, then at first glance everything seems to work OK. I.e. it boots to desktop without any errors, the new CallASWI + CLib have been loaded, and (after upgrading from a 2MB machine config to 4MB), MineHunt successfully loads and runs (so C apps are working, at least).

I haven’t tried extracting everything under Arculator, but presumably that would also work (I did the above test before thinking to check if the selected filesystem was the cause of the SparkPlug failure)

Re: SparkPlug, is there anything you’d like me to fix…

I had to use Arculator recently, and I found that people were being tripped up by SparkFS insisting on System being present when it was never going to use it. The !Run file should be changed at source.

Given SparkFS is now free. I see Spark/Plug as of no further relevance.