Old RISC OS Open ROMs and HardDisc4 images

Hello, I was interested in getting almost all of ROM and HardDisc4 (self extracting) builds of RISC OS Open. To clarify, I need:

• Representive nightly builds (i.e. the latest ones)
• Softloaded ROMs for IOMD based ARM computers (i.e. RiscPC/A7000+)
• Self extracting HardDisc4 archives

That’s it, since I’m interested in archiving them as well as checking them out in RPCemu (and probably review some if I could complete my GUI section.)

Thank you for appreciation.

So let me get this straight. I want to test builds of RISC OS Open inside RPCemu and archive them. I tried looking up via the Wayback Machine and it’s unviable as some links aren’t archived. I like RISC OS, I have a RISC OS 5.28 setup on RPCemu (with some goodies) and I think it’s great, I have RISC OS Direct 5.27 and 5.29 (June 16 iirc). I want to have all builds (representive nightly builds + stable builds of RISC OS Open, from 5.15 to 5.27). Thanks for appreciation.

Edit: I could also appreciate if I could access a public server with all RISC OS Open builds available (for example, Steve Pampling’s server), or if someone had those and want to send it via Google Drive or something.

I want to have all builds (representive nightly builds + stable builds of RISC OS Open, from 5.15 to 5.27).

If you persevere with the Wayback Machine, you should be able to grab ROMs for three stable releases: RISC OS 5.20 (2013), RISC OS 5.22 (2015) and RISC OS 5.24 (2018). This base URL may be of some help.

I am puzzled why you would be interested in odd-numbered (development) builds. Really early builds (prior to the first stable release) are likely to contain serious bugs, and most (if not all) of the new features in a development build would appear in the next stable release anyway.

bq.I am puzzled why you would be interested in odd-numbered (development) builds. Really early builds (prior to the first stable release) are likely to contain serious bugs, and most (if not all) of the new features in a development build would appear in the next stable release anyway.

Well, honestly, It’s for simple archiving and for messing some stuff. I was looking for newest and the most recent nightly builds only, since it wouls be too much if I asked for all builds possible ¹ and it’s interesting to look them inside RPCemu.

¹ It would be thousands of files (IOMD ROMs and the HardDisc4 archive), which I wouldn’t fit on my HDD.

You can get the most recent build for RPCEmu from https://www.riscosopen.org/content/downloads/riscpc

Lmao, i only needed older versions, and i have 5 copies of RPCemu on my hdd (Main, RISC OS Direct and 3.71, an dev enviroment and a testbench where I test RISC OS Open builds)

I am interested in 5.24 source code so that I have some options available to me. In versions of RISC-OS after 5.24 any program in boot’s post desk does not run due to there being no memory available. I have no idea how feasible it is to compile my own ROMs with 5.24 desktop and the rest of the OS as 5.28, or kill and soft load modules to mix and match via a script on boot. Is this a good example of one potential use case and justification for having versions of source code and ROMs available in an official spot? A la Linux to roll your own OS. Certainly, as a minimum, stable releases of ROMs would have helped me quickly trace at what point in the OS versions this issue occurred. Much more preferable to crossing my fingers and hoping that I had certain versions of the ROMs from either a supplier or from my own backups.

I have no idea how feasible it is to compile my own ROMs with 5.24 desktop and the rest of the OS as 5.28

One problem you would have (at least in terms of functionality) is that the RISC OS desktop contains a lot of code that would normally appear in the kernel of an OS. Trying to “mix and match” components between releases may not work all that well.

But if you wanted to patch a specific bug in an older release, that is feasible: the base information (at least in terms of “what versions of each component appeared in what release”) is available on the GitLab server. For example, the RISC OS 5.24 build for the Raspberry Pi is defined here:
https://gitlab.riscosopen.org/Products/BCM2835/-/tree/BCM2835-5_24

If you wanted the corresponding information for a Risc PC build you would start here:
https://gitlab.riscosopen.org/Products/IOMDHAL/-/tree/IOMDHAL-5_24

Deleted because it wasn’t “on-topic”. :/

this is obviously an incorrect assertion given that many of us are using up to date builds of RISC OS and they boot okay.

He’s referring to this issue which happens on shutdown, not during normal running (Chris’s program is one to cut the power to a Raspberry Pi once shutdown is complete, by sending a specific command to external hardware on the I²C bus). The bug would affect any program called from PostDesk.

I don’t know if Julie is still looking at the problem, or whether things have just gone quiet.

Deleted because it wasn’t “on-topic”. :/

Note: the workaround to get PostDesk working is now described in more detail on my blog.

Uhh… I thought this is a thread for requesting old builds of RISC OS Open. If you wanted to, move it on an another post, so it wouldn’t clutter the main discussion.

I have 5.17 on RPCemu actually, but I was finding for a working 5.15 image on RPCEmu then 5.19-5.27 (representive nightly builds only, not necessarily all.)

Given that somebody else said they were interested in old builds in order to work around a specific problem, it seemed rather logical to see if there was an alternative solution that didn’t require depending upon something older/less developed/etc.

But, whatever, bye.

@Rick. I was wondering how to say thank you in a really nice way. THANKYOU! You’re an absolute star. I’ll run through your blog post tonight. Is appreciation off topic? ;)

Well, archiving it is my second priority, the major intent on why the bulk is, for comparison and experimentation (i.e. messing around with it). It’s pretty interesting how it transformed from an operating system on the Iyonix to supporting other platforms such as the Raspberry Pi and A7000/RiscPC.

It might seem pedantic, but there is the small issue of licencing.
ROOL/RODL have open sourced the OS, but I’m not sure whether that retrospectively applies to the built images from 2012 (earliest v5.19 for IOMD that was in general circulation I think)

I believe it does. The Git history was ‘patched’ with updated licences so even if you check out OS 3.5 era code it has the Apache licence on it. It would follow that the ROMs built from that code would also be Apache.

@Steve

It might seem pedantic, but there is the small issue of licencing.
ROOL/RODL have open sourced the OS, but I’m not sure whether that retrospectively applies to the built images from 2012 (earliest v5.19 for IOMD that was in general circulation I think)

I really hope an old downloads section in the site, where people can download old images (as an “if-everything-goes-wrong” option

I’m not sure whether that retrospectively applies to the built images from 2012

The RISC OS 5.20 distribution (July 2013) came with the Castle licence, which permitted copying and distribution provided that the licence was included. I don’t have any 5.19 downloads, but there’s a good chance they included the Castle licence as well.

It’s hard to find the ROM builds and HardDisc4 images in the Wayback Machine, for example, I got a HardDisc4 image from let’s say, January 2011 (a nightly build), but the ROM is from November 2010, which does mismatch the Jan 2011 nightly build. A stable build may sometimes lack the ROM (because it wasn’t captured) but the HardDisc4 did. That’s why I asked here in the forums directly.

It might seem pedantic, but there is the small issue of licencing. ROOL/RODL have open sourced the OS, but I’m not sure whether that retrospectively applies to the built images from 2012 (earliest v5.19 for IOMD that was in general circulation I think)

Why should this be an issue? As long as you don’t want money for it, you can freely distribute all ROOL RISC OS versions, no matter if the old Castle Shared Source license is still active or the new-fangled Apache stuff.

If I dig deep enough, I am sure I can find some older versions, but I haven’t properly archived stuff, all I found quickly was e.g. ROOL IOMD ROMs of 5.17 vintage. And specially patched stuff from Tom Walker (July 2010, whatever that version was – ISTR 5.15 being the first version running inside RPCEmu) and Jeffrey Lee (June 2011 – that might be 5.17), I don’t think there was a proper harddisc image back then.

as an “if-everything-goes-wrong” option

The last thing you want “if-everything-goes-wrong” is to download an ancient 5.1x ROM ;-) Punters can always fall back to the last stable version. For paranoia, it might be nice to have the second-to-last stable version available for checking if things do seem different. Having much earlier versions available just encourages people to try to use them.

but I’m not sure whether that retrospectively applies to the built images from 2012

Yes, no, maybe.

As the copyright holders, ROOL/RODev can change the licence as they wish.
If you have a set of sources downloaded, the licence that applies is the one supplied. The owner retrospectively changing things doesn’t alter that which already exists elsewhere.

If you want it fully open rather than Castle open, then follow the suggestion above and check out an earlier release which will come with the updated licence.

which permitted copying and distribution provided that the licence was included.

Yup. It was pretty much open source (in the OSI definition) as far as most of us were concerned. The only “major” restriction was that it couldn’t be included in a hardware product.
http://www.castle-technology.co.uk/licence/baselicence.shtml

Oh, and you couldn’t port it to non-ARM platforms, which given that it’s like a couple of hundred megabytes of assembler closely tied to how the ARM behaves… yeah, I can’t see anybody actually wanting to try. ;)

So, as Steffen says, the ROM images and associated source it can be distributed without restrictions.

Having much earlier versions available just encourages people to try to use them.

Now now, if we need nannying we’d go the way of Le Gros Pomme.

It can be useful to have a history of checkpoints. You’ll notice from time to time odd issues crop up and one works back through available builds (usually thanks to Steve) to see what and where.

It’s also useful to be able to use a previous build to roll back in case something is messed up in the newer build.

I’ll give an example. Circa 5.27 (which is what I think is installed), my USB mouse fails on the Beagle xM. It seems to start up okay (light on) and is then dead. I need to unplug it and plug it in again.
I notice that the USB storage flickers a lot during boot too, as if the devices are being enumerated twice instead of just the once.
I made mention once or twice here, but since I don’t use that machine much and since the previous version of RISC OS running on it was the one Jeffrey built for me with s-video support (5.17?), it seemed like a pointless task trying to narrow it down. I mean, “somewhere between 2012 and 2019” isn’t helpful really, is it? ;)

If I had a bunch of Beagle builds accessible, even if just the stables, I could work through and say “between this and this” at least.

(of course, it might have been fixed more recently, I don’t know)

Just like I said, my main intention with this is I’m going to mess around with RISC OS Open as well as archiving it. I would appreciate if someone has it all (representive nightly builds + stable builds after 5.20).

My main goal is archiving them all, and messing with it. It’s a pretty underrated system by itself, and since more ARM based rose to the mainstream (with the Raspberry Pi and more recently, M1 and M2 based Macs), I think it deserves to be seen more, and also preserve it. While RISCOS Ltd. (and later 3QD Developments Ltd.) sell all Acorn and RISCOS Ltd. versions, Iyonix releases aren’t preserved, as well as older RISC OS Open versions (except for the Wayback Machine, but if you tried to download older nightly releases, it might wouldn’t archived.) and the emulation is nearly non existent (unless the MAME guys made some magic) unlike the RicPC or the A7000.