RISC OS: 35-Year-Old Original ARM OS Is Alive and Well (theregister.com) 51
RISC OS, the operating system of the original Arm computer, the Acorn Archimedes, is still very much alive -- and doing relatively well for its age. The Register reports: In June 1987, Acorn launched the Archimedes A305 and A310, starting at $982 and running a new operating system called Arthur. At the time, it was a radical and very fast computer. In his review (PDF) for Personal Computer World, Dick Pountain memorably said: "It loads huge programs with a faint burping noise, in the time it takes to blink an eye." Arthur was loosely related to Acorn's earlier MOS, the BBC Micro operating system but looked very different thanks to a prototype graphical desktop, implemented in BBC BASIC, that could charitably be called "technicolor." Renamed RISC OS, version 2 followed in 1989 -- the same year that Sun started selling its new SPARCstation 1 (a snip at $9,200) and DEC launched the MIPS R2000-chipset-based DECstation 3100 (for $10,800).
RISC OS has had a rather convoluted history, partly due to Acorn spinning out Arm, eventually pulling out of the computer market, rebranding as Element 14 and being acquired by Broadcom, where Arm co-designer Sophie Wilson still works today. And partly due to drama over the ownership of the OS post-Acorn at one point. One fork of RISC OS still supports Acorn-era Arm's odd 26-bit mode, meaning that today it mostly runs on the commercial Virtual Acorn emulator. The other branch, designed for the 32-bit mode of more recent Arm chips, is now owned by RISC OS Developments, which made it fully open source back in 2018. Development and maintenance is done by the team at RISC OS Open Ltd -- ROOL for short -- which offers downloads for a variety of current Arm hardware, such as the Titanium desktops. [...]
RISC OS Developments are still working on new functionality for the OS. Notably, it recently released a new TCP/IP stack, derived from OpenBSD. Right now, the main benefit is IPv6 support. A feature more significant to most users is still in development: Wi-Fi support. Also still under development, but available to paid backers, is a new RISC OS web browser, Iris. RISC OS does come with a choice of browsers -- NetSurf and Otter -- but the plan is that the new Iris browser will be a native app, with the RISC OS look and feel, but using the WebKit engine for better compatibility with the modern web. The main remaining limitation is SMP. As an OS from the 1980s, long before the 21st-century technology of mainstream multicore processors, RISC OS practically only supports a single CPU core. Various experimental efforts are under way to address this. One has got NetBSD running on another core, and another has the experimental Genode OS running alongside RISC OS. Another effort is working on adding SMP support into the RISC OS kernel itself.
RISC OS has had a rather convoluted history, partly due to Acorn spinning out Arm, eventually pulling out of the computer market, rebranding as Element 14 and being acquired by Broadcom, where Arm co-designer Sophie Wilson still works today. And partly due to drama over the ownership of the OS post-Acorn at one point. One fork of RISC OS still supports Acorn-era Arm's odd 26-bit mode, meaning that today it mostly runs on the commercial Virtual Acorn emulator. The other branch, designed for the 32-bit mode of more recent Arm chips, is now owned by RISC OS Developments, which made it fully open source back in 2018. Development and maintenance is done by the team at RISC OS Open Ltd -- ROOL for short -- which offers downloads for a variety of current Arm hardware, such as the Titanium desktops. [...]
RISC OS Developments are still working on new functionality for the OS. Notably, it recently released a new TCP/IP stack, derived from OpenBSD. Right now, the main benefit is IPv6 support. A feature more significant to most users is still in development: Wi-Fi support. Also still under development, but available to paid backers, is a new RISC OS web browser, Iris. RISC OS does come with a choice of browsers -- NetSurf and Otter -- but the plan is that the new Iris browser will be a native app, with the RISC OS look and feel, but using the WebKit engine for better compatibility with the modern web. The main remaining limitation is SMP. As an OS from the 1980s, long before the 21st-century technology of mainstream multicore processors, RISC OS practically only supports a single CPU core. Various experimental efforts are under way to address this. One has got NetBSD running on another core, and another has the experimental Genode OS running alongside RISC OS. Another effort is working on adding SMP support into the RISC OS kernel itself.
Summary misses the most important thing: (Score:5, Interesting)
Re: (Score:1)
Windows is stored on a SSD that's faster than that ROM was. That's not why it boots faster.
Re: (Score:3)
The ROM chips, certainly on the early machines were just in the address space same as the ram and ran at full speed.
Sure, a modern NVMe can transfer data faster than the main memory bus of an archie. But to boot off an ssd, you have to wait for the transfer into ram before your execute. For the acorn design, that wait doesn't exist at all. Or, if you prefer, the SSD has a latency of a few hundred microseconds, corresponding to a cycle frequency of the inverse, I.e. A few kHz. The ram and rom on an acorn ra
Re: (Score:2)
Sure, the RAM on an Acorn could pump gingerly along at 125ns, and yes, an SSD is going to take ~90us or so.
However, after that first delay, the Acorn is sitting there waiting for its next machine word for another 125ns.
In that time, the SSD has pumped 16 machine words directly into RAM, and every 120ns thereafter the lead only increases.
So yes, a modern SSD is much faster at loading an OS than reading from ROM at 8Mhz.
The reason an Acorn boots faster than a modern Windows distrib
Re: (Score:2)
However, after that first delay, the Acorn is sitting there waiting for its next machine word for another 125ns.
In other news, CPUs in the late 1980s clocked in at single digit MHz...
But at that point, the OS isn't booting it's simply running. It's a stretch to way beyond breaking point that pulling instructions from RAM into the CPU is specifically part of the booting process.
So yes, a modern SSD is much faster at loading an OS than reading from ROM at 8Mhz.
No, you're still wrong. The SSD loads the OS very
Re: (Score:2)
Well as pointed out you're not really booting the acorn, you're just starting the firmware and initializing the hardware.
A modern machine does that too before it even starts trying to boot a disk-based OS, and it probably takes longer than the acorn did because it has a lot more complex hardware to initialize and a lot more potential hardware configurations to account for.
Re: (Score:2)
Except the firmware in this case is a complete graphical OS with development tools included. It was certainly as much as an OS as its contemporaries.
Re: (Score:2)
In other news, CPUs in the late 1980s clocked in at single digit MHz...
I wouldn't attach snark to the garbage post you produced, it just looks worse.
But at that point, the OS isn't booting it's simply running. It's a stretch to way beyond breaking point that pulling instructions from RAM into the CPU is specifically part of the booting process.
No. A CPU doesn't care where data was fetch from. High bandwidth, high latency? Low bandwidth, low latency? It doesn't care.
It fills cache lines, and it executes from them.
For example, PCs have not used NOR flash for their ROM in ages. They cannot execute from it.
Instead, they pull a page out of it, and go.
No, you're still wrong. The SSD loads the OS very fast. The ancient machine with the OS in ROM spends zero time loading the OS because it doesn't doesn't load the OS. The fact that an 8MHz ARM is incredibly slow doesn't change that. All that means is it's very slow to execute the OS. The one that took no time to load because it was already loaded with the machine off.
lol. Your confidence in your ignorance makes me smile, I'll give you that.
You previously attributed the boot time differen
Re: (Score:2)
His problem with your argumentation is:
a) you are extremely bad in explaining
b) you are half wrong anyway
Wrong is:
Your PC is not booting from ROM. It is executing some firm ware, and then booting from disk.
The old Archimedes did not boot at all ROM was just part of the address space: it simply started running, just like an Apple ][ or an Comodore 64, I'm pretty sure an Amiga was the same.
Bad explained:
ROM is super slow in relation to RAM. At least in our days. So your argument is: loading the OS from SSD in
Re: (Score:2)
His problem with your argumentation is:
His problem with my argumentation is that he doesn't know what he's talking about. He's got some armchair computer nerd knowledge, and he's trying to run with it. I don't fault him for that, I'm merely correcting him, as I'm about to do to you.
b) you are half wrong anyway
I am most certainly not, as I'll explain below.
Your PC is not booting from ROM. It is executing some firm ware, and then booting from disk.
What do you think firmware is stored on? lol.
On your PC (and every modern processor), the boot process works precisely like this (it's well documented):
Your CPU (or secure processor if you have one- Intel/AMD mostly) bo
Re: (Score:2)
Except ROM is slow. Its generally on the order of around 100ns a
Re: (Score:2)
This wasn't an issue back in the day when RAM was also in the 100ns range and you had CPU speeds in the single MHz range
So, exactly like the kind of machines RISCOS was built to run on, in other words the topic of conversation.
Re: (Score:2)
Whatever, the topic of conversation is that being in ROM isn't what makes it faster to boot than a modern OS, which is also stored in something like ROM. What makes it faster is all the stuff it doesn't do. We could do the same thing today by making the whole OS a coreboot payload.
Re: (Score:2)
It's a bit of both. Running on relatively restricted hardware means there's not a lot of that fuckery to do, and running from ROM means that the OS doesn't have to boot to run. It's already there and just starts executing.
It was always much faster even when it did comparable amounts.
Re: (Score:2)
Not only that, but an OS so small could run entirely from the cpu cache on a modern processor.
Re: (Score:1)
Re: (Score:2)
There's nothing remarkable about switching on a C64 and it showing the prompt immediately. What's unusual about the Archimedes is that it maintained the "home computer" feel (both good and bad) into the 32-bit era.
Nothing remarkable about the C64 sure. But the archie and later RiscPCs were instant on to a sophisticated GUI which was as good and often somewhat better than its contemporaries.
Re: (Score:2)
The ROM chips, certainly on the early machines were just in the address space same as the ram and ran at full speed.
Is that right? Whilst they were certainly in the same address space ISTR that the ROMs ran at only half the speed of the RAM. One speed-up technique was to copy crucial bits of the ROMs into RAM.
Re: (Score:2)
Re: (Score:2, Interesting)
Yup, it was light and FAST. Incredible what was managed in a few MB - some of the software was amazingly efficient. Entire wordprocessors (Impression), vector art packages (ArtWorks) or music (Sibelius) that ran on under 1 MB, and loaded in seconds. My A3000 used to go from power off to working on a project in seconds. I really miss that.
Re: (Score:2)
I bought an A310 when they first launched. It was staggeringly fast for its time.
The free game "Lander" (which you could buy as "Zarch" [wikipedia.org]) was astounding if a bit limited.
It was the first true 3D 3rd person shoot em up in colour! (If only David Braben [wikipedia.org] had the fast inverse square root rountine [wikipedia.org], how much better could it have been?)
Impression was a beautiful Word Processor but the guys who wrote it went a bit further and wrote their own OS to replace RISC OS called "Impulse".
I don't think it was ever released bu
Impulse, the "renegade" operating system for ARM (Score:2)
I contacted Computer Concepts to ask if they still had the code for their alternative operating system Impulse. (They had scrapped the project when RISC OS 2 came out, offering co-operative multitasking and a usable GUI; perhaps it wasn't what CC had hoped for but it was good enough.) I had hoped the Impulse prototype could be released as free software and bundled with the 'arcem' emulator. But they replied saying there was nothing left. That was 25 years ago.
Re: (Score:2)
That's real shame. I've often wondered what happened to Impulse. They were a very talented bunch, Computer Concepts.
Re: (Score:2)
RISC OS was still remarkably slow to start up for a ROM based operating system though. I don't know what it was doing during the boot sequence but an Amiga with partly ROM based OS could boot into a GUI in seconds from cold. Most of the GUI was in fact in the ROM, there was just no way to load it without a disk of some kind.
At least that was my experience on Archimedes machines, I think all of which had either internal HDDs or some kind of shared drive (one drive between two computers IIRC).
One thing I did
Re: (Score:1)
Re: (Score:2)
Ah, that could be it. I think I started with RISC OS 3.
I had quite a lot of stuff loading on Amiga OS, but it still only took less than 10 seconds from power on to fully ready to go.
What is interesting about RISCOS? (Score:4, Insightful)
I never hear too much about RISCOS. Even at the time, the attraction seemed to be simple but fast hardware. So beyond simple nostalgia, what is the attraction of RISC-OS? Similar vintage AmigaOS had slidable screens of different resolutions and ultra-lightweight interprocess communication. What did RISC-OS offer that is unusual even compared to modern systems?
Re: (Score:2)
They invented the idea that an application is a directory, and all resources are inside (perhaps not really, but definitely before NeXT and then Apple).
Inside of the folder/directory were a few standard named basic programs, e.g. "Run", which would be executed when you double click the application.
You could somehow intercept drag and drop (run your own basic program) and modify what happened depending on shift/alt/ctrl etc. - the OS supported aliases like Windows and old Mac OS - but I think no real links.
T
Re: (Score:2)
Inside of the folder/directory were a few standard named basic programs, e.g. "Run", which would be executed when you double click the application.
Wasn't it !BOOT
The Basic Interpreter was absurd fast even 1st person shooters were written in Basic. The Basic was quite capable, e.g. had Functions and Procedures.
Definitely did, it also had a built-in cleanly integrated assembler. I didn't use the RISC-OS one, only the earlier AMOS one which was less sophisticated. Even with that one, the assembler understood c
Re: (Score:2)
Oh neat thanks for letting me know.
I can't remember from my bbc days if !boot was OS commands or basic.
Re:What is interesting about RISCOS? (Score:4, Insightful)
[Author of the linked article here]
For me, there were sever things.
The ST and Amiga were games machines, from companies whose previous 8-bit ranges had been very strong in games. They had the same mainstream CISC CPU, a solid choice but not blazing fast. The Amiga had amazingly capable supporting chips for amazing hardware-accelerated games graphics and sound, but very lacklustre mediocre programming languages. So the programming languages that took off were 3rd party add-ons, so not standard, meaning rivalry, no interop, etc.
On the Amiga and ST, development was intended to be done by pros, on different machines.
Acorn's previous hit was the BBC Micro, an educational computer, very strong in programming languages, with a structured BASIC that had named procedures and inline assembler.
So the Archimedes range was designed as a programmer's computer, with a screaming fast CPU (but no fancy chipset), an integrated state-of-the-art BASIC supporting local variables, so you could write recursive procedures etc., a GUI code editor bundled, plus graphics and sound editors _right there in the ROM_.
ST and Amiga owners were expected to play games written by professional software companies.
Archimedes owners were expected to write their own programs, and the OS came with all the tools you needed to do that. This predates the rise of the C language, and even compiled languages in general. To fit the OS into ROM chips, it was hand-coded in assembly language by a team of 7, 4 of whom I interviewed on Zoom on Monday night:
https://rougol.jellybaby.net/m... [jellybaby.net]
So the app format is just a folder, with plain text files (a script, some BASIC if you want, some bitmap graphics for icons etc.) and all the tools to make them are part of the OS. You didn't need to buy anything extra. Obviously you could, lots of it in time, but it wasn't essential. You got the best interpreted language in the business, which was also an assembler, you got a monitor, you got editors to write code or draw or paint graphics, play or record music, and all right there in the ROM, accessible instantly, without disk swapping, on a single-floppy machine.
The OS did not _load_ from ROM: it _ran_ from ROM. So, all the RAM is user RAM. A 1MB machine had 1MB of user RAM, because the OS is in ROM that's right there in the memory map.
When you turn on an Android phone, it boots from ROM, meaning it loads the OS from ROM into RAM and *then*, after gigs of code have been transferred, it starts executing.
When you turn on an Archimedes, the code starts executing immediately. It's like a PC whose BIOS (or UEFI) is a complete multitasking GUI OS, so once the POST is done, that is it: you're at the desktop and ready to go.
At the point in the power on sequence when a PC _begins to load the OS_, the Archie was ready to use.
Now, to be fair, this had downsides. Acorn _should_ have stressed games more: the hardware was more than capable. The software division wrote the OS so they had no time left to do apps as well, so the 3rd party app market came later than it did for Atari and Commodore.
Re: (Score:2)
> were sever things.
* several things
Oops.
Re: (Score:2)
That just doesn't sound that much different from an Amiga in practice, aside from starting with a more powerful CPU, and having more of the OS in ROM. An Amiga with a HDD would boot very quickly, to the point that any difference is measured in single-digit numbers of seconds. AmigaBASIC was not in ROM, it was on a floppy, but it was a very powerful implementation. I remember my friend Charlie adding some trivial hardware onto his Amiga's circuitry to implement an IR receiver (I forget where it was connected
Re: (Score:2)
The first A1000 and some models of the A3000 softkicked by default, all the other models had most of the OS in ROM.
The A4000T moved workbench.library onto disk, so you couldn't start workbench from a boot floppy unless you included that too.
Re: (Score:2)
You can softkick any Amiga. I've made my own kicks before...
Re: (Score:2)
Re: (Score:2)
Yeah, no. Bootloaders or Kickstarter or Toolkit in ROM doesn't count.
I *used* an Amiga with a single floppy, and multiple Macs with a single floppy. It was a nightmare. Even copying a largish file from 1 disk to another could take a dozen swaps.
On an ST or an Archie, it was very much more pleasant, because no code needed to be loaded into RAM: it was already there, in the memory map, in ROM.
The difference, for me, is that the Archie had a pleasant multicolour GUI that ran in hi-res mode in full colour, with
Comment removed (Score:4, Informative)
Re: (Score:2)
I don't agree with a single sentence of that, but I can see that you are keen to re-enact 35+ year old platform wars.
I am not.
So, yeah, not even going to try to engage with any of this mid-1980s platform-boosterism.
I have an Amiga, but I only got one this century, and not being a gamer, I never found all that much interest in it. It's a nice little vintage computer, and I have a CF card and interface to put in it to replace its elderly 400MB IDE hard disk, and I hope to get it running AmigaOS 3.9 and maybe
Re: (Score:2)
You could drop into a powerful BASIC interpreter with a couple of keystrokes, that was pretty nice. I guess these days kids start with Python or web stuff.
I thought that the three button mouse was nifty at the time, the GUI made good use of it. Of course those are standard now.
There were some nice apps too. There was a DTP one I used quite a bit... It might have been called Impression. While simply by today's standards, that's kind of what made it good. A lot like PageStream on the Amiga.
RiscOS has always been ... (Score:2)
... on my shortlist of alternative OSes with real world use. And it runs flawlessly on Rasberry pi. Most likely still worth using, although modern browsing might pose a problem.
Re:RiscOS has always been ... (Score:4, Informative)
There's a WebKit-based browser available (Iris), although it's currently in paid beta. I believe that the plan is to make it free eventually.
RISC OS is very fascinating to me. (Score:1)
Re: RISC OS is very fascinating to me. (Score:5, Informative)
Re: (Score:2)
Um. It is not hard. You download it, you write it to a card, you put the card into the Pi, and you turn the Pi on.
That is about it.
The IP owners, RISC OS Developments, have a distro especially for the Pi and aimed at RISC OS newbies. It's called RISC OS Direct and it's here:
https://www.riscosdev.com/dire... [riscosdev.com]
It requests a 16GB card, but I installed a fresh copy as part of the research for this article and it seems to be only an 8GB image. So an 8GB card should be fine.
Write it with `dd` on Linux, and when it
RISC/os (Score:2)
Re: RISC/os (Score:2)
Re: (Score:2)
Broken link.