AROS (AmigaOS) is now 64-bit

It’s not very fresh news and it’s still at an Alpha stage, but it’s done. Working on the x86 architecture with talk of porting it to ARM (!), it can now be said to be a modern operating system fully using modern CPUs.

One may argue that the global Commodore Amiga user base is at least 10 times the size than the Acorn RISC OS one ever was and hence has a larger programmer milieu to draw contributors from, but going 64-bit ensures survival, they understand that.

Since the British RISC OS milieu hasn’t manages to do this in a quarter of a century, staying 32-bit even after the latest ARM architecture revision dropped support for 32-bit mode, one wonder if it’ll ever happen. If it does, I guess it’ll be a German initiative, bringing the platform out from the 20th Century into the 21st. And capable of fully using the most modern ARM CPUs and GPUs. Evolution.

That’s the perfect example of why a 64bit version of RISC OS is not for tomorrow.

As you said, AROS is still at an alpha stage, after 29 YEARS of work. Since it’s a rewrite in C, yes, it’s more portable than before, even if most of the ports are even not in alpha stage.

And it’s absolutely NOT a modern operating system : still no robust enough preemptive scheduler system, still no memory protection, still no multicore support, etc.

That’s really a VERY bad example.
You wan’t a better one? HaikuOS.

but going 64-bit ensures survival, they understand that.

No, absolutely not. The only “present” of AROS is:
- on old PPC computers with a closed source (dying) derivative (MorphOS).
- on 68k computers (Apollo & the Amiga 600GS).

The 68k Amiga is coming back, because that’s were the market is.

Are you saying that RISC OS doesn’t have a bigger potential than that, going 64-bit?

https://openhub.net/p/aros/estimated_cost

1949 person years of work, amounting to about $100M at a $50K salary. And it’s still not finished.

Regarding “survival”, all of the non-68K ports have an emulator so it can run Amiga software. Because an OS without software is a toy.

Note, also, that it targets multiple different platforms. That is better for survival than banging on some “What do we want? 64 bit! When do we want it? Right now!” drum.
Why? Because 64 bit doesn’t bloody matter and for the average RISC OS user is unlikely to make any actual difference.
I think you would need to come up with contrived examples to say why going to 64 bit would be such a great thing.
Processor independence is what will assure a future. Because if done sexy new chip comes along (with a datasheet), you just need to write the glue code, maybe fiddle with the low level drivers for the specifics of this new thing, and just recompile the rest.
Okay, it’s not quite as easy as that but it can be done. AROS is sort of there, Linux is a master of this.

Programming languages matters. Back in the day with the 4 MIPS ARM2 it made sense to write RISC OS in Assembler to squeeze every bit of performance out of it, but at the same time locking it to one CPU command-set, one kernel.

With today’s CPUs being that much faster and multi-core to boot it makes sense to write OSes in C for the sake of compability with newer CPUs and their changed command sets – they’re moving targets.

This is the reason I’m harping on the “rewrite RISC OS in C” issue – then it can run on the fastest ARM CPUs and GPUs out there, become more attractive to more users, which is a necessity for the platform to survive, possibly turning the trend of users leaving RISC OS in droves. Face it, 32-bit is out.

Are you saying that RISC OS doesn’t have a bigger potential than that, going 64-bit?

64bit does not mean modern.

This is the reason I’m harping on the “rewrite RISC OS in C” issue

As every RISC OS developer. But guess what? To rewrite all the components in C will take time. Probably decades.

And when all the OS will be available in C, that will not solve AT ALL the 64bit problem. That will just ease it.

then it can run on the fastest ARM CPUs and GPUs out there

No, sorry, but being written in C does not mean working on the fastest CPUs and using the whole power of latest GPUs.

HaikuOS is a 64bit system, written in C++. And no, it doesn’t support magically GPU and NPU. There is also a 32bit version of it. And no, it isn’t less modern than the 64bit one.

You leave in confusion.

And you don’t even know what is AROS today.

Which method would you suggest to turn the ongoing trend of RISC OS users leaving the platform, then?

Acorn Ltd. didn’t spend several years developing RISC OS 2.0, after all.

Which method would you suggest to turn the ongoing trend of RISC OS users leaving the platform, then?

Ongoing? Pretty much the only people ceasing using RO currently, like the last few years, are those who have sadly departed this plane of existence.
Generally, the trend seems to be returning users and small numbers of new users.

It’s never going to blaze a trail and wipe out Windows, Linux etc. but some people like it.

While we have questions on the go, when are you going to do anything useful? Or do you have your less than zero-sum already planned?

You leave in confusion.

We can dream…

Acorn Ltd. didn’t spend several years developing RISC OS 2.0, after all.

Arthur – 1987.
RISC OS 2 – 1989.
RISC OS 3 – 1991.

So, yeah, they kind of did spend several years on it. The dev team had five months to create a port of the BBC MOS, which became Arthur.
It then took a further four years to get it to something that behaves like the RISC OS we know today (actually longer, as 5 is really the scion of 3.7; but the biggest main leap in development was bringing 3.1 to fruition, so we’ll count that as a logical progenitor).

One doesn’t pluck a ready made OS from out of their arse. It’s hard work to make it happen and – more importantly – do it right. That’s why somebody like Linus Torvalds is a tech superstar and you…just aren’t.

Which method would you suggest to turn the ongoing trend of RISC OS users leaving the platform, then?

First, I don’t especially want this to happen. Even OSes have a begin and an end.

IMHO, we have two potential markets.

1/ Embedded or low cost ARM boards, where Linux isn’t so efficient. So I will bet more on Bluetooth or faster networking than on 64bit. Just to get – at least – a good offer for the Pi0 and similar devices. I would love too to be able to use hardware debugging ports to debug RISC OS things running on one device from another (RISC OS?) device.

2/ Geeks and retrogaming, with the best of the best of the Acorn world. Would need probably to add a very optimized port of RPCEmu (to be the most complete solution to run current and past RISC OS software), and probably a port of BBC Basic for SDL 2 (to be the ultimate BBC Basic programming platform).

For the high-end workstation market, we are lucky to be able to run RISC OS on the Pi4. Perhaps, with a lot of efforts, that the Pi5 could be reachable. And then? For me, an AARCH64 JIT for RPCEmu (Raspberry Pi OS + macOS) and a KVM/Qemu port (for Pi5 and more) would be OK. I really do not ask for more.

Anyway, the next Pi0 will be compatible with RISC OS, and perhaps even the next one. So we’ll have fresh devices for at least a decade, on the Pi side, and at least two or three decades with other companies.

Workstation and server market are definitively lost: we are so far away from AI and cloud platforms. On the end user market, mobile devices promise to replace almost all classic computers (isn’t it already the case?). Except for some games, all RISC OS applications are irrelevant on mobile devices. So our platform is DE FACTO phased out of theses 3 markets. 64bit or not. GPU support or not. RISCV support or not.

Embedded, geek and retrogaming markets are still accessible.

Nota: all of this is IMHO. Developers will follow their own roadmap.

And to correct one point: ARM 32bit isn’t out AT ALL. It’s out on the Cortex-A, designed for high end devices. High end devices where RISC OS is totally irrelevant, as it can’t compete with Linux, Android or Windows (and will never do, as these platforms move much faster than our). I wont bet a penny on this market. But, yes, we can dream. See the (little) comeback of the Amiga 68k, just because of the hype around the new version of Octamed. Musician geekery.

ARM 32bit isn’t out AT ALL. It’s out on the Cortex-A, designed for high end devices

See how far you get running RISC OS on a MMU-less chip.

RISC OS 2 – 1989

A pedant writes Sep 1988. Plebs didn’t get their hands on it until 1989.

See how far you get running RISC OS on a MMU-less chip

Correct. But are we sure there will never be some MMU on other Cortex lines?

On the other hand, the project that converts the Pico into a Palm Pilot shows how you can use a low level JIT layer to add what you need to your processor.

http://dmitry.gr/?r=05.Projects&proj=27.%20rePalm

A very interesting project.

Still off topic. On Cortex-M, memory is often external memory. So if you use PSRAM, you must 1/ support it on the OS and its apps or 2/ emulate a memory management unit.

This can be quite fast, using second core, local memory for cache and some tricks, as DMA:

https://dmitry.gr/?r=05.Projects&proj=33.%20LinuxCard

The real problem IMHO, is that Cortex-M does not support non Thumb mode. Perhaps one day (after all, Cortex-R is making some slow transition from ARM 32bit without MMU to ARM 64bit with MMU).

Anyway, on Cortex-M, I was more thinking of a cut down version of RISC OS, CLI only and mono task only.

The fact is that 32-bit RISC OS can only use a small percentage of the full potential of those ARM CPUs it can run on, and not at all on the latest architecture revision.

Correct. So the 64bit version will probably use only a small percentage of the full potential of the 64bit processors too. Good point.

The fact is that 32-bit RISC OS can only use a small percentage of the full potential

Yup. A quarter of a quad core, so about eight bits by my reckoning. 😂