RISC OS Open
A fast and easily customised operating system for ARM devices
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → Aldershot →

The long term future of RISC OS

Subscribe to The long term future of RISC OS 72 posts, 27 voices

Posts per page:

Pages: 1 2 3

 
Feb 8, 2018 2:32pm
Avatar Patrick M (2888) 77 posts

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

 
Feb 8, 2018 2:54pm
Avatar Rick Murray (539) 7571 posts

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.

 
Feb 8, 2018 6:53pm
Avatar GavinWraith (26) 852 posts

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.

 
Feb 8, 2018 8:31pm
Avatar Chris Evans (457) 1438 posts

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!

 
Feb 8, 2018 9:07pm
Avatar Rick Murray (539) 7571 posts

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!

 
Feb 9, 2018 3:26pm
Avatar Steffen Huber (91) 1152 posts

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 :-)

 
Feb 9, 2018 11:01pm
Avatar nemo (145) 1396 posts

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)

 
Feb 10, 2018 7:41am
Avatar Clive Semmens (2335) 1361 posts

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?

 
Feb 10, 2018 11:12am
Avatar nemo (145) 1396 posts

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.

 
Feb 10, 2018 12:12pm
Avatar Rick Murray (539) 7571 posts

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 veroboard1, one of these chips, and it’s all there…

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

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

 
Feb 10, 2018 2:31pm
Avatar Clive Semmens (2335) 1361 posts

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.

 
Feb 10, 2018 9:02pm
Avatar nemo (145) 1396 posts

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).

 
Feb 11, 2018 3:37am
Avatar Tristan M. (2946) 873 posts

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.

 
Feb 13, 2018 4:20am
Avatar Alan Robertson (52) 293 posts

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!

 
Feb 13, 2018 8:14am
Avatar James Wheeler (3283) 344 posts

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.

 
Feb 13, 2018 11:59am
Avatar George T. Greenfield (154) 396 posts

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?

 
Feb 13, 2018 1:13pm
Avatar Rick Murray (539) 7571 posts

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…

 
Feb 13, 2018 1:43pm
Avatar John Sandgrounder (1650) 372 posts

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

and users

 
Feb 13, 2018 2:15pm
Avatar Jeffrey Lee (213) 5289 posts

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?)

 
Feb 19, 2018 1:04am
Avatar Bryan Hogan (339) 312 posts

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!

 
Feb 19, 2018 7:25am
Avatar Clive Semmens (2335) 1361 posts

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!

 
Feb 20, 2018 12:40am
Avatar Jeffrey Lee (213) 5289 posts

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? ;-)

 
Feb 20, 2018 5:57pm
Avatar Patrick M (2888) 105 posts

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.

 
Feb 20, 2018 8:10pm
Avatar Steve Pampling (1551) 4319 posts

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…
 
Feb 20, 2018 8:11pm
Avatar Bryan Hogan (339) 312 posts

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 :-)

Next page

Pages: 1 2 3

Reply

To post replies, please first log in.

Forums → Aldershot →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

Everything with nothing particularly or remotely to do with ROOL.

Voices

  • Patrick M (2888)
  • Rick Murray (539)
  • GavinWraith (26)
  • Chris Evans (457)
  • Steffen Huber (91)
  • nemo (145)
  • Clive Semmens (2335)
  • Tristan M. (2946)
  • Alan Robertson (52)
  • James Wheeler (3283)
  • George T. Greenfield (154)
  • John Sandgrounder (1650)
  • Jeffrey Lee (213)
  • Bryan Hogan (339)
  • Patrick M (2888)
  • Steve Pampling (1551)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys