RISC OS: 35-year-old original Arm operating system is alive and well 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. In June 1987, Acorn launched the Archimedes A305 and A310, starting at £800 ($982) and running a new operating system called Arthur. At the time, it was a radical and very fast …
If you're going to leave it in the loft, make sure you remove the VARTA V280* cell, as those shipped in the: A3000, A3010, A3020, A4000, A5000, A7000, A4, and RiscPC, have an annoying habit of leaking, after 30+ years of loft non-living. The earlier A300 / A400 / R500 series use a pair of AA batteries, that will also leak, but in a separate battery holder, behind the cases power supply, so less likely to destroy several PCB tracks, to leave you with a pile of e-waste, or at best collection of parts to be eBayed, when the house is cleared.
Ditto if you have an old Commodore Amiga, remove the battery if you plan to abandon your old toy for a decade.
File meta data id rather than everyone+dog deciding to grab all the common 3 letter extensions for themselves (looking at you autodesk)
On my A310 with 1Mb of RAM being able to drag memory usage limits around in realtime to give my program more memory at the expense of screen resolution or font cache.
And if only everyone else had adopted "." as the separator in directory paths we wouldn't have had 40years of escaping bloody "\"
And if only everyone else had adopted "." as the separator in directory paths we wouldn't have had 40years of escaping bloody "\"
Or if DOS/Windows had standardized on / instead of just adding support for it. Or if Unix and a lot of others had dropped /. I'd also contend that / is better than . for separation because even by then, the . was commonly used in filenames for extensions or merely for separating components. Given that we're already escaping lots of other characters depending on what we're entering into, maybe it's not so bad to accept that it's going to happen.
This brings us to your other suggestion, about file metadata fields. That often doesn't work. Any file can contain any data, so you'd need some mechanism to ensure the metadata fields always stay with an object when you move it. The problem with that is that you'd either end up with metadata fields with no meaning or ones that aren't useful. For example, you could use them for the same purpose as extensions, which appears to be your concern, by storing something like the MIME type in it. When a new format comes along, you wouldn't have a type for it and would get stuck until someone added it. If they didn't, someone would eventually include their own data in there, which would break things if the eventually-assigned ID was different or if anything else used the same identifier. Maybe you'd use it for the OS to associate programs with files, which would work fine on your computer, but as soon as you transferred the file to something that didn't have the program identified, the field would stop working. This would be a problem for file portability. Essentially, you would probably end up with all the problems that extensions have but, instead of an OS's explorer program, your cludge to implement it would now have tendrils in the filesystem, all file-based programs, and multiple parts of the OS itself.
Still think dot works, we use it in internet addresses. Dos used \ to avoid accusations of copying CPM
The metadata on RiscOS was IIRC a 32bit ID. 16bit assigned to the software vendor and a 16but field for them to use internally. Rather like MAC addresses
As I recall they already had / as the escape character for end of line. It seemed to me that when those vast hard drives were added to PCs they tried to do a pivot from the rather DEC-like command-line syntax of CP/M and early MS-DOS to something more Unix-like to accommodate subdirectories and ended up being neither.
DOS 1.0 didn't have directories, but already used /x for command-line switches. (You could change this to -x with INT 21h/ah=37h). Hence, for compatibility reasons, when DOS 2.0 added directories they had to use \path\file although it always supported /path/file internally.
"Still think dot works, we use it in internet addresses."
Domains, yes, but paths, no. If we used . paths in URIs, for example theregister.com.2022.06.21.risc_os_35, the browser couldn't identify where to split the URI to find the server and we'd have to change the spec for URIs.
"The metadata on RiscOS was IIRC a 32bit ID. 16bit assigned to the software vendor and a 16but field for them to use internally. Rather like MAC addresses"
Exactly. You'd have to copy that every time a file was copied, and it wouldn't work for nearly any standard format. For an audio file created by an audio editor, would you set it to the ID of the editor or of a player that could play it? When copied to a system that has a different editor and player and lacks the one identified, how would the user figure out what to do and get the number changed? Extensions work in this scenario because they can guess that .mp3 files can be played as audio and you just set a program you want to handle that format. To say nothing of having to centralize each vendor number and dealing with the inevitable exhaustion of those values (we've had at least 65536 file formats created by someone since 1988).
> The metadata on RiscOS was IIRC a 32bit ID. 16bit assigned to the software vendor and a 16but field for them to use internally. Rather like MAC addresses
Not exactly for file metadata - maybe you're thinking of SWI (system call) numbers, which were allocated by Acorn in blocks with a vendor prefix.
File metadata was the same as on the BBC, two 32 bit fields for load and execute addresses. Then in RiscOS they were repurposed to contain a 12-bit file type and the rest used for the file modification time (there was only one timestamp). The file type was again allocated centrally by Acorn. Applications which needed MIME or had to interpret file extensions from other systems needed to manage them themselves, there was no OS-level file type database.
Yes, there were a lot of numbers allocated by Acorn. No, that would never work today.
I don't see file types as worse than three-letter file-name extensions. Even with file-name extensions, programs need to know what they mean -- you can't just create an new extension such as .l8r and expect programs to know what to do. The OS needs to assign default applications to each file-name extension, which isn't much different from assigning default applications to file types, as RISC OS does by setting OS variables (which can also assign icons to file types). And there is the same risk of the same file-name extension or type being used for different purposes, creating confusion. I have observed this several times with file-name extensions.
The main problem with RISC OS file types is that there are too few: 12 bits gives 4096 different types, where three alphanumeric characters (case insensitive) give 46656 different file-name extensions, which is over ten times as many. 32-bit file types would work in most cases, and picking a random type is unlikely to clash with other types. 64 bits would be even better.
Also, a lot of programs expect file-name extensions and take, for example, a .tex file and produces .aux, .log, .pdf and so on with the same root name. If these are compiled for RISC OS, the root name would be a directory containing files named tex, aux, log, and pdf (since RISC OS uses . as directory separator). In some cases, it is nice that all these files are combined in a single folder, but you often need to copy the pdf file to some other location, and then you would lose the root name, unless you rename the file. You could modify LaTeX and other programs to use file types instead, but that would be a major effort. The best solution is probably to have a wrapper for Linux programs that, in a temporary directory, modifies file type to file-name extensions (using subdirectories) and afterwards convert back to file types. This wrapper could be generic for all Linux command-line programs as long as the wrapper has a translation of all the file-name extensions and file types involved. Has one such ever been made?
"Even with file-name extensions, programs need to know what they mean -- you can't just create an new extension such as .l8r and expect programs to know what to do."
Of course you can. I can name a file stuff.l8r and my filesystem will handle it. I can open that file in an application using its file open control. I can attempt to open it in my file manager of choice and it will ask me what to do with it, allowing me to associate a default program with it. In no case did I have to apply to the OS vendor to assign a number to me, and the only risk is that two programs will both decide to use .l8r, which is still fine if one of them is using it internally or if I keep my files organized. Not to mention that we've had longer and shorter extensions for a long time, so we can always make a longer one to avoid collisions.
I would really like to see the file-types concept to be extended to cover also directory types. As it is, directories with names starting with ! are apps, but that would be better done as a directory type. I also recall that some word processors saved documents as apps, so pictures etc. were stored in separate files in the directory, but you could still open the document by clicking the icon. This, too, would be better handled by directory types, so the documents did not need names starting with !.
The immediate problem I can see with your idea is that it prevents apps from being stored on non-RISC OS filesystems, because most filesystems I'm aware of have a single type for directories.
Suddenly you wouldn't be able to copy an app onto a FAT volume, or onto a network server, or anything except an ADFS-style FS.
That gives me unpleasant memories of people copying classic Mac files onto non-Mac media, thus losing the resource fork, and the file being corrupted into uselessness. No thank you.
P.S. I think the app you're thinking of was Impression, which was a DTP program rather than a wordprocessor.
You can always adopt the Apple-style bundles. It still involves extensions though. If your folder name ends with .app and has a "Contents" folder in it, it's treated as a single file that can be activated and run. Like other extensions, you can create new bundle types without having to have special numbers, and any other OS will just see it as a folder with a . in the name.
>Yes, there were a lot of numbers allocated by Acorn. No, that would never work today.
Well you might need more than 16bits....
But since most software is obtained from app stores, and is signed by the author who has some sort of account relationship with the store.
With a bit of thought you could mix it with a MIME type as part of the number.
Eg. a 256bit ID would tell me it was created by XYZ Software, and possibly even prove that cryptographically, and tell other apps it is an MP3 file while still allowing XYZ software to distinguish various uses of MP3 within their own software.
Really it's meaningless today to have a "file extension" on a binary blob distributed over the net to a device that has no user visible file system.
The dot doesn't mean anything in 'ix', its just a character like any other. If we humans choose to interpret as something than that's our business.
(The dot as a filename means "this directory" &tc. -- but I suppose we're all familiar with the rules for ix pathing.)
What's particularly annoying about Microsoft's use of the backslash is that in the real world its an escape operator. Obviously it, too, can be escaped to mean the actual character but its still a mess. Fortunately I don't have to do anything with this environment any more so I can ignore it.
To some extent, you're right, but that's also true of basically any CLI system before the utilities are considered. Tools written for *ix systems do tend to interpret the . as having meaning (starting with . will mean it's hidden by some applications, for example). "." and ".." as names are reserved by the filesystem. Most GUI file managers take a traditional approach to having default applications based on file extension as well. It's basically the same as Windows or Mac OS, neither of which will object to extraneous .s in file names, but the applications above them will treat them as meaning something.
And if only everyone else had adopted "." as the separator in directory paths we wouldn't have had 40years of escaping bloody "\"
All paths should be of the form
machine::device:[directory.subdirectory.subsubdirectory.etc]filename.extension;version
with especial emphasis on the version number.
In the 80es, it at times required black arts to get the letter ø displayed, or even worse, printed.
It still does. And still often doesn't work. Probably because some of the shiny new web-stuff has back-ends reliant on code from the 80s.
Back when the UK was more entangled with Europe than it currently is, many UK organisations had great difficulty in correctly addressing mail to foreign addresses with 'funny' characters in them. In Scandinavia, many people had to resort to the standard ASCII replacements of 'oe' for 'ø' and 'ö', 'ae' for 'æ' and 'ä', and 'aa' for 'å' , and in German-speaking locations 'ue' for 'ü'. You could use the correct character on a website profile, but whatever back-end printed the envelopes would at best leave a blank in place of the letter, or sometimes an inappropriate glyph.
It is less of an issue now, as many UK organisations reliant on legacy code for their core operations no longer do business with people outside the UK.
It's going to take a long time before UTF-8 is universal.
Well, kinda; the compose key is a great idea and I still use it (on Windows too, courtesy of, er... SharpKeys, I think) but it still relied on whatever ASCII codepage was available on the terminal. I've no doubt if DEC was still around they'd have adopted UTF, but y'know, "if DEC was still around" would've been cool in lots of ways.
I dunno why it never really caught on. Certainly easier to use than AltGr and a bunch of unmemorable numeric codes and less annoying than sticky accents.
And if only everyone else had adopted "." as the separator in directory paths we wouldn't have had 40years of escaping bloody "\"All paths should be of the form
machine::device:[directory.subdirectory.subsubdirectory.etc]filename.extension;versionwith especial emphasis on the version number.
I was just about to mention the wondrousness of VMS's naming conventions; plus you had logical names of various sorts which could replace arbitrary bits of it too, with or without a hierarchy, which is especially useful for not going off the ends of lines when someone is a bit liberal with the blockquotes. ahem.
For some reason I used to get irritated at it using a semicolon for the version number separator but it was happy enough for me to use another dot instead which mostly curtailed my griping.
Similarly (well actually not, except for the existence of dots) there's MVS and its
MY.DATASET.NAME(THINGY)
but last time I looked, THINGY was just up to 8 characters of alphanumerics, no extra dots to be had there. That may have changed in the past 25 years tho'.
And CMS, which apparently now has subdirectories too; but thanks to OS/2's influence it's also adopted \ as its separator. Bleh.
> All paths should be of the form
> machine::device:[directory.subdirectory.subsubdirectory.etc]filename.extension;version
> with especial emphasis on the version number.
Close. It should be something more like:
file-serving-service:[directory.subdirectory.subsubdirectory.etc]filename.extension;version
i.e. addressed by a service name and you don't care where or which machine it is on.
Even better would be to give every file a unique id - an inode on steroids - and then the translation of whatever the user wishes to use to represent that file into the uuid can be done by a local service. That service can appear as a traditional hierarchical file system; or it could be shown as a skeuomorphic representation of a library with books on shelves; or even as a messy desk that you have to leaf through. The advantage being that I'll still be able to find a file that I created months earlier, even after various managers and project management office staff have "efficiently re-organised" the project's file system.
Versioning with a 7 - 10 year retention should be enough to deal with most accidental deletions and editing screw-ups. ;-)
all went into the West Midlands IT mafia for the next 25 years. I worked at one place that was spun out of ACT while the company the floor above had as well, and so had the company the floor above that. They all used to gossip at smoke breaks.
I worked for the outfit that built a financial package that ACT decided "wasn't their thing" ... LSS that had a brief plc life as WMS.
> Am I remembering correctly that lander was written in BASIC?
No, you aren't. In fact, I think it was written before Arm BASIC was finished.
It's fairly pure assembler.
At Monday's talk we learned that David Braben offered to work with Acorn to add a bunch of extensions to BBC BASIC and RISC OS to make it a better games platform, but Acorn refused, afraid of the computers getting stereotyped as games machines.
There's a _lot_ of software, but there are a couple of snags:
[1] Old software is 26-bit and doesn't run on its own on 32-bit RISC OS. *But* RISC OS Direct includes a free copy of Aemulor, which will make most of those old desktop apps work. (Games etc., no, but there are emulators for that.)
[2] RISC OS' glory days predate the WWW and the rise of abundant FOSS software, so a lot of RO software is commercial and still costs money today.
From my daybook: Wed 24-Jun-1987
4 hours Monotype
3.5 hours Acorn
ACORN 0060.7
RISC Machine 1st Word+
[Porting from the Atari ST / DR GEM]
https://en.wikipedia.org/wiki/1st_Word/1st_Word_Plus
A few snippets:
'Only 1 "short slower than int message'
'sscanf corrupts its 1st arg"
'Bug in the linker: cannot create non-contiguous files'
When I was a student at Strathclyde Uni, one of the lecturers worked at the company that developed 1st Word.
He said in a software development lecture that the way they improved performance between versions was to reduce the counter in random for loops that basically did nothing except slow down the performance.
Happy to read about this. I’ve been using RISC OS on a Raspberry PI 400, as the Direct version comes with useful software bundled, which it was necessary to pay for before. I use it when I want to do distraction free writing, but I also like the nostalgic charm.
Long may it continue to develop with the SMP etc, I wish I had the time and chops to help.
Before the Raspberry Pi appeared, it was such a sad environment for RISCOS. The main emulator VirtualRPC was full of DRM and the Iyonix was almost impossible to get hold of. The port to BeagleBoard was also too immature at that point.
Things are better now, especially Peter Howkins's RPCEmu (and great work on CDE btw!), however in many ways I am avoiding re-engaging with RISCOS in case things dry up again.
My high school had a computer lab of Acorns back in the late 80s and early 90s and at that point i had only every seen the odd X86 PC in offices and on TV, no one i knew had one at home, it was all Amiga's Atari ST's or a few had Acorns.
So when i left school to go to college and their labs had PCs running Win 3.11 it felt like a step backwards compared to the slick RiscOS of the Acorns I had been using at school for 5 years.
Lucky for me there were a couple of Archimedes in the corner of the college lab and so i would jump on them to do my work if the tutor would allow me to.
But the second year of the course they were replaced with 2 more Windows PCs and I never go to use RiscOS again after 1993, so I might look at firing it up in a VM to play around with after reading this article.
[Author here]
It's an ARM OS. No x86 VMs will help you here.
But as I linked, RPCemu is there, FOSS, works well, and even in 256MB of RAM, RO Direct works very well. It's not quite the same, IMHO, but it works.
Virtual Acorn is not expensive and gives things like cut'n'paste between host and guest, I think.
[Author here]
That is why I said "and runs on modern hardware".
Yes, AmigaOS is alive, if not very active, but it only runs on PowerPC kit, and there is hardly any PowerPC Amiga kit. Apple moved off PowerPC *seventeen years ago* and since then there's not been much new PPC desktop kit.
There is exotic kit like the Raptor Computing hardware:
https://www.raptorcs.com/TALOSII/
... but AmigaOS doesn't support them.
I have written about AmigaOS before, and I have a Mac mini G4 running MorphOS. MorphOS is an unauthorised 3rd party reimplementation, but it does at least run on COTS PPC kit, meaning 20-year-old Macs.
So there's AmigaOS (closed source, rare expensive proprietary kit only, most of which is old now); MorphOS (closed source, mostly supports old Apple kit); and AROS (FOSS, runs mainly on x86, best in VMware).
All have to emulate 68K hardware for old apps, and none, AFAIK, are binary-compatible with one another.
They backed the wrong horse, I'm afraid. PowerPC faded out of the mainstream, and AmigaOS never went FOSS.
The 32-bit RO is FOSS, and it runs on modern commodity ARM hardware, critically including the cheapest and most widespread Arm SBC that is out there. So you can run it _well_ on £5 of kit and _superbly_ on £50 worth.
You're not thinking of the Master Compact by any chance?
That's the only "pizza box" machine Acorn made before the Archies.
They did various ECONET servers in pizza box cases, but they were basically just Master Compacts badged and tweaked to act as ECONET file servers.
I worked in the IT Centre for Newcastle Education Authority at the time supporting school staff on BBC B's, Masters, Macs (we were one the early ARICs - Apple Regional Information Centres), and eventually Archies.
We even had the official Acorn maintenance training run by Acorn on the 305, 310, 410, 440 from the day they were launched.
God those early ones were so full of bugs - hardware and software.
"They did various ECONET servers in pizza box cases, but they were basically just Master Compacts badged and tweaked to act as ECONET file servers."
No they weren't, they are completely different machines, completely different motherboard, completely different boxes. You're close to comparing a printer with a radio just because they both have transisters inside.
You are correct, but your analogy is rubbish.
More like comparing two different models of radios from the same manufacturer - one with a digital frequency display and keypad (the Compact) and the other with an on/off switch and a single preset channel button (the FileStore E01S)
I always rememberd the Filestore E01S as being more like a Master Compact because it used the same awful EEPROM (IIRC) for storing the system settings, same as the Compact, compared to the Master proper which uses real CMOS RAM.
Never liked the E01S. Much preferred Level 3 Econet FilerStore to run on a Master 128 with internal 65C02 co-pro. Much easier to work with if the hard drive file structure got trashed (which happened a fair number of times in Newcastle schools).
Then there was the SJ Research Econet file "server".
Dick Pountain's review describes the Master as a soaped up Beeb and it certainly wasn't that. Maybe it was something else - it was along time ago so my recollection is a bit shaky. It cersinly wouldn't have been something very expensive because buying expensive things for what was a speculative diversion didn't happen.
> Dick Pountain's review describes the Master as a soaped up Beeb and it certainly wasn't that.
Well, it was really - enhanced processor but still 6502 family, more RAM using the sideways technology that had previously been available with third party addons, floppy disc interface as standard, bigger OS and extended BASIC. IIRC the price on release for the Master 128 was £500, compared to £400 for the BBC B.
Nice hardware, but it was only a stopgap.
The standard Master 128 was a 65C102, compared to the BBC B's 6502A.
It also had 64K of "sideways" RAM into which you could install sideways ROM "images" as well as plug ROMs into both the mainboard on the inside or via the two catridge slots.
It also had 20K of "shadow" RAM which alleviated a lot of the issues the BBC B had with the higher resolution modes leaving very little user RAM. The remaining 12K of "extra" RAM was used as private workspace for the MOS (Machine Operating System) and the sideways ROMS.
It had an internal TUBE slot for internal co-processors (mine here at home is the Master 512 which is a Master 128 with internal 80C186 co-processor running DOS+) as well as a (little used) modem connector.
Built in floppy disc interface (using the WD1770/1772) complete with DFS and ADFS. All of those were extras on the BBC B, which also ate up precious user RAM, and the "standard" disc interface used the Intel 8271 which couldn't do ADFS.
Finally it had a CMOS RAM for maintaining the various configuration settings. Oh it also had various bits of software built into the system ROM (as sideways ROMS) including the View word processor and ViewSheet speadsheet.
So all in all a VERY "suped up" Beeb.
The Master range were very much souped-up Beebs, yes. They even carried the BBC branding.
They had numeric keypads, 2 cartridge slots for easier insertion of ROMs -- I think those never really caught on, as the socketed ROMs of the original Beeb were too well established.
The most basic one, IIRC, was a Beeb+ in the new case. 64 kB of RAM, ½ of it sideways RAM.
Then there were a bunch of models with co-processors as standard: a 2nd 6502, or a Z80, or an 80186, or a NatSemi 32016.
"2 cartridge slots for easier insertion of ROMs -- I think those never really caught on, as the socketed ROMs of the original Beeb were too well established."
Oh yes they did once "empty" catridges started to be sold by Watford Electronics, Technomatic etc (I have several). Much easier to swap your physical ROMs over that way. Especially if you have any of those "protected" ROMs which are much harder to produce an image off and load into sideways RAM.
Ahh the memories ...
I started school in the late 80s when BBCs and Acorns were the stalwart of school computing. I became something of an "expert" - I was the computer monitor, setting people up with floppy disks, messing with settings etc. Later we got an A3010 at home (2MB RAM, no HDD) and I learned to code in BASIC, writing/hacking WIMP programs, messing with SWIs and modules. My friend brought round a modem and we connected to Arcade BBS and downloaded a game which was beyond comprehension at the time. At secondary school I'd have many arguments with PC advocates about how much better Acorns were (Windows 3.11 was still the PC game in town) and I was obsessive to a fault.
In my late teens as schools abandoned this kit, I used to post on education newsgroups offering to "clear out" their old computers and make a donation to school funds which they were happy to accept (now this is a very common business model for companies needing old kit clearing out). At one point I had 20 RiscPCs, I removed all the podules and network interfaces and sold them on eBay to enthusiasts, and then sold the remaining computers to an Acorn dealer for several more times than I'd paid for all the kit in the first place. At 17 years old this was eye-watering money.
Also during that time I got my hands on a BBC Doomsday setup. It didn't work (laser disc player issue), but I had remembered using it at school in the library and being mesmerised by walking around a virtual town (as per Google Maps today). I wish I had kept hold of it. I actually had the two laserdiscs, immaculate in original packaging. Imagine that. That system was unbelievably impressive, given the hardware available and how they made it work.
Later (1999) I moved into the world of the internet/WWW which became my bread and butter, learning Linux and HTML and so on, and now I work on a cloud software platform. But those BBC and Acorn days set me up for a lifetime of success and I had a lot of fun (and made some good money) along the way. I'm grateful to the teachers who saw my passion/aptitude for computers and gave me after school access and privileges afforded to few others, and to those who hired me straight out of school at 16 so I could work at my passion.
In my latter teenage years and early twenties I managed to convert myself from a full on nerd to something more of a geek, forcing myself to learn social skills resulting in my time becoming more full of distractions like women and exercise and all that boring stuff rather than quite so much tinkering and late nights in front of a VDU. But some part of me still dreams of a room full of all this old kit, if only just to reminisce, and I can't help but get excited once in a while figuring out a solution to something using a Pi or Arduino and so on. Inner nerds truly never die.
God bless you Acorn and RISC OS. In many ways you were ahead of your time and were "beaten" by an inferior Wintel product. I won't lie, it warms my heart that today I am writing this on an M1 Pro Mac ... a fitting full circle.
If I were them, I would add SMP to RiscOS. There's a strategy to this.
Both Linux and a few BSD branches followed a pattern of implementing SMP using a BKL (Big Kernel Lock) first, then whittling away the kernel lock over time. In detail, you start with a big kernel lock, your interrupts still go to CPU 0, your kernel code all runs on CPU 0, and any access to the kernel functionality from applications is one-at-a-time due to the big kernel lock, if two programs try to call into the kernel (not just the same function, any functionality..) the second one will block until the first one completes. This allows minimal changes to the rest of the kernel (other than like the process scheduler and probably some cache flushes have to be thrown in) while allowing SMP program execution. If your programs are I/O heavy, performance will be bad; if it's CPU-intensive this'll be perfectly fine. I would guess you could get away with this with RiscOS and call it a day, an ARM system is probably not going to be running like 10gbps ethernet and whatever that'd make you really want your kernel code to be able to use multiple cores. But you can then rewrite subsystems and drivers as you get to them, remove big kernel lock and put in smaller locks on those systems as needed. Linux and a few BSDs did just that; my friend used NetBSD when they added SMP to that and it was a mess, they actually added threading without using a BKL, and THAT was a mess, data corruption and crash city, they must have had a lot of locks missing when they started doing that.
(Edit: an ARM RiscOS desktop won't have 10gbps ethernet etc., i'm sure there's arm systems that can have connectivity like that but you wouldn't be running RiscOS on it 8-)
[Article author here]
I defer to Reg Ed-in-Chief Chris Williams here, who is also a RISC OS type, but has far better in-depth knowledge than your humble correspondent.
Saying that, AIUI, the main problem is that most of the RISC OS code is not re-entrant.
Ever since RO2 it has had a "task window", a pre-emptively multitasked command-line. The underlying character-level stuff might be at least partially re-entrant, but the higher, GUI levels of the code are not.
With cooperative multitasking only, adding SMP is not trivial.
My only-somewhat-facetious suggestion on the ROOL fora was to port RO to run in dom0 under Xen, and then give it the ability to fire up multiple other RO instances in hardware VMs in a master-slave arrangement.
Partly because once you can do that, you could have VMs running other ARM OSes under the control of the "master" VM.
"my friend used NetBSD when they added SMP to that and it was a mess"
That sounds like the M:N threading support using scheduler activations rather than the SMP support itself. SA was a neat concept, but hellishly complex to implement and only really understood by one developer. Then another developer added a much simpler 1:1 threading implementation that worked very well. This mirrored what happened with Solaris - initially M:N then 1:1 threading.
...was to keep the excellent bits of RiscOS that everybody liked - the GUI and desktop - and reimplement them on top of a Linux or BSD kernel and userland. Put all of their development effort into compatibility libraries, ARM emulation, runtime support, etc to make reuse or porting of applications as easy as possible. So getting SMP, networking, hardware drivers and all the rest for free, as well as being able to run on commodity hardware. Sadly nobody took up the challenge.
[Author here]
Au contraire.
There have been several such attempts.
The whole RO kernel can be run as a Linux program:
https://github.com/TimothyEBaldwin/RISC_OS_Linux_Source
There was also ROLF, which is sort of like WINE but for RISC OS:
http://ro-lookandfeel.blogspot.com/
The desktop was re-implemented many years ago:
http://rox.sourceforge.net/desktop/
I have very fond memories of RISC-OS at school - we had a 'wacky' computer science teacher who made everything fun and interesting (and also let us take machines apart to fit hardware etc - I seem to remember we didn't destroy the Hawk V9 hand scanner :-D )
It was a bit of a shock when I went to Poly and had to use PCs running Windows 3.0 - it seemed so janky, and only 2 mouse buttons ;-)
I wanted a RiscPC but the price was too high for an impoverished student at the time, sadly.
Now I'm wondering if there's somewhere on the web I can go and play Zarch again, good times :-)
The problem with RISC OS since the glory days has always been keeping up with the times. While hardware and remote access advanced by leaps and bounds in the rest of the world, RISC OS was beset by Acorn's desertion and IP squabbles among the remainers. Its native hardware all but vanished, with the few machines available hampered by a lack of drivers for modern PC hardware. The app community melted away, with killer apps like Sibelius migrating to PC in order to survive at all.
From core OS functionality to hardware support to apps to Internet connectivity to design for security, RISC OS has just about enough novelty to survive as a hobbyists plaything, but the amount of work needed to bring it back to a usable state is massive.
ROOL have at least made that possible by hacking down the IP jungle and open-sourcing it, but what it needs now is an army of new talent. How is that ever going to happen?
Happy recollections of our Acorn A3000 from my teenage years only slightly tempered by the recollection that in spite of being a better computer by any technical metric, all the good games were on the Amiga and Atari ST. Everyone else talking about R-Type or Shadow Of The beast and we were stuck with the 4th Dimension knock-off - and fair play to the 4th Dimension, I think they were the only reason we had any games on the Arc at all.
We did get the best version of Elite in the end, though. That was a win.
I dunno, as an Amiga owner who's best mate had an A310 (though by the time he'd finished upgrading it, describing it as a mere A310 was doing it a disservice), there were a few games in his collection that I'd have loved to have had at home - Interdictor and Chocks Away are the first two that come to mind which, IIRC, were only ever released on the Archie (although the Amiga did have games of a similar bent), and unless it was just something I dreamed up whilst under the influence of a heavy cold or something, then I'm sure there was also a stupidly good game that allowed you to create your own tracks with jumps and loops and so on and then go racing around them - a bit like a fusion of Stunt Car Racer and Hard Drivin, plus some of the "earn points by crashing in spectacular ways" game mechanics that the Burnout series introduced many years later.
Plus, although they both did eventually get ported over to the Amiga, for a while the Archie was the only way I was able to play Zarch and Conqueror, and without doubt remained the best place to play them even after the ports.
Still, regardless of which system you owned or had access to back then, it was a truly epic period of time to be involved in the home computer scene, and articles like this always make me happy as they whisk me back on a nostalgic trek to those good old days.
Starfighter 3000 on the Archimedes was perhaps the biggest indicator of what ARM and vector handling could do - and where the future was. That's an absolutely amazing game. It took a significantly beefier, and much later X86 PC to run anywhere near as well as the Archimedes could handle it.
Amiga was legendary for it's custom hardware for sprite / blitter object lobbing capabilities. Arguably, the best design of it's kind for that job ever made in fact. But as soon as you started throwing 3D and/or non-TV resolutions at the system the advantages of the custom graphics hardware were lost. A technological dead end so to speak. The AAA chipset was, according to some, a step towards the Playstation style vector handling - binned by incompetent commodore management for the more incremental AGA that saw the platform fall behind at a rate of knots. The 68020 wasn't a viable competitor on brute force to the 486DX; and certain titles (MS Office, DOOM, Xwing) more or less sealed amiga's fate.
On balance, I am glad I had the Amiga over other systems of same era; mostly because of the enormous software catalogue. Archimedes or even the Atari ST never came close to what was available in Amigaland.
Acorn never really were able to compete on price (nor did they intend to) but I never doubted the capability of those systems I had the chance to use.
RISC OS is a nice thing to go and play with occassionally, but the RasPi spends most of it's time in Raspbian.
AAA was supposed to be the successor to ECS, but manglement incompetence-induced delays meant AGA ended up being hacked together instead to provide at least *some* level of upgrade for the A4000 and A1200.
You might be thinking more about the Hombre chipset that was proposed as a replacement for AAA given that, by the time that was expected to finally emerge from the labs into production, it wouldn't have been anything like the upgrade it would have been had it launched as planned a few years earlier. Hombre was the point at which the chipset would have given up any pretence of trying to remain backward compatible, allowing it to focus on the sorts of graphics techniques required for the Amiga to remain competitive.
Pretty much the entire Amiga story is a bittersweet saga of greatness tinged with countless cries of "if only", "what if", and "dear god, why" throughout, and of a small and utterly dedicated team of engineers working miracles in spite of management attempts to hinder them almost every step of the way.
The Archimedes story is rather bittersweet too - a truly world class system designed from the ground up here in the UK, which managed to almost entirely fail to capture the attention of the masses, ending up as a niche education machine and ultimately living on only (*) as the ARM processor, and in the fond memories of anyone lucky enough to have used one at the time.
(*) as someone who earns a comfortable living designing systems with ARM processors at their heart, I'm well aware that the ARM-spinoff side of the Archimedes story is a genuine success of the UK tech industry and so, generally speaking, definitely not worthy of being idly dismissed as an "only" footnote. I'm just trying to - badly perhaps - make the point that despite the success ARM has become, it's still rather sad that the Archimedes wasn't able to latch onto any of that success and survive as a complete system to continue demonstrating to the world just what you could do with a well designed processor driving a well designed OS...
Isn't OS/2 also still around, now named eComstation? Although that is based on the OS/2 Warp version that is very different from the original 16-bit OS/2 that was released in the eighties.
Arguably all the various BSD versions also date from that era, being derivatives of Berkeley Unix.
Yes, I was going to say the same. BSD as an OS dates back to 1977 or so and the likes of FreeBSD, NetBSD and OpenBSD are direct genetic descendants, not re-implementations.
(Currently running FreeBSD 12.3 RELEASE here, on two desktop, this laptop and on my file server - Thinking about upgrading to 13 now that 13.1 is out - I still don't like n.0 of anything :-))
*General-purpose,* *graphical,* *desktop* OS?
UNIX in general is still around, but nobody sells proprietary-Unix workstations any more.
I am sure there are many other survivors, too.
Windows is still around, but it's not the same codebase as it was in the 1980s. It's an entirely new OS with a derivative of the same API grafted onto it.
RISC OS is mainly ARM assembler, and this means that it is locked to 32-bit ARM processors, while the rest of the world is moving to 64-bit processors. There are even ARM processors now that are 64-bit only, so they can't run 32-bit code.
Porting to 64-bit ARM assembler is just another dead end, so the OS needs to be rewritten to a high-level language with minimal assembly code. Making RISC OS into a Linux distribution that maintains as many features of RISC OS as possible might even be a reasonable choice.
I fully agree. Using a high level language could also bring us device independence as well, once the processor becomes that which runs the OS, rather than that which the OS is inextricably intertwined with.
However, I would imagine that the annual budget of the entire RISC OS world is less than the Linux Foundation spends on coffee, so...
...any volunteers?
If the core of the project is kept small and tight, with objectives of making the OS fit in the same footprint as existing RISC OS it's not so unreasonable for a team of 20 or so really skilled developers to be able to manage.
For a spare time project it's a bit of an ask; but where did Linux come from too?
In taking the ARM Assemblerness out of RISC OS of course, would no longer make it RISC OS.
The OS from scratch tutorials for RasPi are a fun diversion; though I certainly do not have the knowledge or experience to build much on top of where the tutorial leaves you.
From what I see of Linux development outside of the core Linux Kernel team, it might be better to look how the FreeBSD guys operate than how any of the big Linux "distro" teams operate. Especially the philosophy of keeping the kernel and userland development models together and sync.
I still use RISC OS most of the day and get really annoyed when I use Windows and the right mouse button doesn't reverse the direction of scroll buttons as RISC OS does. I wonder why Windows doesn't do this! Anyone has done a hack to implement that? n.b. Most of our four man business is selling and supporting new and second hand RISC OS systems and Acorn BBC's.
My bugbear when using Windows for work related stuff after using FreeBSD (same with Linux), is that when I use the mouse to highlight text, I can't just paste it somewhere else with a click of the mouse. That catches me out EVERY TIME :-) It would such a simple and efficient improvement to Windows.
So many firsts for me (happy school memories):
Customising all the GUI widgets and icons
Full-window dragging (not outline)
Lemmings (the first port I had access to).
Zarch
The amazing ARTWorks
Cascade
Hand-held document scanners
Pineapple video digitiser (had a VHS and camera attached, I was blown away)
First experience of centralised file servers and printing (Integrex?) - via econet
The collection of samples from various films of Arnie swearing that was going around at the time
Instant creation of a ramdisk by dragging a slider
Anti-aliased fonts
Applications self-contained in a single !Directory with their own icon
Modes 31 (oohh high res icons) and 40 (oohh lots of colours)
Saving something by dragging an icon to a filer window
That demo where you could move a 3D teapot(?) around in real time
The list goes on and on!
int main(enter the void)... The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
