RPi5 out

All of this is already done.

I imagine this needs a rewrite of the window manager on linux/freebsd.

There is already a RISC OS like WM: ROX.

Then it needs as many RISC OS SWI calls as possible veneered into the host os.

Some work were already done around that. Else you have the emulator path.

Then you build a basic interpreter for that environment.

There are at least two excellent BBC Basic interpreters for Linux.

Then you might have an environment where apps written in C might be recompiled for the host os while still thinking its RISC OS

Why? Standard Unix libraries are much more rich and consistent then the RISC OS offer.

Now, with all of this, most RISC OS users can switch to Linux. And guess what: they did, a long time ago. Of around 200 French RISC OS users, there are only 3 left. Jean-Michel, Rick and me.

It’s an efficient way to kill RISC OS as a separate computing platform, making the nimble ~238KB RISC OS micro-kernel run on top of the Brontosaurus-like 1.2GB(!) Linux kernel through emulation.

Somebody with good insight into OS development and writing emulators should look at the logistics here – what will make most sense, require the least work and ensure long-term survival – mixing RISC OS in with the Linux bug-mountain vs. “cut the umbilical”, go 64-bit with full 26/32-bit emulation of legacy software (which afaik even the 32-bit RISC OS version doesn’t have) and a modern user-friendly SDK? It’d still have a micro-kernel and guaranteed out-perform any mainstream OS out there, provided multi-core and multi-threading support is added – it’d fly.

Using a work-from home model with proper management in GitHub could bring out 64-bit RISC OS in a few months, provided mostly pensioned RISC OS C/assembler programmers could be engaged and be paid from RO64 sales. Is this something to work with?

So from my perspective, I’ll never be using a Linux-based emulator until it can be guaranteed never to make Linux visible. I used Unix (SunOS 1.4) many years ago for work, which I didn’t find too bad, but tried Linux (Ubuntu) a few years ago, and found it impossible to get my head around. It seemsd to have a random mix of gui tools, and config files to edit, with no apparent rationale behind the choice. After I totally failed to get printing working to my network printers, I gave up on it.

So an emulator would need to completely hide Linux for me to be comfortable with it.

I do use VRPC, but only when I have to, off site with just a laptop. It’s mainly so I can use Pipedream anmd Cashbook. For the rest of my needs in that situation I use Windows – Firefox and Messenger Pro for Windows in the main.

Mickysoft Arm-support is pretty flakey. A 64-bit version of RISC OS could possibly use all the latest libraries supporting graphic standards, wifi, latest USB, ditto HDMI – a clean break with the obsolete (in a desktop/laptop sense) 32-bit Arm architectures, but have full support for legacy software using these architectures.

The RO WIMP/desktop-system can mostly stay the same visually and functionally, but software written with a new 64-bit SDK could take advantage of all the added wifi/USB etc. functionality. So 64-bit RO would for all practical purposes be a brand new modern operating system – I think it deserves that fate.

Emulated software running at very high speed, native 64-bit software – lightspeed. Keeping the micro-kernel with added support for multi-core/threading would ensure that. Device standards (wifi, USB..) could be handled by relocatable modules. So the changes would be more functional than structural. Anything wrong with this approach?

making the nimble ~238KB RISC OS micro-kernel run on top of the Brontosaurus-like 1.2GB(!) Linux kernel

1.2GB?!?

All of my IP cameras run some sort of Linux. Most of them on RALink MIPS hardware. Most of those with about 64MB of memory (and maybe half that in flash).

Just because you can make a kernel that is vast and features three different kitchen sinks to choose from…doesn’t mean that it is necessary to do so.
(for example, isn’t the Raspbian kernel about 22MB?)

could bring out 64-bit RISC OS in a few months,

<spits tea across the room>

provided mostly pensioned RISC OS C/assembler programmers could be engaged

I have about this much inclination to learn a new ISA (holds fingers together).

I’ll be looking at emulation, but I guess the problem is that I’m old enough and crusty enough (though far from being a pensioner these days) that the hardware that I have now may well be the last actual ARM silicon that I ever run RISC OS upon.

and be paid from RO64 sales

Translation: “make my dreams come true for free”

until it can be guaranteed never to make Linux visible.

My opinion of Linux isn’t much better than yours, however I’ll tolerate the least necessary to start itself up and kick over to the RISC OS environment.

That being said, Linux will never entirely go away. There will be issues. Like eccentricity with the file types, the rather alien concept of case sensitive filenames, and…

It’s an efficient way to kill RISC OS as a separate computing platform, making the nimble ~238KB RISC OS micro-kernel run on top of the Brontosaurus-like 1.2GB(!) Linux kernel through emulation.

Who the hell cares?

RISC OS is a desktop operating system not an embedded OS on a microcontroller, it is no longer important that it runs efficiently on an 8MHz ARM2 with 512K of RAM. Even the smallest SD card you can still buy is big enough for RISC OS and every RISC OS application ever written. RISC OS leaves most of the memory of even a 512MB Pi sitting around completely unused, not even using it as a cache. This is one of the reasons it is far slower than Linux for most things on the same hardware, there are plenty more.

A 64 bit multi-threaded RISC OS could be the fastest OS out there, but with zero native applications running on it, no one would give a flying fsck.

So RISC OS will in a short time be pure history, like Amiga and Commodore. A French guy wrote in some thread on this forum that French RISC OS users had dropped from 200 (in it’s heyday?) to currently 3 – a ~+98% drop. If this is representative for other countries RISC OS is in a free fall to oblivion since the market disappeared except for a few 32-bit-ingrained fanatic hobbyists.

Thus fades the best, most productive and user friendly Operating System I’ve ever used. Which is a bugger on steroids.

The “Help me RISC OS-Wan Kenobi, you’re my only hope” plea is about as useful as raising the Titanic to bring back luxury transatlantic travel.

It would be nice, but having started with “all it needs is a bit of a 64bit update”, and moved on to “and magically, the 64bit update will support everything that doesn’t work yet, whilst still allowing all old software to work and cause the 2nd coming, all in our lifetime”, making some sort of bare metal or extremely small host OS which then runs a consistent and well defined container seems vastly simpler and less likely to cause more headaches.

Seems counter productive to have a spanky new 64bit OS where all the software is emulated.

So RISC OS will in a short time be pure history…

RISCOS is already pure history, apart from being used by a few of us old farts who use it in preference to climbing new learning curves unnecessarily. Oh, we’ll climb necessary learning curves as the need arises, but while we have hardware that RISCOS runs on and familiar software running on it, we’ll use it for what it’s good enough at. And in my case at least, and I suspect almost all (or very possibly quite all), we’ll use other systems for other purposes.

Who the hell cares?

I care about how generally responsive and snappy RISC OS is, amongst its other virtues.

This view makes a lot of sense. +1

I get the general feeling that the people who use RISC OS as their daily driver tend to know that it’s not the end of the world with the arrival of 64-bit-only hardware.

When we look at this thread and others, it’s good to know you can run RISC OS on various platforms, from the Raspberry Pi, OrangePi, and Pinebook Pro—Apple Computers, including potentially anything that runs Linux or Windows.

It is also heartening that people are looking at various solutions to keep RISC OS running well into the future.

I have been reading this thread with bemusment.

@Sveinung
RISC OS does not just run on 32 bit Raspberry Pi’s, it now supported on the RockChip SK3399 as well and that will be available for a fair few years yet. Indeed Pi 4B will be in production till 2029 apparently. Plus R-Comp announced that they had it on a Orange Pi as well at last week Zoom Club meeting. So we really have no immediate panic. I understand both ROOL and ROD have been working out ideas how to move us 64 bit RISC OS.

Oh another correction 26 bit software is still supported via the use of Aemulor on 32 bit only RISC OS.

So please stop all this scaremongering it does not help the market.

We might well get a middle step of emulation at some point in the move to 64 bit.

So… Shiny new 64 bit OS, that runs all the old apps, potentially better than the current incarnation, done from the ground up in a few months as a volunteer effort by a group of pensioners, the return of the Messiah, peace on earth, etc.

I can’t help but feel that this tick list is getting out of control. Y’all wanna rein it in a little and aim for what’s actually possible rather than the fantastic?

Mr. Hughes, you got your quote above wrong (@Sveinung); I didn’t write that. Cut back on tea a bit, maybe? :)

It was not a quote but a response to your nonsense.

Since when did it become nonsense to hope that one’s favourite computer platform don’t meet the same fate as other minority platforms? That reply is just daft. Look for long-term solutions, not defeatism masquerading as spite. If this means bringing in pensioners who both have the necessary experience and a love for RISC OS, so be it. Everything isn’t peachy in RISC OS-land with its shrinking borders, lack of real development and a severely reduced user base.

A “tabula raza” rewrite taking advantage of modern ARM CPU/GPU functionality with as mentioned brand new SDK and legacy emulation will naturally entail a brand new OS under the hood, but with the WIMP system intact since it’s brilliant and don’t need much fixing.

The main issue is the transition from an OS mostly written in old Arm assembler code (unportable) to an OS written in pure C (portable and maintainable). That’s the only option for a new lease of life for good old RISC OS in my book. Let’s just hope that most useful RISC OS software are written in C and not asm so it may be ported. ..which may not be the case.

Mr, Sememens, at 59 I’ve become a pretty old fart too. And learning curves aren’t equal to specific functionality. Doing mixes of colour -gradings with graded transparencies on an object using!ArtWorks is a breeze, but not a function in Libreoffice Draw or Inkscape as far as I’ve looked/found. An the RISC OS (WIMP) has the best flow in the Work Process I’ve ever encountered. As a GUI it should be a winner – it’s the stuff beneath it (Core/RMs) which is in dire need of serious updating and RM expansion to support new devices/standards.

In short, bring it into the 21st Century with a song in its heart.
I think the Acorn Computers fellows who created it would approve of their creation taking this both bold and necessary step, not too early?

I recall we previously wanted a risk4all.

Heh, the only snag is that some mistake RISC OS for RISK OS.. the only logo-related item I’d like back is the green acorn with a little twig beneath it. Maybe render it in 3D, make animated GIF (can it be done with Sprites, ok) and make it spin or tumble when pointer is over. Just a jippo and could be configurable, not to put the RISC OS’ Desktop’s basic air of so(m)berness at risk.

This was a longt thread that I am trying to follow.But to be short:

Everything is possible and there is no rush!

Posted from the november owb snapshot. Invite to get OWB is still open!

don’t meet the same fate as other minority platforms?

I’m not convinced that this fate is as bad as you suggest. As well as developing for RISC OS, I also create homebrew for the Nintendo DS, and the scene there is doing pretty well – possibly better than ever before. This is despite the fact that all models have been discontinued, and that the most recent one was released 13 years ago. Other consoles are still getting new releases after 30 years despite the underlying hardware not changing. If RISC OS is struggling in any way, it’s not because we don’t have the absolute latest hardware to play with.

it’s the stuff beneath it (Core/RMs) which is in dire need of serious updating and RM expansion to support new devices/standards.

Based on what you’ve said previously, it sounds like you’re less interested in RISC OS as an operating system, and more as a GUI and a way to run specific applications. This makes it confusing when you put down Linux or the idea of running RISC OS on top of it. The thing to bear in mind is that the reason a lot of applications on RISC OS are fast is because the limitations of RISC OS make it quite unforgiving towards applications that aren’t. 1GHz processors weren’t a thing for a significant portion of RISC OS’s existence, VFP support isn’t widespread, there’s hardly any hardware acceleration support, it’s necessary to manually yield to the operating system, etc. On other platforms it’s forgivable to ignore limitations like this even if it makes things sluggish on lower spec machines. On RISC OS, you can’t get away with that kind of thing without more significant consequences. In other words, you can write software for Linux that’ll work equally well as on RISC OS – it’s just that most people aren’t bothered by it.

Which leads to a bigger question I have: What do you want to do with RISC OS? Never mind about having to replace your current device in when it dies, or about bringing anyone else to the platform. What are you doing on RISC OS right now, and what are you prevented from doing that’s specifically because RISC OS is specific to AArch32 and not anything else? Most RISC OS users are happy with what we already have in terms of software and that’s why fewer people are insisting that we move to AArch64 as soon as possible. As such, it would be helpful to know what you’re doing with RISC OS and why switch to AArch64 would benefit you personally.

That’s a good question; I want to use RISC OS to do the things I’m forced to do on other platforms, because RISC OS does not have the technical underpinnings or breadth of applications, and never will.

There’s two things we love about RISC OS.

1. The way the RISC OS desktop works
2. The applications we know and use

The vast majority of applications are never going to be re-written for an even modest changes to the OS such as pre-emption or multi-threading, never mind a completely incompatible 64 bit version, but they will continue to be used under emulation in some form.

The RISC OS look and feel is what is left and if that could be transplanted to another platform, it would allow most of what was so innovative about RISC OS to live on in a meaningful way, and even gain exposure. It would need to be done as not only a customised window manager like ROX, but modifications to a full suite of desktop applications such to give a consistent environment, such as that provided by MATE or Cinnamon desktops on Linux Mint. It’s a lot of work, but not nearly as much as designing a new OS and writing the applications from scratch, but I don’t know we have enough people with the necessary skills for even that.

Linux’ X-Windows system does not support a 3-button mouse which RISC OS’ WIMP system does (sel-men-adj) which is a main factor to its fundamental user friendliness and productivity. Does any other platform?

You’ve got no bloody clue, X has always supported 3 button mice, and can be made to do whatever you want.

CDE on Solaris (which I’m pretty sure runs under X) even called the buttons Select, Adjust and Menu!

Do they. Never used the Solaris system nor X in Linux with a 3-button mouse. So nice of you to clear that up.

Guess it’s the totality of RISC OS WIMP system which makes it what it is. It’s the stuff beneath which is lagging a decade or two behind.