Roughly 30 years after its birth at UK's Acorn Computers, RISC OS 5 is going open source

Re: Yep

You mean "your Prussian friend"?

Re: Yep

Hermann Hauser was, and is, Austrian.

Re: A bit too old now.

RISC OS has undergone steady but slow development over the years. RO5 is a lot more modern than the classic RO3.x. But the slow pace of often paid-for development under profit-hungry and peccadillo-riddled closed licensing has left a lot of holes and was one of the big reasons to push for open-sourcing it. Let's hope the community bites.

Re: A bit too old now.

Or build a new kernel that supports multi-core and pre-emptive multitasking, which would need a fair rewrite of the OS, or gradually migrate modules and apps and run the older stuff in a subsystem layer. New drivers for new hardware.

All possible. A lot of effort. Though if fully open source and get away from god awful CVS, it may go somewhere if there's enough interest.

RISC OS on Linux just seems incompatible with the 'RISC' in the name, unless it's restricted to ARM Linux only.

Re: A bit too old now.

"I think the best route would be to build a RISC OS desktop on top of a Linux kernel, rewriting the RISC OS modules and applications in Rust (or C), and use Linux drivers etc. to make it exploit modern hardware."

Although this isn't what you meant, take a look at this.

Re: "Underpowered"?

>The original Archimedes hails back to 1987. At that time, the Atari ST520 was available and the Amiga 500 was released. The Atari had no graphics assist beyond some sprite handling

Atari added BLiTTER coprocessors to its lines in 1987 - the 520 ST was released in 1985 (January 1st at that) - ie the year before Acorn released the BBC Master 128.

...and it did!

If you look at the core implementation of modern Intel and many other processors, including the zSeries mainframe, they have microcoded RISC processors in them.

And that is not taking into account the remaining RISC processors, ARM, IBM PowerPC (although this is the most un-RISC RISC processor I've ever seen), RISC-V, and MIPS derived processors that are still available.

And I don't think that the micro-controllers and PIC processors that you find embedded in many millions of devices would exist without the research done for RISC processors.

Re: I had an A310 and loved it

I didn't have and Acorn - my Dad bought us a Dragon 32 - but I share your feelings about the passage of time. Every time I visit the National Museum Of Computing it becomes a tick list of machines I used to own, machines I use to work on and machine I use to covet.

Re: Vector drawing

One thing that I would have wanted for RISC OS is to allow !Draw-files for file/application icons. This would allow them to be arbitrarily scalable, and a bit of caching would make the overhead negligible. It was such caching that made Bezier-curve fonts render in reasonable time on an 8MHz machine. Similarly, you could define cursor shapes as !Draw files to make cursors easily scalable. Thumbnails of files could also be !Draw files.

Another obvious extension would be folder types, similar to file types. As it is, you need a ! in front of a folder name to make into an application, and there are no other kinds of folder than normal or application. Using types, you can make, say, word-processor files into typed folders. For example, a LaTeX folder could contain both .tex, .aux, .log, .toc, and all the other files generated by running LaTeX. I recall that one of the RISC OS word processors used application folders as save files, but that meant that all file names had to start with !. You could get rid of this for both save files and applications by using folder types instead.

For modern times, you will probably need more bits for file types than back in the day. I don't know if later versions of RISC OS has added more bits, bit if not you might as well add folder types at the same time that you add more bits for file types.

Re: Vector drawing

In their defence, the classic Mac OS natively supported PICT files — a merely serialisation of QuickDraw API commands, and therefore usually considered a vector file format — from day one, and it was expected that applications would be able to open and use them anywhere an image could be placed. It just didn't come with a decent editor.

Microsoft did much the same thing in WMF, but not until Windows 3.0.

Re: What I grew up with...

I also remember 4th D. As I recall, they did E-Type, Saloon Cars, Holed Out, Chocks Away, and Apocalypse(?), amongst others.

Ah - them were the days. All innocent and full of unicorns, before DooM came and ruined us all.

Re: Sadly

Hah - ChangeFSI. I'd forgotten about that. The docs explained how Floyd-Steinberg error diffusion worked, and I used that to write a program to print .PPM files in colour, requesting the closest colour from the printer driver, setting that as the PLOT colour, drawing a pixel to the page, and smearing the difference around the surrounding pixels.

Was slow as hell, but it did a *lot* of OS calls from BASIC. Maybe this is why I pull apart everyone's graphics these days.

Re: arguably other languages better suited to the modern world

Yes, BBC BASIC was only an improvement on what you got for default on home computers at the time, which is almost all cases were BASIC variants, and most often inferior to BBC BASIC. Hard disks were uncommon even at the time Archimedes shipped (with a floppy as standard), so using compilers were impractical -- you wanted programs to load and run without storing extra files on your floppy or using large amounts of memory for compiled code. It was only after I got a hard disk that I started using compilers on my Archimedes. Several compilers existed early on for RISC OS, including Pascal, which was arguably the most popular compiled language at the time (until C took over that role). There was even a compiler for ML, which is a much better language than both Pascal or C.

So, to look at alternatives for BBC BASIC for floppy-only machines, let us consider languages that runs interpreted without too much overhead and which were well-known at the time. Pascal and C are rules out because they are compiled. Forth was mentioned, but only RPN enthusiasts would consider this a superior language. LISP (and variant such as Scheme) is a possibility (LISP was actually available even for the BBC MIcro as a plug-in ROM), but it is probably a bot too esoteric for most hobbyists, and it requires more memory than BASIC and similar languages. Prolog is even more esoteric. COMAL is not much different from BBC BASIC, so this is no strong contender.

Also, BASIC was what was taught in schools, so using a radically different language would have hurt sales. So, overall, I would say BBC BASIC was a sensible choice as the default language. Other languages such as C, Pascal, or ML, were available as alternatives for the more professionally minded (who could afford hard disks and more than 1MB of RAM).

Re: Good luck

Boo! Down with this sort of thing!

Re: Good luck

32-bit code is useful for IoT stuff as 32-bit ARM chips are still a thing. It'd probably be wise not to throw it out just yet.

Re: Good luck

@ cuddlyjumper

Oh yes that is certainly the case, and the developers know it. Its what happens when the parent company breaks apart and the code gets no significant attention. I remember a few years ago somebody was writing a new SSL library to replace the convoluted spaghetti code mess that OpenSSL had become. LibreSSL I think it was callled and it basically chucked most of OpenSSL out of the window to get rid of the mess. OpenSSL is still widely used and became such a mess due to the fact that this heavily used code is developed by a team of...two.

Heartbleed happened because one of the two developers made a typo.

Somebody out there was interested enough to start writing LibreSSL, just like somebody out there is still interested in maintaining GNU Emacs. Someone will enjoy moving RISC OS into a multi-core world.

"and there's no immediate vision of where it's going" erm I think they know exactly where they are going. They even will PAY you to help get it there.

https://www.riscosopen.org/bounty/

@ elgarak1

There are plenty of applications to cover most stuff. In fact there are UNIX/Linux compatibility libraries that allow for easy porting of software from Linux.

RISC OS might not fulfill every need, just like Linux did only 10 years ago. In this day and age though most users tend to use multiple devices and operating systems and spread their needs across many of them. I know of a few people on youtube who say they use Linux for most things but switch to a machine running windows just to use some certain video editing software either because they know that software well or the Linux equivalent does not yet support something.

George R.R Martin maintains a DOS machine just so he can use his fave version of Wordstar to write his novels. He knows Wordstar so well that he sees no need to move to something more modern as that will incur a significant learning curve that he simply doesnt want to bother with. I'm sure for most other things he uses a more newer machine but when it comes to writing it must be Wordstar or bust.

One of my needs is to use Free Software wherever possible as I'm one of those guys who likes what Richard Stallman says and totally agrees with it. I do however remain flexible enough to allow personal exceptions such as booting Windows so I can use Sony Vegas as the Linux equivalents did not fully support the HD DV video format I was using. Then they started to, and now I boot windows to install windows updates and play certain windows based games/steam.

Re: RISC OS 6

I don't think it matters, because as far as I understand it, RISC OS 6 isn't a more advanced version, it's a fork.