!Store sale starts Jan 1st

Everything Steve said. My concern is for software no longer being maintained that may be lost by this change. It does need to be done, I’m just wary of the risk of reducing available software and the impact that this may have.

I suppose soon I ought to download the source tarballs and mod my own build with ZPP enabled.

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

I don’t think the bug fixing is the only benefit but I do consider that eliminating use of a specific section of memory that shouldn’t be used in that fashion is important to a more flexible use of the memory map.
The use blocking is something that should have been done and dusted nearly two decades¹ ago.
ZP providing a bandaid “fix” and flagging the culprit is good, maybe it could be made better.

¹ 1996 was the deprecation, by 1997 authors should have cleaned up most of the software. There’s also a decent chance that with encouragement all current OS revisions would be clean.

All I read is:

It does need to be done

It’s a good thing that it is being done.

But no good reason.

The reason for Zeropain is not to fix bugs – that’s a side effect. It’s a feasability study to assess the consequences to riscos of moving to high vectors. As I understand it high vectors are needed for future arm cpus. Just because future cpus will break certain programs is not a good reason to make them fail on current processors. Yes you want new and currently maintained programs to be aware of the future change and written accordingly but there’s no reason to break others yet.

I don’t think the bug fixing is the only benefit

So what is the benefit?

So what is the benefit?

Maybe if you read the rest of the sentence? Then again, your “feasibility study” remark shows you already know.

Do bear in mind that RO on a mobile/tablet development board can only be an interim if RO is to continue. Let’s not deliberately go down side alleys.

My understanding is so we have a hope of running RISC OS on something actually modern.
The titanium, mx6 and others are old – reaching legacy status if you compare it to tablets/smartphones.
Don’t get me wrong, they are fantastic machines for running RISC OS.
But when I want a new machine in say 2 years time – I don’t want to be running on an A15 tablet/smartphone CPU.
I’d want (idealy) a 64 bit desktop/server CPU, multicore capable OS with full PCI support, USB 3.0 (or >), multi sata etc.
Great work has been done for a lot of this, but people (or certainly myself) only learn from pain.
Maybe it should be EnjoyThePain rather than ZeroPain ;-)

I also thought that the initial memory area is also needed for multicore support as well.
Now that includes most of the current lineup of ARM processors as well.

Maybe if you read the rest of the sentence?

I did and it wasn’t a reason worth losing 1 legacy program. Flexible memory arrangements on its own is useless so lets run with the reason everyone is putting up with this namely getting riscos onto multiple cpu’s. If someone wanted to do that wouldn’t it be better to fork risc os and have a risc os high vector version for those who want to contribute to it. Most updates would benefit both versions and the shift could happen when the new version matures.

wouldn’t it be better to fork risc os

No, no, please, no.
Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

a hope of running RISC OS on something actually modern.

Given the Pi and iMX6 (etc) are currently being sold, I would be inclined to consider them modern if not exactly cutting edge.

if you compare it to tablets/smartphones.

The smartphone you bought last week is legacy status if you compare to tablets/smartphones.

On a more serious note, an awful lot of smartphone and tablet hardware is pseudo-custom, wrapped in NDAs, and for which there exists scant technical documentation.
I’ll throw one out there. Look at some sort of online tech site for what’s a new development in mobile comms. I think Samsung have just released Yet Another Galaxy.
Now point me to a datasheet for the onboard hardware. I don’t mean a teardown with a list of chips, I mean a datasheet detailed enough that a port of RISC OS could be made.
Now bear in mind the degree of technical content of the somewhat pitiful BCMxxxx “datasheet” of the Pi1’s processor. Do we even have a Pi2 datasheet yet?

I’d want (idealy) a 64 bit desktop/server CPU, multicore capable OS with full PCI support, USB 3.0 (or >), multi sata etc.

Is 64 bit really viable in the world of RISC OS? It isn’t as if we (Otter excepted) run applications that require hundreds of megabytes of memory just to perform startup.
Multicore, would be nice. It’s a bit silly to have four cores and only be using one. That said, RISC OS is still at its heart a single user single process OS. I think the work to support multicore will hit a frightening number of weird obstacles. Consider the use of any filing system in a CallAfter. Oh, wait, you pretty much can’t. This general lack of re-entrancy makes multiple processes on one core an interesting proposition. When we throw multiple cores into the mix…
PCI? Is that still going? Jeez, I thought we’d moved to a mini variant, and then on to USB3.
USB3 is good if you have the hardware to support it. I’m not entirely convinced that the Pi1 is capable of running a saturated USB2 link (480mbit); and many of the current boards of the older generation (OMAP3 / Pi) provide USB and ethernet via a very useful little chip that is a hub and an ethernet controller in one board. They interface in different ways (as a PHY with OMAP3, as a USB hub on the Pi1), but this little implementation detail hides one critical feature. That the fastest your USB will ever go is as fast as one port can go. No amount of clever software will get around this. If you file copy from two USB devices, running flat out it will go a maximum of 240mbit average, as all of the communications are ultimately pushed through one port.
SATA. Would be nice to have. As much as we might like to insult spinning rust, it has near-infinite write cycles, which is more than can be said for any sort of flash based storage. Decent spinning rust can mostly match flash media for reads, and can easily outperform for writes, and definitely outperform for longevity.

And finally… The ace cards. RISC OS has always had a very mouse-centric UI, and has always made full use of all three buttons. How would you replicate that on a tablet-like device? Do note that Android is, in general, moving away from having a menu button and towards having a little on-screen three-dots-in-a-row icon. Neither Android nor iOS understand the concept of context sensitive menus. The menu “context” is based upon what you are looking at, which leads nicely on to…
RISC OS is a full GUI environment. If you’ve used Android or iOS, you’ll note that – apart from a few halfassed attempts at multiple window support – the UI theme provided is very definitely single-app-at-a-time. Not only that, but single thing in a single app at a time.
That, plus the fact that my phone (for instance) is running email and such to a 5-odd-inch 1280×720 display. Which at a rough guess would imply everything is like 100 point text. What happens if you set the Wimp to use 100pt text?
Our mouse handling doesn’t exactly provide sane or sensible support for scroll wheels on mice, how would you plan to support such things as multitouch, touch pressure, tap-hold-drag, tap-tap-hold-drag, and so on?

So, if you manage to work around the hardware issues, you still have a metric tonne of UI and software issues to contend with if wanting to make RISC OS work on a tablet.

If someone wanted to do that wouldn’t it be better to fork risc os and have a risc os high vector version for those who want to contribute to it.

Given the potential issues involved, and the noted lack of “official” stable release for Pi type hardware, I frankly wouldn’t be surprised to see the next official release(s) being low vector versions.
The ZPP? That’s for us in the land of nightly builds. We’re the developers. We’re the ones that ought to know how to deal with things (and make sense of the ZeroPain logging). We’re the ones that ought to be fixing our software to work correctly. So we’re the ones that have to put up with ZPP (or build our own without it).

wouldn’t it be better to fork risc os

Yeah. That’s a great idea. Forking RISC OS worked so well the last time…

‘wouldn’t it be better to fork risc os’

Yeah. That’s a great idea. Forking RISC OS worked so well the last time…

So in the mean time users don’t get access to all the fixes/improvements that don’t break riscos because they don’t want to use a version that breaks a program they use.

So in the mean time users don’t get access to all the fixes/improvements that don’t break riscos because they don’t want to use a version that breaks a program they use.

Currently zero page relocation only affects the development builds. Stable builds haven’t (yet) been affected, so users aren’t seeing any breakages (yet).

To follow up what I said about mobiles, take a look at:
http://www.theregister.co.uk/2016/01/02/mobile_trends_for_2016/

@rick yeah agree completely. But I was being a little terse.
The A9 and A15 design’s have been superceeded a few times now.
Not that they aren’t great for us and now. But I would suspect that 2 years down the line 32bit may not be such an easy option for hardware.

64 bits are useful for quite a lot more than memory, but that misses what I was trying to say – my fault entirely.
The higher end arm CPU’s are 64bit which was my point.

But who knows, all I do know is progress is good and that was largely overall point.

And as for android, shessh, no. Only because the other choice is sell my soul,my wife’s soul and my kids souls ;-)

Ironic as it sounds, relocating Page Zero actually helps improve backward compatibility with software long term…why…it allows Page Zero accesses to be virtualised and remapped on-the-fly to legal RISCOS calls. This is the very reason I personally pushed for it to be implemented, as without it being moved neither a Hypervisor or Multi-core would be viable with the amount of unmaintained software out there.

As with the changes to ARM when StrongARM was implemented, it may seem like a backward step now, but the long benefits far outweigh the short term pain. Yes, some unmaintained software will break short-term due to bugs or use of direct access to Page Zero values, but these can be fixed with a compatibility shim Module if there’s a pressing need to get them working. This is what ZeroPain partially does as well as reporting the accesses to allow bugs to be fixed.

A lot of this has been implemented in the next release of ADFFS to provide backward compatibility, where a specific version of RISCOS from 2 to 5 can be specified and Page Zero is then translated accordingly. However, as Page Zero wasn’t remapped at the time, I had to implement an instruction emulator to look for Page Zero reads – this goes against what ADFFS does, which is to allow code to run natively on the CPU. With Page Zero now relocated, the LDR/LDM emulator can be removed and code once again allowed to run natively with all the speed benefits that provides.

Admittedly, the bulk of the community has no interest in ADFFS or any idea what it does, or how it differs from anything else that’s been implemented before. I’ve been critised many times for its game centric nature, but there’s a simple reason for this – games are a worst case backward compatibility nightmare and Apps are already covered very well by Aemulor. Not only do most games directly access legacy hardware, but they also touch Page Zero for vectors and values. If the bulk of games can be made to run on modern hardware, it’s not a big leap to get applications running in the future.

ADFFS is simply a test bed for the techniques and components required for a Hypervisor, it’s essentially a partial Paravirtualizing Hypervisor with support for only one VMM. When I get around to looking at Wimp support I’ll be aiming for a multi-core VMM via a full Hypervisor that will allow multiple versions of RISCOS to run on the machine and shim the apps back to the host Wimp. This wouldn’t be possible without Page Zero being relocated.

In summary, as a community we can either moan about changes in the OS breaking software and simply freeze OS development and progress. Or, fix what we can now where source is available, move on from poorly written software or find alternatives and worst case provide compatibility layers for unmaintained essential software.

Long term 32bits days are numbered in the ARM world and that’s going to make this change look trivial by comparison if RISCOS is to live on, on future hardware.

In summary, as a community we can either moan about changes…

I presume that is directed at me as I seem to be the only one advocating a roadmap which mininizes disruption so I’ll reply.

I’m pleased that riscos changes makes your program run better but you can’t assume ‘poorly written software’ is worthless. Someone may need to use it and until the compatibility layers are written the old software shouldn’t be broken if it can be avoided which it can at this present moment.

As far as I can see is the roadmap forward is break risc os and see who/what is left. It doesn’t matter to me, my self interest is in new stuff – I rarely use other peoples programs – but someone has to voice concern about the way forward instead of just following over the cliff.

Long term 32bits days are numbered in the ARM world

That day will see the end of risc os. We can’t even write the new stuff in C never mind convert the old stuff. All the HALs are written in assembler we have a culture of writing arm code. So converting risc os to a different processor – which a 64bit only arm is – will be impossible.

you can’t assume ‘poorly written software’ is worthless

The problem I have here is that this claim is based on the idea that reading from zero page is somehow ‘benign’ and can safely be ignored. I’m yet to be convinced.

Anything reading from zero page deliberately, in order to get information, is going to break at some stage when the undocumented contents of zero page move around. Such breakages won’t be clean and obvious; they will probably be subtle misbehaviour or hard to diagnose crashes. Jon seems to have the right idea for this with a system like ADFFS, to cleanly emulate the old OS versions on demand.

Anything reading from zero page accidentally is broken. How broken remains to be seen, but the only example that I can think of that’s guaranteed to be ‘safe’ is something like

if (*pointer == bar && pointer != NULL)

in C (or the equivalent in BASIC, where there’s no lazy evaluation of IF … THEN expressions). Anything that potentially does something more difficult with that NULL pointer, such as

IF pointer% <> 0 AND FNbar(pointer%) THEN

is in to dangerous territory, depending on what FNbar() tries to do with the supplied pointer.

As I’ve said before, maybe I write my code more robustly than most RISC OS developers, but so far all the ZeroPain bugs that I’ve found and fixed (one each in CashBook and Locate, IIRC) have been trampling over all sorts of random memory as a result of that one read from zero page. Neither of the bugs were what I’d call benign.

I know that the RISC OS world has a touching desire to bury its head in the sand about software that does undefined things on the newer OSs (running with Alignment Exceptions off, anyone?), but remember that we’re talking about breaking already broken software when it runs on an OS build that’s only aimed at developers.

but remember that we’re talking about breaking already broken software when it runs on an OS build that’s only aimed at developers.

The thing is that it isn’t only aimed at developers because there simpy aren’t enough developers testing things deeply enough to find the bugs / shortcomings in the software so there are victims volunteer testers too. That’s everyone that runs a development build and records/reports the problems they have.

People reading this that feel they can contribute by testing are doing a useful task when they do.

Edit: I’d add that we are not talking about “breaking already broken software” what we are talking about is implementing a feature that allows a new development thread to move forward and exposing the brokenesss of some software in the process.

The problem I have here is that this claim is based on the idea that reading from zero page is somehow ‘benign’ and can safely be ignored. I’m yet to be convinced.

Suppose you have a program that you must use that reads zero page and now fails to run. Are you saying the fact that the zero page access is now avoided is more important to you than being able to use the program.

Such breakages won’t be clean and obvious; they will probably be subtle misbehaviour or hard to diagnose crashes. […] Anything reading from zero page accidentally is broken. How broken remains to be seen, […]

A good example here is reading from an uninitialised pointer. Writing would fault, or risk stiffing the machine (in the old days) either immediately or upon a software reset, depending on how much was written.

Reading, on the other hand, is “safe”. You don’t trash the machine by reading from address &0. However this is where we get to the odd hard to diagnose bugs issue. If you are reading from zero, you are reading it for a reason. What is the reason? Is it a pointer to data? Is it a check word? Is it a string itself? We know the OS is not immune from these bugs, the most obvious being “oflaoflaofla”. Problem is, pretty much every version of RISC OS has different data at those addresses; branches or LDR PC, and to different addresses/offsets. This has the potential of introducing some very subtle bugs that potentially differ from machine to machine.
Just to make the point, *MemoryI 0 will show you that the infamous message, on a Pi with low vectors at least, is dofladofladofla.

but so far all the ZeroPain bugs that I’ve found and fixed (one each in CashBook and Locate, IIRC) have been trampling over all sorts of random memory as a result of that one read from zero page. Neither of the bugs were what I’d call benign.

Ditto. I had the misfortune of storing a bit of data at array offset +236. Read from the base of page zero, that’s &2001B738. Step back a little bit, you’ll see the text “ADP VBUS ON TIMER”. That makes it fairly easy to locate – a brief peek in the ROM components, and it turns out to be part of DWCDriver.
Oh.
Crap.

Kinda supports my thoughts that the RMA shouldn’t be writeable from user mode code, but all the same, it nicely highlights how an innocuous little error can cause potentially bigger problems all around.

To be honest, I’m glad that this is being seen to, because uninitialised pointers are a very real and very frequent problem. They can be noticed on other systems – I believe TurboC in DOS used to abort with a message like “NULL pointer exception”. If you were running in the debug mode, then you’d land right at the problem, simple fix.
RISC OS, on the other hand, has pretty much ignored this problem for far far too long.

My concern is for older software that people may wish to continue using that is not going to be further developed. If ROOL release the next stable ROM with ZPP and ZeroPain (without logging) as a user option, then that’ll be fine. It is a giant sticky plaster but given that this problem has been around for a quarter century and both Steve F and myself have admitted to being caught by it ourselves, I don’t see that a giant sticky plaster is necessarily a bad thing. It is going to be a trade-off between enhanced system stability¹ and not alienating users who may depend upon older (technically broken) software.

¹ I am telling myself that this is going on for potential multicore support in the future; as for basic system stability reasons it doesn’t sound so great given the awful lack of anything resembling sensible memory protection; that coupled with the legacy of the utter mess that is the RMA. There are many other things that arguably need to be fixed first. So I will tell myself “future multicore support, future multicore support” and just thank God² that finally there is something that will notice and fault if I screw up and use a pointer before pointing it at something.

² Alternative sky fairies are available.

and just thank God that finally there is something that will notice and fault if I screw up and use a pointer before pointing it at something.

This is another reason why ZeroPain (in its logging form) should persist. It is already less than easy to translate zero pain to a line of code that is failing – what this entire thread was about.
If future problems cause the program to simply abort, then the task of fixing things will become that much harder.

Now I’m excited! Are sky fairies avaliable as part of the !Store sale?
Hope there is an extra “bulk” discount.
Can we add that to a wish list in RISC OS?
Who is the most experienced in that area to implement said functionality?

I think Amazon already has that partially covered: http://www.amazon.co.jp/dp/B018HVTR2U

Or see that translated into something vaguely resembling English:
https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.amazon.co.jp%2Fdp%2FB018HVTR2U&edit-text=&act=url

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

Back on Topic again. Is there still a free/distributable reader for the latest versions of Datapower?

Suppose you have a program that you must use that reads zero page and now fails to run. Are you saying the fact that the zero page access is now avoided is more important to you than being able to use the program.

No, of course not. I’m suggesting that knowing that there’s a problem and, as a developer, being able to investigate and fix the problem is better than not knowing. Having users be able to report problems from all of those use cases that would never have occurred to me is better than not.

Remember that we’re still talking about development builds of the OS, not stable ones. As I’ve already said, the use of development builds is consensual.

I’m also going to need convincing about your use of ‘being able to use the program’; again, the examples that I’ve found were both very unlikely to have ever worked in any meaningful sense. At best they would have resulted in data being stored over something else in memory.

This is another reason why ZeroPain (in its logging form) should persist.

Agreed. I think the use of ZeroPain should remain an option for the long term (which it effectively is, albeit unofficially), as this isn’t a problem that’s going to get fixed overnight.