Who'll do the "da Vinci" workstation, then?

… or enough free programmer time. I’m feeling guilty as it is that I haven’t had time or energy to work on !tabby (never mind the IDE I was working on) for ages. So while I would like to contribute to the C port, I am not in a position to make a positive contribution. I suspect I am not the only person here in that position.

There is also the question of what are we going to do with RISC OS when we have really modern hardware to run it on? Where is the new software going to come from?

Personally I think the Raspberry Pi is the best way forward for keeping RISC OS going in hardware, it is cheap and RISC OS is a good OS for limited hardware (one of the things that made it such a good OS in the 90s). I don’t think it is reactionary to be happy with that. RISC OS is never going to compete with UNIX, at least for me, as a platform for doing useful work (or as a nice platform to program on – I wrote !tabby to try and improve that a bit, but there are many other issues). I’d be perfectly happy with RISC OS as my MGA to tinker with at the weekends but drive my Fiesta to work every day.

However, if the sea bass were both ill-tempered and mutated, I might be tempted. ;o)

@ Cameron

I suggest to avoid engaging this type of threads. Of course you are absolutely right on each single point you’ve made my friend.

The problem with these threads is that whoever starts them has no clue of all the technical and economical challenges behind their “daydreaming” and the more we engage the more they add nonsense to them (especially when the folk who posted is one of those who wants to be right at all costs) so the thing becomes a spiral of wasted time.

What need a FAQ entry on what sort of RISC OS development can realistically be achieved, and what can’t. Or just a forum entitled Dreaming…

What need a FAQ entry on what sort of RISC OS development can realistically be achieved, and what can’t. Or just a forum entitled Dreaming…

+1, I think that is a good idea, there might be a forum called “Dreaming” where the general user could go as wild as they want. In the end everyone should be free to express whatever they want and others are free to completely ignore it.

Arm has dropped 32-bit support with ArmV9. What happens when RPi has to use CPUs based on this architecture on their cards? Do you plan to write a hypervisored/sandboxed emulator where 32-bit RISC OS can only use no more than maximum 5% of the total CPU/GPU capabilities? How much work will it take to write this emulator versus rewriting RISC OS in C? I’m asking these questions since this is the situation the RISC OS Tribe will find itself in the near future.

Nearly 10 years has passed since Arm went 64-bit, so based on that Trinbal reaction time lag RISC OS will disappear with its last user sometime beyond 2030. Which is a shame since the GUI/WIMP system is really worth preserving, and ROX doesn’t quite do it. So – 64-bit or toast. That’s the bottom line.

DNFTT, but…

can only use no more than maximum 5% of the total CPU/GPU capabilities?

Based upon what metric? It sounds suspiciously like a figure pulled out of your arse.

How much work will it take to write this emulator versus rewriting RISC OS in C?

Well, there’s not one but two RiscPC era emulators, so I feel you’re being a bit disingenuous here.

I personally feel we should have a pass-through emulator that does the minimum necessary to glue RISC OS to the host hardware, but at the very least, a quick port of the existing RPCEmu and RISC OS is good to go.

Yes, it’ll be slower than native, of course. But maybe a few grand in bounty cash and a couple of months for the work to be done and it might be achievable (those were figures I pulled out of my arse, but porting something that already exists will be much simpler than reinventing the wheel from trees and saws).

Or, you know, just accept that there’s still a lot more that can be done with existing hardware and look to maximising that potential?

So – 64-bit or toast. That’s the bottom line.

Reinvent something that nothing existing will run on without some sort of environment emulation, or just run the entire system within an emulator.
That is the bottom line.

If you feel otherwise, and I’m sure you do, then please go away and devise a costed proposal of exactly what needs done – I mean, think about the API and how things will interact, rather than fuzzy references to “The Tribe” ¹ as if all of these technical issues are just minor hiccups.

I also suggest you pick up a copy of Tanenbaum’s Operating System Design and Implementation (Google will find you a legally dubious PDF on GitHub) and read it. All thousand pages. Then you’ll understand why Q4 2023 is ludicrous. It might take you that long to work through the book, never mind actually reinventing an entire new OS.

Then, when you have a solid proposal and financing, well, RISC OS is open source. Go for it. Make it happen.

¹ I’m an introvert. My “tribe” is myself, my cat (Anna), and I’ll be generous and include that snail leaving icky marks on the window. I think I’ll call it Derek. Three’s a crowd, but the snail doesn’t count, so it’s cat and her human. That’s as big of a tribe as I’m interested in.

1) RISC OS currently runs on 1 core out of NN.’ No “gueing to the hardware” to speak of there.
2) It cannot utilize Arm’s hottest GPU (Immortalis G715) at all. Realtime raytracing, no thanks?
3) Keeping the GUI/WIMP system (“The RISC OS Experience”) appear to be the least issue. But not as just another Linux DE. Cinnamon is peachy there.

Yeah and I like the cat people too. They’re pretty daft&sneaky.

For what it’s worth, I don’t like cats. Or dogs. Well, they’re nice enough, as long as they keep a reasonable distance.

On the other hand, I am a(n honorary) member of an actual tribe – the Oraon or Kurukh, you can look them up on DuckDuckGo if you’re so inclined (or G**gle if that’s your search engine). I married into it, a pretty unusual event, hence the honorary membership. When I was first there (in 1983), few of the tribe had used a landline phone, never mind a computer. Few of them had ever heard of computers. Today, mobile phones (almost all ARM-based) are common there. RISCOS? Not a sign. Apple Macs & iPads? A few. PCs? Zillions.

My Mac is my main workhorse. I don’t expect ever to use RISCOS for the things I do on the Mac. That’s just realism. No, MacOS isn’t perfect, but it’s not in my power to fix it. I use RISCOS for a few things it does well, and I’m familiar with it – but there are more things that it doesn’t do, or that the Mac does better. That’s life. I think most of us on this forum are in a broadly similar position, and realistic about it.

If some folk aren’t realistic about it, that really is their problem, not ours.

I personally feel we should have a pass-through emulator that does the minimum necessary to glue RISC OS to the host hardware, but at the very least, a quick port of the existing RPCEmu and RISC OS is good to go.

Are we thinking something involving Genode here?

that snail leaving icky marks on the window. I think I’ll call it Derek.

Not Brian? Son of, son of,son of, Brian (friend of Dougal & Florence)

However, if the sea bass were both ill-tempered and mutated, I might be tempted. ;o)

All I asked for were frikkin’ sharks with frikkin’ laser beams on their frikkin’ heads!

Could Timothy Baldwin’s RISC OS on Linux port form the basis of a solution here?

Finally, a voice in the wilderness. ..Could it?

The Linux port allows RISC OS run on Linux as an application using QEMU, i.e. an emulator. While it will run on 64 bit ARM (and 64 bit x86) it’s no closer to making RISC OS a 64 bit OS.

Looks like someone already completed the machine development stage and knew how to actually call it to dedicate it to Leonardo Da Vinci:

https://www.comune.bologna.it/notizie/inaugurato-leonardo-super-computer

It has been classified as the 4th most powerful super computer in the world and its name is Leonardo (not Da Vinci).

More on a serious note:

Do you plan to write a hypervisored/sandboxed emulator where 32-bit RISC OS can only use no more than maximum 5% of the total CPU/GPU capabilities?

That is clearly trolling, I am sorry. First, you say you’re not a developer, then you throw around performance mesurements, for which you clearly have absolutely no idea.

The future of the traditional RISC OS (which includes RO 5 as we use it today), IS into either Emulation OR Binary translation and this is for a number of reasons.

a) Who would use a RISC OS that is not compatible with the past and has no software at all?

b) There are NO 64 bit RO traditional tools yet to actually even face a 64 bit port of the original sources, so, most likely the discussion should start from which tools/languages and internal architecture such a (completely new) RISC OS should have

c) For b, there are folks that are already looking into all possible paths, they have also published a document on here which they seems to be keeping up to date with their newer findings (when they have time).

d) IF and only IF (and WHEN, if at all) a 64 bit RISC OS will be available, it will need to have an emulation layer anyway to run old software and the discussion is still fully opened for what API it will expose to 64 bit Apps (and if such API is going to be completely different than the original 32 bit it will be also a new world for the old coders)

e) Even converting old ASM to C (which, btw is not a straight forward process because RISC OS API was not designed for C Kernel development and RISC OS present also a set of assumptions that are very much Acorn MOS-like), when moving to 64 bit is NOT just a matter of “let’s recompile it” for a 64 bit target. There is going to be a lot of things that we’ll need to take care of, not to mention that the “stub API” that will need to be designed (most likely as a must) to keep codebase consistency between the old 32 bit and the new 64bit will still be in ASM and will still cause complexity in developments.

This is just scratching the surface of the problem ahead, hence your posts are just daydreaming (especially on the matter of timescale) and they are utterly superficial in the consideration of the challenges ahead and the COSTS mostly.

Consider this, my post here is extremely (like very very very) superficial on the matter, so use it to measure the level of superficiality yours is.

I am not trying to be aggressive, so (as always) apologies if I sound as such, but the reality is, there is no way one can seriously engage in what you’ve posted.

it’s no closer to making RISC OS a 64 bit OS.

I know that. I’m starting from the assumption that a 64-bit RISC OS is, practically speaking, an impossibility, for all the reasons that have been rehearsed here. What we will have to deal with, however, is the disappearance in due course of 32-bit-capable ARM cores to run RISC OS on.

What we will have to deal with, however, is the disappearance in due course of 32-bit-capable ARM cores to run RISC OS on.

I do slightly wonder how old the youngest RISCOS enthusiasts are, whether it’s at all likely that new, young recruits to the OS will appear, and how long Pi3s & Pi4s will last once P14s are no longer produced. (Are they still being produced today? I don’t even know that.)

I see where you’re coming from, Clive: how many of the current crop of RO enthusiasts/users will still have functioning brain cells (or anything else, for that matter) when 32-bit machines are finally consigned to the scrapheap? In other words, should we worry?

In other words, should we worry?

My feeling exactly. I have a son and a daughter, both of whom grew up using RISCOS machines, but neither of whom still use them. Even I use the Mac far more than the Pi, although I would certainly miss the Pi if it wasn’t there for the things I do use it for.

will still have functioning brain cells

Dammit! There’s always something.

<walks away>

My worry is that the most productive operating system I’ve ever used (and wish to use again!) will disappear while (in a parallel universe) it’s running in full 64-bit mode, GUI/WIMP fully intact, using all cores in multi-threaded mode and hopefully but not necessary in preemptive mode but certainly using the G715 in full, legacy software running under emulation at better-than StrongARM speed until they can be rewritten for 64-bit light-speed performance.

It’s one humdinger of a project to achieve but if the platform is to have a future it has to be done somehow. Along with some rather ludicrously fast hardware (The Tesla?:P) which may be the easiest part of this endeavor. Maybe all those pensioned RISC OS programmers expert at both ArmV3 assembler and C can conspire to pull it off? Who knows. Stranger things have happened.

It’s a salvage operation in rather deep waters.

Sweet dreams, Sveinung.

I’m 73. How old are you?

I’m optimistic about having functioning brain cells well into my nineties – there’s plenty of family precedent for it – which might well mean I outlive the Pi. If so, I’ll have to bite the emulation bullet. I don’t dream of anything more advanced than that. If it happens, I’ll be a happy user, but I’m not holding my breath, nor will I spend much effort chasing moonbeams.

Edit: just this minute heard that my uncle – my mother’s younger brother – has died today. He was 92, and all there mentally to the end. Only one of that generation left now.

I’m one of the eternal optimists who believe that 64-bit RISC OS is possible, albeit that it will take a lot of effort and time to achieve.

The key goal is something that has a sufficiently similar API that existing software can be compiled with minimal or no changes, and work.

Any added functionality (e.g. PMT, multicore) is a bonus.

The first task, as I see it, is to rewrite the existing OS in C. Love it ot loathe it (and I don’t much like it), it’s the language that was developed for writing operating systems. It has had a remarkably long life. I don’t see any realistic alternative.

I looked into the RISC OS sources this afternoon. The first module I looked at was Desktop. It’s not very big. It must be a candidate for an experiment in translation. I didn’t see the machine instructions as undule difficult. What threw me, and it does it every time I look at this sort of stuff, is the assembler directives. But I do think it’s do-able.

My idea is to start on an easy one, and work up to the more difficult parts.

Some of the issues that need looking at are:

• The new API needs to be defined. Who, apart from Gerph and Jeffrey, have sufficent overview to do this?
• How to test translated stuff.
• How to build it. Best hope seems to be to cross-compile it.

I’m optimistic about having functioning brain cells well into my nineties

Given the way things are going, I’m not sure I want to have functioning brain cells in forty years. That being said, I doubt I’ll have forty years.

Sadly, I have no family history upon which to draw. My father’s side being from Glasgow, enjoyed a wee dram a bit too much. Apart from one who was actually mad, I’ve already long outlived them. My mother’s side… is an enigma. And one upon which the records are legally sealed forever.

Makes it interesting when you reach the age doctors ask “do you have a family history of…?” and the only possible reply is no idea.

nor will I spend much effort chasing moonbeams.

The way I see it is twofold.

The first is that RISC OS didn’t die with Acorn, so not only did we get another quarter of a century with it, we also got to experience it on the sort of hardware that would have been a wet dream when RISC OS was created (a gigabyte was the size of a large SCSI harddisc, not the amount of memory installed), at a price that would have been a wet dream back in Acorn’s day (put together a full functioning machine for a hundred quid?).
That it is open source and we can all peek behind the curtain is a bonus, especially for the inner geek, but the idea that it’s still a supported thing on processors clocking over a gigahertz with gigabyte memory is pretty mind blowing.
Yes, there will be an eventual end. But the platform has overcome extinction level events numerous times already. So it would not surprise me to see it continuing in a 32 bit form under emulation once the core speeds are fast enough that emulation beats native on older hardware. This might be the end of 32 bit ARM, but I don’t think 32 bit RISC OS is done just yet. Even with existing hardware, there’s so much more that can be done.

Secondly, any fantastical new 64 bit RISC OS might bear some UI similarity to the existing Wimp, but it will be more than different enough in every other way that it probably ought to have it’s own name (Steve!) and stop being called RISC OS. For starters, if you can’t make an x86 build of it, you’re doing it wrong.

Right, I think the next ep of Wednesday has downloaded, so bye. Snarky monochrome goth girl, the perfect weekend date. ❤️

The key goal is something that has a sufficiently similar API that existing software can be compiled with minimal or no changes, and work.

Not only would that be a terrible idea, repeating all the mistakes of the past, but how would one handle a system where the behaviour of the processor is different? The current API is heavily tied to the SWI command, the registers…

The first task, as I see it, is to rewrite the existing OS in C.

Again, because it’s an assembler OS to which C was added later, it will be challenging to get any useful work done in C until CLib has started up. Which precludes the kernel or anything that the C runtime relies upon being available first.

It must be a candidate for an experiment in translation. I didn’t see the machine instructions as undule difficult.

Oh my god. Assembler to C translation will result in an unmaintainable clustermew that only has a passing resemblance to C.
You need to work out what the code is actually doing and write that algorithm, not a literal translation from assembler to C.

While it is useful to convert parts of RISC OS to C for easier maintenance, this shouldn’t be conflated with any transition to 64 bit. That one will need a redesign from the ground up, lest whoever does this waste an inordinate amount of time repeating the mistakes that a thirty year old heritage has brought to light.
Fundamentally, RISC OS is insecure and inadequete for modern computing uses. The only reason we haven’t been pwned to hell and back is obscurity to the point of midnight under a heavy sky on the day of the new moon. That’s no form of security. And that’s not something that should be replicated going forward. If somebody is seriously imagining writing a new OS, then for the love of everything beautiful, do the job correctly!