!Store sale starts Jan 1st

BTW… Address &FC170C98 is at offset &000010DC in module ‘SharedCLibrary’

Unfortunately CLib does not sanitise its inputs, so it is quite possible for something like strcmp(*str, *NULL) (where *str is a given string and *NULL is an uninitialised pointer set to NULL) to throw an error in CLib. Your best bet is to see what R14 points to (easier using ZeroPain!) and what R0/R1 are, you can then work backwards to find out what was called…

…but it is going to remain a rather difficult act as neither ZeroPain, the Debugger, nor any available development tools in the DDE are capable of translating CLib addresses to C functions.

ZeroPain is being removed ahead of RISC OS 5.24 to try and make sure that any bugs that are left in the OS (or other software, for that matter) actually get reported – it’s all too easy to ignore/forget about the ZeroPain log file that’s in the root of your hard disc.

So the logic is…to prompt people to report bugs, we’ll remove the utility that helps diagnose what is going on?

Would it not be better to provide an updated version of ZeroPain that sets a CallBack of half a second, then reports something like:

1234 serious problems were encountered with the program you are using.
The problems have been logged in the file “$.ZeroPain”.

Build in some logic so it will only warn you X times in an hour, to avoid landing in a never-ending loop where nothing can be done as the warning is always onscreen. The half second delay is so that if you get 47 doses of Pain in starting a program, you’ll be told once and not 47 times (!).

Make it annoying, not impossible.

This way:

• Shoddy software still works
• Ain’t nobody can pretend they didn’t know about the problems
• Developers will hopefully get some useful reports

ZeroPain is being removed ahead of RISC OS 5.24 to try and make sure that any bugs that are left in the OS (or other software, for that matter) actually get reported

Right, template for mostly likely submission:
“My system goes **** up (base over apex) at random intervals, I don’t have clue why. Please fix it.”

Alternate template:
“This system is **** and I’m off to use windows/linux/android (select as appropriate)”

I really don’t think that’s the route to go. I suspect there may be a few others feel the approach is wrong.

Would it not be better to…

What he said +1

Developers will hopefully get some useful reports

Well definitely what he said.
Prime example, Dave Higton finding an obscure bug in PopStar. I mean it’s not like people use a mail fetcher every day is it? Er…

Have to say, I agree entirely. There’s no way I’m going to install a ROM that may randomly stiff my machine at any moment, any number of times a day, quite possibly while I’m doing something complicated/time-consuming/crucial (delete as appropriate), just for the good of the cause, however much I agree with the objective: RISC OS is my /working/ environment. If the general idea – or one of them – is encourage a wider userbase to get involved, I don’t think this is the way…

Of course there is the slight problem that removing ZeroPain reduces the amount of debug information you’re likely to get when things do go wrong – which is why one of the things on my todo/wish list is to build some better crash logging tools directly into the OS.

I have to say that I can’t help but think that the time to disable ZeroPain is after you’ve done this additional work, not before…

Of course there is the slight problem that removing ZeroPain reduces the amount of debug information you’re likely to get when things do go wrong – which is why one of the things on my todo/wish list is to build some better crash logging tools directly into the OS.

I have to say that I can’t help but think that the time to disable ZeroPain is after you’ve done this additional work, not before…

Well I did start a couple of threads about my ideas for how to improve the OS’s logging capabilities, but they didn’t exactly garner many responses, so the ideas got pushed back into the depths of my todo list while I worked on other things for which demand was more tangible. Task prioritisation isn’t easy!

Well I did start a couple of threads about my ideas for how to improve the OS’s logging capabilities, but they didn’t exactly garner many responses

I saw the comments as thoughts on a step toward a system wide logging, which if you step back in time to the period Rick produced Harinezumi, you might note I was rather keen on.
Of course nagging for more detail or progress didn’t seem like a good idea.¹

Logging needs to start seriously early so that boot errors can be diagnosed as well as pre-desk/desktop and application errors

¹ I hate people asking for updates every five minutes at work thereby wrecking the “zone” state I’ve got into and delaying progress.

Of course there is the slight problem that removing ZeroPain reduces the amount of debug information you’re likely to get when things do go wrong

I prefer to fully enjoy the pristine zero page experience with the latest 2016 ROM builds and no ZeroPain module by default, however I do have a 2016 ZeroPain that can be softloaded at any time for diagnostics and rmkilled when done. !ZeroPain does not have to be in PreDesk.

By which time you have lost the work you were doing. You don’t need zeropain to do what you want just note the error address and use memoryi, whereis and showregs. Zeropain is needed to stop the program crashing in the first place so you don’t lose your work.

Just to be clear why I don’t like ZPP 5.24 + ZeroPain as a solution (one reason, but there are more)… Whilst ZeroPain provides a solution for some/much software, any ZPP build breaks Aemulor (and I think one or two other things, but this one is a definate) even with ZeroPain.

From my experience selling systems, most users have one or two apps that need Aemulor, even if they fall into the “rarely used” category. Impression-X will need Aemulor for the foreseeable future too, and that’s an actively developed program.

Right now, there is no even-numbered build for any current “top tier” hardware. Indeed, a quick check shows no even-number build for Pi either. So, in practise, as far as I can tell, only Beagle/Pandaboard (both effectively superceeded) have even-numbered “stable” builds.

I think it is thus important that a tested/stable build without ZPP be offered for all current hardware systems before ZPP is enforced:

These are the currently available hardware platforms that are live. Before we break things (and as Jeffrey has said, the benefits are minimal since ZPP write-protection came in for [I think] 3.71 and definately OS4), each of these boards needs to have a stable, current OS which users can fall back to in case of problems. My proposal is that this be 5.24, whenever that is decided to occur.

Note – as a major supplier of commercial hardware, I simply cannot ship [and by extension recommend as definitive] a “stable” OS update (eg. 5.24) that breaks existing, working machines/software. When a machine is sold, it is advertised with a specific capability (eg. ability to use Aemulor for legacy software). To release an OS update that reverts an advertised capability would need a very strong justification, or else it creates a potentialy serious problem. Remember that when Sony removed Linux compatibility from the PS3, they faced a class action lawsuit.

Sorry to rant. Just to be clear, I am broadly supportive of the end result (down the line), but I feel that the push to rapid ZPP adoption helps no-one. What I’m proposing (I hope) is a path that gets us there in a way that is measured and clear. I would assume that these proposed 5.24 builds would then be available “long term” ie. beyond 5.26 should they be needed. This would avoid the current “where can I get Dec30th build please?” problems.

Side note for developers – Adrian Lees released some useful ZPP protection BASIC tools which allow you to write-protect zero page on older systems. I use these to test ZPP on VirtualAcorn for example. For development purposes, these provide a useful way of testing without the need for an entire ZPP OS build. Info at http://sendiri.co.uk/

I am sure that ROOL will be aware of the customer service dictum that ‘the customer is always right’. It is a useful and valid principle.

Whilst ZeroPain provides a solution for some/much software, any ZPP build breaks Aemulor

Has anyone approached Adrian about Aemulor?

I’m guessing it’s reading values in Page Zero which aren’t being translated by ZeroPain, having said that I don’t recall seeing any ZeroPain crash reports here, so perhaps there’s a more fundamental issue with Aemulor that needs resolving. I’m fairly certain that the outcome of the discussions Adrian, Jeffrey and I had about PZ values needed for Aemulor and ADFFS to continue working resulted in legal means being added to RISCOS to retrieve pointers to the values.

Of course Adrian may be aware of the issue(s), but unable to resolve if the underlying problem is DDE or simply not had time to make the necessary changes.

Has anyone approached Adrian about Aemulor?

I’m guessing it’s reading values in Page Zero which aren’t being translated by ZeroPain, having said that I don’t recall seeing any ZeroPain crash reports here,

Looks like you missed Adrians comments. From memory the issue is that it has to use ZP in the fashion it does to do what it does.

I think the main issue on progress is time/health.

Looks like you missed Adrians comments.

Did he mention the issues elsewhere? Looking at all his posts, the last one is showing as 2011. Could have swarn I’d seen more recent posts than that, perhaps the site index isn’t up to date?

I think the main issue on progress is time/health.

Same as me then, programming in RISCOS is bad for your health!!

Did he mention the issues elsewhere?

http://sendiri.co.uk/ pretty much the first item after the introduction.
Aemulor info and then the description of the issue.

I think Adrian regarded Aemulor as a short/medium term workaround so there may be mileage in you talking hypervisor stuff with him so things could be part of the OS.
Given the freebie status of Aemulor on OMAP3/4/iMX6 I suspect he isn’t expecting it to provide an income.

Looking at all his posts, the last one is showing as 2011. Could have swarn I’d seen more recent posts than that, perhaps the site index isn’t up to date?

I could have sworn there was more recent content too.

having said that I don’t recall seeing any ZeroPain crash reports here

I managed to put my foot in it some time ago

Build in some logic so it will only warn you X times in an hour.

Or just warn you once per software.

I think the main issue on progress is time/health.

True for a 2016 module too :)

Build in some logic so it will only warn you X times in an hour.

Or just warn you once per software.

Trouble is, I have seen some ZP logs where the software that has the bug is not mentioned … just red herrings. And anyway, sometimes the frequency is a clue!

Trouble is, I have seen some ZP logs where the software that has the bug is not mentioned … just red herrings. And anyway, sometimes the frequency is a clue!

“Sometimes” getting meaningful information is more use than “never”
And the frequency is something that Rick picked up on.

A modified version behaving like SysLog strikes me as useful, especially with a frequency count for looping errors and a multiple log file feature to avoid losing logged events when the assigned log file size is reached/exceeded.

A modified version behaving like SysLog strikes me as useful, especially with a frequency count for looping errors and a multiple log file feature to avoid losing logged events when the assigned log file size is reached/exceeded.

Logged events are not lost immediately ZP reaches its file limit. It still stores them (up to 128?) and if the ZeroPain file is renamed it immediately creates another one with the missing logs. A message when it is full is displayed in Reporter, if it is running. (which oddly enough I do!). ZP also displays a message for each ZP log, with a count if there are a large number in a short time.

The latest Reporter will also write to syslog … but that probably is not what you are asking.

I have written a simple program which reads a ZeroPain log and does a 1-line summary of each, which makes it much easier to spot ones of interest, or which are multiples of the same bug.

I think Adrian regarded Aemulor as a short/medium term workaround

I’ve never had the impression when talking to him, certainly not at the London show when discussing his plans for an upgrade to Aemulor re ZPP.

n.b. His last post to the forums was Sep 23, 2015 in this thread

I’ve never had the impression when talking to him, certainly not at the London show when discussing his plans for an upgrade to Aemulor re ZPP.

Neither have I, Aemulor is very definitely a long term solution as the OS is never going to provide backward compatibility.

n.b. His last post to the forums was Sep 23, 2015 in this thread

There’s something wrong with the indexing on here, as clicking on a user and selecting all posts is returning a partial result. Something for an admin to look at.

http://sendiri.co.uk/ pretty much the first item after the introduction. Aemulor info and then the description of the issue.

From reading that, it sounds deeper than just Page Zero relocation that’s breaking it, so I had a look at David Pitt’s ZP reports

In the first, Aemulor is relying on an undocumented entry point into the Kernel, the pointer of which is stored at &394 – this could probably be added to ZeroPain to resolve short term. In the second report it’s directly touching the Address Exception Handler at &14 to see if it’s an “LDR PC, …” instruction – again this could be added to ZeroPain to resolve. I suspect there is further reliance on Page Zero and/or Kernel code due to the way Aemulor has to cap the app limit.

Jeffrey – is it worth considering adding an SWI to allow the applimit to be capped? Aemulor and the 26bit limit isn’t going to go away any time soon as there’s big name software that’s unmaintained that’s reliant on it, so a legal means to cap to 32mb sounds more sensible than having to tweak parts of the kernel. BASIC could also do with some additions, to allow USR and CALL to be intercepted for the same reasons.

there may be mileage in you talking hypervisor stuff with him so things could be part of the OS.

There’s a thread here on the subject and it’s requirements, of which Adrian has added input. There are further changes required to RISCOS before a Hypervisor would be viable, points 3 (Page Zero relocation) and 4 (improved cache flushing) have both now been implemented, however points 1 (improvements to HAL_Timers) and 2 (Memory switching) would need implementing as well.

Back to topic: a lot of discounts on RComp titles, but also Amcog games. I bought the whole. Very happy with each package. Almost all titles from RComp come with welcomed add-ons.

Back off topic.

I am staying in High Vector land on the Raspberry Pi for now.

That is 2016 Pi ROM and no ZeroPain module, as apparently intended by ROOL. Just a brief note on how that went.

LanMan98 pained on attempting to connect to an Apple Time Machine. That doesn’t matter much as ROOL’s LanManFS should be a pain free alternative. It didn’t connect to the Time Machine either but it didn’t pain. So far so good, then.

The show stopper was StrongED pain. StrongED is a “must have”, so that is the end of the strict high vectors thing, a 2016 ZeroPain module is now in PreDesk.