X command

Sources to the FileStore

You wrote an emulator didn’t you?

1stWord+

That had a terribly simple file format didn’t it? Just like an 8bit word processor.

I am not representative of the average user.

And your RISC OS is not representative of the average RISC OS. :-)

I’m afraid the writing’s on the wall for the 32bit ARM too.

I don’t think 32 bit will be dropped quite like 26 bit was. However, I do think that whatever mode the processor is running in is a “mere triviality” dealt with by a compiler, so for the majority of software, moving from 32 to 64 would be a case of recompiling and patching up whatever differences crop up. You’ll all have noticed that Linux contains VERY LITTLE assembler, so it’s not onerous to switch architecture. As such, the only thing keeping 32 bit around is the weight of systems using it. When they go, I rather imagine that 32 bit will follow.

I’ve no idea why bq. has stopped working at this point.

Because Textile hates you. It’s the only thing I can think of for times when things that should work, don’t. Textile is a moody bugger, and utterly irrational. Like Greek Gods, and with about as much power over your written prose.

“I know this won’t work on that other version but I don’t care because I use this version”

Not entirely correct: I don’t care whether of not this works on that other version because that’s an old version no longer being developed; I’m targetting the current version.
It’s more of a mouthful, but more honest.

if I had said it with regard to RO4, you would be the first to deride.

I’ve come across quite a few things that need bits of RO4 – Toolbox usually.
But then I’ve come across quite a few thngs (mostly GCCSDK/ported stuff) that either needs alignment exceptions on, or just plain crashes.
I’ve given up worrying about such things. Those that I can fix, I try to. Those I can’t, I drop.

and transparently ran the same software.

Haha! Thanks to our exposure to architectural differences due to compilers trying to be clever, we can’t necessarily transparently run software from one end of RISC OS 5 to the other.

Then it’s fortunate I don’t need your programs. :-(

Let’s be honest: There’s nothing I could write that you couldn’t do better.
Some people program, and some people dabble when they’re bored.
And I think that about sums up the differences between us.

Case in point:

Oh I patched the stack emulation too, because that was dead wrong.
Oh yes, I changed its OS too.

:-)

You wrote an emulator didn’t you?

I started writing an emulator in VisualBasic (!), but never got as far as something capable of booting the OS – what the code was doing to the FDC didn’t match what was supposed to happen according to the datasheet; and it’s about then that I got back into RISC OS and pretty much gave up on doing stuff on Windows.
I did want to try making it work using TCP/IP as a transport, perhaps talking to BeebEm or something, but never got that far.
The fact that, being in VB, it was as slow as molasses wasn’t a big issue. The real thing wasn’t known for its blinding speed. ;-)
So, yeah, I’ve not thought about that in about a decade…

That had a terribly simple file format didn’t it?

Extremely simple. Simple enough that I wrote conversion routines to other formats (from ZapRedraw to HTML to ANSI) in an evening or two. But this was back around… ’97? Whenever “My So-Called Life” was first being shown on C4.
Simple enough, also, that Printers used to (still can?) understand much of it and mostly correctly output a 1stWord+ file in text mode.

Just like an 8bit word processor.

I think it began life on GEM, so you’re not far off.

One final question – has Boot$OSVersion been set since 3.50 boot sequence as well? That’d let me bypass another legacy (and largely pointless IMHO) file.

mere triviality

I suspect there’s more BASIC programs with a few lines of ARM in than you might expect. Quarts and pintpots and all that.

no longer being developed

Literally everything is no longer being developed except for that glorious moment something new is released. Otherwise it’s all promises and best intentions.

There’s nothing I could write that you couldn’t do better.

Nonsense. And even if it were true, so what. Perfect is the enemy of good, and I can’t tell you how cross I have got with otherwise excellent engineers who refused to fix something now because they had a wonderful plan for what they were going to do eventually.

It may be that my *Handles for example is slightly ‘better’ than your *Handles, but unless they’re both available for people to choose between, it’s an entirely academic comparison, and an unedifying one.

Simple enough, also, that Printers used to (still can?) understand much of it and mostly correctly output a 1stWord+ file in text mode.

Fascinating. I think I might have known that once, it sounds familiar.

has Boot$OSVersion been set since 3.50 boot sequence as well?

The disc image distributed with RISC OS 3.5 sets Boot$OSVersion (in !Boot.!Run).

Likewise, the Universal Boot image distributed in 1998 also sets Boot$OSVersion (!Boot.!Run calls !Boot.Utils.BootVars if Boot$OSVersion isn’t already set).

I’m having to check this the hard way because my copy of RPCEmu won’t run RISC OS 3.5 at all :-(

I’m having to check this the hard way because my copy of RPCEmu won’t run RISC OS 3.5 at all

Don’t forget to change the cpu to something other than a strong arm

Tried that. Also disabled “Reduce CPU Usage”, disabled VRAM, and set RAM to 64MB. No luck.

FWIW, boot-up hangs at about the point where it would be trying to read hd4.hdf to execute !Boot. Running RISC OS 3.7 (with the same hd4.hdf) works a treat, so I’m pretty sure it isn’t hd4.hdf itself. I think it may be a bug in the RPCEmu macOS port, but as RISC OS 3.7 works it only really affects me when I’m trying to answer Andrew’s questions :-)

Printers used to (still can?) understand [1stWord+]

It does (except Sprinter). There’s even a note from Phil Colmer in the sources documenting the degree to which he had reverse engineered the format! (he’s wrong about fonts in rulers though).

Investigated. The conversion, from “1stWordMinus” to !Printers’ internal format is done by !Printers.Code – the resulting data is passed to the particular backend for the selected printer. Sprinter’s backend ignores the text interfaces, but PS has a go.

Interestingly the filetype is irrelevant – it does the conversion on text files too. As the magic only affects control characters you’d hope you wouldn’t notice. This does mean that sticking <&1F>9[]311 at the start of your text file will make it all come out two characters to a line.

Thanks Stuart :)

I’m having to check this the hard way because my copy of RPCEmu won’t run RISC OS 3.5 at all :-(

Works fine for me as long as CPU emulation is set to ARM610. Both versions 0.8.15 and 0.9.1 work fine. On Windows 10.

I think it may be a bug in the RPCEmu macOS port

OS3.50 boots here using ARM610 on RPCEmu 0.9.1 on Mojave 10.14.6.

I’d forgotten to replace cmos.ram (I had been fiddling around with 3.70 and presumably 3.70 unplugs a module essential to 3.5) and 3.5 now boots to the desktop. Sadly, trying to open HardDisc4 gives a “Broken directory” error (the disc is still readable under 3.71). Like I said, not that important since 3.70 and 3.71 both work.

Sadly, trying to open HardDisc4 gives a “Broken directory” error (the disc is still readable under 3.71).

Presumably a “large filecore” format, bigger than 512 MiB. Yes, filecore’s limit per partition was 512 MiB in RISC OS 3.5 just like RISC OS 2 and 3. Those were the days…

Conversely, is anyone really using newly-acquired software on 3.1 without Universal !Boot?

From our experience of 3.1 users I’d expect only a small proportion of them would be using Universal !Boot some because it uses up too much of their 1, 2 or 4MB RAM others because they aren’t aware of its existence.
Having said that most of them will have been running their systems for particular software or if returning to RISC OS will be looking at running old ‘Retro’ software so not looking at new software.