Bringing the first native OS for Arm back from the brink The mid-1980s codebase for RISC OS, the original native OS for the Arm processor, is still run on present-day hardware and actively maintained and developed. We spoke to RISC OS Open boss Steve Revill about its 26-bit origins, working to bring it to newer 32-bit Arm chips, efforts to update its BSD-based network stack, and more …
If we didn't include a transcript, some would say they need it because they can't watch the video for whatever reason. And if we include the transcript - which is handy for Google indexing too - then some say it's in the way.
We've moved the transcript to a second page for now. Hope this helps.
C.
It would seem from the observations made by Steve Revill, RISC OS Open has gained alot of real-world experience on this process; I wonder whether this has been documented and thus available to a larger audience.
If not, perhaps this could be a basis of a PhD thesis...
This post has been deleted by its author
There isn't much profit in Risc OS. You can't sell it to most people who want any level of app compatibility, and the people who understand its limitations and still like it also know that you can get it for free if it's open source. Some of the skills required to get it and maintain it are skills that someone would pay for, but they would be paying someone to use the skills on something unrelated, the same way that if all the developers currently working on Android ROMs for mobile phone manufacturers turned their attention to mobile Linux we'd have a great product that runs on everything, but those people are either not interested or too busy doing work that actually makes money.
I still look fondly on RISC OS, and indeed am considering going to the Southwest Show (25 Feb.) to see how it's getting on.
The Archimedes was the first (probably only) computer I really got to understand at all levels, even down to writing some ARM code that could handle 128 large completely independent sprites with full collision detection - using BBC BASIC's in-line assembler.
I think a port to 64-bit ARM should try to rewrite as much as possible to a high-level language, so it can be recompiled on other platforms. Some parts of the kernel may very well need to be written in assembly language, but this should be minimized, perhaps by refactoring the kernel to separate the hardware-dependent parts from the hardware-independent parts.
An interface that allows Linux or BSD drivers to be used with RISC OS would also be useful, as it would open up a lot of external devices. Something that can use graphics processors effectively (such as OpenGL and OpenCL interfaces) would also be nice.
While my first computers were a BBC Model B, an Archimedes 400, and an A5000, what I loved about RISC OS was not so much that it ran on ARM, but some of the features it offered that no other OS at the time did, and few do today:
- A font manager and anti-aliasing renderer that gave identical (up to resolution) output on screen and print. Printing was a bit slow, as a bit map was sent to the printer, but the benefits were enormous.
- A common interface for saving and loading files by drag-and-drop.
- Applications-as-folders.
- File types that do not depend on file-name extensions. I wish this had been extended to folder types too, so we could avoid the ! in application names.
- Select, Menu, and Modify Mouse buttons. Especially the pop-up menus are nice.
- Easy-to-use graphics. The effort it takes to open a graphics window and draw a line on other systems is just ridiculous.
But RISC OS is lagging increasingly behind other systems, especially where device support is concerned. It also has poor security. The main reason it is not infested with malware is that nobody bothers to make it.
"File types that do not depend on file-name extensions"
The Amiga had IFF (Interchange File Format) 2 years before Arthur was released - whilst many people just associate IFF as a format for storing bitmap images (because by and large that'll have been the most likely/only contact they had with IFF files) as the name suggests it was a generic format for storing any type of data within a file and allowing the OS or handling application to determine what the format was based on the header data within the file.
Not to take anything away from the immense achievement that the Archimedes was as a complete system mind - to this day I still remember the first time I saw one, after going round to my best friends house following him phoning me up to say he'd upgraded from his old BBC Model B and did I want to come round to see the new computer... Little did I know what I'd be experiencing when I arrived - having spent 4 years immersed in the world of 8-bit home computers using his Beeb and my 48k Spectrum, and reading about these weird other things (C64s, Dragons, Orics etc.) in the magazines, to suddenly come face to face with an Archie. Mind blowing. After that I was desperate to upgrade my own setup, resulting in an Amiga 500 landing on my desk about a year later, which was equally mind blowing.
I'm immensely thankful I was around to live through those epic early years of the home computing revolution, all the way through to the late 90's and the introduction of 3D accelerators. However these days I'm conseqently rather less impressed with newer developments in home computer tech, as it feels like we've swapped genuinely innovative approaches with a more btute force means of bringing in improvements - every year we get ever faster CPUs and GPUs, but essentially the PC that's sat in front of me today is barely any different from the first one I built 25 years ago. And the less said about how much of that power is sucked out of the system through badly performing software, including the OS itself (apologies to Linux etc. users here, my perspective on PCs remains firmly rooted in the Windows world here for various reasons) the better - when you think back to that period in the mid-late 80's when things like the Amiga and Archimedes were launched, and consider just how much performance they were able to wring out of hardware that today wouldn't even register as a flicker on the graph of total processing power within a system, it's utterly depressing to realise where we could be today if the same level of performance for software vs the underlying hardware had been maintained throughout.
Sigh, time to crawl back into my old grumpy man cave methinks...
"However these days I'm conseqently rather less impressed with newer developments in home computer tech"
That's how I feel about phones, to be honest. The period sort of 2010 to 2020 had a lot of development. My first smartphone was something like 800x600 in a weird stretched format and it could record VGA video.
My current phone has a screen with so many pixels I set it to half resolution (makes the battery last longer) and it doesn't make any discernable difference. It is nippy, responsive, has loads of memory, and a camera that can record 4K. Actually, it can do 8K but the files are stupidly massive. And...it isn't even a flagship. It's just a middle of the road not-crap modern smartphone.
"it's utterly depressing"
If you would have an Android phone, poke around the application settings. Yes, that simple application really is taking up a quarter of a gigabyte, and yes it really does have a few hundred megabytes wasted in cache files that it seems incapable of tidying up for itself.
As somebody who once, a long time ago, hand wrote something in assembler and even worked out the instruction timings... the sheer horrific wastage of resources is... utterly depressing.
When you make it back to your man cave, please put the kettle on. I feel I need tea.
Did you just step inside my brain to write that? Other than my first smartphone being even older than that (SPV E200 from the early 00's with a 172x220 screen - but compared to the Nokia 3510 I'd been using beforehand, it was like having an entire computer in my pocket, awesome stuff), I'm reading it nodding and mm-hmm'ing away to myself in complete agreement and understanding.
Thinking about the state of modern tech, probably the only thing I've experienced in recent years which has had that same wow factor for me was when we got a Quest 2 headset - up till then my only hands-on experience with VR had been via those passive headsets into which you fit your phone, which could be quite impressive given the right source material (flying backseat in a Blue Angels F18 during a display was one I particularly recall as showing the potential of VR), but which was still limited by its reliance on the phone sensors. So to pull on the Quest 2, pick up the controllers, and for the first time ever actually get that sensation I was IN the VR environment rather than merely sat watching it, did manage to break through my curmudgeon-wall (like a firewall that blocks new fads from polluting your personal comfort zone :-) and impress me. One game of Beat Saber later and I was like, hell yeah, more of the same please!
So yes, there ARE some breakthrough technologies (or at least ones which have been around for ages but where the underlying tech has finally caught up to their expectations/requirements so that they're now actually worth using) still coming along, but not so much in areas where those of us of certain ages used to experience them on a regular basis. Maybe in 20-30 years time the youngsters of today will be getting retro vibes about things like the Quest, paying small fortunes to get their hands on still-working examples, whilst the youngsters of the day go "ok granddad, you play around with your clunky old white box that you have to strap to your forehead, I'll just jack into the matrix and get my VR kicks that way thanks all the same"...
Anyhoo, kettle's boiling, how strong do you want your tea?
As much as I agree, gigabytes and using APIs on top of APIs are percieved to be cheaper than hiring low-level programmers to write tight code. Security "patches" and maintenance of apps then become dependent on managing interdependencies of all the dozens of underlying APIs. Basically no software in API land can ever be "really" up to date.
Whereas something monolithic and lacking dependencies can last for years if not decades. Though often lacks eye candy.
Tediously: the 1984 Macintosh did file types and application associations as resource fork key/value pairs, allowing per-file associations and not putting any trace of the type into the file’s name. I doubt it was the first, and — to be overt — RISC OS was way ahead in uncountably many other areas.
I agree. Any future RISC OS really ought to be processor agnostic. Linux has demonstrated that it is possible.
Printing was slow using bit maps (I'm nutty enough to have done it with a dot matrix), but once you got beyond the basic built in text styles it was all bitmap based. Postscript wasn't a known thing to domestic printers, and the hardware inside many of them was quite mediocre. Hmm, wasn't the original Deskjet 500 a souped up Z80 with barely enough memory to actually function?
What the font manager was especially good at was making comprehensible text at small sizes on crappy cathode ray monitors, like the 50Hz TV style ones that were popular when multisync cost the earth.
RISC OS is lagging vastly behind others, because they've had about twenty odd years of development. Think have many versions of Windows there have been in the interim. Hell, how many processor architectures has Apple been through in that time? Definitely needs some TLC, but it still works, it's still friendly, and it still has a better thought out UI than others I've seen.
And best yet, the general pace of development means that nobody is screwing with the entire UI every other year to shoehorn in the latest newfangled paradigm. Remember when everybody learned the word skuomorphism (to lament what was lost)? The buttons on RISC OS still look like buttons and like they did thirty years ago. That's hardcore consistency right there.
All my Pi's run RISO OS Open ever since I discovered it was still about. As a 90's kid I was schooled on RISC OS machines, and own an Acorn A3020 and RISC PC today (got the RISC PC before the prices on ebay went crazy). I also have an Acorn Electron.
What I love about all of this is:
- RISC OS was designed specifically with the GUI in mind, although there is a commandline, the GUI is a well designed and consistent interface. It does take a little getting used to as there are a few concepts that RISC OS created that are slightly unique. The middle mouse button is the most important of all for example.
- Today we all talk about flatpack and appimage etc, a way to package an application in one file. Well not sure if it was done earluer but thats how RISC OS did it from the 80's onwards! It's dead simple, each application is actually, a normal folder pretending to be the apps icon. You can enter the folder itself and see the apps files using a modifier key when double clicking. Inside are all the apps resources and libraries. As a kid it felt so natural to copy an app to a floppy disc and simplyt have it work on other machines, well now I know I was copying the ENTIRE app and its supporting resources, in one icon. This however is NOT perfect, there are some resources that need to be installed system wide in the RISC OS system directory. Doing that is a simple case of drag and drop, but there is no method to manage those changes. If you want rid of the ap, just delete its icon, but that system stuff remains. Further development is all thats needed.
- BASIC - My ACorn Electron, like its bigger brother the BBC MICRO use BBC BASIC, so does RISC OS. Although a much later version, BASIC still is there and will run the old code. But being a MUCH later version its is so much more capable. It is fully integrated with the OS, meaing that anyone can write a full featured GUI app in BBC BASISC using RISC OS's text editor. Many games and applications for the system are just that. The BASIC interpreter also proviodes an ARM assembler, machine code can be entered directly into a BASIC routine, this can also be done on the BBC micro etc but of course that would be a 6502 assembler.
- And here is one of my faves. On a RPI, the GPIO pins are accessible in BBC BASIC in RISC OS. In fact, besides writing in assempler I have seen benchmarks that show that BBC BASIC on RISO OS on the Pi has the lowest latency access to the GPIO pins, behind assempler/machine code. Great id you want to do some bit banging.
Of course there is more to do. RISC OS runs fine on any Pi, even a Pi Zero, but it can only use a single core. USB device support handles the basics, mice, flash drives etc, evan a USB floppy if you want but wifi NIC's are not yet supported well. Ethernet is.
Although Acorn never quite cracked the US market and its machines are little known outside Europe, the BBC Micro was a highly influential machine.
The BBC was an amazing machine, people were still finding new things to do with it in the early 90s. It also had a hand in the early ARM development. Stever Furber had an idea for a multi-CPU machine called the Proton. This never materialised, but the front half of the machine did, as the BBC, complete with the TUBE interface to the secondary CPU.
It was this that allowed it to be used as a host for the early ARMs with ease. (or as a DOS PC or Z80 CP/M machine, or just a faster machine for playing Elite).
There's a couple of (very long) interviews on Youtube, one with Furber and Sophie Wilson where they discuss the early years of ARM. Very interesting, especially when you realise they were essentially 'self taught' (as were all CPU architects back then I suppose).
One thing that never seemed to get much attention at the time is that Acorn were working on another chip, this went on to become Broadcoms Firepath, used in most of those BT green boxes for vDSL stuff.
I wonder where the developers see RISC OS in the future. No 64-bit, no SMT, no pre-emptive multitasking, no memory protection, no Wifi, no Firefox or Chromium, no Libreoffice, no mind share. It will be quite hard to make it useful again without (a) rewriting everything and (b) porting most of their apps from Linux (like Haiku does). And then you'd lose backward compatibility to RISC OS apps and the approval of many nostalgic fans. Still I wish them well. I hope they live for another 40 years.
When x86 PC adoption accelerated while Acorn became no more, it was sad for RISC OS.
I remember discussions on comp.acorn newsgroups. Newsgroups/usenet were the original social media AND decentrantralised. Mastodon et al is usenet 2.0, a progression of that.
Despite that decline, enthusiasts kept it going, as your article links to. And with the advent of the Raspberry Pi, bolstered this movement, though that is not the only modern ARM platform it can run on, so I've read.
It's not my daily main driver though. But long may that continue. Choice is good. And these days choice is a bit more recognised, with niche hardware such as ZX Spectrum Next, Commander 16. Add to this with more mainstream such as Android, iOS, Ubuntu capably doing jobs that Windows does.
Some challenges though: I read that it is still a single-core OS in that it doesn't take advantage of multi-core ARM chips.
Also the co-operative multitasking is not in keeping with pre-emptive multi-tasking operating systems which are the mainstream. Wonder where Dave Allison who worked at BT in Belfast is these days, I used EasyC++ which his brilliantly written GUI library. It actually had multithreading and a form of pre-emptiveness that sat on top of RISC OS, a mix of inline ARM assembly inside C++. His expertise could perhaps be used here in progressing RISC OS Kernel.
Porting the OS to C++ might also benefit from Dave Allison's expertise. Well, they did it with Sibelius music notation software, which was originally for the Acorn ARM series computers, Archimedes, Risc PC. It was a killer app for the platform. It was written in ARM assembly and got ported to mac and Windows, so wonder if the same could be done for RISC OS itself.
Ahh, I remember using RISC-OS at school on various A310/3000 machines. It was quite a shock to go to Poly and have to use Windows 3 instead - felt like somewhat of a downgrade ;-) Mind you, all my assessments etc in the first year were typed up on my Atari ST so... :-D
You can't build the OS with GCC and one assumes that the income stream means that there's little incentive to push things in that direction. Every successful open source project I can think of is built on an open toolchain. The "I'm going to dabble" cost is zero. No forms to fill in, no requests to make, no money to be spent, just download the compiler and off you go.
This is, ultimately, why the open source versions of Amiga OS and BeOS began with a total ground-up rewrite (AROS and Haiku, respectively). Each took about ten years to reach self-boot and self-compile and another five to ten to reach 'usable' status, but they are surprisingly complete for anyone not paying specific attention to those little niches.
RISC OS is at this point a curiosity to play around with on an unused Raspberry Pi, probably not for long once the user realizes that most of the daily-use apps available such as browers, word processors, etc are paid-only and extremely outdated.
There are some things that make sense to charge for, such as programming bounties (I wonder how much WIFI will eventually cost the community) and ports to different ARM systems by independent developers (there is an RK3399 port in progress, which cost €199 to a kickstarter last year for beta access, which is about the same as buying the Pinebook Pro laptop it's intended to run on which itself comes with many linux options). But to charge £49 for a basic 25 year old application that only works through an emulation layer? It doesn't give a great impression to the casual tinkering tourist.
RISC OS was, and still is fantastic. It's such a shame Acorn's pricing meant it wasn't really viable as a home computer outside of the wealthiest places.
The Archimedes A3000 was a vast leap over the Commodore A2000 I had at home; while being of more or less the same vintage. Notwithstanding software selection on the latter.
We had an Acorn computer in my primary school around 1998/1999, can remember it had this kitchen game where you could open cupboards and move items around and had a rat hidden in it. Funniest thing to do as a primary school kid was to find the rat and put it in the bin. Wish a could remember the name of the game to have a look at it again.
"Bringing the first native OS for Arm back from the brink"
Nowhere in the exposition of of the rudiments of RiscOS, nor in the poor transcription (obviously subjected to some form of mechanical "aid"; do a better job next time; OK?) can one find a compelling reason for "...bringing it back from the brink...". It has nothing to offer; its time was over long ago.
The fact that the the only commonly available system--the Raspberry Pi--which can use it is not a sufficient reason---quite the opposite, as a matter of fact.
This situation (i.e., "..bringing it back from the brink...") reminds me of the the saying / cliche which was used to answer proponents of 'The Big Band Era', when 'Big Band' wannabes (some were and still are very good) were making a resurgence years ago, and these proponents would (breathlessly) proclaim that "...the Big Bands are coming back...!". The answer?---
"That's wonderful; but where are they going to go when they come back?"
For any Acorn users out there who may have had an Archimedes back in the day, I’d like to recommend Arculator, which is a freeware Acorn Archimedes emulator for Windows and Linux.
I had an Archimedes A310 which entertained me during the late 80s-2000s, until its hard disk packed up and I meandered over to the world of Windows laptops (alas the Arc ended up in the garage and later got thrown out).
I had previously discovered Red Squirrel, another Archimedes emulator, which kept (most of) my backed-up Archie stuff alive, but it was flaky and couldn’t go full screen without crashing. I also used an older version of Arculator, which allowed me to do most of the stuff that Red Squirrel had problems with, but again was quite basic.
Fast forward a few years, and I think the Arculator developer must’ve had some spare time during the coronavirus lockdowns, because in September 2021 they released a fantastic new version (2.1), which took the emulation to a whole new level.
First off, it includes the ROM images for Arthur and RISC OS 2 and 3, so works out-of-the-box without having to grab ROM images from a physical machine. The fact that Arthur is included allowed me to resurrect some old software (Electromusic Research’s SoundSynth), which previously I could never get running. I’ll admit I fist-punched the air that first time it ran, after a gap of about 25 years!
Secondly, you can create hardware profiles, so you can have a profile for an Arthur machine, a separate profile or a RISC OS 2 machine, and so on. This is great for organising your software between appropriate hardware configurations.
Thirdly, a ‘Host OS’ filesystem has been added that links to a folder on the local computer, making file transfer into the emulated computer a doddle.
There’s lots of other good stuff such as support for hard disk images, podule emulation, etc.
Having used Arculator 2.1 for several months now, I’m actually of the opinion that the emulated platform is better than my old Archimedes A310. Running on a modern laptop, it looks better, sounds better… old software that sat in my cupboard for 25 years has been brought back to life… I could wax lyrical all day but I think you get the gist!
Arculator 2.1 can be downloaded here: http://b-em.bbcmicro.com/arculator/
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
