RPi5 out

Interesting remark about arm 64 v arm 32 on Rick’s site.

So we’re all agreed then
- RISC OS on Linux is the way forward!
(^_^)

bq.So we’re all agreed then
- RISC OS on Linux is the way forward!
(^_^)

Sir, thou art pulling my leg.. seriously, I’ve give my opinion on that issue. Making RISC OS Yet Another Linux Desktop is pointless – it would only contribute to kill RISC OS as a full operating system. It’s 64-bit or toast within this decade.

It may be that updating and extending many of the relocatable modules plus develop fully transparent emulation for legacy stuff is the most work-intensive task – the core (tiny as it is) may not pose a big challenge except for adding PMT, multicore support and multi-threading. Not being a programmer I’ pretty certain there will be a rush to point out I’m talking through my derriere here. Though I hope not.

So the main applications I use are Ovation Pro (could be done on Windows), Pipedream, SchemED, Messenger/Netfetch, plus BASIC. With Pipedream I use quite a lot of custom functions, which I really don’t want to have to replicate in something else.

I have a huge software system written in BASIC which makes extensive use of WIMP, filesystem and Network APIs, plus some use of GPIO. It’s origin predated the affordable availability of the toolbox and Dr Wimp, so all the WIMP libraries are home-grown. To move that to a 64-bit platform would require a fully compatible BASIC and a large chunk of the RO 32-bit API, plus Reporter, not just the desktop look and feel. It probably needs case-insensitive filename handling as well. There’s one bit where using 64-bit integers would help though. Doing arithmetic on RO 5-byte times is painful.

one bit where using 64-bit integers would help though

That could be done right now, on all our existing 32-bit platforms.

Making RISC OS Yet Another Linux Desktop is pointless

In this I agree with you. RISC OS as a fully emulated application on Linux, hiding Linux from the user, would be useful. That would allow everything that currently runs to continue to run.

Linux with a desktop that looked like RO would be useless – RO’s usefulness is inthe applications, allied with the user-friendly desktop. Without the applications it’s nothing.

A 64-bit conversion of RO (not realistic given the resources available) would still need to preserve the 32-bit API in addition to a new 64-bit API, otherwise the applications would not run. It would also need a way for 32-bit code to run, since the 64-bit instruction set is incompatible in too many ways. So in effect a 64-bit RO would need an embedded 32-bit emulator. The only advantage I can see is that there would not be a foreign OS underneath it, though 64-bit RO would be pretty foreign.

Finally, some constructive thoughts. Everything I write is from a user standpoint with a focus on desktop publishing and illustration (print/web). The software I used – Impression Publisher, Ovation Pro, ArtWorks, Vantage, Photodesk, TopModel – were brilliant both by themselves and in conjunction with each other.

My private “64-bit RO campaign” may not be 100% realistic seeing the downward spiraling of the RO market versus the substantial funding this whole transition would need. But RO just as it is, 32-bit, is still a leader in productivity bar the lack of development to support new printing systems and device drivers. Maybe that train has gone, the Dopplerd flute fading away. Still, for the sake of platform plurality if nothing else, I wish it’d happen.

Sir, thou art pulling my leg..

Yes, indeed, thou art correct

seriously, I’ve give my opinion on that issue.

but seriously, why do you have to repeat your opinion so many times?

I disagree with you that RISC OS on Linux would kill off RISC OS
- my opinion is quite the reverse

The biggest challenge facing RISC OS currently is that Arm CPUs are dropping native 32-bit support
- so, for old-timers who just want to run on h/w upto an RP4, that’s fine
- but if you want to run RISC OS on anything after an RP4 (A72) generation of product, there needs to be a way of running the 32-bit RISC OS in user-space (i.e. EL0) on h/w that doesn’t support 32-bit in the OS
- e.g. RP5 or Rockchip RK3588 based SBCs

Or go down the pure emulation route of RPCEmu (which way well be acceptable in a lot of use-cases)

So, one way (but by no means the only way) of achieving this would be to progress the Timothy Baldwin RISC OS on Linux project
- it seems like one of the few realistic ways to allow RISC OS to run on modern h/w

Dreaming of an ideal solution is all very well, but, as others have pointed out, would require far more effort than is available in the RISC OS Community

Have a read of this post (and thread)
- it provides a good overview of the current state of play, and the opinions there upon

https://www.riscosopen.org/forum/forums/9/topics/18863?page=1#posts-144154

Mr, Sememens, at 59 I’ve become a pretty old fart too.

Middle-aged at best.

there needs to be a way of running the 32-bit RISC OS in user-space (i.e. EL0) on h/w that doesn’t support 32-bit in the OS

How long would you imagine we can rely upon a 32 bit world of any kind existing in 64 bit hardware?
This isn’t x86. I would imagine ARM will be keen to ditch it and go fully 64 bit ASAP.
And then what?

As for RISC OS on Linux, I’m not looking forward to the idea as I find Linux to be a massive pain in the arse, however, it is a lifeline. Maybe not ideal for the purists, but the alternative is to say “this is it guys, the end of the road ¹”.
If there are other options, well, now has come the time to start considering them. Linux, a virtual environment written in Python, whatever. The more possibilities, the more ways forward.

¹ I say this only partly in jest as there’s a ridiculous amount that could be done with existant hardware. Like Bluetooth, WiFi, 21st century networking (that is on the way…), GPU acceleration for video, having the DDE compiler support VFP instead of still relying on an ancient bloody emulation, those other three cores……..

How long would you imagine we can rely upon a 32 bit world of any kind existing in 64 bit hardware?
This isn’t x86. I would imagine ARM will be keen to ditch it and go fully 64 bit ASAP.
And then what?

Well, as far as I know, aarch32 in EL0 is supported upto A78 / X1
- eg. nVidia Orin, Microsoft Arm Dev Kit (no longer available?) (based on a Snapdragon 2, I think)

Everything after than is pure aarch64 (as far as I know)

So, there may possibly be another generation of Raspberry Pi with aarch32 support
- depending on when they release the next version
- there was some discussion with Upton about it in the most recent version of Archive, I believe…

Anyway, 2-4 years is the short answer

After that, QEmu’s emulation/JIT, someother JIT?

With regards to Linux, it would be reasonably possible to do a cut down version that booted into RISC OS
- to be honest, I’m not sure if I have the skills to do that (I have done something similar on some actual products, but I’m no expert by any means…)
- others may be better suited to that task than me
- but it’s certainly possible…

Pyromanics may be viable also
- both the Linux and Pyromanics solutions rely on QEmu to some degree…
- so, as others have suggested making sure QEmu is working well would be worthwhile

(I did look at it a little look today, and it seems reasonably understandable, the bit I looked at I mean… Tiny Code Generator )

Pyromanics isn’t (yet) open source though, so, it depends on getting that open source, I would think…

Anyway, I can understand some people not being in love with Linux
- but it does give you a lot
- more than you need
- and, it’s better to have more than you need, than less than you need!

With regards to ‘Kernel-In-C’
- then, yes, it seems sensible to, gradually, over time, move the kernel, module-by-module, into C, shimming all the way, as necessary

That allows easier development going forward, no matter what…

-and when all is done it can be compiled into a 64-bit version. It’d just need the 26/32 emulator.* immediately to have a ready software base, with a possibility to do a new 64-bit user friendly SDK with a 64-bit compiler. Then it’s Arm V9, here we come? Could run fine on the RPi5 too. Thanks for inspiration Mr. Phillips.

• RO3-7-emu? Last stable Acorn Comp. ROM upgrade..

A lot of non sense here. Sorry.

If we make a new 64bit OS, it will be completely incompatible with RISC OS and its applications. The shift will be the same as between BBC MOS and RISC OS. Something a bit similar, but not compatible at all, so the need of an emulator. Do we wan’t to start again from 0? Do we wan’t to leave our 32bit ecosystem?

I will not comment on the fact that making all in C will not solve the 64bit port.
It’ll just ease it (impossible will become possible).

the core (tiny as it is) may not pose a big challenge except for adding PMT, multicore support and multi-threading

Yep, for Linux or BSD kernels, it was just hundred of man-year work. And, sometimes, the giant lock problem is still not fully solved. The Linux kernel has a bunch of features that will be very difficult to replicate. Do not forget this is a 22+ year work, with thousand of developers.

Anyway. What can we do now?

New Cortex-A76-A78 systems

1. The main road is ARM on Linux. Working, but needs to be finished.
2. We could also imagine some 64bit glue to redirect all SVC/SWI needs, for a full native RISC OS on Pi5.
3. Or something between the two (RISC OS for ARM vSphere, RISC OS for Genode…).

Incompatible systems (AArch64 only, x86….)

1. Before doing a new 64bit OS from scratch, emulation is the fast lane.
2. We have already many solutions (RPCEmu, Pyromaniac…).
3. IMHO, a QEMU port + Virtio drivers would be great too. And a good bet for future ARM on ARM solutions.

Market opportunities
There are still a bunch of AArch32 systems coming to the market. In IoT, most systems were based on Cortex-M processors, but the new ones use Cortex-A33/A53 processors. The same for automotive market, where I can see more and more Cortex-A53/A55 processors along the Cortex-R processor. More than half of ARM SBC coming in the market are 32bit compatible, and all the smallest one (Pi0 like).

The current Pi0, and probably the next ones, is/will be compatible with RISC OS. Yes, there are not the fastest ARM boards. But their cost is interesting.

My point
Instead of betting on a different OS for a different architecture, why not making RISC OS the best ARM 32bit OS on the market? For this, a lot of work is needed: multicore support (AMP?), GPU acceleration, USB 3.0, WiFi, etc.

If it’s a good OS, capable of supporting desktop on low end systems, it will be used by a lot of people, because Linux can’t do that (and do not plan to target that). RISC OS can run on 20 euros systems or less. And could work later on 10 euros systems, 5 euros systems, etc.

I’m pretty sure that if there is a market, the Raspberry Pi Foundation will protect it. And ARM too, since they do now own a part of the Foundation. ARM 32bit is not dead. RISC OS exists on it, but needs to become better. So let’s make always more for less.

Dream?
We could also try to go further: microcontrollers. Of course, Cortex-M cores use Thumb code and do not provide a MMU. The rePalm guy manages to add several MB of RAM to the RP2040, and to develop a JIT layer to convert ARM 32 bits to Thumb code. With this, the normal Palm Tungsten T ROM works, at almost the full speed. RISC OS 5 needs an ARM 6 to work, and some megabytes of memory. How much work would be needed to transform a RP2040 in a RISC OS 5 system? How much work would be needed to slim down RISC OS 5 to make it work on 512KB microcontrollers? Perhaps a CLI version only, with Basic support and the same AIF compiled code we use today.

Why this is interesting? 1/ Linux will not going there soon 2/ RISC OS on a sub 1 euro microcontroler, that’s great! 3/ The rePlam guy proved it can be done. 4/ It will be still a system compatible with RISC OS applications. 5/ We could imagine side car projects (Thumb support in DDE to emit full native code) 6/ It will have a lot of sense when ARM microcontrollers will switch from Thumb code to normal 32bit code. 7/ It could attract more people from the retro community.

Nota: if you really wan’t to write a new OS for a new CPU architecturs, it would be better to support all of them with a portable offer, or to bet on RISC V (did you see the 64 core Milk-V system, the Litchee offers? this is an outlook on the future). But good luck to compete there with Linux, *BSD or the excellent HaikuOS. And good luck too to exploit the TPU, because future systems will all be controlled via IA systems. Bye the GUI, bye the WIMP… (even if I will stay on CLI or GUI systems for the rest of my life).

If we are going the emulation route then Virtual Risc PC is streets ahead of RPCEmu and Pyromaniac. Findamentally important is that existing RISC OS applications must continue to work not just those written in BASIC.

I’m a little surprised and my thoughts go to David. We have more hardware than ever available for RISC OS, but we are only using a fraction of its potential. WiFi, USB3, Bluetooth etc. are missing… The development seems to be poorly coordinated, ROD and ROOL seem to be pulling from different sides and not in the same direction…
Maybe I’m wrong, but I’m afraid I won’t see a 64bit RISC OS that I can and want to use in my lifetime. I see the potential of RISC OS in a similar way to David and if everyone involved doesn’t finally get together and advance development together, all dreams will burst like a soap bubble.

If we are going the emulation route then Virtual Risc PC is streets ahead of RPCEmu and Pyromaniac…

Correct. We already have all that’s needed for this, even if I think a QEMU port would be great too, because it’s the core solution for all the biggest efforts around ARM on ARM emulation.

RISC OS on Linux/Genode/HAL64 would be great for current A76/A78 systems. The Pi5, the RK3588 systems, and perhaps the Pi6. But probably the last move on the “always more (power)” direction.

Now we still have the “always less (price, power, resources…)” direction. With a bunch of devices: SBC, tablets, phones, etc. This is a huge market. With the right boards, we could imagine future complete computers (board, PSU, cases) for less than 50 euros and with good performances and a large ecosystem of applications and games.

That’s what RComp (and also RISCOSbits) tries to do: choosing the right processor for the next port to provide new kind of products. Trying to do the good move.RK3399 was a good bet (Pinebook Pro…) and RK3562/3566 seem to very promising, with a bunch of devices coming, low cost / low size. I would love to have, as next RISC OS product, a small portable gaming device (Odroid?).

This is very exciting.

WiFi, USB3, Bluetooth etc. are missing… The development seems to be poorly coordinated, ROD and ROOL seem to be pulling from different sides and not in the same direction…

True for the network stack. But that’s – IMHO – a ‘small’ problem.

VFP support
Done for Basic, done for ABC.
In the ROOL roadmap for DDE. IMHO, it’s top priority.
VFP accelerated FPEmulator still missing.

Large disc support
On the rool roadmap.
Some already propose this.
IMHO, work should be sync with Jon to add big disc formatting support in Partition Manager.

GPU acceleration
Dead end for now. That’s sad.

Multicore
Jeffrey did some work around this.
I would love to be able to do light threads (IE with limited API) on other cores, from Basic or DDE.
A CLI Tube like system would be great too.

I really like also the work of Michael (?) around BSD/RISC OS systems that can run on other cores.
For me, it’s could really be the roots of an AMP implementation.

So, all is slow, because of the lack of resources, but this is not a lost cause. IMHO, the problem is not on the RISC OS side, but in the actual world. The counterpart of the massive crisis coming is that everything is accelerating up to the limit, and we really have no time left for anything. It’s really a problem, but it’ll probably break soon.

RISC OS on FreeRTOS could give you a lot of what you want
- support for many different microcontrollers but with support for bigger CPUs as well

RP3B
https://github.com/eggman/FreeRTOS-raspi3

RP4
https://github.com/TImada/raspi4_freertos

Support for multi-thread, multi-core

A lot of non sense here. Sorry.

Don’t apologise. Some of what’s been posted here is comically ridiculous.

VFP support

The reason my ray casting code was written in BASIC was precisely because the ABC compiler (which isn’t exactly a clever optimising compiler) could spit out VFP code that flew.
Or, to put it in different words, the DDE’s continued reliance upon FPEm is embarrassingly bad.

The shift will be the same as between BBC MOS and RISC OS.

This. Without emulation, it’ll be “something new that sort of resembles the OS we know”.

Yes, there are not the fastest ARM boards.

Is this even a relevant point when there are three cores doing nothing on most boards? A potential massive speedup requires the OS to change, not the hardware.

We could also try to go further: microcontrollers.

A nice idea, but have you used the Arduino IDE recently? Okay, it’s crap and it’s slow, but it has plug in compilers for all sorts of things and so many library options it would be hard to find something that isn’t supported.
Internet radio on an ESP32? Time lapse camera (writing images to a FAT formatted SD card)? Most of my code was simply gluing the bits together.
I dread to think what would be involved in getting something similar working under RISC OS…

That’s not to say it’s not an idea worth looking at – more a warning that we’re up against an established and supported ecosystem.

Note also the price these ESP32 or Arduino boards are going for, and that programming them can be as easy as writing some code and telling the IDE to build it and flash it. It’s literally one button click, and there’s even a working mini Arduino IDE that runs on 64 bit Android devices (my LapseCam code was built on it, on a Samsung S9 it was actually faster than my old PC!).

the problem is not on the RISC OS side, but in the actual world.

Yes, the world is really badly broken, but I’m not sure that supporting (or not) RISC OS is going to make an iota of difference. It’s more a worthy distraction to stave off the impending madness.

DDE’s continued reliance upon FPEm is embarrassingly bad

Just to take it temporarily off-topic, any DDE C users that want to try using VFP in their application (and maybe even still use the same build on non-VFP systems, like RPCEmu), have a look at https://www.riscosopen.org/forum/forums/2/topics/3457?page=10#posts-126520 onwards. ROOL continue to be very helpful in bug-fixing to assist this effort even though it’s technically unsupported. Please continue over there though, not here!

If we are going the emulation route then Virtual Risc PC is streets ahead of RPCEmu and Pyromaniac.

Good idea. Use the closed source thing that costs money and ostensibly has a bus factor of one for the open source OS that you want more people to use.

Emulating a RiscPC – unless it’s an imaginary RiscPC without the RAM and VRAM limits of the real beast – seems rather uninteresting…