The long term future of RISC OS

Hello,

A while ago I read a post by Rick Murray that RISC OS would likely never get ported to the 64bit version of ARM because it’s so different from the 32bit ARM.

This makes me worried about whether or not RISC OS will be around for much longer. Is it possible that ARM processors would drop support for 32bit ARM? Or is that unlikely to happen? I don’t really know anything about ARM architecture or processor instruction sets.

Is it likely that RISC OS will still exist 10 or 20 years from now? I mean in the sense of it being maintained and available for use on (relatively) inexpensive and up-to-date hardware.

Regards,
- PM

Nobody has a crystal ball so it’s hard to predict a decade in advance. For an idea, I never thought I’d see RISC OS on a gigahertz processor with loads of memory, a machine costing less than a meal out.

Remember, Thumb is still around. And I think that while there will be less support for 32 bit, I don’t see it dying out in a hurry either.

Acorn computers started out making laboratory equipment, and this meant that their products were ideal for the amateur who wanted try their hand at low-level programming. When the early ARM processors replaced the more primitive 6502, and RISC OS was designed to accompany them, the Archimedes was a very attractive machine for the enthusiastic amateur. Since then computer systems in general, and CPUs in particular, have become a lot more complex. Gone are the days when the keen programmer could write optimizing code with the BBC BASIC assembler and reckon up, fairly precisely, just how many microseconds that code would take. These days it makes more sense to leave all that to a compiler, because the behaviour of CPUs is no longer a playground for amateurs. That does not mean that RISC OS is no longer of use; just that it will have to do a slightly different job for the amateur enthusiast. It also means that the porting and adaptation of software tools to RISC OS becomes a critical factor in its future, IMHO.

8 bit processors are still being made. I think RISC OS compatible 32 bit ARM CPUs will be available in fifty years time. I may not be around by then!

I was at work so didn’t have time to elaborate, but there is a place for 32 bit ARM. A place where you want the native power of ARM without the compromises inherent in Thumb, but you don’t need the raw power of 64 bit, nor to have the expense of laying out 64 bit interconnects. Remember, Thumb was originally born from a desire to have all that’s good about the ARM, but in a cheaper hardware design using 16 bit Flash and memory and having that on the board instead of a full 32 bit bus. The birth of the integrated SoC has made a lot of this moot (though note that the later Pi devices don’t use stacked memory).

As Chris says, 8 bit processors are still around doing simple jobs. A fair few of the cheap MP3 players (including those capable of playing AMV video) are actually based upon a Z80 core (clocking something like 20-80MHz) with a DSP unit attached. And when I say Z80, I mean 64K addressing with memory banking like the Master128 did. If you have a bread maker, it’s probably some incarnation of the 8051. Central heating? That can probably be handled by a PIC…

Taking over from the eight bit devices is the ARM Cortex M series. The Thumb cores. My drone isn’t a complicated beast, but it needs some processing power to handle user input (via radio) and gyro stabilisation, and work out how to run (PCM, I suspect) for motors to achieve the desired result of stable flight. It’s an M0 chip.

The extreme other end is a modern smartphone or tablet. We don’t want to look at webpages, we want to record QHD video at 60fps flawlessly, and have a smooth user interface while that’s happening. We want to play complex games that adapt in realtime to the environment around the user. 64 bit isn’t just for server farms, it opens up possibilities to make the stuff a modern phone can do… seem effortless.

The Pi, on the other hand, demonstrates why there will be a place for 32 bit yet. The older ones could quite happily show full HD content (via OSMC etc) even with a seemingly slow ARM core. How? Easy. The ARM core run a stripped down operating system that more or less just dealt with getting data in the right place for the GPU to deal with. That’s sorry if how my ancient (ARM926) PVR can record SD TV in realtime with a 200MHz ARM – it’s basically the housekeeper and butler, something else does the heavy lifting. And as such, I do expect to see ARM32 continue into the foreseeable future as there are plenty of cases where something would want to run a “real OS” (which means some incarnation of Linux, these days) but doesn’t require a lot of grunt, at least not from the ARM side.
Either that or ARM will give up on ARM32 and basically hand the entire midrange market to MIPS (you’ll find those in many cheap WiFi enabled devices (media sharers, bridges, IPCAMs, etc); the ones that aren’t running ARM, that is…!).

Or, as Elon Musk had programmed into his flying car’s display: Don’t panic!

I think the 64bit/32bit thing is ultimately not the deciding issue. We have emulators, we have existing hardware that will last a long time. RISC OS runs only on a selected few boards anyway, we have specific needs if we want to port RISC OS to a new SoC. Even if all future SoCs would still support the 32bit ARM architecture, it might be (next to) impossible to port RISC OS onto them.

On the other hand, we have the “RISC OS on Linux” project by Timothy, which could be the ultimate solution for everything :-)

I concur. Emulators FTW. There will always be 32b ARM cores available, but they may not be in a device you’d want to use. For example, there are still 6502 cores around… inside talking greetings cards.

(Lovely devices, the Sunplus chips. They’re actually 2/3 of a 6502)

Which 2/3? And what, if anything, else is on the chip? Do you have a link to their spec and a source? Are they readily available to Fred in a Shed?

Oops, SunPlus have now spun those devices out into a separate company called GeneralPlus. Who knew.

All of the 8bit products on this page are 6502s: http://www.generalplus.com/1LVlangLN14SVprot_noSNproduct

Click on the CPU class (such as GPC1) and then on an individual part number.

There’s a VAST range of devices, depending on core CPU, number of ADCs, IOs, PWM, ADPCM, ROM size etc. Don’t expect a lot of on-board RAM though. For example, this monster:

The GPC3680A is embedded with an 8-bit processor, 2M bytes Working ROM, 128-byte working SRAM, three sets of 12-bit timer/counters, twenty-four general I/Os, a 3-channel mixer, a pair of 12-bit PWM outputs and a Real Time Clock(RTC). The microprocessor can implement software based on audio processing, functional control and others. For audio processing, melody and speech can be mixed into one output. It operates over a wide voltage range from 2.0V through 5.5V, and it includes Low Voltage Reset to assure system operating appropriately under low voltage condition. In addition, GPC3680A also provides sleep mode for power saving. With the high cost/performance, GPC3680A is one of the most suitable engines in the industry for vocal products.

Or something more specialised:

The GPRT5507A integrates an 8-bit CPU, speech generator, segment LED driver, analog switches, programmable attenuator and a gain amplifier into one chip. The GPRT5507A includes a 40K-byte ROM, 128-byte working SRAM, 4 edge-mode interrupts and a fixed time based generator (FCPU/1024)*. This chip which incorporated with 1 or 2 pieces of 4M X 4 ARAM, can be applied to the versatile audio field, such as a language repeater.

I had a lot of fun creating a time-stretching wavetable synthesiser for a toy company on an 8MHz 6502 with only A and Y registers.

Damn!

I have wanted for some time to make a little 6502 device (CPU, 6522, ACIA…) just for the sake of doing so, when all I really need to do is grab a bit of veroboard¹, one of these chips, and it’s all there…

Are these things available to normal nobodies? How are they programmed?

¹ Yes, I am aware that there’s a 99% chance of these being surface mount.

Yes, I am aware that there’s a 99% chance of these being surface mount.

This Fred-in-a-shed has been known to attach a surface mount chip upside down on veroboard with epoxy resin and solder flying leads to it.

But seriously, although I have a nostalgia for 6502s – 17 of them in an asymmetric multiprocessor system was my high point – I don’t think I’ll ever work with them again.

There’s a number of different package formats. The development board I used had a separate 28pin EPROM, so that was convenient (once I’d built a carrier board for my Beeb-era EPROM programmer).

There are an obscene amount of things out there with a 6502 at the core. So it really just depends on what you want to do. Easiest solution would probably be just to use a 6502 based computer. That doesn’t fill the DIY urge though, which can be fun.

Teasing the conversation back to the original question ‘Is it likely that RISC OS will still exist 10 or 20 years from now?’

My thoughts is that RISC OS will easily be around for at least another 20 years. Sure, there are many aspects of RISC OS that are less than ideal, and indeed less than practical for the everyday user.

I don’t think RISC OS has found its purpose; it failed in the desktop market. It failed in the NC market, it failed in the STB market. But yet it is still being developed and is vastly better than it was even 5 years ago.
You’ve got to ask yourselves, if RISC OS has all the fundamentals in place; Security, Internet, Filing Systems, Connectivity, Multi-core/processor support and 64-Bit, why would it not survive?

Yes, it’s a lot of work, but it can be done. We have some amazing low-level guys; ROOL, Sprow, JLee and Nemo to name but a few.

If this was Poker, I’d be all in!

You’ve got to ask yourselves, if RISC OS has all the fundamentals in place; Security, Internet, Filing Systems, Connectivity, Multi-core/processor support and 64-Bit, why would it not survive?

That is a ton of work. Once you factor in backwards compatibility, it’s almost impossible.

Once you factor in backwards compatibility

There’s the rub. But, given the wealth of available emulators (ArcEm, VRPC, RPCEmu etc) covering the 26-bit era, is there not a case for gritting the teeth and ploughing on regardless?

is there not a case for gritting the teeth and ploughing on regardless?

Personally, I don’t think compatibility should be broken for the sake of it (every break loses software), but it shouldn’t be a noose that forever ties is to the past…

Personally, I don’t think compatibility should be broken …. (every break loses software)

and users

I enjoy a good challenge, so part of the fun of working on RISC OS is in finding ways to implement new features without breaking (too much) compatibility with old software. Designing and implement a multi-core OS from scratch is child’s play compared to retro-fitting multicore support into an existing single-core/single-thread OS.

64bit is a task which is easily an order of magnitude greater. There are some limitations in the architecture on when & where 32bit-64bit context switches can occur, which will have a big impact on the design & implementation of the new OS (unless we want to cause compatibility issues on the scale of the 26bit to 32bit switch, or simply not support 32bit code). Plus there’s all the assembler code in the OS which will need rewriting in a higher-level language, and lots of questions to answer about exactly how things will operate (how are SWIs called from 64bit code? how are errors handled? how much can we change without making it difficult for developers to use the same source code for building both 32bit and 64bit versions of their apps? how do we handle interaction between 32bit and 64bit programs?)

With apologies for the short notice, we will be talking about this at ROUGOL later today (Monday 19th Feb):
http://www.rougol.jellybaby.net/meetings/index.html

All welcome to come along and join in the discussion!

Sadly, anything that starts at 19:45 in SE1 would be difficult for me, as my last train home leaves Kings Cross at 22:44 and the return trip costs me £31.20 – not trivial for a pensioner!

With apologies for the short notice, we will be talking about this at ROUGOL later today (Monday 19th Feb)

So did you manage to solve all of our problems? ;-)

If necessary in the future, perhaps we could come together and produce our own 32bit ARM processors specially designed & intended for use with RISC OS. Maybe we could get help and funding from Richard Branson.

And I suppose that in the worst case scenario, we can still keep using RISC OS on our old Raspberry Pis. The Raspberry Pi is apparently the best selling British computer of all time, so there should be spare second hand Raspberry Pis available for a long time to come. Perhaps we should start stockpiling old/original Raspberry Pis.

So did you manage to solve all of our problems? ;-)

:)
Discussions are good.

At work:

1. People identify something that needs doing/fixing
2. Senior managers discuss the item and agree how to deal with it
3. People in our office do what will actually achieve the result (sometimes matches the agreement in point 2)
4. We document the setup in parallel with point 3 and bung it in the ISO Quality documentation.
5. Time gap
6. S.M discover the difference and we point at the setup and documentation being in agreement – and it’s in the quality manual…

my last train home leaves Kings Cross at 22:44

That’s not a problem as the main part of the meeting finishes by 21:30 at the latest.

and the return trip costs me £31.20 – not trivial for a pensioner!

But not much we can do about that :-( except suggest an OAP railcard!

So did you manage to solve all of our problems?

IIRC the answer was 42, but unfortunately the pub was destroyed to make way for a hyperspace bypass before we could write down the details :-)