RPi5 out

> Surely VRPC’s inability to run RO 5 entirely disqualifies it from further consideration?

Apart from support for modern platforms what other reasons make it more desirable than say 4.39? I use 5 a Pi400 every day with Nettle, Sunfish and Zap and that’s all good but if somebody sends me an image to fix I push that out of the way open the laptop it sits on and fire up VRPC-SA 4.39, Draw and Paint are heaps better there as is the magic automatic image conversion stuff though it would be nice if that learned a few modern formats. The built in apps on 5 seem way behind.

On pc hardware > 10 years old I find RPCEMU to be much faster than VARPC-SA. I even wondered about compiling a version of RPCEMU with path names altered so it could be a drop in replacement but there’s still the HostTCPIP or socket veneer or whatever it is that VARPC networking does that’s different to RPCEMU to fix first.

If we have to emulate then the closer we can get the host native services to our favorite apps the better its going to be. I wonder some days how many apps would actually get broken if they had to deal with a host native filesystem name space. (Assuming that file type metadata is handled).

And that really sums up why emulation is a dead end for RISC OS, OS development. If you are running an emulator, you want the old version of the OS for maximum compatibility.

If we want to have an OS which is being actively developed in some shape or form, but can no longer run natively on the hardware, the term to use is virtualisation,
i.e. running on a non specific virtual ARM machine, which is what the QEMU effort is about. Just a shame that also has the abbreviation ‘emu’ in its name.

Compared to other OS’es RISC OS is so tiny that an Acorn-era RISC OS versions could be patched to work as a RM, snapping up 26/32-bit legacy software and handle all their code. With gigabytes of RAM to spare. This, of course, requires.. guess-what.

This, of course, requires.. guess-what.

Magic?
Aemulor?
A bit of both?

Multi-core, Multi-threading, Preemptive M.T., x2 bitness..

https://www.riscosopen.org/wiki/documentation/show/Addressing%20the%20end-of-life%20of%20AArch32

Yay, 4! :-)

Looking at that roadmap I’m trying to think of which of my publicly available software would still be relevant / I could bother porting to any 64 bit OS.

Yes:-

• DiscKnight is the easiest to port as it is portable C and already runs on 64 bit platforms, I would hope that FileCore is ditched as the primary filesystem format on a 64 bit OS, but no doubt FileCore would be retained for compatibility. The front end being C/Toolbox should also port easily.
• ARMalyser again 64 bit portable C, so no problem but not a huge amount of use being able to analyse Aarch32 when running on Aarch64. Font end being a DDE front end requires no porting.
• WorkSpace I would want it, so I’d make the effort, its C/Wimp so would need some work
• WindOpen crucial to the way I use RISC OS, but an assembler module so would need re-writing, gah

No:-

• TimerMod – this should be in the OS
• GraphTask – most things it runs wont be ported so run them in an 32 bit emulator instead
• SWIstat, APPstat, SERVstat, VECstat – rely on assembler modules, not useful enough to bother
• CPUstat – uses APPstat module so unfortunately not
• Countdown – have much better command line versions in multiple languages, so can’t be bothered with a RO front end
• FreeMap, Gamma, CTenhance, *eject modules – all obsolete crap

And no, I’m not converting any of the dozens of 3rd party 26 bit applications I ported to 32 bit on to 64 bit, even where I have the sources, not enough time or interest.

Yes: Fireworkz. It already can run natively on x64 Windows (although the distributed version is x86). Would want AMU+Norcroft though. If gcc, CMake, forget it.

Maybe: Fireworkz Pro. Depends on Datapower engine being ported.

No: PipeDream. Would be too much work.

[Edit: Is it worth someone creating a thread where software authors/maintainers could indicate what, if anything, they’d be interesting in migrating to AArch64 ‘RISC OS’ if ROOL came up with the goods?]

Me: Probably nothing. Most of my stuff depends upon DeskLib – and I can imagine it would be quite a bit of work porting that to a new API, not to mention dealing with the differences, which will be legion.

If I was twenty-something, I’d be up for the challenge as an intellectual exercise. But I’m weeks off turning fifty and, honestly, I don’t think I have the time or concentration to learn a new API ¹ and new CPU when there’s still plenty to do with what I’m familiar with. I’ll probably stick with the 32 bit OS for as long as it’s useful to me.

¹ If I was going to teach myself how to handle a new OS, it would probably be some incarnation of Debian…

If I was twenty-something, I’d be up for the challenge as an intellectual exercise. But I’m weeks off turning fifty and, honestly, I don’t think I have the time or concentration to learn a new API 1 and new CPU when there’s still plenty to do with what I’m familiar with. I’ll probably stick with the 32 bit OS for as long as it’s useful to me.

At just turned 74, that’s pretty much how I feel about all this too. Everything I want of RISCOS seems to work just fine, and far faster than it ever did before, with far bigger files, on my Pi4. Of which I have a spare, and a 3b which also works fine. Those beasts will probably outlast me.