X command

Hi folks,

Quick question – how far back does the X *command go back? ie. what’s the earliest version of RISC OS that you can do: X Obey to not get an error reported if doesn’t exist.

I know I can use IfThere, but that wasn’t a ROM command until at least OS 4, I think, maybe later. I’m not sure how far back it was a disk-based Library utility (3.7 perhaps, or 3.5/3.6?) – is it older or younger than “X”?

I’m trying to update something that should run back to RISC OS 3.1 if necessary (certainly 3.5) so would like to avoid using commands that aren’t supported on older OSs.

From OS3.71.

RISC OS 3.71 (19 Feb 1997)
*
*which X
File: HostFS::HostFS.$.!Boot.Resources.!Internet.bin.X
*Which IfThere
Command 'IfThere' in module BootCommands

OS3.11, as on VirtualA5000, has IfThere in !Boot.Library, and X as above.

By OS4.39 X is in BootCommands.

The disc image distributed with RISC OS 3.7 has “X” in !Boot.Resources.!Internet.bin (file dated 18 May 1996).

The RISC OS 3.6 disc image does not have a !Boot.Resources.!Internet directory, so “X” must be presumed missing. Likewise the RISC OS 3.5 disc image.

It will of course be in the Universal Boot image, which may be how some people are seeing it in RISC OS 3.1.

Does 5.24 version works on older ROS3? Don’t forget that the OS is now under Apache 2.0 License :)

All the modules in the 5.26 ROM (Apache licence) are identical to those in the 5.24 ROM (Castle licence), except utility module.

Thanks for this. What’s the earliest version to have IfThere (ignoring universal !boot which effectively retro-fitted 3.71 !Boot onto 3.1+) ?

The disc image distributed with RISC OS 3.5 has “IfThere” in !Boot.Library (file dated 28 Sep 1994).

It was not present on Applications Disc 1 distributed with RISC OS 3.1.

Thanks, that’s really helpful.

Final question. If a program that was originally designed for RISC OS 3.1+ (but took advantage of 3.5+) was re-released (for free) requiring IfThere (ie. 3.50+ or new !Boot), is that acceptable to everyone? I’d have thought it’d be OK, but what’s the feeling? Technically it is restricting use for the free version compared to the original. Conversely, is anyone really using newly-acquired software on 3.1 without Universal !Boot?

I’m pretty sure that’s a settled matter. Page 7 of the RISC OS Style Guide states:

“You can assume that all users will have a version of the Universal Boot application installed on their computer.”

Unless the Style Guide is wrong, of course :-)

I cannot believe that anyone gives a toss about hardware which you cannot purchase in the last half decade.

Anyone using an Acorn-era machine, including an Iyonix, is clearly into retro computing. That is nice for what it is, but I find it hard to imagine spending a single second caring about supporting those commercially. If people want to tinker, that’s fine.

Surely anyone using RISC OS seriously is using a version of 4 or 5 on an emulator (on a modern PC/Mac) or a modern ARM platform?!

Anyone on RISC OS 3 or 4.0 can use the ROOL Boot/HardDisc4 if they want to try running anything made after 1999.

I don’t want this to come across as having a go at Andrew. Not after the web site! This is a more generalised comment. I am more on Rick’s page, which I think was test on RO5, anything else is a bonus.

Thanks Richard, that’s more or less my feeling too (although I like to include RO 4+ too, as that is also still available in VRPC form).

It was a more generalised question, though, because I could imagine the retro community being aghast that their favourite early-90s app now couldn’t run on OS2 or something.
It isn’t a community I have much/any contact with, because I don’t really deal in the legacy components. Anyway, I’ve gone ahead with the changes – my justification is that if someone wants an “unmolested” version for legacy systems, they can dig out the original floppies (or images thereof).

Anyone using an Acorn-era machine, including an Iyonix, is clearly into retro computing.

I wouldn’t include the IYONIX here in the retro category. Its CPU might be a bit slower than the latest offerings, but it does have high video resolutions, fast disk I/O and Gigabit Ethernet – so overall a lot better than BeagleBoard, PandaBoard and most RPis. And it also runs the latest RISC OS 5 version. So it is very much a “current” machine.

It really all depends on the specific case. There is certainly software that could sensibly be run even on a RISC OS 2 single floppy 1 MiB RAM machine. My personal criteria is always “how much work is it to ensure backwards compatibility”. Many of my libs are from RISC OS 3.1 age, the compiler is happy to produce ARMv4 compatible code that also runs on ARMv8. So there is no criteria that immediately says “will not run on a RiscPC”. The number of must-have features in RISC OS 5 is not that big compared to say RISC OS 3.5 with UniBoot, so it is not really much work to ensure backwards compatibility.

But I would never invest (much) work to save the last bit of RAM so that it would work on a 4 MiB machine.

For the record, the evolution of BootCommands is:

3.60    1.14 (20 Mar 1995)
        + AddApp, AppSize, Do, IfThere, LoadCMOS, Repeat, SafeLogon
3.70    1.16 (24 Jun 1996)
4.02    1.17 (24 Mar 1999)
        + FreePool
4.24    1.19 (15 Jun 2001)
4.33    1.20 (15 Jun 2001)
4.37    1.23 (17 Aug 2003)
4.39    1.24 (03 May 2004)
        + X
6.20    1.26 (14 Dec 2009)
5.19    1.42 (14 Jan 2012)
        + SaveCMOS, ShrinkRMA, AddToRMA, AppSlot
5.22    1.48 (06 Apr 2014)
5.24    1.49 (02 Aug 2015)

X was disc-based until 4.39, but I don’t know when it was introduced. The disc-based version had got to 1.05 before it was ROMified.

As for backwards-compatible use of *X, the preferred method would be to include a command-line X in the application directory, then use that to detect whether it already exists and, if not, alias. i.e.

Unset X$Error
<Obey$Dir>.X X ||
If "<X$Error>"<>"" Then Set Alias$X <Obey$Dir>.X %*0
X blah blah blah

Ideally one would copy the app-supplied one into Run$Path, but that’s not easy to do in an Obey. A BASIC installer would probably be required at the least (to dig into Run$Path recursively until it finds somewhere it can write to).

cannot purchase in the last half decade.

Half decade? Sorry to break it to you and make you feel crusty and old, but it’s more like quarter century. It’s been nearly 20 years since Acorn was dissolved.

I am more on Rick’s page, which I think was test on RO5, anything else is a bonus.

Target RISC OS 5, anything else is a bonus.

But, the thing is, I’m not getting paid. I make my rubbish, and release it, and that’s pretty much that. I have the liberty to say “FFS, upgrade!” especially now that a basic Pi solution that will kick the ass of any RiscPC ever made and will set you back between forty and a hundred odd, depending upon how much you salvage. My mouse, for instance, came out of a bin at work. Frayed/damaged cable at the mouse end. Simple job to pull the cable in a bit, solder the wires into place, clean the thing (twice!) and then plug it in. Total outlay, zero.
Plus, however much you spend on the Pi, it’ll repay itself soon enough in the electricity bills, for a little USB brick is nothing compared to a full PSU.

However, the fact that I’m doing this for pleasure and not pay is an important one. I have the flexibility to simply say “no”. It may be that there are a sufficient number of hold outs still with their Mesolithic machines that it is simple business sense to consider supporting them, no matter how ridiculous a prospect that actually is – it would be akin to Microsoft expecting developers to support Windows 3.11, or Google to expect support for every version of Android ever. You’d be hard pushed to find an app on iOS that supports version 9, these days, yet it seems that in the world of RISC OS it’s just expected that we’re okay with supporting stuff that was current when I left school two thirds of a lifetime ago.
Maybe there’s a business reason? I doubt it, but maybe.

could imagine the retro community being aghast

So let them whinge on csam. I don’t read that any more… :-)

my justification is that if someone wants an “unmolested” version for legacy systems

Yup. That’s why I made potentially breaking changes to Zap (DebuggerPlus ditched, for a start). There’s a perfectly decent version available for the 26 bit era, all I’m trying to do is get it working nicely for the 32 bit world. I’m not going to attempt to deal with the peculiarities of both.

so overall a lot better than BeagleBoard,

Well, given TIs rubbish GPUs, an etch-a-sketch would probably have a higher resolution. It’s abominable that the Beagle xM’s documented video capabilities would struggle to support my 1280×1024 monitor at the usual frame rate (rated max is 1400×1050 but that’s 50Hz, my monitor doesn’t want to know anything below 60).

I would also categorise the Iyonix as “modern enough”. It’s not terribly fast, but then neither is the original Beagle or the Pi1. It would seem to me that the only issue likely to affect the Iyonix (other than their propensity for hardware failure, especially the flash) is that it is the only modern generation machine that doesn’t have some sort of hardware FP.

And it also runs the latest RISC OS 5 version.

As can a RiscPC.

So there is no criteria that immediately says “will not run on a RiscPC”.

Exactly. That’s probably in part the noose around our necks that is stopping great forward development (notice how the compiler is being updated to handle ARMv7 ops, but it’ll still generate effing FPA code for floating point), and in part the fact that not a lot has actually changed. Much of what’s different in 5 is under the hood stuff – PMP, GraphicsV, high vectors… Not really things apps are going to be that concerned about. The main anomaly in this respect is all the stuff in the later ROLtd releases that don’t exist elsewhere.

As I always say, I aim my software at 5, but apart from a few things here and there, there isn’t really anything to prevent said software working on older machines. For those that do exist, I may or may not fix. I’ve only just gotten around to having Manga attempt to do something on 77 file/dir systems. It’s a hack, but it makes Manga usable. Mostly. That’s good enough. I find my Pi2 slow when it takes ~5 seconds to throw a JPEG at ChangeFSI (because SpriteExtend is too dumb to attempt to dither scaled images), I don’t want to contemplate what it would be like on an ARM610…

even on a RISC OS 2 single floppy 1 MiB RAM machine.

While I’d agree about 1MiB/floppy, you might be surprised at the amount of stuff that RISC OS 2 does not do. It’s only one hop away from Arthur, after all.

BASIC installer would probably be required at the least

Wouldn’t it be nice if the OS had some way of managing its resources with a simple command…

Target RISC OS 5, anything else is a bonus.

I’m clearly going to have to get a lot more robust because the message is not getting through.

I do not use RISC OS 5. I cannot use it. I do not wish to use it. I have no use for it.

I continue to use RISC OS 4. I am not doing this for ‘retro’ purposes. As far as I’m concerned, RISC OS 5 is as retro, quaint and irrelevant as RISC OS 4, but RO4 runs all the software I want to run, and RO5 doesn’t. RO4 also has a wider API and a better UX. So that’s the end of that discussion.

I want to see API unification. But then I’d also like module version numbers to increase monotonically so I’m clearly highly unreasonable.

Now you can continue to push for ClinicalParanoiaOS 5 if you wish, gradually morphing into LocalProgramsForLocalPeopleOS 7 before finally achieving TheresNothingHereForYouOS 8 some time around 2035, but if you continue to view RISC OS as more than one operating system you may as well be writing software only for people who support the same football team as you.

OS version is not supposed to be a shibboleth.

There are two things here.

1/ RISC OS. RISC OS 5 DOES provide a lot of things RISC OS 4 doesn’t. And it has a roadmap.
2/ RISC OS Computers. As Rick said, the Pi provides much more power than an RPC. And so, opens new uses.

But I agree on some arguments:
- If it’s possible, try to make things compatible with older OSes.
- If it’s possible, try to make new computers be compatible with older ones.

But also:
- If it’s not, forget the past.

BasicVFP is an excellent example here. “RISC OS 5 + modern” computers only, but SO useful!
That does not mean Basic should not exist or evolve on older computers.

OS compatibility should not be a shibboleth either.
But consistency could be one, and so emulation.

I’m very happy to be able to use the best emulators for BBC Micro and Archimedes, with an almost perfect integration into current RISC OS computers. Now, we are just a few steps from a RISC OS computer that could be able to emulate an RPC at 30/40 MHz speed.

Questions: could the old ROMs become free for all RISC OS 5 users? Could the work on Aemulor start again? Could 26bit code work on a 26bit computer running a 32bit version of RISC OS? How much RISC OS 5 code could be compile in a potential 26bit OS?

I really hope that one day, RISC OS 5 + modern hardware will be able to provide a perfect BBC Micro offer (free 32bit version of 6502em + windowed mode?), a perfect Archimedes offer (done: ArchiEmu) and a perfect RPC offer. And also the perfect DOS compatibility layer (DOSbox + Win 95/98 patches) to keep the PC card world alive.

So that’s the end of that discussion.

Except for the point where it is no longer being developed, and only works for you at all thanks to the emulation of a twenty four year old processor and twenty five year old machine.

Not to much a shibboleth as a practical reality; and yes, it would be very nice to have the API unified, but all the hopes and dreams don’t change the simple fact that the world abandoned the 26 bit ARM long ago, so anything that runs in that configuration is, at best, an anachronism. Though, granted, one could more or less say the same thing about RISC OS in any of its incarnations.

but if you continue to view RISC OS as more than one operating system

I don’t. I view it as versions. Old ones and new ones. And like ideas and childhood imaginings, one should be prepared to let go of the old to embrace the new.

Or do you actually still support Arthur in your programs? Because Arthur is RISC OS. It’s a simple matter of nomenclature that is easily resolved by noting that three of the parts of the kernel carry the name, not to mention references to it all over the kernel source.

some time around 2035

I’ll be 62. Chances are I probably won’t care by then.

because the message is not getting through.

It’s simple enough.
You choose to use an older version of RISC OS.
I choose not to consciously go out of my way to support it.

Nota: excepting Compo, Vantage, TopModel and HOMM2, all the applications I did use before work perfectly on new hardware. And I’m not sure these 4 apps could not work with little (or no) changes under Aemulor.

I would pay a lot for TopModel and HOMM2 :)

That does not mean Basic should not exist or evolve on older computers.

The creation of a shiny new BASIC doesn’t mean the older ones cease to exist.
As for evolution, it’s possible that BASIC with all the new keywords COLOUR OF ON and the like could be made, but then I don’t recall Acorn ever bothering to issue an upgrade when the RiscPC came along and suddenly one could COLOUR r,g,b instead of all that TINT nonsense.

could the old ROMs become free for all RISC OS 5 users?

How do you mean?

Could 26bit code work on a 26bit computer running a 32bit version of RISC OS?

In theory, yes. I’ve had 32 bit code running on a 26 bit OS. The problem is that RISC OS is targeted to a specific mode of operation so it might get a bit sulky if it finds itself in an unexpected mode; or it might return back to you in 32 bit. Given this question only affects one platform, I would not advise wasting time on it.

How much RISC OS 5 code could be compile in a potential 26bit OS?

Try it.
See if you can build an IOMD version in 26 bit.

I really hope that one day

…that I’ll be able to “do stuff” on a machine and the underlying OS will be mostly irrelevant.
…that Frenchies will discover the simple joy of an egg & cress sandwich, and I’ll be able to buy them in the supermarket.

I rather expect the “do stuff” to be true in a decade or so.
As for the egg and cress…….

How do you mean?

The old ROMs legally free to use for every users.

Given this question only affects one platform, I would not advise wasting time on it.

Not really, it could affect emulators too. And so could be a good base to add new features to the emulator.
Even if ADFFS/Aemulor is probably a better way…

I rather expect the “do stuff” to be true in a decade or so.

I do. That doesn’t mean I can’t have dreams or an alternative roadmap :)

HOMM2 – that’s an R-Comp title. I wonder if they have the source?

Of course. But does Andrew have the time. That’s the real question :)

The old ROMs legally free to use for every users.

That might raise the question of who actually owns what, and look how well that worked out in the past. ;-)

Talking of owning stuff… I’d be interested if RODev has any of the following kicking around:

• Sources to the FileStore (I’ve been asking for about twenty years…)
• 1stWord+ (mind you, I think I’m the only person on the planet that liked it)
• Whatever happened to 65Host and 65Tube? I recall Host was pretty good at the end, too many hours lost to Chuckie Egg.

Rick reasonably reasoned

Except for the point where it is no longer being developed,

I am not representative of the average user.

and only works for you at all thanks to the emulation of a twenty four year old processor and twenty five year old machine.

Rick mused

Whatever happened to 65Host and 65Tube?

They didn’t make it past the ARM pipeline length change.

I have an updated 65Tube here, but it’s resolutely 26bit because although it emulates the 6502 opcodes it doesn’t emulate the flags – it gets them for free from the ARM, and then manipulates them occasionally. Naturally it does all that the 26bit way.

I’ve considered converting it to 32bit… but there’s a lot of TEQPs to beat into submission (33, and that’s the least of it). But it works in 26bit mode once the pipeline issue was fixed.

Oh I patched the stack emulation too, because that was dead wrong.

Oh yes, I changed its OS too. I’d forgotten that: