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

Since the terrible demise of Acorn Ltd., development in the RISC OS DTP/illustration scene has trundled on, software being developed quite a bit in some areas and not in others. The fact is that people are getting old, becoming pensioners, without a new generation or new recruits to carry on development of existing software at a professional/expert level, able to compete with software features and functionality on other platforms. -Or is there? We’ll be very happy to be proven utterly wrong here.

Another issue hindering a true revival in general is RISC OS still being 32-bit. It’s said to run “pretty fast” on one (!) of the four cores on the ARM Cortex-A72 sitting on the Raspberry PI 4 card, but who is asking “how fast will it be using all cores?”. On even faster Arm CPUs with even more cores? Never mind multi-CPU/GPU systems? The answer is “A bit faster” (understatement). Real-time raytracing (even real-time everything) is in the works, available now. Arm’s Immortalis G715 anyone? -Maybe !TopModel.. As dramatic as the performance jump from the BBC Model B to the (ARM2) Archimedes in terms of capabilities, that’s what we need and can have, in theory, from what already is. Thinking 64-bit RISC OS desktop or laptop workstations using (upcoming) 12-core Armv9 X* CPUs. Imagine what we could do..! Never mind do with multi-CPU+GPU/SoC desktop workstations.

We must draw the necessary conclusion here – RISC OS’ core and modules etc. has to be rewritten then, for multi-core and multi-threaded (ARM) CPUs, in C this time not to lock ourselves to current instruction set versions. Anyone thinking the RISC OS scene will expand never mind survive for (semi)professional use still being 32-bit beyond the time 128-bit CPUs become common some 4-6 years hence are fooling themselves. Bottom line: The RISC OS experience, the productivity, is too valuable to let that happen! And the RISC OS Software Development Kit/environment, compilers and libraries can’t do 64-bit anything at the moment so it must be written with Linux’ SDK, probably. That’s how far off we’ve drifted. Must set a new course, straightly aimed at pretty Sixtyfourbit Island.

Apart from making the RISC OS core and its modules 64-bit the GUI needs a face-lift, halving the height of the icon bar, use the .svg format for !sprites(22) icons, make the Desktop icon set both functional and aesthetically pleasing (engage pro GUI gfx designer to do this, maybe). Keep the 3-button mouse/middle-click menu concept as it is (very ergonomic, nifty solution). Plus enable legacy 26/32-bit titles to be run transparently (to the user) until proper 64-bit versions can be made.

Is anyone currently developing RISC OS source code motivated, enthusiastic and capable/skilled enough to take on and manage this rather big project, provided the funding can be secured somehow? A most respected and very prolific RISC OS programmer said that doing RO64 “isn’t much worse than writing a web browser supporting HTML5 with bells and whistles” or something to that effect. So the gains in performance will be.. spectacular. Simply by making RISC OS compatible with 64-bit Arm architectures., using the whole chip. It doesn’t need a face-lift except for the one mentioned, it’s the plumbing (core/most modules) which is mildly put unusable in the new 64-bit terrain.

Maybe part of the hesitancy regarding “going 64-bit” is related to the fact that the whole software development kit will have to be updated as well, not just to support 64-bit but also to become user friendly and comparable in capabilities to other platforms’ SDKs. Fact: Can’t have 64-bit RISC OS without a 64-bit enabled SDK! Who can take on that not-so-inconsequential job? Because this project must naturally be performed simultaneously with the OS-update and be finished as soon as there is a 64-bit RISC OS, this to remain (become?) a credible modern computing platform. Too embarrassing having to write/compile RISC OS software using other platforms, what what? Really.

Making new RISC OS 64-bit desktops and laptops with state-of-the art Arm CPUs and GPUs (the upcoming MediaTek Dimensity 9200 may fit the bill here), having an OS core/modules understanding multi-core, multi-thread, multi-CPU systems – isn’t that where we ought to be in 2022? The operating system (core/desktop) is here, massively ignorant of multi-everything in modern Arm CPU system versions so it has to reflect that to become compatible, meaning a total rewrite of core and modules. The Desktop should be kept as is. Look and Feel must be maintained to a very high degree and (system) icon sets can be by config choice. Configurable R Us, indeed. Encourage development!

This will level the playing field a bit, after everyone else (inc our phones) went 64-bit a decade ago, Running legacy 26/32-bit software with emulation will probably be faster than a StrongARM Risc PC. Native 64-bit compiled GFX software with support from all OpenXX libraries and Vulkan concerning audio and video etc. will be pretty Nirvana to work with, make no mistake. G715, real-time raytracing.. ye gods and little fishes. At what resolution/frame rate/color depth and with which software tools? They must surface from within the RISC OS scene and then this pretty good software can be 64-bit/jazzed up.

So what will having 64-bit RISC OS/SDK entail, apart from the possibility of us (how many..) working with new and rabidly fast computers? What else is 64-bit nowadays.. oh yes, mobile phones! Billions of them! Just waiting to run a very decent, very fast operating system! The income from just 0.1% of this market.. It goes without saying that phones have different demands than desktops/laptops, but that’s mostly related to the GUI and phone-specific functionality. Take that away, build multi-CPU/GPU desktops and laptops running very fast, for very long (laptops), very cool, using the same RISC OS core and our Desktop slightly tweaked – and we will have something that will stop traffic. Make people outside our little Tribe take notice. Maybe join our Tribe. That would be good.

Here we have RISC OS phones, RISC OS Desktops/laptops.. just add a state-of-the-art RISC OS (core) Gamer Console (another huge market), the PlayStation/X-Box-slayer (on price/performance/sheer coolness), supporting real-time raytracing making Elite Dangerous and other games look sooo good! Only what current RISC OS companies can take on rewriting it, make a phone OS/GUI making Android look bad, plus design/prototype/manufacture/market/distribute/support the other devices? One at a time, phones first, with its ocean of users as potential customers. Income from this venture (if done right) will generate income enough to do “the other stuff”, with moneys to spare. A year from now?

One last but crucial issue.. control. We wouldn’t enable anyone to “pull an Acorn Ltd” on us, fission the phones business off from The Tribe (long-suffering RISC OS companies and their dwindling customers) so for heaven’s sake, engage an intrepid biz lawyer (yeah.) to write an unassailable project contract saying “It stays with The Tribe!” or legalese words to that effect. Use a mass market to support a niche market. This way the Tribe Companies (cooperating as if one company with a common objective, common slush fund) can both maintain the platform and even develop it much further, develop both software and hardware for many devices, some not yet explored yet with “ARM Inside”, some not yet built. A virtual Acorn, rising from the ashes like mythological bird Phoenix? Hey. High time it did.

NB, the phones thing is just a sneaky means to an end to we get the hardware/software we sorely need to stay reasonably credible in potentially several professional computing fields (DTP, 2D/3D GFX. Video, Audio) plus guarantee the Desktop platform’s not just survival but a resounding revival with serious go-faster-stripes. Become 21st century. For real this time. –Discuss.

What are you smoking?

Dunno what he’s smoking, but I WANT SOME!

Well, I guess it’s better than the last time somebody came along telling us what we had to do and suggested changing the entire OS to follow the “DOM model”.

Thanks but I don’t want what he’s smoking. There’s already more than enough crazy in the world right now…

Hello, and welcome. Introduce yourself, and perhaps, tell us which RISC OS system you use. Where are your interests?

The topics of 64-bit, new users, multicore and other things are all in this forum.

How can you help? As you say, there is a lot to do and plenty of opportunities to help out :) See the following article, link for some ideas.

There’s already more than enough crazy in the world right now…

Okay, I don’t really want any, either. I’ve never (knowingly) partaken of any mind-altering substance, and don’t want to. Not even alcohol. Oh, I suppose sedatives and anaesthetics might count, which I’ve had for surgery.

(“Knowingly” – a friend, whom I still count as a friend despite this, once fed everyone, including me, a mushroom omelette at a picnic lunch. Not all the mushrooms had come from the supermarket, a fact he didn’t inform anyone of until later. It was a weird afternoon…)

I used to be pretty active on comp.sys.acorn.* Usenet forums back in the 1990’s when using first an upgraded Archimedes 310 (Arm3, 8MB RAM, Colourcard..) then a StrongARM RSC PC to do desktop publishing and illustrations for my company Dolphin Design. Must admit I haven’t got room to set up neither Acorn system where I live so I’ve lived in Linux-land since early 2000’s.

Typical of someone to ask what’s being smoked instead of addressing the issue – go 64-bit or disappear as a platform in a few years, fiddling with obsolete equipment. Going for an existing mass market (phones) is smart to get 64-bit RISC OS (core) since sales there automatically dwarfs any sales figures one may have dreamed of achieving way back when.

Granted 64-bit RISC OS existed, Arm Ltd’s CPU architectures has advanced “a bit” since StrongArm, actually capable of running in circles around a StrongARM going flat out. As to recent Arm GPUs.. a magnitude above what we’re used to, in every parameter which counts and then some. Are we supposed to sit on the sidelines and just think about what we could do creatively with that sort of CPU/GPU performance from.. Acorn RISC Machines?

It’s not a small job, rewriting RISC OS and the SDK to be 64-bit, with just the dwindling Acorn market to think of. But phones.. with that market to aim at, maybe ROOL/ROD/R-Comp together could pool their resources, split the job up into logical tasks, then distribute these according to expertise in those tasks. And think about distribution/marketing/support at the same time.

In the meantime, follow https://i.mediatek.com/all-new-dimensity and think “Wouldn’t 64-bit RISC OS run nicely on a new desktop (da Vinci) having a few of those inside (multi-CPU/GPU SoC)”. You needn’t smoke anything to be a bit interested in getting there. :)

It’s not a small job, rewriting RISC OS and the SDK to be 64-bit

This is the crunch.

But phones..

Indeed, that’s where much of ARM is – was already, fifteen years ago when I was still working at ARM. But RISCOS on phones?? Back to that crunch…

Now if someone puts RISCOS running native on the new Macs… yes, please. But really? Who’s got that many person-years of effort available?

Maybe if there was a road map for 64 bits – an agreed way to do it – even if that is not likely. Talk of re-writing modules in C – is that actually going on. Where is the sum total of RISC OS for 64 bits – wiki page somewhere?

Mr Tengelsen was well known in the RISC OS world of the 90s and has always got an interesting vision. Someone can come along and say “why not” – even if you then tell them why not.

Good to hear you were an Acorn devotee, as you’ve not been a RISC OS user since the early 2000s. What’s brought you back to this forum?

@David. I see; what you mean.

A Wiki page detailing a 64-bit road map would be good. Not the page I remember seeing, but here is a roadmap link

EDIT: Here’s the page I recall seeing, that contains a timeline/roadmap/wishlist for RISC OS.

@Andrew – wow so many wishes. Interesting to me, that page links to one which describes some of the problems the 64 bit instruction set poses:

https://www.riscosopen.org/wiki/documentation/show/Addressing%20the%20end-of-life%20of%20AArch32

Someone has given the matter serious thought.

Those of us around back in the ’90s may remember Sveinung as Pixeleyes if they were on the IRC #acorn channel, and they used to post on the csa.* usenet newsgroups.

(gerph)

Here’s my €0,02:

It is good to see stuff being rewritten in C as it is a slow but careful move away from piles of assembler that fewer and fewer people understand. This can aid with maintainability down the line.

However, I do not think that it has any real relevance to any sort of 64 bit incarnation of RISC OS. For starters, the processor is entirely different in behaviour, so the old API (billions of SWI calls tightly bound to passing stuff in registers and/or on the stack) will need to be ditched. Indeed, if we go for a basic operating system written in C (please, let’s not repeat the past and even think about any more assembler than is strictly necessary to bring up the kernel and fudge for exceptions), then it may be that we’ll need to have an alternative to the SWI call mechanism? I’m not at all familiar with how Linux handles linking modules/libraries into programs, but it’s something we’ll need to think about.

This is, of course, assuming that it is even viable. I feel the most likely direction will actually be to run a 32 bit RISC OS within some form of partial emulation. This is because writing a brand new OS from the ground up is hard. There aren’t actually that many such things as a modern multitasking OS, and history is littered with forgotten attempts that, for whatever reason, got left by the wayside.

Don’t waste your time even imagining putting any form of RISC OS on a phone. Microsoft failed in that market. If they couldn’t cut out a niche for the Windows phone, what the hell hope do we have?
Plus, to be any use whatsoever in the context of a phone, it’ll need to be locked down tighter than a nun’s chastity belt, and frankly RISC OS fails that sort of security in every way imaginable.

My personal belief is that RISC OS may have a better future being a little lightweight embedded OS with a UI that people don’t even need to know what’s running “under the hood”. Bush tried to do such a thing with their Internet box back at the end of the ‘90s, and it might have had some sort of traction if it wasn’t dumbed down to the point of being damn near unusable. Obviously “the web” isn’t a place RISC OS can play these days, it’s far too computationally involved. But the point remains. A POS device, something for handling stock/checking in a library, whatever. Just one of those “things” that the end user uses and doesn’t have to do anything other than turn it on.

Back around 2009 or so, I got myself a little ARM9 based PVR that could record SD video (the datasheet was ‘optimistic’ so it actually did 720×288 because while the chip had the throughput for handling full frame video, it didn’t have the power to do that and maintain the operating system that was actually tossing the data to a USB stick!). Anyway, a later firmware version switched from the nano windowing system to Qt4 (I think), and as part of that, it needed to hijack the CF slot because the built in 16MB of flash was not big enough to hold the OS.

I think 16MB is more than enough to hold all of RISC OS uncompressed as well as a tiny disc image to supply a prebuilt stripped down version of !Boot and whatever the desired application code would be. Because, as I said, RISC OS is lightweight.

Or how about those little IP cameras that you can pick up cheaply (that, these days, seem more about sending data to China than anything else)? They are often based around a video chip hooked to one of those MIPS all-in-ones that has the processor and WiFi onboard. Well, if a video camera driver existed for RISC OS, and some sort of server that supported stuff like RTMP, than that could be another possibility for RISC OS? Basically a set-and-forget device that can just get on with the job for those who want that, but be able to be tweaked for those who understand what RISC OS is.
(oh, and even RISC OS is liable to be more secure than many of those IP cameras!)

go 64-bit or disappear as a platform in a few years

Hmm… I look at it like this: the platform has pretty much disappeared. It’s in the past. It’s over. Acorn, like anyone else who wasn’t Microsoft or Apple, didn’t survive. In fact, Apple had a pretty close-call at one point, and Microsoft had to lend them a lifeline!

What we have is a bunch of people who enjoy the quirkiness. I don’t think we need any delusions of what is possible. Forget that. Just enjoy what we have. And if people want to tinker with things, then that’s great.

I don’t see a great deal of difference between playing with RISC OS 5, and getting an old A310 with RISC OS 2 working, or even restoring a BBC Model B or Master 128. In fact, the 8-bit machines probably have a larger following!

This is in no way a message of doom, though. I say embrace it!

> Those of us around back in the ’90s may remember Sveinung as Pixeleyes if they were on the IRC
> #acorn channel, and they used to post on the csa.* usenet newsgroups.
>
> (gerph)

Hi there. Long time no see. 8) Still haunt E. Hills now and then.

I like the extra speed and memory of my Pi4, but what I really value about RISCOS is the fact that it runs BBC BASIC, !Zap, and !Draw – which all do things I find useful, and with which I’m familiar, which saves an old git like from having to get familiar with alternative ways of doing those things on other platforms.

I’m also rather of the opinion that !Draw and !Zap do what they do rather better than packages I’ve encountered on other platforms – including some bloody expensive packages I’ve only encountered because they’ve had them where I’ve worked. I don’t think that’s just familiarity, whereas I’m pretty sure it’s just familiarity with BBC BASIC that prevents me bothering to learn other languages. Oh, it’s better than Fortran IV or COBOL or various other languages I used in the dim and distant past, but whether any new languages are better? I’m an old git and I don’t care any longer.

If I could have BBC BASIC, !Zap and !Draw on any other platform, or in RISCOS on AArch64 or wherever, I’d be happy – as long as BBC BASIC could do all the WIMPy things it can do in the RISCOS desktop…

Good to hear you were an Acorn devotee, as you’ve not been a RISC OS user since the early 2000s. What’s brought you back to this forum?

Some three weeks ago I went to buy a Raspberry Pi 4 board to work over VNC as a bridge to a DAC but they were sold out and will be so for a long time, allegedly. And I really looked forward to running RISC OS again, warts and all, remembering the joy of using the productive GUI for DTP/gfx.

The occasion led to a study of RISC OS 2022 status, and found it as if put in amber, frozen in time, while the CPU architecture it’s based on (welded to the 32-bit silicon, more like) has moved on into new realms of excellence/state-of-the-art performance, even used in supercomputers (Fujitsu’s A64FX in the Fugaku). Wow.

Writing RISC OS in C will hardly be much slower than assembler running on 2-3GHz CPUs. A millisecond or three per second – will one even notice that? The gains far outweigh the losses. And RISC OS “quirks” (mostly hailing back to a time they weren’t) dealing with security/firewalls and some other issues, can be adressed through a maintainable rewrite in C along with an update to the SDK (which currently is “a nightmare” according to some very experienced people, compared to other SDKs). Housecleaning.

This RISC OS – it’s core anyway – can be written to be stable, secure and update-able on any device having an Arm CPU. Custom GUIs suiting the different devices can be made. And desktop workstations with multi-SoC performance one only can dream of can run the RISC OS GUI we love more or less as is. A version of that workstation’s motherboard can go into a Gamer Box (mass market) with expandable SOtA performance. The CPUs and GPUs to do this are, as mentioned, already here.

Some three weeks ago I went to buy a Raspberry Pi 4 board to work over VNC as a bridge to a DAC but they were sold out and will be so for a long time, allegedly. And I really looked forward to running RISC OS again, warts and all, remembering the joy of using the productive GUI for DTP/gfx.

Contact one of the RISC OS vendors – they have stock of boards, in boxes with storage and PSU, basically a ready to go system waiting for you to connect the display, keyboard and mouse (although you could buy those at the same time)

> Contact one of the RISC OS vendors – they have stock of boards, in boxes with storage and PSU,
> basically a ready to go system waiting for you to connect the display, keyboard and mouse
> (although you could buy those at the same time)

Not an option. It’s so cramped here that setting up the old Acorn gear is out. Intended to use the laptop (Acer Swift 3 running Fedora 37) over Ethernet to the RPI4 using VNC, RPI4 connected to DAC over a very short USB cable. Recon the sound will be a bit better than through a 5-meter long unshielded USB cable. If not I’ll at least have something to run RISC OS on again. On 1 core of 4.

I’ll look into RPI4 availability in other countries.

Not an option. It’s so cramped here that setting up the old Acorn gear is out.

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

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

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

Looks nice. Just had a look at https://i.mediatek.com/dimensity-9200 and wondered what 64-bit RISC OS would be like on that chip. Or rather several of them in a desktop workstation for >subject< and realized what it would take getting from 32-bit here to 64-bit there -

- a lot of very specialized programmer work decoding/translating ArmV1 assembler into C commands reflecting 64-bit ArmV8/9 core functions which probably must be written in a (64-bit) Linux system with loads of open source libraries at its disposal. So must know C expertly and old/new ArmVs. The Sixteen Men of Tain. ;) Guess you know who you are, but are you in a position where you can be paid by going rates to do what must be done (long list)?

How would you define a viable computing platform? Would it be something like “A platform with 1) an unique core/kernel with its own resources with 2) a nice user-friendly GUI on top of that, plus 3) a programmer-friendly software developing environment (editors, libraries, compilers) and 4) a userbase numbering more than say 100000 or more.” -Can’t be far off the mark?

I’m given to understand that current 32-bit RISC OS matches 1, 2 and maybe 4 well but not at all 3.
That’s a surprise to me, but “rewrite” (except the GUI functionality) appears to be legion in this situation if there is a wish at all to go 64-bit, let those who want stay on in the 32-bit swamp, no hard feelings. Sure wish some Arm people would take an interest in this endeavor, if for nothing else for old time’s sake. Plus it’d be a laugh. And even new nifty 64-bit hardware, maybe. For Work and Diversions.

let those who want stay on in the 32-bit swamp, no hard feelings

I’ve no particular desire to stay in the 32-bit swamp, but it does work – if a working 64-bit RISCOS really comes into being, I shall be Very Happy, of course, and would be willing to spend a bit of money on it (but not a lot – I’m a pensioner…). I’d be happy to help with development, if I had any relevant skills, but sadly I very much doubt if I have. I fear it’s all a bit of a dream, really, but I’d be very happy to be proved wrong.

Yes, dreaming of the future is good for us. But we need less of what could be and more people willing to help, whether contributing to a bounty, getting stuck in with coding, reviewing documents, or something else.

Otherwise, again, we spend time and energy completing another cycle of the same topic dressed up as something else; the net result is a good discussion and zero progress towards the goals.