!Store sale starts Jan 1st

We are pleased to announce that the !Store sale will start after lunch on January 1st. A variety of products will be on offer during the sale, with new items going on sale as the event progresses. Don’t forget to check back regularly for new offers.

If you’re a 3rd party developer and would like to have your software discounted during the sale, please get in touch and let us know what level of discount you’d like to offer.

For those unfamiliar with !Store, start by looking in your Apps icon on the iconbar – many systems will have !Store pre-loaded ready for use. If not, please download the !Store application from http://www.plingstore.org.uk/ The software works like any other RISC OS application, and allows you to view products, download free applications, buy commpercial ones and see special offers etc.

So is there a new version of NetFetch available or is Hermes going to die on development versions of RISC OS tomorrow?

I’d imagine somebody will make an updated version of ZeroPain.

I’m not running a ZPP version of RISC OS myself (haven’t had the time/desire to apply my customisations and rebuild the entire OS from newer sources) so…this is guesswork. ;-)

If you don’t have the sources to hand, there are two ways you can do this:

• Run the ZeroPain module through UnModSqz (you’re a bit stuffed if you don’t have this, as ZeroPain is supplied squeezed).
• Load it into Zap.
• It looks as if the instruction at offset +&44C (BNE &458) should be changed to B &458 (no conditional). This ought to defeat the check for the date and just run ZeroPain whenever.
• Save, done.

Alternatively:

• UnModSqz ZeroPain.
• Load it into Zap.
• Notice “2015” at offset +&544.
• Make it say “2016”.
• Save, done.

Have you tested it? It is possible that the rom iteself will suppress zeropain after 1st Jan.

die on development versions of RISC OS tomorrow?

Tomorrow has come here now, 2016 has arrived and NetFetch works exactly as it did yesterday in 2015, ZeroPains are recorded and emails fetched. It is worth a reminder of exactly what does happen today, 1st Jan 2016, the Important software compatibility notice of 5 July 2015 was very clear.

Phase 2 of the testing process is due to begin on 1st Jan, 2016. ZeroPain will refuse to run on any ROM built on or after that date.

The relevant date is not the calendar date but the build date of the ROM as revealed by OS_ReadSysInfo,9,2. ZeroPains will only become actual errors when the next beta ROM build is released.

So I built a Pi ROM anyway which has a build date containing “2016”, that put a stop to NetFetch/Hermes. Fiddling the date in the ZeroPain module to “2016” did evade that.

In the absence of UnModSqz Verma will extract ZeroPain unsqueezed. The year is at offset &41C in ZeroPain 0.04.

At the moment there is no need to do anything at all. It’s not broken, yet!

I thought NetFetch and its components had been fixed? There was a new version released at London, and I’m sure the announcement a few days before specifically mentioned the zero page issues.

Edit: NetFetch 4.00 released at London Show this weekend

The biggest prompt for this was the “Zero Page Protection” changes introduced by RISC OS Open over the summer

I think that when the next beta rom is created, there will be no bundled zeropain module in the zip. Hence you will need to have already downloaded the zeropain module and done the ‘2017’ fix suggested above. There are some things that require a beta rom image rather than a 5.22 ‘last stable’ version, not least support in EtherUSB 0.35 (20-Dec-2015) for the AX8872B-based USB to Ethernet dongle. Hence the 20-12-2015 beta rom image for the Raspberry Pi is a good thing to download now, while it is still the latest beta rom (there have been no changes yet to CVS since 20-12-2015).

Archive 23:12 (which appeared on my doormat yesterday) gives some of the background to the ZeroPain changes.

Archive 23:12 (which appeared on my doormat yesterday) gives some of the background to the ZeroPain changes.

As does The WROCC 33.5, which was emailed out to those on PDF subscriptions just before Christmas and should be on the doormats of those who take printed copies some time in the next few weeks¹. It’s on the WROCC website for any members who don’t get it by email and would like to read it now.

That issue of The WROCC also has a lot of more general information on compatibility requirements with modern hardware, as part of the meeting report.

¹ Shortly after the WROCC AGM, I suspect. We’re catching up on the missing issues at the moment, so I think the plan is to see what has been done by next week and then mail them all out in one package. That said, I don’t deal with that side of things; I just make the original newsletters late…

I thought NetFetch and its components had been fixed? There was a new version released at London, and I’m sure the announcement a few days before specifically mentioned the zero page issues.

It did specifically mentioned the zero page issues, but it also said :-

Please note that due to last minute testing, we may not have every function enabled in the show release, but any necessary updates will follow as free upgrades. The show edition will have all the key elements, but we anticipate that there will be future updates too.

The future update is still in the future.

I thought that paragraph was referring to additional (ie new) features in the software, rather than it being a reference to any zero page issues.

I’d imagine somebody will make an updated version of ZeroPain.

I was rather hoping that that “somebody” would be ROOL! In a rare fit of pragmatism they might realise that crippling the OS in the name of “doing it right or not at all” isn’t the way to drive users to our platform! Especially since it’s not just 3rd party apps which fall foul, but the OS itself!

Apologies to Andrew for hijacking his thread!

I thought that paragraph was referring to additional (ie new) features in the software, rather than it being a reference to any zero page issues.

So did I. Wrongly, as I found out after purchase. I believe the ZPP update is in the works somewhere.

I’m not running a ZPP version of RISC OS myself (haven’t had the time/desire to apply my customisations and rebuild the entire OS from newer sources) so…this is guesswork. ;-)

As I recall it was all discussed back in July, but either changing ZeroPain.c.cmodule line 93
if (e || !date || !strstr(date,"2015"))

to have “2016” will do for the next 12 months or
commenting out line 95
return error_get(E_Unsupported);

so that it doesn’t return the error for use over an indefinite period.

Both of course assume ROOL don’t amend the ROM to not work that way and thus force the issue of compatibility.

I should of course say IANAP

Especially since it’s not just 3rd party apps which fall foul, but the OS itself!

My pandaboard seems to be happy running with zpp on – rool must believe this change to be in the way of bigger better things (multiple cores? preemption?) so working through the bugs is better than just patching zeropain every 12 months. As it’s jan 1st, eat less salt, do more exercise, and other virtuous things…

In a rare fit of pragmatism they might realise that crippling the OS in the name of “doing it right or not at all” isn’t the way to drive users to our platform!

Some perspective might be good!

The only versions of the OS that are affected are the Development builds; Stable builds don’t have an issue, so any problems are currently consensual on the part of the user. For those who choose to use Development builds, the output of ZeroPain is extremely useful in tracking down bugs.

Yes, ROOL need to sort out the OS and DDE (I’m not sure if the current version of the latter solves all the ZeroPain problems), and the 2016 deadline might be optimistic. Despite that, though, it’s a real shame to see someone from a major RISC OS company knocking such a positive development from ROOL.

I’m not going to get into this argument again, but can I just clarify that when I’m posting on my own account under my own name then I’m not posting on behalf of any RISC OS company, but posting my own thoughts and opinions, which may, or may not, differ from those of my employer.

working through the bugs is better than just patching zeropain every 12 months.

First it should be pointed out that it hasn’t been a full 6 months yet then you have to consider that the zero page issues in the OS and DDE might have been a surprise.

A smidgen under 6 months was a challenging deadline, so perhaps an extension is in order. Long enough to release a clean OS and DDE perhaps?

My personal take is that we probably need one more “stable” build without ZPP, then go ZPP after that. The logic being that there have been significant changes since the last “stable” release (PMPs for a start) and no “stable” release for many modern boards (inc Pi2 if memory serves). As such, before we do something that is likely to break many programs, let’s do another “stable” release that can be a “long term” build. Remember that Aemulor currently won’t work on ZPP builds, which means that legacy software is also lost.

I think that it is probably too big a change for limited/little gain for the bulk of the userbase (remember that the jump to 32bit or ARMv7 was accompanied by a corresponding jump in performance/functionality due to next generation hardware – existing machines were also unaffected). ZPP unfortunately currently has the effect of “making things that used to work stop working” from a user’s perspective, for no equivalent upside, and affects any system running OS5, not just a new piece of hardware.

BACK ON TOPIC…. Messenger Pro and Datapower family now on offer for half-price or lower.

Messenger Pro and Datapower family now on offer for half-price or lower

I’ll ask the obvious question: ZPP compliant?

Perhaps,worth mentioning that AFAIK, there is not even a stable release for the Pi 1. I cannot see the logic in producing a stable version of RO5 for the Risc PC but not the Pi…

I cannot see the logic in producing a stable version of RO5 for the Risc PC but not the Pi…

If you consider a little you will realise that the processor difference and consequent behaviour with certain instructions is likely to be the issue there rather than being an intentional thing.

The software always worked on RPC, tweaking a little for an OS change being a little different to the changes for a different processor.

Remember that Aemulor currently won’t work on ZPP builds, which means that legacy software is also lost.

Unless there’s any fundamental bugs in Aemulor that ZPP highlights or hardcoded addresses, in theory it should just need a recompile. However, it’s not that straightforward as it requires an updated DDE. Unless I missed something, as far as I’m aware DDE does not take account of all ARMv7 deprecated instruction sequences and errata yet, and ZP issues may or may not be resolved in the latest release. The other issue is of course that its not being given freely to all existing purchasers pre-ZPP, which I think is a missed opportunity in assisting developers to get their software working on 5.23

Regarding ZPP and RISCOS in general, there are large sections of code that haven’t been checked for ZP access so it’s a tricky call on releasing a stable release. That said, I feel we do need a stable release soon for the original Pi, as its been in beta far too long. Pi2 support however complicates things, as that is still very much beta and due to the deprecated instructions and changes in cache structure, there may still be minor issues in the OS that need resolving.

Finally, regarding the ZeroPain Module, IIRC the deadline wasn’t set in stone and more a goal to get the development community to start looking at their software. Six months was always going to be a push for some of us, I for one have suffered serious health issues which have seriously delayed getting a ZPP fixed version of ADFFS released and I know I’m not the only one in that boat, so to speak. For those of us that are actively developing software, it’s not just a case of fixing the ZP access overnight, we have to fix all the other bugs we’ve introduced in the meantime and finish off features in development. And in some cases, wait for RISCOS to be extended so ZP access can be done legally – both Aemulor and ADFFS fall into this category due to the fundamental low level nature of what they’re doing.

In the unlikely event that ZeroPain is withdrawn, don’t panic…I’m sure I can provide a replacement, backward compatibility is my area after all and ADFFS has had it implemented for over 18 months. It wouldn’t take much to add an option to auto-enable it on load and add any missing addresses that need translation, should the need arise.

Regarding ZPP and RISCOS in general, there are large sections of code that haven’t been checked for ZP access

The Filer survives because the Wimp greys out certain options, try a key shortcut into the same sections of code and you’re in ZPP land.

In the unlikely event that ZeroPain is withdrawn

The next new build will need a new ZeroPain since the next new build will have a 2016 build date.

ZPP unfortunately currently has the effect of “making things that used to work stop working” from a user’s perspective, for no equivalent upside, and affects any system running OS5, not just a new piece of hardware.

This one has been simmering in my mind overnight.

Zero page errors are a probable source of many elusive “quirks”/“bugs” in various RO software. If the ZeroPain module setup had been available 10 years ago I’m sure a lot of random errors would have been tracked down and eliminated.
It’s a good thing that it is being done. The only element I have concerns over is the short timescale.

Of course if Jon magically managed to produce a full hypervisor by Monday¹ the issue would go away.

¹ Not likely in this reality. Not even a million to one (Discworld ref.)

Yes it is a good thing to fix zero page bugs but not at the expense of stopping something working altogether. If the only upside of zeropain is fixing a few obscure bugs which riscos has lived with for years then it is a complete waste of time – the same effect could have been made available to programmers only and not involved breaking legacy programs. I certainly hope ROOL have a good reason for implementing it – as it is I can see non. I’m sure they have a good reason but it would have been nice if that reason was explained seeing as how it’s the users that have to live with their decisions.