Rick's b.log - entry 2025/06/05

A busy Saturday

I'm kind of hoping that this is a known problem and he'll reach up under the dashboard and plug something in better.
Yesterday after work my key fob opened the car. No problems. The inside buttons both worked (I checked) and I went to Lidl and everything was fine. Got home, opened the boot, locked the car. I was thinking that I should get in touch with the mechanic to say it appears to be working, but I left my phone in the car so I pressed the key fob and...
Nothing.

So it seems like some sort of bizarre intermittent fault. The car knows when either of the doors is open as there's an icon on the dashboard, and for the driver door it beeps annoyingly. The locking system gets this as well because it won't lock when the door is open. So maybe all of this is down to some sort of signal it is not getting, or is getting all the time...?
This could also explain the endless blinking - it does the blinky-blinky like normal, but a combination of unexpected/bogus input and really lousy programming gets the thing into a loop. Yeah, one doesn't think about crashing a keyless lock system but there you go. It's probably some 8051 jobbie thrown together in China. Coping sensibly with invalid inputs probably won't have been in the specification, they'll just say "undefined behaviour" and leave it at that.

More tools

Shiny new sockets.

This is mounted on an internal door of the cow barn where the mowers and stuff live along with the screwdrivers.

The tools that aren't the garden tools.

I also have the tools I had before, of course. The black box are screwdrivers and sockets. The cream bowl is an Imperial set that Alison gave me when she moved away, which was very useful for my previous ride-on mower (Marte) because it was made in Mexico or somesuch so it was all bolts with nutty sizes like 9/16ths.

The older tools.

If you're a girl and you find any of this interesting then yay you! Mom's attitude was that it's a "man thing" and she just can't get excited by tools.
To be fair, I lack enthusiasm when looking at knitting needles and crotchet hooks... but it's not so much "oh look, a 13mm spanner!" but it's more the idea that with tools one can take broken things apart and look to fixing them (or, cough, make them even more broken ☺).
And, to be fair to mom, a crotchet hook and a couple of balls of expensive yarn and a small eternity and "here's a nice winter hat, Rick". I'm afraid I just don't have the patience.
But, anyway, if you're a girl and you regard spanners, sockets, and screwdrivers with interest, thank you. Maintenance and repair of stuff, even oily hunks of metal, should be an equal-opportunities inclusive task.

The future of RISC OS

Let's just get that out there. And it's not because I'm sulking or anything like that. It's simply that RISC OS has fallen so far behind and the current "future" plans don't really inspire much confidence.

Let's look at it like this. I have three main reasons that I use RISC OS:

• I can write software for it, so I use some of the software that I have written, such as Tea so set my satellite receiver to record things of interest.
• I have certain apps that I know well and can use - primarily OvationPro for documents and Zap for writing stuff like this (though, note, this is being written on gedit). I also find it simpler to create diagrams in DrawPlus than other more capable (and complex) software elsewhere.
  To put that last point into context, I have no doubt that gimp is quite capable and powerful, but when I tried to resize and crop a picture everything went to hell. Sure, it's familiarity, but I can't help but think that such things ought to have a "basic" mode for users who just want to fix their photos without all of the pro features.
• Familiarity.

Are you spotting a trend? It's mostly stuff that works for me that I am familiar with.

Recently, RISC OS Open announced a "Moonshot" to raise money to drag RISC OS into the 64 bit age. Literally shooting for the moon because they're hoping to secure two and a half million quid. Yes, really!

It seems from what I understand that they want to keep the API as much like current RISC OS as possible, to transition as much as possible to higher level languages so there can be one codebase for both 32 and 64 bit versions, and I think "for the moment" they'll be restricting things to 32 bit addresses for compatibility (read: kicking a can down the road).

Which is, in my largely ignored opinion, exactly how not to go about it.

Let's look first at what RISC OS lacks. This is a non-exhaustive list because I am wondering what to make for dinner so I'll keep it brief.

• Any form of Bluetooth support. Keyboards, headphones, zapping pictures around, etc.
• USB audio devices.
• USB video devices (even if just a frame grabber).
• Hardware video acceleration so one can watch YouTube (1).
• Modern killer apps, like an office suite.
• Any sort of compatibility with modern printers (2).
• A competent browser (3).

1 - I know there's ytplay and some machines can cope with playing 480p or maybe 720p. My middle-of-the-road phone is happy with 2160p because it hands all of the number crunching to the GPU, and even the freebie tablet (spec not unlike a Pi 3B+) can cope with streaming 1080p.
2 - There's a work in progress by Dave. It's not part of the OS, and he's had to do his own device scanning because neither of the two Resolvers and Internet can handle mDNS queries.
3 - Iris is good and continually improving but it's a bit of a slog both to create and to use and the reason is "because RISC OS". It's far ahead of NetSurf but there's only so much that is possible on a mid-80s OS that runs on a single core. That it exists at all is quite impressive. But it shouldn't have had to have been that much work to make happen.

Now I'm not asking for the moon on a stick (to keep with the moon theme). This sort of stuff is just expected on other devices. I took some screenshots on my Linux machine. I could start the Bluetooth UI and send the file, but after adding the "Send via Bluetooth" action I only needed to right-click a file and choose "Send via Bluetooth" and it would ask me which device and that was it. I listen to streaming radio at work and shopping using Bluetooth headphones. I capture things off satellite TV using an HDMI video capture device, I just plug it in and it (mostly) works. Other devices don't have a problem with my printer, using either a special HP app for best results, or falling back to IPP otherwise. And so on, this stuff is just expected. The more time goes by, the more the basic things the OS cannot do stand out. It could be a daily driver for people who grew up with it. For the younger generation, it'll seem cute and antiquated and something that probably belongs in a museum. Daily driver? Where's Reddit? ChatGPT? An office suite? Kitten videos? Zoom? Netflix?

In terms of use, I am using RISC OS for "fun" but not for serious things. It is not a terribly stable OS. It will run just fine, my uptimes measure in weeks, but if you do something that upsets it (quite simple when programming), it may fall like a house of cards. This is because the API was written in the early eighties with some questionable decisions along the way and plenty of crap tacked on through the years (how many API calls have magic words like "TASK" or "TRUE" to change their behaviour?). Allowing DAs to say "no upper limit" might have been a lazy cop-out when people had 32MB of RAM, but when 1/2/4GB is available, it's a really easy way to slaughter address space.

To break this down more... There is a horrific mangling of kernel and user space. Not only can applications fart around in the RMA (system module area), the RMA itself is an unholy blend of executable code and anything and everything that wants to grab some memory that won't be swapped out on a task switch. The RMA needs to be taken out back and shot.

Due to how modules are added to the OS, vast amounts of code needlessly runs with kernel level privilege. Take, for example, my MIDI module. It replicates the original Acorn MIDI API. It works by talking to the file handle that represents the USB input and output endpoints and it makes HAL device calls for the high resolution timer. There's no justification for any of that to be running in SVC mode, but that's how SWIs work and they are used extensively within RISC OS. The problem is that a fault or crash in module code can easily take down the entire OS because the kernel cannot recover as you've just messed up the kernel's own stack/data.

Far far too many OS calls hand out pointers to data in the RMA. With read/write access.

OS_EnterOS. That is all.

The thing is, if they want to try to preserve the original API then I fear that the opportunity to fix the mistakes of the past will be missed, which would itself be a mistake.
I also fear that the obsession with 64 bit will result in an OS that may run on 64 bit devices, but will exhibit all of the above problems (architecturally and historically) of current RISC OS.

What needs to be done, if they're trying to shoot for the moon, is to actually fire a rocket for the moon and not just aim a water pistol at it.

• Redesign the OS from the ground up with security and stability in mind. The current API fails in every possible way.
• Support POSIX as much as possible, certainly things like threads and processes, in order that porting stuff doesn't need to be a massive pain in the arse.
• Look at the feasibility of supporting kernel modules from Ubuntu or one of the bsds if GPL is a concern. That way the new RISC OS could leverage the wealth of existing code and support that exists elsewhere without having to reinvent the wheel over and over. This could potentially answer some of the many missing things like GPU support, modern video codecs, Bluetooth...
• Make an API fit for the new twenties, not the old eighties. The ARM is forty years old this year...RISC OS is only two years off of that.
• It does not necessarily need to be an entirely new "RISC OS" kernel. One should look at what it is that makes RISC OS special, and what can be done to advance while keeping with the spirit of RISC OS. After all, a bastardised version of Linux became Android. Apple's iOS sits atop a heavily modified Mach (OSFMK) kernel (called XNU) and bits of FreeBSD. By all means start from the ground up if that scratches a particular itch, but don't be afraid to look at all options.
• If you care whether or not the target processor is 64 bits, you're doing it wrong. One should expect to be able to build the new OS for a RiscPC, an old Pentium box, or the RaspberryPi 5. Clearly it'll be up to somebody else to get the Pentium hardware working (especially given the mess of possible graphics cards in PC-land), but as far as possible the system ought to be pretty system-agnostic. Need examples? Look at Linux.
• And what about all the RISC OS apps we know and love? Easy - emulation. Preferably an app-based emulation that is able to make the software appear as if it is running natively when it is using an entirely different API (the old RISC OS one) and may be running on an emulated 32 bit ARM core. Because there is no much that people are used to that is not going to be ported to the new system. Either because there's no longer any real support (the amazing Mr Pilling has retired from making software, so who would port OvationPro?) or time (I probably won't port any of my stuff) or it's just not possible (Zap, interacting modules written in assembler). The way to keep these things alive and give value to the RISC OS we know is to emulate their environment. This isn't crazy, it's sort of what WINE does on Linux, only with extras to emulate the processor because the stuff won't be able to run natively (unlike Windows apps which can thunk down to (32 bit) x86 on an x64 (64 bit) core).

As you can see, it's a massive job. It would probably be far far simpler to just make some sort of system emulation that can run 32 bit RISC OS on a 64 bit system and accept that writing a new OS from the ground up is kind of nuts in this day and age. Oh, look, some people are already - in various ways - making way in doing that sort of thing...in Python, in Rust, or other clever hackery. I understand that somebody is even working on a way to just "run modules to make RISC OS work" which doesn't sound that complicated until it is pointed out that 26 bit RISC OS 4.39 modules on RISC OS 5? Doable. Wait, what?

There is a future for RISC OS. Machines these days are fast enough the clever people can do some pretty exciting things with RISC OS as it is today. And, honestly, I think that's where the strength of RISC OS lies. It's far too clunky and broken (at the API level) to match a modern OS and writing something new from the ground up doesn't make sense unless there's a very specific target in mind, like a mini-OS for embedded devices with graphics support. It is worth noting here that Microsoft poured billions into their mobile phone devices to try to be a third option since Apple and Google managed to take over the world and kill off Blackberry and Symbian. They failed. With that in mind, any future plans of what to do with RISC OS should be made cautiously. And these plans should not come at the expense of neglecting all of the issues, problems, and lack of features in the current versions of the OS.

But most of all, it absolutely shouldn't be like it is now, only different because "like it is now" is half the problem, the other half being the vast amount of hand-written ARM assembler.

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺
As of February 2025, commenting is no longer available to UK residents, following the implementation of the vague and overly broad Online Safety Act. You must tick the box below to verify that you are not a UK resident, and you expressly agree if you are in fact a UK resident that you will indemnify me (Richard Murray), as well as the person maintaining my site (Rob O'Donnell), the hosting providers, and so on. It's a shitty law, complain to your MP.
It's not that I don't want to hear from my British friends, it's because your country makes stupid laws.
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

jgh, 7th June 2025, 13:48

Your last bullet point. Just emulate it.  In around 1990 I needed to be able to run loads of Z80 code at work. My Z80 CoPro wouldn't plug into my A5000 or the Unix machine at work. So I wrote Z80Tube and cZ80Tube.

A tree-dwelling mammal, 7th June 2025, 23:13

I've said this before and I'll say it again...    Implement an API emulation layer on top of a unix-like kernel.    Binaries compiled for a 64-bit target (ie AArch64) can run natively.    Binaries compiled for AArch32 can run using an emulation layer.    And finally binaries compiled for AArch26 can also run using an emulation layer.    The modern ARM hardware (Pi5 anyone) is more than fast enough to emulate 32-bit or 26-bit modes considerably faster than any Acorn-era hardware.    Of course the biggest issue is that unless or until there's a port of Firefox to RISC OS, it's just not a viable platform for modern usage. Especially when you can boot Raspbian on the same hardware and make full use of the multi-core multi-threaded capabilities of the CPU.

C Ferris, 7th June 2025, 23:31

On the Pi5 you can run 'Linux RO' as a Linux Prog.  (Tim's prog)    No sound working at the moment.

Add a comment (v0.12) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 68954 backwards.
		UK resident	Check to verify that you are NOT a UK resident.
		Your comment