- entry 2020/10/11

White hat and walnuts

Since Covid, lockdown, etc etc it's been a nightmare for the stock girls to order in the equipment that we need. Plastic aprons, sleeves, rubber gloves, face masks ... all the sorts of things that we use day to day in food production is suddenly wanted by the entire world as PPE.

So, at this exact moment, the supplier of our normal blue hats has run out of them, so we are temporarily using white hats.

Me, a white hat.

So, I can now hold my head up high and say "Look ma, I'm finally a white hat!"

There's also a red hat for external contractors when they're on site, but it isn't a fedora so it doesn't count.....

My walnut tree had a good year. Most of the walnuts fell on the ground, as I don't personally care much for walnuts. When I was young, a Walnut Whip and the crunchy stuff around the edges of properly made carrot cake was about it.

So I asked some girls at work if any of them were interested in walnuts. One said yes. Therefore...

A bag of walnuts.

I gave her a bag of walnuts. Probably weighed around a kilogram? Just guessing. They aren't groundfall either, properly harvested by hand directly from the tree.

There's another walnut tree too, but that's surrounded by brambles and regular readers to this drivel I pass off as a blog will be aware that we've encountered the word "bramble" rather a lot already this year...

Shanqiu Mini 12V UPS

The Mini UPS accepts 12V and can output 5V, 9V, or 12V at up to 2A. It also has a USB socket (normal type and mini) to act as a USB power bank as well (but you can't run it as a UPS from a 5V USB input).

I purchased this device primarily because we have short brownouts out here in the country. I do wonder if it's all the locals turning on their milking machines or something. The power cuts are brief enough that the Pi just shrugs it off as a non-event. But the Livebox reboots. Which takes ages. Not what you want when halfway through watching a movie.

Here is an unboxing and setup video:

Of course, you know where you are, so...

Mini UPS, inside.

Power is provided by four 18650 cells (2200mAh at 3.7V with a capacity of 8.14Wh). I have not looked to see how these are wired up, except to note that there are two positives and two negatives between the battery pack and the board, so maybe they're two 7.4V pairs? There's also a brown wire...

There's probably a boost convertor and a buck convertor to get the three voltages - the 5V, the 9V, and the 12V required. An LPS LP28400A handles charging Lithium Ion cells.

The main controller is an SH88F2051A which is an enhanced 8051 offering 4K or FlashROM, 256 bytes of RAM, and 512 byte of EEPROM, three 16 bit timer/counters, 8-bit PWM, EUART, 10 bit ADC, and low-voltage reset. Pipelining features help this 8051 core outperform the traditional 8051. There's no obvious oscllator on the board, so it might be using its internal 16.6MHz clock source.
Yeah... my little UPS has more processing power than a Minitel. Go figure...

Underneath, it has a not-terribly-well printed identity. Given the user guide makes no mention of actual accreditation (no UL or TEAG or whatever one normally sees), I'm guessing the CE and FCC logos are complete bollocks. Luckily it's a low voltage device. I'd be worried if it accepted mains...

Mini UPS, product markings.

The indicators when power is on:

Mini UPS, indicators when power on.

And when power is off:

Mini UPS, indicators when power off.

The device does not beep, and there's no status communication available to warn a device of the power cut. However, I unplugged the power and went for a pee, made a cup of tea, took a brief walk outside because my back is not happy... maybe six or seven minutes? The Livebox kept on running, and the battery indicator stayed with all four LEDs lit. So I can imagine this device keeping the router going for at least half an hour in that case.

The future of RISC OS

You see, the original ARM design was lovely to use and work with. Full conditional execution on every instruction, for example, made for some lovely compact code. And having come across from the 6502 with a brief (and all too horrific) exposure to x86, the ability to conditionally state-restore the entire processor in one single instruction was deserving of the word "awesome". A single line return-to-caller (even handing down from a privileged mode).
64 bit ARM loses all of this. Hell, even the load/store mulitple has gone, to be replaced by - at most - loading and storing pairs of 64 bit words, which strikes me as batshit crazy on a processor with some thirty registers. But modern ARM, the 64 bit ARM, is not designed for programmers. It isn't designed to be sexy or fun. It's simply designed for compilers, to be easier to optimise for, to be more predictable (in terms of caching and speculative execution), and it's designed for a modern world where people are more likely to know something like Rust than have any clue as to what the hell the punctuation means in STR R14, [R13, #-4]!, for writing stuff in assembler is rapidly becoming a lost art.

Linux is an OS that is easy to port to different architectures, because very little of it is in assembler. The minimal start up code, some fudging for handling exceptions, and... that's about it. Pretty much all of the rest of the way, it's written in C. Hell, even U-Boot is mostly written in C. So porting it to a 64 bit ARM basically means writing the low-level glue and then recompiling. For most things, it doesn't matter if the processor has twenty registers or only six. It has an API for how libraries work and how the programs interact with the OS. The underlying mechanics of actually making this work is a problem for the compiler to deal with. As such, Linux is on ARM (all flavours, but the 26 bit ones are mostly forgotten these days), x86, x86-64, MIPS, 68K, etc etc etc. As long as the processor is technically competent (like, with an MMU), then Linux is possible. Indeed, the main hitch isn't getting the kernel running, it's talking to the hardware. For while devices in the PC world have been standardised for quite a while (you can pretty much assume basic BIOS services for a harddisc, something that will behave like a VGA display, and something that looks a little like a 386), some other designs - notably ARM until fairly recently - have been a sort of "whatever the chip designer felt like doing". The Beagle's OMAP3 and the Pi's BCMxxxx both have an ARM core, on-board USB, serial port, display, audio, etc etc all the stuff you'd expect to find on a single-board computer. The thing is, they're all entirely different. Different enough that RISC OS actually comes in seperate versions. There's one for the Beagle (OMAP3) family, there's a different one for the Pi family, and the Titanium, the iMX6, and even the OMAP4... each have different builds of RISC OS. As I said, things are starting to improve with the use of a thing called a "device tree" that can be handed to the OS to tell it what's on-board and where it is located, so the OS can set up the correct drivers. Which ought to mean, soon enough, one Linux for whatever ARM board one happens to be runing.

Now, to RISC OS. Much of RISC OS, and several of its major applications, are written in assembly language. This is because the guys at Acorn wanted a small and fast OS to run on their new machine, the Archimedes. They had a brief foray into a modern-style OS that was to have been called ARX, and written in Modula-2. It was a Unix-like OS with pre-emptive multitasking, multi-threadings, multi-user support, and in short would have been ridiculously ahead of its time.
So ahead, in fact, that not only did the OS suffer from mostly running in user mode (and needed costly switches into kernel mode to perform mutexes), and according to the talk given to ROUGOL by Paul Fellows, running four clock applications caused the virtual memory to kick in, the system started swapping, and page swapping on an 8MHz processor with 1987-era harddiscs would have just been painful. There was no way in those days that Acorn could have launched a new machine with a requirement of 4MiB of memory and a harddisc. The lowest spec A305 launched with half a megabyte of memory and a floppy drive. And that, with a TV-style colour monitor, would set you back about a grand.

So, Arthur was created as a sort of quick port of the BBC MOS. It was mostly command line or full screen applications, because crucially it could not multitask. There was a sort of window manager, but it only ran one task at a time. The desktop (that you will have seen last Saturday) was a fake. But convincing enough that it was clear that ARX was waaay too overambitious for the time.

Part of RISC OS' speed and compactness is because it was written in pure assembler, chunks of it by the very people who designed the processor itself. And they were very clever people indeed, if one compares the specification of the BBC Micro against most other home computers of that era. Vectors, hooks, plug-in ROMs, floppy and harddisc filing systems (floppy being an add-on but provision already provided on the motherboard), the same for local area networking including user and access rights. All of this was replicated in Arthur, and taking the "sideways ROM" concept to the extreme by providing the entire OS as a series of modules. Modules which were self-contained, but could interact, and more importantly could be replaced. There probably isn't a RiscPC around that doesn't load an updated C library as part of its boot.

While, in later times, some things became to be written in C, the majority of the operating system (the kernel, the services, the devices, the GUI, and pretty much the entire filesystem) are assembler. This created complications when ARM ditched its 26 bit (combined PC+PSR) behaviour, however some careful work (and changing the API to not expect flags to be restored) allowed RISC OS to thrive on 32 bit ARM because there were not that many differences between the 26 bit model and the 32 bit model. I would imagine a greater problem than PC+PSR would be any code that inadvertently used a signed comparison on memory blocks - which would break on any address over the 2GiB limit (that would appear to be a large negative number).

Now enter ARM's 64 bit behaviour. As I said above, everything that made ARM cool has gone, replaced by something weird that is aimed at running compiled code quickly with the least amount of power. It isn't ARM as people like I know it. It isn't ARM at all really.

And for RISC OS, it's not so much a roadblock as a gaping chasm over which no bridge has been built. RISC OS cannot be translated to ARM 64. You might as well consider porting it to MIPS or IA-64, it's really that different.

Some optimistic people on the forum are suggesting that 32 bit capable devices will continue for a while yet. Given that most of the rest of the world has gone 64 bit, I'm afraid I can't really see much use case for new silicon to contain any 32 bit. What's the point, if there's nothing much that will run on it?
There may be some lower-end 32 bit only devices around, like those Alwinner chips, but whether or not they will exist in a form suitable for RISC OS (along with necesary documentation) is another matter.

There are three primary proposals. One that might happen, and two that won't.

The first is to recreate RISC OS using machine translation. Given the amount of clever code in RISC OS, how heavily it depends upon the behaviour of the ARM, how easy it will be to trip up automated translation, and how such code is generally incomprehensible gibberish... this is a non-starter.

Besides, the worst thing that could be done, if porting RISC OS to a new architecture, is to retain the current system as it is, with all of the 1987 (and prior!) baggage. Some bits of RISC OS are unpleasant - I think we can point a finger at anything to do with the keyboard. Or user modules running at kernel level (99% of that code does not need to run as SVC, and I say that as a person who has written numerous modules).
So, the logical step is to think about wht RISC OS will be. And this will likely require a complete change of API as we can't pass registers R0-R8 to SWI calls because now there's X0-X30 or something, with a rather different arrangement of how that all looks and feels.
So, we'll be rewriting RISC OS into something a little more future-proof like C (works for Linux!) and while we're there, support pre-emption, memory protection, and all the more modern stuff.
Nice idea, but who is going to do it? RISC OS is largely maintained these days by volunteers who do their work with RISC OS in their free time (as opposed to work they're actually paid for). ROOL has various bounties using money raised from the users, but even that doesn't guarantee anything, as the time necessary for some jobs and the technical knowledge to do the work are both in short supply these days. So if we have trouble finding somebody to help port the bsd network stack to give RISC OS support for IPv4 and IPv6, then exactly where the hell are we supposed to find volunteers to redesign RISC OS for a modern world, and write it, essentially from the ground up, in C?

Not to mention, the huge majority of existing software will be lost. Some things could be ported to the new RISC OS, but it will be an ever-diminishing list.

Which leaves us with the third, and most viable option. That of running 32 bit RISC OS within an emulator on a 64 bit machine. As much as I'd like RISC OS to continue on ARM, I think that this is pretty much the end of the road as far as native processor support is concerned.

That's not to say there is no hope - there is plenty that we can do with our current systems. RISC OS is only capable of using one processor. Every moment my Pi is running, one core is running RISC OS and the other three cores are basically doing nothing at all. We don't have IPv6 (yet), nor do we have support for things like WiFi and Bluetooth. Our networking stack is from the early-mid '90s. Amusingly we have an SSL module that uses the latest mbedTLS, so our secure sockets interface is more up to date than most people's mobile phones, but that's one thing up to date. Only a million other things to go.

This led me to think - why do I use RISC OS? I use it primarily because it is efficient and it is friendly.

Don't get me wrong - I could just as easily create blog articles on a PC, phone, or tablet. And, indeed, these days many of them are written on the tablet (and I have looked at Android editors for writing HTML), with numerous images being processed either on the PC (using PhotoImpact 5) or more these days on my phone using the built in Photo Editor.

Both of these devices offer more powerful image manipulation than anything under RISC OS. Paint is too simplistic, and PhotoDesk is complex but still lacking (rotate a photo by 8 degrees, and then by -8 degrees and notice all of the artefacts; notice also the hard edges between the sides of the image and the inserted white parts. There's also no real-time preview and it appears as if rotation cannot be undone, so it's a bit hit and miss if you don't know exactly how much you need to rotate in order to straighten a slightly wonky picture. Okay, to be fair PhotoDesk was born in 1996, but even so, it isn't intuitive.

Where these devices fall down is primarily in text editing. I use Notepad++ on the PC, and QuickEdit on Android. They can both cope with HTML, and they both attempt to colourise it. I just find Zap friendly to use. Along with the RISC OS file system paradigm (drag and drop to/from the application and a directory), and I find the Windows method (every app has a portal into the filesystem) annoying. And as for Android... I suppose it's about the best one can expect for a system that doesn't multitask in the traditional sense. But still aggravating.

So, for the time being RISC OS is still here, as am I, and as is Zap. I would say "the writing is on the wall", but the funny thing is, people said that in 1998 when Acorn gave up the ghost. It's 22 years later...

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! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
 
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.

Gavin Wraith, 12th October 2020, 11:48

What I have always liked best about RISC OS is its GUI. The article today in Slashdot, What If They Replaced Windows with Microsoft Linux, makes me mourn for the ROX filer and window manager. This goes no way toward providing a future for RISC OS software, but I do find that the popular Linux GUIs are sadly lacking in comparison with RISC OS, perhaps because RISC OS has so little exposure.

David Pilling, 14th October 2020, 01:27

No squirrels then - because you have walnuts - try wazzing them up in a food processor and you'll have something that can replace ground almonds.    Wazz them too long and you'll get walnut butter.    I found the discussion of 64 bit ARM very interesting. I did not know most of it.    Back when ARM came out, it was common to read that RISC processors were too messy for programmers to write in assembler. It was a pleasant surprise to discover ARM assembler.    We've had companies produce processors with compatible instruction sets and be warned not to by ARM.    Traditionally processors go down market, today's desktop processor is inside tomorrow's toaster.    The debate over the future of RISC OS reminds me of 20 years back. My preference would have been to put RISC OS (written in C) on top of a Linux core. Like they did with Mac OS (and Windows) - obviously not Linux but other proper OSs.    I did not like the idea of emulators running on Windows etc - but they did get a lot of support, and for many people wanting to run legacy apps they were a good solution.    So if you want an emulator, they already exist.    We were saved from emulator domination by the various ARM based computers that came out - Raspberry Pi etc.    About the time Acorn pulled out, ARM Linux was quite a rare thing - something that only just existed.    Anyway ARM not just an instruction set, end of the Wilson ARM instruction set, wow!

David Boddie, 17th October 2020, 18:29

Good to know that you have a plan for evolving RISC OS. You could call the new version Rick's OS. ;)

J.G.Harston, 2nd February 2021, 01:14

The BBC MOS API is an engineer's dream. I have 500 bytes of code that interfaces a USB keyboard straight into KEYV and EVENTV transparently almost as though it came with the original hardware. It's interesting typing away on a nice clacky 104-key Lenovo on my BBC Master. :)

J.G.Harston, 2nd February 2021, 01:19

You can still get brand new Z80s. I would not be surprised if 32-bit ARMs continued to be available.    It's annoying that the ARM-64 instruction set is called "ARM". If &E1A03002 isn't MOV R3,R2 it's not ARM!

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 78954 backwards.
		Your comment