The Future of DTP, Illustration and general GFX/Audio using RISC OS desktop computers (Is 64-bit!)

64-bit was the present some ten years ago. 32-bit is history by now. Locking oneself within a time capsule and pretend everything outside is irrelevant is denying technology evolution which will bring both faster and more if implemented. Even when somewhat late in the day.

Apart from the lack of developers, money and time, the other major consideration is the availability of the source code to major applications, and where available, is it assembler or C code? Without some of the applications that make RISC OS what it is, what will we have gained by going 64-bit. You could argue that applications can be ported from Linux, but unless they can seamlessly fit in with the RISC OS interface and ways of working, what’s really gained that couldn’t just be done on Linux anyway?

Negatives aside, I’d still like to see RISC OS have future one way or another.

Ask the commercial users of RISC OS whether they think they need it, and are willing to put up £5m (min.).

Writing RISC OS in C will hardly be much slower than assembler running on 2-3GHz CPUs.

Sure. A system written in C can run reasonably quickly, as Linux demonstrates.

But… Writing RISC OS in C?

And RISC OS “quirks” […] dealing with security/firewalls and some other issues, can be adressed through a maintainable rewrite in C

You know, part of what makes RISC OS interesting is that you can mess around and the OS doesn’t get in the way.
If you want a system that is able to be locked down tight and has a good ecosystem, why would you look at something other than Linux (for a gadget) or Android (for a phone)?

Serious question.
I remind you, again, even Microsoft failed to make any impact on the phone market.

along with an update to the SDK

Update.
An update.

Yeah. Okay. If you say so.

(which currently is “a nightmare” according to some very experienced people, compared to other SDKs).

Provide examples. Maybe your “very experienced people” are used to dynamic runtime linking of whatever pile of libraries they require? The RISC OS API not only predates a lot of that sort of thing, it’s also extraordinarily heavily based around how the ARM processor works. Which means that your “update the SDK” is…. yeah.

The API isn’t that bad so long as you don’t go near the keyboard handler. Certainly, I find it more pleasing to write stuff for RISC OS than for Windows, even considering that using Visual Basic it was dead easy to do things (until you needed to mess with the underlying SDK at which point it got a bit messy).

Maybe that’s the issue? VB did a lot, but invariably did it just slightly wrongly or in an overly difficult way? RISC OS, by contrast, does next to nothing so breaking the rules is not hard. ;)

Of course, breaking updating the API in order to make it work within the context of a 64 bit OS written in C means that no existing software will work.
Nothing.
This is insurmountable – AArch64 is not a close relative of ARM32, as 26/32 was. It’s practically an entirely different beast. Consider, for instance, trying to get RISC OS and its apps working on an Xtensa processor and you’re about there.

Not only that, even stuff written in BASIC will fail, unless it’s pure BASIC and doesn’t call SYS once.

Assuming, that is, that this 64 bit RISC OS even supports BASIC. There are better options these days. I’ll let others make the arguments for Lua, Python, etc etc.

This RISC OS – it’s core anyway – can be written to be stable, secure and update-able on any device having an Arm CPU.

By whom?

Custom GUIs suiting the different devices can be made.

By whom?

To put this into context, we are in the position of having workable test builds of a WebKit based browser, we’ve only just got IPv6 and a stack that doesn’t date from the 90s, and we’re still waiting on WiFi (that is coming ever closer).
Is anybody doing Bluetooth?

Multicore has test builds but there are fundamental issues with having the Wimp cope with spreading tasks around cores to run them asynchronously. It’s a co-operative system, it just doesn’t work like that.

As others have said, dreaming is fun. But in reality, I’m looking at a lump of amber and saying “ooh, pretty”.

Let’s work with what we have, eh?

what will we have gained by going 64-bit

Apparently “it runs faster”. ;)

I believe that Steve was referring to Pi-based systems.

Yup.

For example, we have all of these in stock, including the miniscule but powerful FOURtress Lite for only £99!

Feeble attempt on my part to be non-partisan, and easily overcome as all can see :)

realized what it would take getting from 32-bit here to 64-bit there

Which is probably a lot easier if the source doesn’t have silly large amounts of assembler in it.

I’m given to understand that current 32-bit RISC OS matches 1, 2 and maybe 4 well but not at all 3.

item 4?? 100 000 users? Er…

No, I don’t think so.

> Let’s work with what we have, eh?

Apparently from what I can tell the same as Furber and Wilson had developing the ARM architecture/RISC OS – no people, no money. Probably slept beneath their desktops,too, Curry and Hauser ready with buckets of cold water in the morning to wake them up.

Seriously, a core rewrite is necessary since the newest architecture versions has advanced beyond recognition of the oldest, so if one want to go from 32 to 64 bit CPUs one has to start nearly from scratch. If the old core is hardwired to the wimp system the new core must be adapted/rewired to the wimp system since maintaining look and feel/drag & drop is paramount. Not an easy job but doable provided there’s reason to do so like having the platform not just survive but thrive and grow. Just hope there’s people to do it.

>current 32-bit RISC OS matches 1, 2 and maybe 4 well but not at all 3.

But 1 is a massive amount of work (kernel, device drivers etc etc) and is the bit of RISC OS that is uniquely bad (no security), and 2 (desktop) not very much work.

What’s the plan, stick with 32 bit, knowing the chips will run out one day, and the eventual destination is emulation.

If Sveinung really really wants to run RISC OS on 64 bit ARM then…

An emulator for Linux on 64 bit ARM where more and more of RISC OS is written in C and runs natively. Then allow new RISC OS apps that have been compiled for 64 bits and don’t need 32 bit emulation.

> An emulator for Linux on 64 bit ARM where more and more of RISC OS is written in C and runs
> natively. Then allow new RISC OS apps that have been compiled for 64 bits and don’t need 32 bit
> emulation.

This isn’t quite the Baron Munchhausen method of dragging oneself out of the swamp by one’s own hair, is it. Since RISC OS has no 64-bit-capable compilers this is the state of affairs. If anyone can see a profit in doing so the better. So is the mass market route (phones) the carrot here to motivate and animate those capable to do the very safe & secure 64-bit version of “RISC OS 64”? It’s the most probable way I can see to generate enough cash to do the hardware we’ve been longing for, disregarding what’s underneath to enjoy the productivity of even emulated software. Look at the Subject of this thread. That, and the prospect of “4DO” gamer consoles based on much the same hardware/software generating even more moneys for development. There must be a way to get from here to there.

An ARM32 on ARM64 emulator is an admission of defeat.

RISC OS 64 would have to have BASIC, otherwise huge numbers of applications would be lost.

The C API would have to change internally, but I don’t see why that would affect applications at C source level. Modules, yes, probably.

RISC OS 64 would have to have BASIC, otherwise huge numbers of applications would be lost.

Including all the WIMP calls that those apps use to run in the desktop. BBC BASIC itself is probably doable without (far too) much difficulty. The WIMP calls I’m not so sure about.

an admission of defeat.

Or an admission of reality. I feel like a parrot but… Who is going to write an entire OS from the ground up?

otherwise huge numbers of applications would be lost.

People who say things like this, or worse thinking they can just be recompiled, probably haven’t understood the scale of the changes between the 32 and 64 bit worlds; not to mention dumping the old assembler programmer friendly API for one that will work with everything in a high(er) level language such as C.

Let’s put it like this. Just like Linux, there’s no real reason why a 64 bit RISC OS written in C can’t be built with an IA64 target.
Now, how will your apps work on that?
This is the scale of change we’re looking at.

These are valid considerations. I didn’t think about BBC Basic also being affected. As important as it is, it will have to be rewritten too, of course, to maintain continuity. But it probably wouldn’t be exactly the same to use. Things have changed since it was written some three decades ago, and it’d have to reflect that. Will it be worth it? If the genius who invented it found a match in The Tribe today plus a few more at the same level able to “go 64-bit”, would they be here?

And the question remains – will The Tribe be content watch their phones getting faster and faster than their best 32-bit systems, even running on one core in 64-bit systems (RPI etc.) running 32-bit OS and software? If the answer is “yes” here among people who are able to do something about it, the platform will be dead as dodo in a few more years. History, an ex-platform resting in in Silicon Heaven.

That’s what I wish to avoid, and 64-bit is the only way to go. Maintaining look and feel, drag and drop, three-button mice may be the least challenge. Provided there is a good 32-bit emulator to run legacy software as transparently as possible at adequate speed one wouldn’t start without a reasonable software base. The titles worthy/needed slowly migrated to 64-bit over time. Native 64-bit software overtaking legacy software in a year or two, enough to claim renewal.

Only to get there, having an overview over everything that must be done – are there even theoretically enough, expert enough, motivated enough people to do it? If so, why didn’t they start out planning the transition the minute Arm Ltd. announced their transition to 64-bit CPUs? That’s the real-life/psychological dilemma arising, a combination of these two explaining a 12-year near-status quo (mainly except the OS isn’t in ROM anymore).

So is this a Quixotic quest on my part, spending energy on something that cannot be? Hoping one day not far away to run RISC OS on https://i.mediatek.com/dimensity-9200 or one of its descendants, creating digital dreams with !TopModel 3 in ray-traced scenes? That’s what irks me – the most productive user interface isn’t a contender there, not even a participant to be honest. Staying with the subject, the rationale for even trying to “teach an old dog to do a new trick” is.. wibbly. -Could there be better things to do?

[…] it will have to be rewritten too, of course […] Provided there is […] why didn’t they start out planning the transition the minute […]

Has it simply not occurred to you that we’re all quite aware that the 32 bit processors are basically end of family as all the serious operating systems that run on ARM are already 64 bit, so there’s no real incentive to waste die space on a 32 bit world that isn’t needed except for the likes of Android Go and the crappy tablets that end up as landfill…?

Here’s a hint – we’ve already discussed this, a lot. Use the search thingy a on the right there.

With this in mind, if we had the people and the talent and the inclination, then there would already be discussions regarding the actual form the API will take. How the OS will function. And so on.
But this hasn’t happened because we greatly lack people to work on the OS as it is right now never mind flights of fancy like a 64 bit version that’s different but somehow the same (basically an impossibility without some serious funding).

Why did nobody think about porting RISC OS to a 64 bit ARM? Simple. The OS is like a hundred megabytes of assembler using an API that is inextricably tied to the behaviour of the older ARM.
Like I said, imagine porting it to a completely different processor. That’s what we’re talking. And, of course, this would be an OS that’s a massive breaking change on all existing software.

So, we either stick with the past and all that entails, or…? Take a lot of time to create an OS that few people will use?

You understand this is largely a volunteer effort, right? So coming along saying what we need to do may well annoy some people.
Because we know what we’d like to have happen, but there’s this thing called reality. People have lives, jobs, families, bills to pay, that sort of thing.

Take a look at the Bounty page (no coconut, honest!) and understand that this is the sort of direction we’re going in because of a general lack of resources, financing, and people. Something that I think Cloverleaf was looking into, but that’s gone rather quiet.

The idea of “just rewrite the entire OS from the ground up for an essentially alien processor” is simply not on the table.

If you think you can change this, then fine. We’ll be helpful and enthusiastic. Just stop telling us what needs to be done. Instead, go start the ball rolling and see how far it goes.

> The idea of “just rewrite the entire OS from the ground up for an essentially alien processor”
> is simply not on the table.

Dead as a dodo then. A 64-bit core++ would mean starting afresh (apart from 26/32-bit emulation) with zero people, zero financing, opening potential vistas to huge new markets (phones; gaming) and being able to run on current 64-bit Arm laptops (chrome, windos) at no doubt respectable speeds.

It could also be used in a very powerful purpose-designed multi-CPU workstation system based on a few MediaTek Dimensity 9200s or better (!) and reduced a bit in capacity, to become a very fast and capable gamer box. All made by no people, no money to speak of.

Initiatives such as https://github.com/TimothyEBaldwin/RISC_OS_Linux_Binary are all well and good, but it won’t truly bring the platform into 64-bit land riding on top of a Linux kernel with its own not-inconsiderable tail of issues. It’s semantics, but what it takes to call oneself a platform I’ve mentioned earlier in this thread, so this isn’t IT from those criteria.

I’ve written before, the 32-bit Tribe can happily use their 32-bi rigs (even running on 32-bit mode in 64-bit CPUs, on one of their many cores) until they won’t work anymore – Arm has removed 32-bit support from ArmV9 so the writing is on the wall. FACT: This isn’t attacking anyone, it’s describing realistically what’ll happen, by an by, unless. Can that be taken for granted?

We need a new Acorn Ltd. with the same visionary drive they had in the mid 80’s and the genius engineers who created the ARM and RISC OS, but even if the currently fission-ed RISC OS company world could be fusion-ed into one – would they be a match to 80’s Acorn Ltd. in capabilities and visionary mettle? I know this isn’t a fair comparison (and probably a daft thought) but I honestly hope the potential is there. The benefits could be enormous.

We know it’s a dead parrot, but it keeps squawking. And that’s good enough for most of us.

I am really grateful to all who have contributed to keeping RISC OS going over the years, surmounting the 26/32-bit transition, various SoC hurdles, but personally feel this one is too high a mountain to climb.

80’s Acorn Ltd. in capabilities

They had a great capacity for splurging money on useless things.

> They had a great capacity for splurging money on useless things.

Developing the ARM architecture and writing Ar.. RISC OS weren’t among them useless things presumably, since you’re happy as a clam with jazzed-up versions of the original system. Doing the “Internet on TV”-thing in the late 90’s (N|C’s – I was there) at a time there was neither the network bandwidth nor TV resolution to make that a pleasant experience. Could have worked well in mass-user contexts such as schools and bureaucracies (low purchase/admin costs) but that wasn’t the focus. Going “Element 14” didn’t help brand recognition either. The question is, can the current RISC OS companies do it technically speaking, go 64-bit, even in theory?

Dead as a dodo then.

It’s still available, it still runs on currently contemporary hardware, and it’s still being developed (slowly, but still ongoing).

Not a bad innings for an OS from 1987 whose creator packed up shop nearly a quarter of a century ago.

So no, not dead as a dodo. The GEM desktop might be a better example of a dodo.

A 64-bit core++ would mean starting afresh […] with zero people, zero financing,

Now you’re getting there.

opening potential vistas to huge new markets (phones; gaming)

Please drop the idea of us making it in the phone arena. Microsoft spaffed nearly ten billion dollars and still failed.

And, note, it’s not just a fancy phone. You’ll need the entire ecosystem behind it. Does it have a Twitter app (or, these days, Mastodon)? How about a Facebook app? An agenda (that talks iCal)? All the secure level stuff to make a SIM work? How about 8K video in realtime with an editor app? Or just buying crap on Amazon and watching Netflix? My little Xaoimi can do all of that, and it was cheap enough that I got it for €1 at contract renewal time.

It’s a cutthroat market, that best thing we could do is go nowhere near it.

run on current 64-bit Arm laptops (chrome, windos) at no doubt respectable speeds.

What’s so bad about the speed of current hardware?

My older Pi 2 clocking 900MHz can compile it’s entire OS from scratch in less time than it takes my 2.4GHz P4 box running XP to compile a 15K source into an image to flash onto an ESP32.

Sure, it can’t really cope with video because it’s using the processor with minimal help from the GPU because, surprise!, the GPU stuff is very often a binary blob from the chip baker and how it actually works is a tightly guarded secret with NDAs aplenty (assuming they’ll even talk to you).
So if the RISC OS 64 dev team doesn’t have the clout to get at the info, moving to 64 bit won’t magically make stuff happen and a lot of functionality will be dead in the water from the outset.
I don’t agree, I hail from an era when all the chips had available datasheets, but I guess back then nobody cared much about such things as “intellectual property”.

Or, you know, just have fun figuring out your own pet project to add to the existing OS. Sure, it’s not 64 bit and it’s unlikely to ever be, but it’s not dead.

A new WebKit browser. A new networking stack. WiFi in the future. Along with the ability to work with IPP/AirPrint printers (that’s most of the WiFi compatible ones). Useful things are happening right now.

I see no dodo.

The question is, can the current RISC OS companies do it technically speaking, go 64-bit, even in theory?

The answer to that is pretty certainly, “No.”

As Stuart says,

We know it’s a dead parrot, but it keeps squawking. And that’s good enough for most of us.

I’m 73. Apart from Rick, we’re probably mostly around that age. Our Pi4s running 32-bit RISCOS on one core will probably see most of us out, and my offspring (and probably others’ offspring too) are quite happy with other OSes.

I’m quite happy really with MacOS for most things. There are annoying things about it, but it’s much less annoying than Windows. There are annoying things about RISCOS too, but it’s got a few things I value enough to keep it going alongside MacOS: !Draw & the Draw file format; BBC BASIC; and !Zap. No offence intended to those who do DTP on RISCOS, which I certainly appreciated in the 1990s, but I really can’t imagine going back to it. I never got into ArtWorks; I liked Photodesk but now use the GIMP on Mac.

I hope my Pi lasts a long time. I want to keep !Draw, BBC BASIC, and !Zap. I don’t need any more power than the Pi’s got for those, but if they and RISCOS magically appear on more modern hardware, I shall be happy. But I’m certainly not holding my breath.

Acorn producing the BBC Micro in 1981 was an achievement, producing something like it now, 40 years later would be greeted with derision and rightly so. It would be very easy and there are much better solutions. It has all been done before; what’s new, what are you adding.

You have to ask what are the likes of the founders of Acorn up to now.

BBC Basic exists for 64 bit ARM, featuring 64 bit ARM assembler:

https://www.bbcbasic.co.uk/console/

BBC Basic exists for 64 bit ARM, featuring 64 bit ARM assembler:

(As I suggested above “BBC BASIC itself is probably doable without (far too) much difficulty.”)

But just BASIC – none of the operating system calls you need to make functioning applications, presumably…

Mr. Murray: The platform cannot grow a user base still being 32-bit, the opposite is more likely – it’s a shadow of a niche already compared to what it was pre-1997. Emulation will as mentioned enable running of legacy apps in 64-bit RISC OS at speeds comparable to or exceeding RPI4 depending on which ARM-based SoC is most interesting then. So going 64-bit will actually prolong the 32-bit era if anyone can see the point having the beautiful new SDK (yeah..) at their disposal with a raft of open source libraries to use. So: Room for 32-bit fiddling, a galaxy of 64-bit possibilities.

Mr. Semmens: I’d be way past blue in the face by now, but am not (at 58 years and puttering along). I wonder, as a honored old engineer in Arm Ltd, don’t you ever wonder (going beyond “mere” DTP/page layout) if MediaTek’s new flagship SoC, the Dimensity 9200 with Cortex X3 CPU and the outrageous Immortalis-G715 Ray Tracing GPU, could revitalize the RISC OS platform in many ways (like capable of rendering Avatar 2 in a multi-SoC system) if the latter is 64-bit? I do realize that 1) It’s a Big Job (rewrite OS, SDK inc. PRMs, BBC Basic) with 2) No Money and 3) No People motivated and/or economically independent enough (in the needed skills class) to do the rather Herculean job, Sisyphus watching from the sidelines. I earnestly think it deserves better.

don’t you ever wonder […] could revitalize the RISC OS platform

No, actually, I don’t ever wonder about things like that at all. My publisher gave me his old Sony Ericsson Xperia phone seven years ago; I send and receive very occasional text messages and voice calls with it. I’m writing this on a nine-year-old MacBookPro that our son gave me secondhand; upstairs I’ve got a fairly new M1 Mac Mini with a 43" 4K screen that it shares with my Pi4 that runs RISCOS. If you’re bored enough, you can see the various things I do on those machines here: http://clive.semmens.org.uk/RISCOS/AppsQ.html

Those machines are all powerful enough to do everything I want to do faster than I can type. I’m not – and never have been – interested in technology for technology’s sake, or RISCOS for RISCOS’s sake. I value RISCOS for the things I can do on it that I can’t easily do on the Mac, but for most things the Mac’s better, so I use that.

Oh, and I wasn’t an engineer at ARM – I was a technical author, with particular responsibility for assembly language and the instruction set architecture.

St. Pilling: If that’s a good starting point (sans audio/video atm), could it conceivably be used in 64-bit RISC OS if it existed? If so that’s one hurdle out of the way, a pretty important one too. To encourage Developers! Developers! Developers! by and by, maybe learn a more portable language too. Correct me if I’m wrong, but isn’t it the Assembler-in-BBC Basic part of what got us into this 32-bit pickle and makes us stay there?

As to what hardware can be made from what is, thinking a multi-Soc MediaTek 9200-based workstation nearly deserving the High Performance Computing label – who’d laugh, about what? Not its performance. Did you mean…. ;)

The founders of Acorn.. guess Mr. Hauser (the Money Guy) is cooling it in his Austrian (?) vineyard, or rather testing the 2022 produce from one of the oak barrels in the cellar. Its bouquet.. Of course if he reads this and want to pitch in he’s very welcome to do so.

We are where we are due to Acorn’s Modula-2 compiler (for that is what was mandated for use within Acorn) being unable to produce ROM-able PIC back in 1986, so we fired up AAsm to ‘write device drivers’. Plus ARM assembler being a delight to write! Assembler-in-BASIC doesn’t actually have anything to do with this.

[But what about C I hear you ask? Nope, that neither. Still doesn’t, as far as I am aware.]