Testing on RISC OS

The RISC OS API was unambiguous in 2004

Well… The documentation was always broken, just less so and pretty much only the one supplier/implementation to worry about.

Then forking happened.
Then things got “interesting” (by a very skewed definition of the word interesting).
Now most of the API matches. But clearly not all of it.

I told Castle

Meanwhile the website of the other version might leave you wondering why it went from version 4 to version 6.

So we have two online PRMs (sort of) and in certain places they say different things, and one (here) sort of maybe sometimes mentions that there’s a difference, but that’s about it (case in point, KeyV reason codes – one for Cerilica and one for Select, no further details).

and was told “it was early days”.

Oh bollocks. If it’s different in the beginning, it’s not going to suddenly magically change to being right somewhere along the line. Especially not when there might be software in use that relies upon that wrongness.

Missing API is one thing, but having flags and in some cases registers in the wrong place is indefensible.

• Can’t do that, they’re the “enemy”
• Not Invented Here
• Couldn’t be arsed to read Gerph’s emails
• Just picked a convenient looking register and screw the consequences
• All of the above?

;)

Seriously, I’m glad I don’t actively support any version of RISC OS 4.
It’s not “Yay Castle, Select Sux” or anything, it’s primarily because I simply don’t have it, and since it is (sadly, very sadly) an evolutionary dead end I don’t see any point in getting it.

Because if Select/Adjust was a thing that was still being developed and maintained, it would be expected to support it, and this sort of nonsense would annoy the hell out of me. As you say, the same damn things in different flags, bloody hell…….

Take a peek at https://www.riscosopen.org/wiki/documentation/show/PointerV and wonder to yourself what and how are mouse scroll wheels supported on the different versions? It looks like PointerV 4 under Select, while we use PointerV 9?
Then again, for many years we had the awful cluster**** of the USB driver itself calling up to the Wimp to fudge things.

Problem is, while I respect Charles’ opinion, and him himself, it’s quite likely that more people who are interested in testing RISC OS stuff will be thinking of this version of the OS.

So in a way it’s a shame that he isn’t willing to support our flavour of brokenness (even if an option that must be explicitly turned on), especially given that the ways and means of how Pyromaniac works might offer serious ideas of how to keep stuff running when 32 bit silicon is no longer. I mean, nobody seriously thinks RISC OS is going to get ported as-is to ARM64, right?

The innovation of Pyromaniac is to actually remove the OS and replace it with something else, with the software being none the wiser. A totally different way of looking at emulation, and one definitely worthy of attention.

The RISC OS API was unambiguous in 2004

I could swear someone started a thread recently that described how an aspect of the OS (pick any version) didn’t match what the documentation said.
Actually, think that should be several threads about aspects of the OS. Repeated items from pre-Castle, pre-ROL, days of yore.

So, perhaps, in this post-Castle era, people could have a chat or two about what the software expects to see and arrange to have that happen – with a resounding bollo to what happens in the layer underneath, provided it works.

I told Castle then that their version was insufficiently compatible with RISC OS and was told “it was early days”.

I’ve developed a number of applications over the years, including supporting some Select-only features as well as RISC OS 5-only bits. But those differences were in enhancements to the common base. I’ve never encountered any other significant incompatibilities, but perhaps I’m just not venturing into those areas.

Examples would help the discussion, I feel, rather than assertions.

Examples would help the discussion

One I remember stumbling across a while back…
https://www.riscosopen.org/wiki/documentation/show/Dynamic%20Area%20Flags

It’s a good example. The page itself notes Inconsistent use of flags between RISC OS 5 and RISC OS Select API.

Oh, and note the brilliance of suggesting to determine which API to use by whether or not OS_Byte 129 returns &AA. 🤦🏻‍♀️

(because, obviously, one cannot expect to have OS_ReadSysInfo 10 return something useful)

There’s also this mess: https://www.riscosopen.org/wiki/documentation/show/OS_ReadSysInfo%206%20Items

It’s still not managed to achieve compatibility with the RISC OS API as it existed when they launched. Missing API is one thing, but having flags and in some cases registers in the wrong place is indefensible.

Do you have a list of what these things are? If there was a collated list, maybe someone could look at doing something about them at some point.

Since this is an open-source project you’re also free to send in patches to fix these issues yourself if you want to.

But I’m beginning to suspect that some people wear incompatibility as a badge of “progress”.

I doubt it. RISC OS is hardly the sort of thing that attracts people who want to move fast and break things!

maybe someone could look at doing something about them at some point.

Please refer to the DA flags that I gave a link to.
Given this has been in the wild for numerous years, exactly how do you think it should be fixed?
There will be software doing it one way, and software doing it another, and really it never should have diverged like that in the first place, it’s not as if there aren’t bits available.
It just seems as if the two branches extended the flags for the use of the newer OS versions, with zero communication between the two.

You have to remember that much of the early RISC OS 5 development being done by PACE was specifically for commercial customers, and never meant to be released to what remained of the post Acorn RISC OS market, so compatibility was not a priority. Neither was working with ROL to feed code in either direction with no commercial imperative. We are actually very lucky that so little divergence occurred between RISC OS 5 and RISC OS 4 above and beyond the whole 32 bit thing.

Select did feature considerable enhancements, but with sporadic nature of later releases, and the cost of subscriptions or single versions, never gained critical mass to become the definitive version of RISC OS that it should have been. The decision not to do a 32 bit version for the Iyonix, meant that it missed the boat by the time of the port of RO5 to the Raspberry Pi and other cheap off the shelf hardware. It is still not too late to port a lot of the Select features to RO5, and much of the behind the scenes restructuring of OS in Select should be a template for future development.

Neither was working with ROL to feed code in either direction with no commercial imperative.

That, and ROL’s “interesting” approach to their documentation probably didn’t help matters. If developers like myself got “please explain” emails from people connected to ROL after releasing applications utilising the new features detailed in the Select subscribers’ packs, one can only imagine the reaction that Pace or Castle would have got if they had used the documents to duplicate those APIs in RISC OS 5…

was specifically for commercial customers, and never meant to be released

and

got “please explain” emails from people connected to ROL

So, in a nutshell, the documentation is a mess, the API is inconsistent, and everybody back then was happily shooting their own feet.

As Druck says:

We are actually very lucky that so little divergence occurred

To reply to Charles’ original point, I’m not doing RISC OS development these days but one thing that would bug me is that I’d sit down with an empty directory and want to write some code. But first I needed to set up a build system, but doing that would take up time and then I’d run out of time for writing useful code.

Really what I wanted was a template Makefile and a folder of tests that I could just do ‘make test’ and it would run everything in a tests folder and say ‘27/27 tests passed’. Because I’d be cross compiling I’d expect the process to run on Unix as well (unit tests are often not OS specific, and better tools for eg tracking memory leaks are often available on other platforms).

Maybe such a thing is out there, between the !Builder world and Charles’ work. But it would be nice to have a clear and simple route to get started.

(although the RISC OS world has a huge amount of inertia, so people just copy the endlessly-hacked-up build system they wrote in 1995. This is a big pain when taking on their code and trying to make it compile)

so people just copy the endlessly-hacked-up build system they wrote in 1995

Why not? It’s not so much inertia as a simple matter of two things:
1, If it ain’t broke…
2, If it works for them
Yes, it’s a pain when taking on other people’s projects (I’ve come across desktop applications developed and built completely outside the desktop, no MakeFile in sight), but the thing there is that you are taking on their code, so there will be differences. Everybody has a personal style. How they like to build, how they comment, where they put the braces, and so on.

While things are getting more “generic” with the introduction of Git and autobuilders (in essence requiring people to follow a third party way of doing things, plus code style guides enforcing particular styles), if a build system was originally designed in 1995 then it predates Google and all of the modern internet stuff.

If it isn’t broken (by their definition) and it works for them, I don’t see any need to alter it. After all, it’ll be all the effort to… to what? To do exactly what the previous build system did? Why bother?

No build system is perfect. The big whoo right now is Git, but it stands on the corpses of various build systems that came before it.
1995 was nearly thirty years ago. I don’t imagine we’ll be using Git in thirty years.

Rick I think you mean GitHub’s or GitLab’s auto builders, not git itself, which I assure you will still be around in 30 years.

No build system is perfect. The big whoo right now is Git, but it stands on the corpses of various build systems that came before it.

I think you’ll find that Git is actually a version control system, and has nothing to do with building code. It’s as unlikely to disappear as Subversion and CVS are: there’s sure to be a new “big thing” in VCS at some point, but projects won’t jump ship until there’s a good reason to do so because of the potential to lose useful history in the process.

The build systems that you’re talking about are separate functionality provided by cloud services such as GitHub or GitLab (or self-hosted variants thereof, like ROOL’s setup) to work on the code stored in their Git instances. Similar tools are available for use with Subversion and other VCS systems, so again – they’re likely to carry on in some form or other into the future.

After all, it’ll be all the effort to… to what?

Your build system is likely to be used a lot when developing code. Streamlining and automating things can be a massive quality of life improvement if you do a lot of developing.

and has nothing to do with building code

It’s a version control system, yes. But these days things are interlinked. Think of more ambitious projects that pull in libraries from all over the place.

but projects won’t jump ship until there’s a good reason to do so because of the potential to lose useful history in the process.

Depends upon the degree of portability. This very site jumped ship to a trendy new GitLab and retained history.

Weirdly, until Iris came along, it wasn’t even possible to read the OS’ source on the OS itself (Netsurf isn’t up to GitLab).

And, annoyingly, it looks naff on mobile devices. The filenames are truncated too short, and since RISC OS has a tendency to have repeated names with a numerical suffix (Wimp01, Wimp02, etc), it’s hard to tell one from the other.

they’re likely to carry on in some form or other into the future.

Ah, yes. Cloud services. Always the reliable option. ;)

Your build system is likely to be used a lot when developing code.

Of course.

The only question I really have… was it you or the other Steve who integrated making release zip files right into the MakeFile? That would be a nice addition.

Otherwise, my build process works for me. You’ll know I’m not a fan of the shared MakeFiles. It helps (me) to know exactly what options are being given to the compiler at exactly what point for exactly which files without having to rummage who-knows-where and understand an entirely different build system.
Especially as I’m a big believer in including function names and not squeezing apps and modules. The first helps with debugging, the second really ought to be pointless on modern hardware.

Streamlining and automating things can be a massive quality of life improvement if you do a lot of developing.

<cough> I do this stuff for amusement and to keep the gooey grey stuff functioning. If I was concerned about quality of life, I’d write code for a platform where bolting a few bits together can turn out great code.
Consider, well, consider ESP32 development. My netradio code is actually really simple. The hard parts are parsing the Icy metadata, and a menu system for setting the thing up. Most of the rest was simply calling third party libraries.
Consider my Mamie game. My view of the world was shuffling sprites on a screen to draw the game world. Now compare against the Unreal engine.
Or, as I’ve said in the past, VisualBasic from a quarter century ago against anything on RISC OS ever.

So I guess it’s just a good thing that a lot of my desire, as seen from recent playing with raycasting, is to understand how it works rather than actually doing anything useful with it. Because then it doesn’t have to be good and impressive, it just needs to demonstrate itself in action and the concepts can be understood.

But these days things are interlinked. Think of more ambitious projects that pull in libraries from all over the place.

That still doesn’t make them the same thing: the GitLab build systems, for example, are quite happy to pull code from Subversion repos as well as Git ones.

The only question I really have… was it you or the other Steve who integrated making release zip files right into the MakeFile?

Yes, that’s me.

I do this stuff for amusement and to keep the gooey grey stuff functioning. If I was concerned about quality of life, I’d write code for a platform where bolting a few bits together can turn out great code.

I don’t follow that. I write for RISC OS for amusement, too, but that doesn’t mean that I find turning my C or BASIC into a finished application interesting. It’s a mechanical process, with plenty of scope for getting things wrong. If it’s automated as much as possible, it leaves much more time for the tasks which are actually fun.

so people just copy the endlessly-hacked-up build system they wrote in 1995

Why not? It’s not so much inertia as a simple matter of two things:
1, If it ain’t broke…
2, If it works for them

Because it often doesn’t work for me. Either they released the source but didn’t include some component like a library, or they are relying on some build tool I don’t have, or they hardcoded the paths for their machine, or they shipped a binary for their build tool but it’s not 32-bit compatible and needless to say won’t work when cross compiling. Again, I waste time sorting out the build system before even getting near the actual code. And it is not exactly uncommon that the developer from 1995 is no longer around and somebody else wants to take on their project.

Build systems, in the general case, are hard, especially when multiple platforms start getting involved. Everyone cooking up their own thing makes them harder for no real benefit.

Either they released the source but didn’t include some component like a library, or they are relying on some build tool I don’t have, or they hardcoded the paths for their machine, or they shipped a binary for their build tool but it’s not 32-bit compatible and needless to say won’t work when cross compiling.

This kind of thing can be quite time-consuming to address, though. It wasn’t until I’d released all of my source code via GitHub and then tried to download and build from it on a clean OS install that I found what hadn’t been included. Aside from hopefully making it possible for others to develop from my source code, however, the exercise did reveal a couple of items that were essential but so low profile that they weren’t even covered by my backup process — let alone publicly released.

What would be useful is some guidance as to what is required to make something work more generally with the cross compiler. I’m not sure that I even fully know that, if I’m honest.

Everyone cooking up their own thing makes them harder for no real benefit.

I do have the feeling that there are a few active developers who have given no thought to, or even don’t care about, their software being useful to the platform after they themselves have moved on.

You’ll know I’m not a fan of the shared MakeFiles. It helps (me) to know exactly what options are being given to the compiler at exactly what point for exactly which files without having to rummage who-knows-where and understand an entirely different build system.

To take a counter view, I find it quite nice to know that if I fix a problem in or make an improvement to the CashBook build arrangements, for example, then that change will automagically be in the build setups for Locate, PrintPDF, Launcher, PS2Paper and probably other projects as well.

Because it often doesn’t work for me.

Yup. I understand that. It’s why I’ve not made any updates/fixes to WebJames. Could build with the DDE, good. Didn’t have all the libraries so it actually worked, not good.

By the way, where is the source of the stuff on riscosports, is that held within GCCSDK?

who have given no thought to

In my own case, the standard DDE stuff plus my version of DeskLib (I tend to link to it if I release the source to anything). Then each app should be self contained and build just by dropping the MakeFile on to AMU.
The stuff I write isn’t complex enough to need a half dozen third party libraries, which I think is where the problem lies. It’s not so much the source (you have that), or the build process (it can be updated/revised), it’s the dependencies.

I’m not sure quite how this discussion drifted so far off the topic I was trying to raise, but to try to bring things back to what I was trying to discuss and the encouragement I was trying to generate…

The documentation has always been problematic, and I’ve discussed my opinion and the mechanisms for solving that a number of times. It is related to, but independent of, the issue of testing your system. You can have tests without documentation and documentation without tests, but when you have both together you have a much more solid foundation. As I have stated, one of the purposes of RISC OS Pyromaniac is to provide a more reliable way of testing the system. The tests that it uses are, as Nemo points out, limited by who writes them. There is a danger in producing tests based only on your own understanding – other people may understand differently, or you may have only tested happy paths. This is why having others review the work is important. This is why having others produce parts of the tests is important.

Nemo’s comments elsewhere about GSTrans have indicated an area that was assumed by me, and for which I have now improved handling inside RISC OS Pyromaniac to report the cases that he raised. I’ve improved the testing in that area just by having had those comments. This is the sort of discussion and action (albeit limited) that I wish to encourage and stimulate through this thread.

The discussion here has ranged broadly to the issue of incompatibilities of the systems, of documentation, of difficulties in building code, and bemoaning the changes in behaviour. There are many individuals, with their own bug-bears and concerns, and that’s understandable (and I have my own, of course) but much of the discussion here does not progress the matter of how RISC OS itself, and applications, are tested or could be tested. It is important – at least to me – to not just complain that something isn’t good, but to try to improve it. In this case, to take the problems and attempt to address them constructively. It is towards the constructive “how can we improve this situation” that I have been trying to get to.

I’ve provided a number of resources for testing – articles, presentations, code examples, repositories and a re-implementation of the OS to make it easier, and accessible online for others to use. On the topic of documentation, there is work ongoing to try to make this easier in the future and if you want to be involved, contact me directly. I’m heartened to hear that some people have produced tests because of the things that have been said, or through their own work – having any form of tests in code is tiresome if you ‘just want something to work’, but it’s how you prove that it /does/ work.

I will apologise that in asking what other people have been doing, I did not give anything of my own examples in testing, – it’s very easy to ask others how they have been testing things but not actually give any concrete examples of their own work (well, in this case, beyond the things that I’ve published already).

So, to try to return to what is being done on testing…

I’ve returned to trying to test the Internet stack on RISC OS Pyromaniac, comparing it to that which went before in terms of RISC OS 4, RISC OS 5 and the new Internet 7. A few of the tests have shown up issues with RISC OS Pyromaniac not behaving like the earlier stack, and this causing failures of some modules. In particular, the handling of interface enumeration was poor, so I now have a better characterised understanding of the Internet 5 stack, and replicated this with the Pyromaniac stack, together with the tests to check this behaviour. In testing with the Internet 7 stack, this showed up some serious differences, which have been reported and some have been addressed. I’ve got tests that now exercise this so I can check that we’re doing a vaguely sensible thing there.

Similarly, with the Internet 7 system, I had a particular frustration with the speed of certain operations it was doing. I’ve re-written that code and tested that it works with some code which exercises the behaviour with different configurations. The test code is part of the repository now, and can be used in the future to check behaviour – it’s not automatically run, but at least it exists.

The tests for the Internet module are up on the riscos-tests repository and will be improved as time goes on. If anyone else wishes to contribute tests in the same way, please feel free. As I said previously, if anyone working on re-implementations of RISC OS wishes to use them, again feel free.

Omnibus response.

Rick wrote

how are mouse scroll wheels supported

And that doesn’t include reason code 100 that XAT and I used for the two-wheel mouse I wrote a driver for in the 90s. [plus I’m not convinced the info on those subpages is entirely correct, but I don’t want to go back to the code right now]

Matthew asked

Examples would help the discussion

Off the top of my head, OS_SetVarVal, Wimp_SetCaretPosition, Wimp_GetCaretPosition, OS_DynamicArea,0, OS_ReadSysInfo,6. There are many more.

Then there’s errors introduced where they have no business, such as corrupting R0 on exit from the SWI handler not only for third party modules but even OS_CallAVector.

Moving the MosVars without updating the API that tells you where they are, killing keyboard interrupt handling… and so on and so on.

But I’m not trying to debate this with anyone, just citing the examples that made up my mind.

There’s a sound piece of advice in the excellent Peopleware book: “Don’t flip the Bozo bit”. i.e. don’t allow yourself to dismiss the other guy as a clown, because once you do that you stop trying to reason with them. In other news, I have stopped trying to reason with ROOL.

Rick retorted

whether or not OS_Byte 129 returns &AA

In fact that’s insufficiently granular, as some significant changes were made between 4.1 and 4.2, so I recommend SYS"OS_Module",20,0,-1TO,,,,,,ver% to read the version number of the Kernel to four decimal digits.

how do you think it should be fixed?

History lesson: WAY back during the Nucleus project I created a module to deal with the few 26bit APIs in the Kernel. It was called OS32, so implemented OS32_Heap, OS32_SubstituteArgs etc (and it was a great deal cleverer than what you ended up with). It has an OS32_DynamicArea call which has a unified set of flags for its API, which are redistributed depending on the Kernel it is sitting on.

One of the few cases where “fixing it with a new one” is warranted.

Druck declared

the cost of subscriptions or single versions, never gained critical mass

I refused to use APIs that were not freely available. However, I’ve been very nearly releasing a blank-slate reimplementation of ImageFileRender and ImageFileConvert for far too long, so I can’t throw stones in this glass house. But what gets my goat is that when ROOL decided that they should, belatedly, add PNG support… NO attempt was made to duplicate the existing PNG APIs supplied by RO4 & 6, but instead another greatly inferior API was added. Cue xkcd Competing Standards strip.

Charles delighted with

I’ve improved the testing in that area

Superb. More power to your excellent elbows.

However, I’ve been very nearly releasing a blank-slate reimplementation of ImageFileRender and ImageFileConvert for far too long

I notice that the wiki now contains info for OS_SpriteOp 23 and 39 which references the MetaSprite module.
Should that also be a link to the page MetaSprite can be downloaded from?

I did not wish to be accused of “self promotion” again. But I’ve added a link to both pages.

Incidentally, I do not add SpriteOps lightly. There are 256 possible SOPs but there are well-established number ranges, so although I would have liked to have combined both functionalities into the existing SpriteOp,39 there’s no way of safely having no sprite name for that SOP (I did try), so the whole-file functionality has to be a SOP <24.