Rick's b.log - entry 2021/04/24

The post has just arrived

So, I now have the first and second CDs, just waiting on the latest.

I've just noticed, there's a Little Chef logo in the background. I have fond memories of far too many All Day Breakfasts.

But, I can't really think about food right now. Had a rather upset stomach in the early hours. Too much sun? Ate something bad? I had some different meals at work, maybe a preservative or antibiotic or something that disagrees with me? I had a bath and washed my hair last night? Maybe a little bit of (from a well) water got into my mouth? I'm not aware of it, but... Or perhaps it was just the wrong phase of the Moon?
Sadly, my digestion is about as stable as the first release of Windows 95. A long list of things that send it flipping over in unpleasant (and often painful) ways. So while I should be out here in the sun with a chicken salad, I'm actually out in partial shade with a yoghurt.
Apparently, this would appear to be something I inherited from my mother. As a child I could eat just about anything. These days? I am a rather unadventurous person food-wise for exactly this reason. I don't eat ice cream any more (it's not lactose, I drink a lot of milk). It's some sort of additive as the expensive ice cream (the ones that are actually frozen cream) are okay, but pretty much everything ordinary isn't.
There may be a common thread tying this all together, but in mom's life nobody ever managed to. Just lucky that I quite like pasta with a 'sauce' of a knob of butter and a tiny sprinkling of pepper. Of course, I'm quite picky there as well, since the primary taste of that meal is the pasta itself, rather than the usual case of the pasta being the bulky stuff that carries the sauce. So it's important to pick a pasta that has a pleasing taste. So many are... bland.
I also choose fresh pasta, because it's two or three minutes rather than ten to twelve. Less time for me in the kitchen, and less humidity in the room.
Anyway...

I've just noticed that the CD has a band that looks different around the outer centimetre. I wonder if it does anything when put into a computer?

Data track?

Whoa - the end of the first song (I Hate The Way) is pretty intense.

An easy weekend

I mowed the grass yesterday, which involved sitting on a bucking bronco (hmm, maybe that's what upset my gut?) and turning a steering wheel.
Today and tomorrow? I'm on a strict "no gardening" rule. Well, I can do little things. But no touching anything that requires repetitive strenuous efforts. I have to do stuff like that at work, I don't want to turn up on Monday more broken than I was on Friday.
That also means no using Some Pig (little mower). Or the rotavator. Or... I'm just looking around as I write this thinking "aw, come on!".
But, things hurt. Time to dial it back a bit while it is an option and not a requirement.

A free bin

I put it out around back beside the big rubbish compressor, and spent the next half hour wondering exactly how I'd get it into the boot.
When I came to collect it, I suddenly had a brainwave - pop it on the passenger seat, whizz the seat belt around it, job done.

A big white bin.

The idea is to put some holes in the bottom (on purpose!), then some Charlotte potatoes and some soil. When it comes time to earth them up, some more potatoes and soil, and just build it up like that in... I don't know, maybe four layers?

The bin and the potato patch.

Distance

Distance?

I know that the speedometer reads about 5% too fast, as travelling at 45 in reality means I should be travelling at 50 on the speedometer. The GPS (set to read exact) agrees with roadside speed report gizmos.
A difference of 88.7km, that's nearly 9% difference, but possibly explained by GPS drop-outs in the forest? I don't know.
If we take the observed difference (9%) and the general speed difference (5%), the average of the two is 7%. We'll work with 7%, and note that this would mean that while the odometer reads 43,643km, subtracting 7% would imply an actual distance travelled of 40,588km. Well, I'm not going to complain about a quick calculation making my car 3,000km younger! It's a better proposition than Felicity whose kilometrage was almost certainly "highly optimistic".

WINNING THE LOTTERY!

<cough>

€4,80.

Okay, so that's an "I'm going to work on Monday", then? ☺

Vaccination

ESP32-CAM reliability

I ordered a pack of micro USB sockets from Amazon.

Micro USB sockets.

I soldered this onto the ESP32-CAM board, using a flying lead for the 5V (so I could swap it out for the serial interface if necessary).

A power solution for an ESP32-CAM.

The device is still responding and was plugged in on Thursday evening. So, that's a good start. I'll need to look to see if there's some sort of watchdog that can be used to force a reboot if the 'loop' stops working? Or maybe some sort of timed reboot to restart the device after a given period of time (say, 24 hours?).

RISC OS show

However, something that is bugging me is how often I hear um um uh ur um. I do not want to pick specifically on Andrew here, he just happens to be the person speaking as I captured the screen.

A screen capture of the Wakefield 2021 show.

Don't take this as a complaint. The ability to participate at all is a great step forward.

RISC OS in the future

Which means, as always, the forthcoming 64 bit world is a problem. The transition of the operating system and its software to 32 bit was "not so difficult" because there were many similarities between 26 bit and 32 bit. The primary difference from the processor behaviour was that the Processor Status Register (mode, flags, etc) which was a part of the Program Counter (limited to 64 megabytes) became split into two separate things - a Program Counter that could cope with up to 4 gigabytes, and a much richer Status Register.
64 bit ARM, on the other hand, is an alien beast. The registers are completely different (and more plentiful), the conditional compilation is not so much any more, the multiple load/save of registers, a lot of the behaviour of the instructions...
Bringing RISC OS to 64 bit is like porting it to MIPS, or x86-64.

In the short term, to be honest, RISC OS needs to run an emulation system upon the 64 bit processor in order to run the 32 bit RISC OS. I know this is a highly polarising opinion, and I would love to see a 64 bit native RISC OS, but one does not write an entire operating system from scratch - think of the length of time from the various Arthur released to RISC OS 2, and the years between that and RISC OS 3, plus the many many years of development through the RiscPC era, the RISC OS Ltd era, and through now into Modern Day. Remember, of course, that the early days of development were not only full time paid developers, but also a number of people intimately involved in creating the chipset upon which the system was based.
The idea of a largely community effort with people doing work around their day job managing to crank out a 64 bit incarnation of RISC OS (likely written in C) in anything that resembles a useful timeframe is... farcical.

Another point that Andrew brings up is that it is ridiculous to "emulate a RiscPC". I believe that any future emulation should provide a "generic ARM board" emulation in order to pass through as much as possible to the host.
Think of it like this - when you want to blat a sprite to the screen, the current emulators take RISC OS bitmaps and format it into VIDC2 format data, with VIDC2 screen modes, etc. The emulator then takes that VIDC2 data and reformats it to whatever the underlying display hardware uses (on Windows, quite possibly DirectX or the like).
Wouldn't it be much better if the emulator could present the underlying display for a RISC OS driver to use directly?
Repeat this for audio drivers, keyboard, and all sorts of other devices. Any future emulation solution should not be hindered by some sort of necessity of emulating a quarter century old machine. Indeed, if RISC OS can have modules in order to directly access specific hardware, why is there a need to emulate any specific machine? Maybe better to make the best possible emulation of a 32 bit ARM processor, in order that RISC OS itself can run...

The future doesn't stand still and wait for anybody to catch up.

Updated with a video ☺

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.

VinceH, 24th April 2021, 22:28

The 'um' thing bugs the hell out of me, too - and I know damned well I was doing it myself a lot more than I should. Being aware of it makes it worse, because each time I did it the realisation broke my train of thought and that made it even more likely I'd do it again in a mo.    I used to be better at stuff like that. :(

Zerosquare, 26th April 2021, 01:40

Your garden looks and sounds nice.

David Pilling, 29th April 2021, 13:02

I think re-coding RISC OS in C would not be a big piece of work. The trouble is that virtually every program I wrote came with a hand coded module that accessed the hardware at some level. Put it another way they can't recompile every RISC OS app for 64 bits - because they can't recompile every app. I tinkered with doing apps for 64 bit Windows but never managed it for the big ones. 64 bits is not just recompile but writing lots of new code.

David Pilling, 29th April 2021, 16:04

One could compile RISC OS modules to C code - that is translate ARM32 -> C and then compile C->ARM64. And over time translate the compiled C into normal C code.  Back to the sinners, OK if everyone has used char * for memory addresses, but there will be those who have used ints to hold 32 bit memory addresses. You get knotty problems like using 32 bit ints for offsets, or offsets in files. Ovation Pro max document size 32 bits, 4GB. Put it on a 64 bit machine and that limit vanishes as far as a compiler that knows only about pointers or handing out memory blocks, but remains in the file structure.  I still have not made SparkFS access more than 2GB.

David Pilling, 30th April 2021, 16:13

Distance error == wheel slippage

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