Rick's b.log - 2024/03/31
It is the 24th of November 2024 You are 13.59.198.150, pleased to meet you!

It's nice when stuff just works

No. They wouldn't. Everything was an hour out.

After making a tea and contemplating how might be the best way to pull apart the data to work out what times it was given, it dawned on my that the local time was also an hour out. Surely that wasn't right?

And, no, it wasn't. My machine was still set to winter time. So I typed:

*Configure DST
*Configure AutoDST

Minor blog tweaks

Connecting to my site using RISC OS.

I didn't fix the YouTube link because it was long past time to do so, I fixed it because to my total and utter horror (that may be a slight exaggeration) I noticed that the "current day" marker on the calendar on the right in desktop mode was showing yellow text in a yellow box when in dark mode.
Which wasn't terribly useful.

So now it shows the yellow text on a pukey-darkish-green background. Part of the choice of colour was because I was getting fed up with Android Chrome that didn't seem to want to reload the new styles. I ended up having to keep opening Incognito tabs in order to force it to not load from cache. And, no, clearing the cache didn't help for some peculiar reason...?
Android Firefox, on the other hand, is much simpler. Poke the refresh icon and it will, hold down the refresh icon and it'll force everything to be refetched anew.

I gave it a blue border with rounded corners, because I can. So as not to leave out the normal non-dark mode users, I gave the "today" there a rounded orange border, as is demonstrated by Iris here.

Programming best practice

One that stood out for me is this:

You can then provide some rendering routines in a library, but - and this is important - you only do the rendering concepts in the library. You don't actually do the operations that will put anything on the screen. You can stub those routines, and allow them to be entirely divorced from the code that's trying to render the code. A function for text size, a function for text plotting, a function for line drawing, maybe. In your test implementation you make those do nothing or return dummy data. Maybe you provide an implementation that uses the VDU system, rather than the Font system.
The point is that the OS interfaces - the parts that you're going to find which might change and might be different in the future, you've kept away from the business logic of adding lines, or working out how a line should be layed out.

This isn't usually how I write my code for RISC OS. I know, naughty... ☺ However my programs are usually intended to directly target RISC OS with no thought about portability as it isn't a factor in the design process.
That isn't to say that I don't know what Gerph is on about, when I threw together RArthur, I had to abstract the graphics routines in order that I could get the screen drawn with both RISC OS and TurboC++'s libraries/facilities. Then I had to abstract a bit more as the DOS side counted the other end of the display as row zero.

Am I worried about a 64 bit transition?
In a word, no.

We've had VFP for around sixteen years (the Iyonix didn't have it, the Beagleboard and everything since has) and while we have a VFP capable version of BASIC64 and a VFP option in the ABC compiler, the official DDE toolchain (and CLib) still has no support, instead preferring to emulate an FP chip. Which is crazy.
This is the reason my examination of basic ray casting was written in BASIC. I had wanted to use C, but the BASIC could be compiled with ABC to kick C's arse hard. On my 3B+, the textured version with distance shading runs between 18fps and 36fps (there's no limiter) depending on how complex the scene to be drawn is - close walls take longer because there's more to draw. C... simply could not handle that when using FP ops.

Every Pi since the Pi 2, and a fair number of other SoCs, come with four cores. This isn't smoke and mirrors like Intel's Pentium4 Hyperthreading, it's four actual execution units. Four seperate processors that can do stuff independently of each other.
In the nine years since this turned up as a thing, very little has been done to RISC OS to support extra processors. Jeffrey has done some work on it, but more as a pet project than anything that could benefit RISC OS.
That being said, RISC OS is at heart a single user single process single context OS, so I'm not entirely sure how it might benefit from having three additional cores. WindowManager's task switching (which, honestly, probably ought to be abstracted out of the Wimp...) relies upon a simple round-robin system, and some stuff such as Recorded Messages and passing around "can you do anything with this file?" requests depend upon it. If you introduced the Wimp to multiple cores, it would wet itself, have a nervous breakdown, and then collapse into a heap of scrambled data.
My personal thought is that maybe the other cores should be running a mini-OS and talking to the prime RISC OS using an interface not unlike the infamous TUBE. Certainly, more demanding applications such as Iris are just slow due to having to share just one core with everything else.

Finally, WiFi and Bluetooth. The first machine with these was, I believe, the Pi3 eight years ago. Work is progressing on WiFi (see below), but Bluetooth is... not even a bounty request.

A large part of the problem is that much of RISC OS is mostly being maintained by volunteers, and while we're certainly thankful for their efforts, the thing is that volunteers will mostly do what appeals to them.
After all, if your paid job is staring at a screen all day sorting out obscure bugs and DNS misconfigurations (it's always DNS...), are you really going to want to come home and stare at a screen all evening to get Bluetooth working because some random shouty people on a forum want it for free and they want it yesterday? I don't think so.

It is for all of these reasons that I'm highly sceptical that there will ever be a 64 bit incarnation of RISC OS. Furthermore, if such a thing should come to be, then it will likely have a massively different API to the current incarnation that we know, which will likely render this discussion moot.
Certainly, as Gerph says, writing things with abstration will ease the process of porting, but there will be a lot of work that still needs done. And with a shiny new (and largely unstressed) API.

And if, just if, they should pull a wabbit out of the proverbial hat and make a RISC OS that has an API and behaviour largely the same as the current version, I would simply walk away. After all, asides from everybody recompiling their code to use instructions like STR W4,[X2, #4]; RET instead of STR R4,[R2,#4]; MOV PC,R14, what would a 64 bit version of the current OS offer? I'll tell you what - a massive missed opportunity if it carries forward the design deficiencies born of it's BBC MOS/early 80s heritage.
But this means not only writing a new OS from the ground up, but also designing a whole new OS (and no cheating and reading the Minix book, that's already been done). Who has the time and/or resources to do that?
Or, should I say, with all the things that never got done with current hardware, who has the time and/or resources to write a new OS?

Especially when writing a Wimp-like WindowManager for Linux would probably give people the experience they like with a secure OS underpinning it (so long as the distro in choice isn't one that's been polluted by systemd).

Adventures in WiFi

On a Pi 3B+ (the machine I'm using), it is actually really rather simple.

Step one - download a recent build of RISC OS (probably for the SDIO changes) and install it.

Step two - install the OBSD Internet stack. For most usual cases, this means running the installer and rebooting (it'll reboot itself again, this is normal).

Note that if you have previously installed a recent OBSD, you must do it again as the WiFi firmware stuff is contained within, so reinstalling it will keep everything up to date.

Installing the new network stack.

There is a TaskObey file called "DoWifi". Don't use this. For some reason, possibly related to string expansion, the command ifconfig wb0 join <wifi$name> wpakey <wifi$key> chokes.

You could use the snazzy new NetManager that has profiles and such... but if, like me, your machine is expected to remain in one place, you won't be needing profiles. While I can understand the usefulness of this on something like the Pinebook, or any mobile device, I find that RISC OS' networking is a bit fragile. I'd rather work out what's going on behind the scenes and set up whatever is necessary to make that, and only that, work.

Luckily, the DoWifi script can give us some inspiration.

So... create a little program that will twiddle thumbs for five seconds, call it "DoWait5". I'd advise turning on the hourglass at the same time.
(if you aren't sure how to do that, you probably shouldn't continue with this!)

Next, you'll need to know the exact SSID and password for your router. In the example below, the SSID will be "MyRouter" and the password will be "53C7E7" (the closest hex will get to "secret").

Then, copy-paste the following Obey file and change the SSID/password as necessary.

| Waiting is a bit paranoid, but in the absence of reading status...
echo Loading WiFi driver
RMLoad obsd:rm.wlanb-dev
<Obey$Dir>.DoWait5
<Obey$Dir>.DoWait5
| 
echo Joining WiFi network
ifconfig wb0 join MyRouter wpakey 53C7E7
<Obey$Dir>.DoWait5
<Obey$Dir>.DoWait5
|
echo Killing off wired ethernet
X RMKill EtherUSB
X RMKill EtherTh
X RMKill EtherGenet
<Obey$Dir>.DoWait5
|
echo Getting an IP address
DHCPExecute wb0
<Obey$Dir>.DoWait5
Echo IP address is <Inet$EtherIPAddr>, done!

So, with your machine booted and the new stack running, it's time to gingerly unplug that LAN cable, cross your fingers, and run the above Obey file.

If everything goes to plan, it'll take a little while to do what it does (most of that is us blindly waiting), and then it'll tell you your IP address.
Once you get that, you can ignore it and instead start up NetSurf or Iris and... go online... by the magic of radio waves... under RISC OS!

There are some caveats, mind you. For starters as you might have noticed by killing off the Ether* modules, it looks like you can't have wired and wireless connections at the same time. This may be a limitation of RISC OS (can it cope with a machine having multiple IP addresses?).
Also, I have noticed that the machine completely freezes at the point where it would restart, so you'd be best off fitting a reset switch if you have not already done so.

And, of course, know that this is a beta test. It may blow up, taunt your cat, or warp reality in exciting ways. But most likely, since it's some deep mojo, it'll just cause your machine to freeze. I've had it running a little under four hours now, and everything is behaving itself. I'll leave it running overnight, see what it's like in the morning. I'm not sure how it would behave with a marginal signal, if - once connected to an AP - it'll automatically reconnect or if it's all manual. But, then, these are issues to be ironed out along the way.

But, for now, what I can say is thanks to RODev, there's not only a modern IPv6 capable stack, but a WiFi driver to go with it.
Which might be because RODev is working on getting current devices working better instead of flights of fancy around a 64 bit world that'll forever remain elusive.

Almost Sakura!

The cherry tree by the stream, probably quite pleased to not be fighting with brambles as tall as a person, is starting to blossom.

It didn't look like this this morning!

As I was walking back, I noticed the oak had also decided it was time to begin to unfurl.

The oak leaves are coming.

An egg free zone

Instead, I made cookies. Out of a pack. Mix 50g of butter (I used 67g, couldn't be bothered cutting the lump I had to size) with one egg, and then spoon out into 12 lumps on a baking sheet.
Well, I decided four big cookies would be better. So that's what I made.

Would you like a cookie?

There was a vide grenier (indoors) at Châteaubriant. I decided that I didn't feel like going. So I sat in bed and watched something recorded from TV instead - Top Gun: Maverick. One of the rare instances of a sequel being better than the original.
But the most amusing thing was that Tencent, who fund a lot of western movies and provide a soft pro-China influence (usually a main character is Chinese, and also one cannot display the Taiwanese flag) bailed out of the project when they realised that the film basically glorifies the American military.
Like, what the hell? Did they even watch the original? Or was this a case of "Tom Cruise is powerful, Tom Cruise is in this movie, we need a piece of this action"?
That being said, my "Tom Cruise can do superhuman stuff" meter found Top Gun not to be too ridiculous. I mean, it wasn't exactly Mission Impossible, even if they did have to pull more Gs than the aircraft (and pilot) could sensibly handle getting the job done. And, yeah, Cruise of course shows 'em how it's done. He is the leading star role after all. ☺

Your comments:

jgh, 31st March 2024, 23:25

When people say "I want a 64-bit RISC OS" you need to pin them against a wall and use Nobby's Fizzy Helper and ask them exactly *what* they want.    Probably 95%+ the answer is: a task bar at the bottom, drag and drop between windows, menu click, drag from SaveAs to filer window. In other words, THE DESKTOP.    I know that 90% of what I "want" from a RISC-OS-on-new-hardware is the desktop and its working metaphores. 5% of what I want is "connect to the MDFS".... which is now possible on Windows machines with the funky new USB-Econet dongle. net logon 0.254 i am jgh    And most of the remaining 5% is BBC BASIC - which exists for so many platforms it is a solved problem.    Now, I'm going to go back to tweeking the RT11 host support for PDP11 BBC BASIC. :)

David Pilling, 1st April 2024, 16:41

Good programming is about generalising stuff and abstraction. In the old days lack of memory and processor power often went against that. Today however there is no excuse. Simple example write in a high level language not in 32 bit ARM.  When I did Ovation Pro for Win, mostly I only had to replace the RISC OS library with a Windows version. (and it still took 5 years).    You're not being very encouraging "it'll never happen and if it does I will ignore it". Even if that has a lot of truth. Many things come and go in the computer world without having any effect on many people. I found a Windows 8 box in my desk yesterday - people used to fight in car parks over Win 8 'v' 7 - I only ever complain that nothing has happened since XP, forgotten about the other ones.    I'm hoping AI is such a thing, will make a mess of the stock market though if true.    I would like to see 64 bit RISC OS - as in what would it be like, rather than I have a pressing need.    JGH makes a good point, "so tell us, tell us, what is it you want, what do you really really want".    There's not much of existing RISC OS that would/could/should appear in a 64 bit version.    But then again, much of the messing about I have done in the last few weeks would not have happened if I could write files bigger than 4GB (or 2GB with SparkFS).    Buzzwords may fade away with time, but files keep getting bigger.

Rick, 4th April 2024, 21:20

As it turns out, AutoDST does NOT work. Because my timezone is +1 hour, the UK territory doesn't recognise it. I used to bake my own Territory that included CET and CEST timezones. I guess I'll have to try doing that again and softloading it as soon as the machine starts.    I'll save you the rant^Wwhinge^Wdiscussion about how bloody awful the Territory system is, what with all this sort of stuff hardcoded into modules and not user-configurable on the fly like any halfway decent OS from the last thirty-odd years...