RO 5.22 for Pi

Stuart^h^h^h^h^h^h^h Steve wrote:

Those who have stuff that breaks can always go back to the last ROM build before July 5th 2015² it may not have bleeding edge alterations but then it works the way it always did.

2 It’s archived.

I presume you mean: here?

The latest Pre 1st July ROMS available there are:
Panda 2015-04-10
Iyonix 2015-06-18
Pi 2015-06-22

n.b. Zero Pain seems to have been added 1st July

Zero Pain seems to have been added 1st July

Zero Pain Day was the 5th July

Whilst the zero pain module was added to the sources on the 1st. I do now see that the ROMS weren’t changed till the 4th so available on the 5th.
Unfortunately this doesn’t mean any later ROMS are available from archive.org.

Stuart wrote:

Who? :)
Edit: Nice, Chris has remembered my name now :)

I presume you mean: here?

Nah, I meant an archive closer to home.¹

There’s the hold your own archive and the caution you are playing with a test build backup.
The first takes a number of MB extending to GB over time.
The second takes very little space and uses a few brain cells – you make a copy of the old ROM before you load the new and revert to the old if you have problems.
I assumed that everyone who does anything with a beta build was keeping copies going back a handful of versions (one at the very least)

¹ Closer to mine anyway. I had wondered about putting it on something at work with external access.

At Wakefield I had the same response from ROOL as Chris Dewhurst, and had it confirmed more recently a month ago in an email from ROOL. I am disappointed by this because I was looking forward to using an OS that is not going to change every few days, and one that is almost wholly comparable with the same version being used on most of the other RISC OS machines. The terrifying discussion of the effects of ZeroPain make me wonder whether I shall ever be able to use my RPi as my every day machine.

The terrifying discussion of the effects of ZeroPain make me wonder whether I shall ever be able to use my RPi as my every day machine.

Since the intention is to work toward a stable 5.24 and 5.23 (pre-July 5th) is as stable as any Pi version has been I don’t see your problem.

Pick a date before July 5th and use the ROM from that date until v5.24 is released.

What I don’t understand is why there has not been a stable release for the Pi yet, yet there IS a stable release for the RISC PC—a situation that makes absolutely no sense. (How many Pis run RO5? How many RISC PCs run RO5? Very few of the latter I’d suspect.)

Two stable releases of RO5 have come and gone since the Pi was introduced, neither of which made it to the Pi. Given the current obsession,with the misleadingly-named ZeroPain, the chances of a stable release of 5.24 for the Pi must be just about nil—it will be HARDER to achieve than for 5.20 or 5.22.

I don’t believe that ROOL have any interest in producing a stable version of RO for the Pi; if they had they would have achieved it by now.

I’m sure ROOL would love to release a stable version for the Pi. The problems hindering that that I know about are:
The Pi is a moving target in hardware (Rev.2, B+, A+, Pi2 …) and in particular firmware (start.elf) also on the Pi they arranged to bundle a significant amount of third party software. This also needs testing for each Hardware and Firmware update. This can be exceeding time consuming.
I wonder if there are people out there who could commit to doing some of the necessary testing?
Though that still needs a lot of time by someone at ROOL to coordinate.
There may be other problems I and you don’t know about!

I still live in hope that ROOL are able to take up my idea of a Facilitator Bounty as I’m convinced that if would expedite a lot of ROOL development. That does rely on someone being able to take time out from their main job.

What I don’t understand is why there has not been a stable release for the Pi yet, yet there IS a stable release for the RISC PC—a situation that makes absolutely no sense.

I’d suggest that it makes a lot of sense: the work required to get RISC OS 5 stable on the RiscPC was probably small, given that Acorn had already done a lot of the work back in the day. The Pi is a different matter, and isn’t helped by the fact that the work is being done by a bunch of volunteers in their spare time (like almost all RISC OS development).

The terrifying discussion of the effects of ZeroPain make me wonder whether I shall ever be able to use my RPi as my every day machine.

What terrifying effects?

Given the current obsession,with the misleadingly-named ZeroPain

As a developer, ZeroPain has already been useful: it’s highlighted a number of ‘features’ in software I maintain.

On the off-chance that it might actual help ….

There seems to be too much being read into the term “stable”. Stable in this case means that the version is not being further developed, it has been tested and deemed good, and is now being left alone.

The development, beta, releases are obviously not stable in the above terms but that does not mean they are necessarily “unstable” in the sense of broken, unreliable or generally useless. Actual development mistakes are very rare, the releases are by a very large majority good and fit for purpose. “Development” need not be a negative term.

As far as the Raspberry Pi goes the release that comes closest to the concept of “stable” is RC14. It is not called “stable” because there are residual issues which Jeffrey posted a link to , a state of affairs that applies to all Raspberry Pi release.

If one really doesn’t fancy the Zero Pain, a perfectly reasonable point of view, then the currently available option on the ROOL site is RC14, which is, I believe, in real terms stable in all but name, or put another way it is a “stable” as it gets Pi-wise.

It is what it is, the Raspberry Pi is cheap and cheerful, and it is a DIY job. You get what you pay for. If the concept of Pi “stability” is perceived to be insufficient then RComp and CJE have more managed non-Pi alternatives.

Fair does, some just want a stable and reliable machine to use for real work and perhaps it is a bit less than obvious what to use. The short answer, already given, is RC14 or a development build before 5th July 2015 and if that is not good enough then “tough”.

What ROOL is not going to release as “stable” something that does not fully come up to their required standard.

ROOL and its contributors have done a superb job and do not deserve complaints.

The terrifying discussion of the effects of ZeroPain

I see no need to be terrified: ZeroPain on a Pi is actually quite benign – it emulates accesses to some storage that has moved, so code can run as normal. It also logs the accesses, but you do not have to read the logs – and anyway even that stops when the log is full.

The logs are useful to developers, as they highlight bugs in our programs which have been very difficult to find in the past.

However, currently RC14 is the nearest to a ‘stable’ version of RISC OS for the Pi. The daily development builds are definitely of varying stability.

Surely anyone concerned about geeky matters discussed on here shouldn’t be using nightly OS images?! As others have said, for the majority of people interested in RISC OS on a Pi, RC14 should be their first port of call.

Looking at the port overview page on the wiki, those look like reasonable reasons for the port not being ‘stable’ (although I think the BCMVideo one might be optimistic).

Surely anyone concerned about geeky matters discussed on here shouldn’t be using nightly OS images?!

As David Pitt pointed out, many people appear to be unreasonably afraid of using development releases. My experience also shows clearly that trouble for the end user is rare. There is always an easy Plan B in the unlikely event that one does give trouble.

Many of us would rather have far more users trying them out.

I have been using a Raspberry Pi as my main machine ever since RISC OS on it became available. I am now using 5.23 on Rpi2. Why do folk bait their brains with chimaerical fancies about stability?

The second takes very little space and uses a few brain cells – you make a copy of the old ROM before you load the new and revert to the old if you have problems.

Is it possible to use the kernel parameter in config.txt to boot selectively (manually editing as appropriate) from riscos.new (latest 5.23, with ZP) or riscos.old (5.21-RC14), presuming one has the latest Harddisc4 installed? Predesk (etc) files to load say Aemulor could then be tweaked to detect 5.21 before loading the module. Or would anything in the latest Harddisc4 break when run on top of ROM 5.21?

Is it possible to use the kernel parameter in config.txt to boot selectively

Though is it is possible to rename the Pi ROM image in config/txt and the Pi will start I think the snag is that the write back of the CMOS on close down is hardwired to riscos/img. There is a hardwired filename in the SDCMOS module. When I tried a ROM rename to save fatiguing myself on every update by having to change the ‘riscos’ to ‘RISCOS/IMG’ the CMOS settings did seem to get lost somewhere. I wouldn’t put too much money on that, I could be wrong.

To achieve pain freeness here I have a card with the 4th of July pre-pain ROM on it. It’s only for test purposes, the pain ROM versions are not that painful though there are some minor breakages they are not enough to impede progress. My RISC OS image is on a SCSI pen so the SD card is very simple, Fat with no partition, just the firmware and ROM.

For selective booting, my way is to have three RISC OS images on the card: one to which I can revert, one new one, and the third is a copy of whichever I want to boot from. The third is named RISCOS/IMG; the others have appropriate names.

To change which I’m booting from, I delete RISCOS/IMG, then copy my chosen one as RISCOS/IMG.

Though is it is possible to rename the Pi ROM image in config/txt and the Pi will start I think the snag is that the write back of the CMOS on close down is hardwired to riscos/img.

Which is a nasty habit that is on Jeffreys clean up list (unassigned status)

Steve wrote, apropos the write back of the CMOS on close down

Which is a nasty habit that is on Jeffreys clean up list (unassigned status)

I think that I have proposed before that it be written as a separate file in the DOS partition.

This could possibly avoid the problem described by David.

I think that I have proposed before that it be written as a separate file in the DOS partition.

The link David posted earlier points to the page where Jeffrey itemised things that needed changing in the Pi build for stability.
As I said it’s on the list to change that CMOS save from saving back to (and potentially corrupting) the ROM image and save it in a file instead.
This will no doubt ring an old bell with Dave Higton. Not wishing to rake over old coals, but he has “told you so rights” on that one.

Brian:

I am disappointed by this because I was looking forward to using an OS that is not going to change every few days,

You know, when RISC OS 3.5 came out, we used it – bugs and all – for a long time, until 3.6 was released which fixed some bugs and introduced others. Then along came 3.7 which was, well, pretty much the same story.

Point is – there are versions of RISC OS that are every bit as reliable as those official Acorn releases that were burned into ROMs. You can install one of those, you do not need to go on the nightly track and update every single day…

and one that is almost wholly comparable with the same version being used on most of the other RISC OS machines.

It is. The change here is a technical change to move something that applications should not be accessing to a place where they can’t access it. While very few applications will be poking around in RISC OS’s private workspace, the bigger problem is that a program trying to read from memory before knowing what it is supposed to be reading will be reading from address &0. This is wrong. The application is wrong. Application workspace begins at &8000 and anything lower should be out of bounds. The problem is, this was never faulted. Until now. And now we’re seeing the side effects of a quarter century of pretending the issue doesn’t exist (look how long it took Acorn to even write protect page zero!).

It is painful now, but in the long run it should mean software is generally more stable. Not the OS, the software itself. Because when accessing bogus memory locations (typically an uninitialised pointer in C) it will fault instead of returning “whatever happens to be there”, so it will be obvious that something is wrong.
Really, I wonder how many of these obscure “hard to track down” bugs are due to varying changes in the contents of the low part of page zero? The application can (incorrectly) read, say, a bit of the FIQ workspace a million times, but one time some other bit of code may be there and the value read would be something different to normal…?

The terrifying discussion of the effects of ZeroPain

Terrifying? Seriously?

Terrifying to me would be to plug in the Pi’s power brick and see the Windows95 splash screen appear. God, that was an abysmal piece of cack…
It was the Microsoft equivalent of Arthur 0.xx – a beginning of interesting things, but otherwise itself best left forgotten.

Let’s see… The quality of the video chipset drivers was so woeful that it convinced Microsoft to begin the DirectX project for a standardised way of talking to such hardware.
The monolithic registry, infamous for how often it could screw itself up.
The one I had contained ScanDisk as the old fashioned DOS style recovery tool – and you’d need it. Long filenames on FAT always were a bodge, and W95 often messed ‘em up.
I don’t think I’ve ever experienced any other machine blue screening (major error report) when doing something as innocuous as eject a CD-ROM. W95 had a habit of doing this. And bluescreening for other reasons, like… oh, I don’t know, random drivers for random bits of hardware just want to crash. It is an anthropomorphic thing – they want to crash. They enjoy ****ing me off. They thought it was funny.

This, I’m describing, was Windows 95. The “OSR2” release was slightly better, but really, it sucked donkey testes until Win98SE came along.

With this in mind, would you please consider re-evaluating your concept of what a RISC OS “stable” (vs what? unstable?) release is? Nothing, not even Arthur 1.20 (which I have used) has been that bad.

make me wonder whether I shall ever be able to use my RPi as my every day machine.

As David helpfully pointed out, there is no such thing as a “stable” release. What the even numbered versions of RISC OS are is tested – meaning development ceases for a short while and all sorts of things are tested to ensure all is good (or that known bugs are known and there are no new surprises). The nightly releases? Untested. We are the testers for those. Not “unstable”, but “untested”.
Because…if you think of all the permutations on the Pi SD image alone, it isn’t feasible to test that every single night.

Now, the beta builds are not necessarily any less stable. There is a possibility that something may go wrong, but the only time that has happened to me were because I had a mismatch between the Pi’s oft-changing firmware and the version that RISC OS needed. It is better to think of the beta versions as “enhanced” rather than “terrifying” (buggy, etc).

If you do not need the enhancements, if none of the new stuff entices you to upgrade, then just install RC14 and be done with it. I used RISC OS 3.7 for six or so years, and that’s still what is in my RiscPC. Likewise the Pi – if you install RISC OS and leave it alone, it won’t mysteriously expire or demand continual upgrades. It will work. Sure, you won’t have the newer features, but what you have will work every bit as well as anything Acorn ever released…

What I don’t understand is why there has not been a stable release for the Pi yet, yet there IS a stable release for the RISC PC—a situation that makes absolutely no sense.

Ah – but the RiscPC is a “known known” while the Pi is a “known unknown”²⁰⁵⁰⁰. Or, in regular English, the RiscPC is a pretty dumb bit of hardware that the OS entirely controls and once all the parts work, that is how it will continue until hardware failure.
The Pi, on the other hand, is an ever-growing family. I have the Pi Model B 256MiB issue 2. There was one before, something different with the IIC ports (maybe some other changes). Then along came the 512MiB version. There’s also a Model A (simpler) and then a Model B+ (more ports). Oh, and somewhere along the way there’s a flattish edge-connector sort of thing (Compute module? is that the name?). But we’re not done yet. We also have the Pi 2 which is really similar but uses different processor technology (Cortex vs ARM11 – doesn’t matter much for us but it matters a lot for the OS that controls it all). Oh, and, yeah, there’s four of ‘em inside that chip.
This isn’t all. Not only have the actual Pi devices changed and evolved a lot, not only that, but the firmware that gets the thing going has changed numerous times too – and not necessarily in compatible ways.
Given the history, we would be dumb not to expect the firmware to change again and possibly another member or two of the Pi family. Not tomorrow, but sometime…

So when you say you want a stable release for the Pi – please first define what you mean by “Pi”.

²⁰⁵⁰⁰ cough

Steve:

What terrifying effects?

Effects suspected to be linked to the use of ZeroPain include:

• Exploding computers
• House collapses
• That 48 car pileup on the LA beltway
• A minor supernova wiping out two planets containing sentient life

And by far the most terrifying effect:

• There is a good (81% probability) chance that your goldfish will spout wings and fly around the kitchen speaking random quotes of Chairman Mao¹ translated into Dutch. Scientists so far do not understand why this happens – they only understand that this is not being done for religious or communist party reasons, your goldfish will do this simply because it can. Utterly terrifying.

¹ It has been noted that some goldfish, particularly the ones with the bulgy bubble eyes, prefer to quote Sun Tzu who is rather more interesting…….provided you understand Dutch.

Why do folk bait their brains with chimaerical fancies about stability?

Had to look that word up. ;-) Turns out there is no ‘ae’ in the derived word ² – and yes, I’m using an authoritative source and not that butcher job corruption known as “American English”…
http://www.oxforddictionaries.com/definition/english/chimera?q=chimaerical#chimera__20

² Don’tcha just love English’s great big pile of contradictions?

David:

I think the snag is that the write back of the CMOS on close down is hardwired to riscos/img.

Yes – it will save the settings to “riscos.img”. I was victim of this a few times (why the <beep!> doesn’t the screen settings work?) until I remembered. I saved the SDCMOS module to disc, twiddled the filename (I called mine “risczp.img” so it was a simple tweak) and loaded it in place of the original…

Having said that, doesn’t the bootloader pass a bunch of parameters to the kernel? It would be nice if RISC OS could read this to know what the ROM image is calling itself…

The tl;dr version: If you are a regular user (not a developer), you don’t need to update RISC OS every single day. You. Just. Don’t.
If you want the closest thing to “stable”, install RC14. Stick with that. The end.

Having said that, doesn’t the bootloader pass a bunch of parameters to the kernel? It would be nice if RISC OS could read this to know what the ROM image is calling itself…

cough one would be wanting the general modification listed by Jeffrey then.
Needs someone to code a CMOS save to file routine that puts the settings into that fancy boot area instead of the ROM image and alter the ROM boot so that it picks the CMOS settings from that file instead of the ROM image.
Know anyone with a Pi that can write assembler? (and is used to accidentally trashing their machines boot)

If you are a regular user (not a developer), you don’t need to update RISC OS every single day. You. Just. Don’t.

Or you don’t mind bo-luxing your test machine for a while.

If you want the closest thing to “stable”, install RC14.

But if you want something that isn’t likely to eat its own ROM image you probably want to go go back to some pre-historic version that doesn’t save the CMOS settings into the ROM.

Needs someone to code a CMOS save to file routine that puts the settings into that fancy boot area instead of the ROM image

…and hope a whole lot that it is either keyword=value based, or that the CMOS layout doesn’t change between RISC OS versions, so that it is safe to use different images with the same CMOS file.

Know anyone with a Pi that can write assembler? (and is used to accidentally trashing their machines boot)

It is significantly harder than that. You will need to be able to probe for the SD card, access it, understand FAT, locate the CMOS file, and load it. Or failsafe if any of this doesn’t work.
All with practically no support whatsoever from RISC OS – if you’re lucky, the HAL might be expanded to contain some useful generic functions but there will be no filesystems yet, probably not even a module area as such (so allocating workspace in the RMA? hmmm…). If something goes wrong… well, you might be able to find a way to blink one of the LEDs under software control. Don’t expect any video, either, as you’d be the one telling RISC OS what sort of video there is supposed to be.

But if you want something that isn’t likely to eat its own ROM image

Yikes!? Never experienced that here…

On the older, evidently weaker, power supply it would sometimes trash its own disc structure – but not had it eat its own ROM image.

you probably want to go go back to some pre-historic version that doesn’t save the CMOS settings into the ROM.

And attempt to find an equally pre-historic firmware to go with it. ;-)

Or you don’t mind bo-luxing your test machine for a while.

But if you want something that isn’t likely to eat its own ROM image you probably want to go go back to some pre-historic version that doesn’t save the CMOS settings into the ROM.

What is the point of this utter drivel. The downside to the write back to the ROM image is only that the ROM image cannot be renamed. Let’s put everyone off the the whole notion.