Help Propel The Original ARM OS Into The Future

We use ARM devices in everything from our microcontroller projects to our laptops, and many of us are aware of the architecture’s humble beginnings in a 1980s Acorn Archimedes computer. ARM processors are not the only survivor from the Archimedes though, its operating system has made it through the decades as well.

RISC OS is a general purpose desktop operating system for ARM platforms that remains useful in 2025, as well as extremely accessible due to a Raspberry Pi port. No software can stand still though, and if RISC OS is to remain relevant it must move with the times. Thus RISC OS Open, the company behind its development, have launched what they call a Moonshots Initiative, moving the OS away from incremental development towards much bolder steps. This is necessary in order for it to support the next generation of ARM architectures.

We like RISC OS here at Hackaday and have kept up to date with its recent developments, but even we as fans can see that it is in part a little dated. From the point of view of RISC OS Open though, they identify support for 64-bit platforms as their highest priority, and to that end they’re looking for developers, funding partners, and community advocates. If that’s you, get in touch with them!

33 thoughts on “Help Propel The Original ARM OS Into The Future

  1. without support for memory protection, there’s a pretty low ceiling to the level of software complexity I’m willing to develop and support on it as a platform. without memory protection it becomes impossible to self-host debugging tools.

    1. It has an MMU with basic userland memory protection, but unfortunately there’s also a ‘kernel’ extension mechanism where you can load relocatable modules. These run in supervisor mode without memory protection, and a huge amount of software uses these. Like, even the BBC BASIC interpreter is an RM, with only the program storage and workspace actually stored in protected memory.

      The underlying RISC OS operating system is actually extremely simple, and rather ad-hoc. A while back I did a Linux binary loader for RISC OS and made a number of discoveries. I already knew there was no preemptive multitasking, for example. But I also found that address 0 is valid memory because there are user-accessible read-only kernel variables there, so NULL dereferences don’t cause traps. Another suprise was that when you do an allocation through the supervisor mode memory allocator, it looks up the stack for certain addresses. This is so that it can check whether it’s being called reentrantly, at which point it uses a different heap — because you’re allowed to do memory allocations from interrupt handlers!

      1. Given the size of the development team, and the era it was developed, it’s very impressive. Unfortunately, that very thing is what makes it so difficult to bring “up to date” 40 years later.

      2. “It has an MMU with basic userland memory protection” that makes sense, given the original ARM2 architecture had an MMU which was usable for user land VM and protection, but less so for supervisor and kernel modes. I did some investigation into a toy OS I call TAVMOS™ (Toy ARM VM Operating System). Even for that, a single MMU is still pretty awful, because managing more than 512kB of VM space requires increasingly ridiculous page sizes up to 32kB.

        I guess even with the improved 32-bit ARM, MMU, RiscOS inherited these kind of design decisions.

  2. “No software can stand still though”
    Pico (which was then copied as GNU Nano) is still as relevant as ever. Even with GNU Nano, only minor changes have been made for decades, not a decade but decades plural. Not a good example? Well how about Windows Notepad?

    There is such a thing as finished software but it’s not flashy and people don’t think much about it.

    1. I Agree! I use “Hyperterm” by Hilgraeve (related to HyperACCESS) on a daily basis, a version which hasn’t been updated or maintained for decades. Original release ~1985.

  3. is RISC OS based on a linux?

    AI Overview.

    No, RISC OS is not based on Linux; it’s a separate, independent
    operating system originally designed for Acorn’s ARM-based computers.

    is RISC OS multitasking?

    AI Overview.

    Yes, RISC OS supports multitasking, specifically using a cooperative
    multitasking system, meaning applications must voluntarily relinquish
    control to allow other applications to run.

  4. Now for the real question, which seems to be unanswered here and there:

    Why?

    … would you want to use this instead of e.g. debian Linux?
    … should you therefore be interested in supporting to bring “carefully crafted 32-bit assembly language” into the future?

    1. hy?

      Unless you have used the OS in the past and were feeling particularly nostalgic, I can’t really think of a reason?

      The OS itself is rather basic, even if you ported it from ARM32 assembler to C (for an ARM64 bit port), the OS is still single user, single core, single process (kind of, the kernel is only aware of one process, it’s just that one process can be the ‘Wimp’ that provides co-operative multitasking (not pre-emptive)), barely any memory protection, no separation between user-space and kernel space APIs (privilege escalation isn’t a bug, it’s a system call any application can use). The closest architecturally similar OS that people might have heard of is DOS with Windows 3.1.

      They are asking for 2.5 million UKP (~3.2 million USD) for the port of the code from assembler to C (for ARM64). Over the past 15 years they have raised ~100 thousand UKP (~130 thousand USD) from public contributions.

      Given the aged userbase of RISC OS, ROOL have even started asking people to leave them bequests in their will. The whole thing feels delusional and skeezy.

          1. See, all it does is raise questions. So you got no answer either, that tells me there is something to the validity of my original question. I still would like to know.

            BSD: security driven server usage
            Plan 9: distributed computing simplified
            Haiku: no answer. Although I saw one of the earliest BeOS prototypes and thought it was cool and might be a real multimedia OS, but that lead to nothing — so it’s in the same league as RISC OS, noone knows what to actually use it for .. TODAY.

        1. Oh, well.

          Why would you want to use this instead of e.g. debian Linux?
          Probably because it will be more efficient because tailored for you CPU?
          Can you do as much? porbably not. But for some tasks or embeded, it’s probably the best you can have.

          Why should you therefore be interested in supporting to bring “carefully crafted 32-bit assembly language” into the future?
          To maintain compatibility?
          So that you can patch security more easily, or add new functions.
          Or to make legacy software run on 64bits CPU.

          Basically, why half the current computer world is designed for, retro compatibility.
          Just ask any bank what programming language they use for their backend, you will be surprised…

          1. I doubt a bank would be running their COBOL code on a RISC OS ARM desktop machine. And if they did — there would be no need for a new updated system, they would be using the same stuff they did 40 years ago.
            Don’t get me wrong, the demise of 32bit desktop OS variants isn’t a great thing. But getting an old handcrafted assembly based OS up to 64bit speed with young developers has a lot of potential to create just another big monstrous OS like the others we are using. Still looking for the “why use it in the first place” point.

    2. IMO, the primary reason for continuing to work on an old code base, RISC OS in this case, is that every different OS embodies its own set of ideas. Some aspects of the OS that make it awkward in terms of portability are an outworking of those ideas. Secondly, an OS, like a CPU is an expression of human creativity and therefore has an inherent value even if it’s less popular.

      If that wasn’t the case, everyone would simply run Windows, surely?

      1. is an expression of human creativity and therefore has an inherent value

        Why would something being an expression of human creativity give it inherent value?

        Counter-example: a war is an expression of human creativity, namely, creating conflict.

      2. If that wasn’t the case, everyone would simply run Windows, surely?

        I think that doesn’t follow. If something has value, does that mean it’s the same for everyone?

    3. Why Ubuntu when Debian exists?

      Why Linux when Unix exists?

      Why ARM when x86 exists?

      Why AMD when Intel exists?

      Having more than one option is a good thing. If one option is clearly better for almost everyone, then the better response is to make the inferior options better rather than just accept that there’s only one good choice.

      1. Cad, I can answer all of those, easily.

        It’s not about reducing choices, I am all for those. But I would like to hear a solid pitch for RISC OS instead of just “because it refuses to die”. Their website just mumbles about “history” and “organisation” and whatnot. That’s not even a reason to install an app, even less so an operating system.

    1. You posted that so I didn’t have to. I still remember upgrading our Archimedes 310 to RISC OS by swapping the ROMS. Progress, but I missed the blue and cream.
      Wonder if a Raspberry Pi could run Arthur still.

      1. I doubt Arthur ever progressed beyond the original 26*-bit ARM CPUs.

        *26 bits for the program counter, the remaining 6 bits were used as a program status register until a proper 32-bit implementation arrived with ARMv3

  5. I reached out to the RISCOS folks a while back to see if I could sublicense the Norcroft compiler suite and get the source code to use with old ARM6 based systems. Or at least put me in contact with whoever in ARM they worked with for the licensing. While they responded they weren’t particularly helpful and my attempts to contact ARM have not really worked out either. The former Codemist folks have the source and are open to releasing it but ARM has exclusive licensing rights.

    I don’t know what kind of market there is for RISCOS but I’ve found my part of the pre-ARMv4 space to be almost completely abandoned and even the IP holders are uninterested. My guess is the best bet would be to open as much as can be and try to build the community or find a new hobby/side gig.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.