VRPC/RPCEmu HostFS

Is it possible to use either emulator – with one HardDisk directory?

ie be able to run either VRPC or RPCEmu without file extensions being upset?

Requiring the use of ‘!Rename’.

What about building in a way to swap between RO4.02 and RO5.xx.
Is it possible to softload backwards – ie softbooting RO4 from RO5?

And is it possible to date a standard Dir in RPCEmu HostFS – required by !Sibelius?

Hmmm, I was going to write “no”, but it’s not quite that simple.

VRPC has an extensions file that lists the Windows file extensions that are mapped, bidirectionally, to RISC OS filetypes. RPCEmu seems to do no such mapping. So, perhaps VRPC can be persuaded to be as unhelpful as RPCEmu and then they won’t bicker about filetypes. I’d find that limiting though.

As for sharing the same ‘mount’ – definitely yes. ‘RPCEmu’ is one of my VRPC mounts. Not that RPCEmu knows that.

Timestamped directories in RPCEmu – nope. They get the most recent timestamp of their contents. But you could wrap !Sibelius in some image filing system, like XFiles or StrongHelp.

What about building in a way to swap between RO4.02 and RO5.xx.
Is it possible to softload backwards – ie softbooting RO4 from RO5?

Isn’t that the bit where, with the !Boot structure as it is, you start hitting issues with 26bit or 32 bit versions of things that sit in said !Boot?
You’d almost need a dummy !Boot that calls a !RealBoot26 or a !RealBoot32 depending on the base OS image.

There was a time when I used to be able to swap between half a dozen versions of the OS with a star command. The !Boot took care of rearranging the CMOS, and booting different sets of modules. However, that was all 26bit. I keep 32bit and 26bit worlds firmly apart, and if you’re using an emulator I can’t see any necessity in running a 32bit OS.

if you’re using an emulator I can’t see any necessity in running a 32bit OS

It’s amazing how much stuff people think is 32 bit safe that isn’t and an emulator is one quick test setup.

Of course the next step is to shift it to a real 32 bit machine -if you have one.

With ref to the timestamp of a standard directory – I did think you could have a program control the time – and then make the directory – and reset the clock back.

Using RedSquirrel/VRPC-DL – I have been using RO4.02/RO5.xx for sometime -Days-Months-Years.

(Is there any reason ‘RPEmu/VRPC’ can’t/isn’t coded 64bit – is this the same problem as 32/64bit ARM)

Dual booting just works.

32bitted many !Boot utils years ago – as needed.

With ref to the timestamp of a standard directory – I did think you could have a program control the time – and then make the directory – and reset the clock back.

Here’s the definitive answer: If your mount is on a FAT disc you should be OK, the directory timestamp is maintained just like a file timestamp.

On NTFS though the behaviour is weird and complex. Usually the timestamp of a folder will change when its contents change – so saving a file into an NTFS folder causes the folder’s timestamp to update. However, this doesn’t necessarily always happen, and there are utilities available that update folder timestamps to that of their most recent contents, if it hasn’t happened for some reason.

It’s a shame, but HostFS can’t guarantee to timestamp directories.

I’m reminded of the centisecond problem with LanManFS – its timestamps don’t have centiseconds, so copying with Newer is tediously ineffective. I wrote a module to hide the centiseconds on all FSes, just so copying to and from LanManFS was saner.

There’s a good argument for HostFS supporting a hidden metadata file so it can apply all RO metadata to host FSes, regardless of underlying implementation.

Is there any reason ‘RPEmu/VRPC’ can’t/isn’t coded 64bit

The primary reason for going to x64 from x32 is access to more memory. That isn’t helpful for an ARM emulator for running RISC OS. 64bit doesn’t magically make things go faster, quite the reverse – all your pointers are twice the size, so memory usage actually goes up. Whether that is significant depends on your code. There’s a very good reason why PostScript interpreters on x64 are internally 32bit.

It’s amazing how much stuff people think is 32 bit safe that isn’t and an emulator is one quick test setup.

It would be if the CPU emulation of the emulators is precise enough. I don’t think this is currently the case, especially on details like cache behaviour and abort handling.

At the moment, the emulators are good for OS version compatibility testing, but not for CPU compatibility testing. Use an RPi 3(+) for that, it is the most modern and least compatible CPU core RISC OS currently runs on.

and there are utilities available that update folder timestamps

“Touch”, what time and date would you like to claim things happened? >:-)

At the moment, the emulators are good for OS version compatibility testing, but not for CPU compatibility testing.

I did say: "Of course the next step is to shift it to a real 32 bit machine… "

Is there any reason ‘RPEmu/VRPC’ can’t/isn’t coded 64bit

RPCEmu can be built in 64bit form (with recompiler support for x64). They probably just don’t bother releasing 64bit binaries because they’re of little benefit.

is this the same problem as 32/64bit ARM

Not for RPCEmu, since they had the sense to write all of the code in a portable language. I’d imagine you could build an AArch64 version of RPCEmu without any problems (apart from the lack of recompiler support).

Converting RISC OS to 64bit is very different, since (a) operating systems have to do a lot more low-level stuff than applications, and (b) large chunks of RISC OS are still written in assembler.

The primary reason for going to x64 from x32 is access to more memory. That isn’t helpful for an ARM emulator for running RISC OS.

For Archimedes & RiscPC emulators, yes. For emulators of newer machines, no. We have RISC OS machines which boot up with 2GB of RAM available to the OS. We have RISC OS machines which have 4GB of physical RAM (most of which is currently unavailable to the OS, but could be made available if we implemented LPAE support).

I did say: "Of course the next step is to shift it to a real 32 bit machine… "

Yes, but the real useful advice is “save yourself the emulator step if you want to know anything about 32bit compatibility – run it on a RPi 3”.

“A real 32bit machine” is not sufficient – the XScale inside the IYONIX is happy with quite some 26bit stuff as we all found out when moving to the BeagleBoard. Personally, I got bitten by code that ran happily on anything up to and including Cortex-A15 (ARMv7) just to find out that it broke on an ARMv8 RPi 3. And that code was not properly made 32bit compatible back in the IYONIX days.

Maybe we are really lucky to have only a few ARM platforms where RISC OS runs on, and all of the modern ones are “plain” ARM cores, not architecture reimplementations. God knows how much software would survive one of the Scorpion/Krait/Kryo Snapdragons or the Exynos stuff or the various Marvell SoCs.

Yes, but the real useful advice is “save yourself the emulator step if you want to know anything about 32bit compatibility – run it on a RPi 3”.

Strange, I thought the advantage of the emulator stage was that you could stick the emulator on a portable device known as a laptop – an item that most people seem to have around their home and work. I’m not aware of a readily available, robust solution involving a RPi of any version that is as portable.

Strange, I thought the advantage of the emulator stage was that you could stick the emulator on a portable device known as a laptop – an item that most people seem to have around their home and work. I’m not aware of a readily available, robust solution involving a RPi of any version that is as portable.

An emulator has many advantages (did I write anything that implies anything different?), but it still does not help you to know anything (reliable!) about 32bit compatibility, no matter how “readily available” or “robust” or “portable” it is. Which is my only point, and I am not sure why you are trying very hard to ignore it.

By the way: Pi-Top exists, and Raik’s great Motorola LapDock solution is probably more robust in its metal case than your average laptop. But probably fails the “readily available” test for most people.

There’s two different usage scenarios clashing here:

1. Emulate specific 32bit hardware to aid in development
2. Emulate something that can run RISC OS

I’m very much in the second camp, and given that emulators are now officially fast enough, I’m not in the market for ARM-based hardware – why would I be, I’d have to give other stuff up!

By the way: Pi-Top exists, and Raik’s great Motorola LapDock solution is probably more robust in its metal case than your average laptop. But probably fails the “readily available” test for most people.

I’m fully aware of those and I chose the words robust and readily available quite deliberately.

A regular reader will recall various issues with Pi-Top and much as Raik has done a very nice construction job for a personal use machine it isn’t ever going to be mainstream.

I’m not in the market for ARM-based hardware – why would I be, I’d have to give other stuff up!

I suppose it depends on your use cases and how much you care about energy consumption.

My Pi is running a server. Except for when there are thunderstorms (or a risk of, if I’m going out somewhere), the Pi is always on.
I’ve not metered the Pi2, however the Pi1 with HDMI adaptor (too much hassle to turn it off) and the Vonets WiFi thingy, all together, draw 9.4W at 230VAC. That’s about a tenner per year in electricity (106.38 hours per kWh unit; ~82kWh per year; €0,13 per kWh gives about €10,50). If I turn off the HDMI as well, it drops to a mere 7.7W at 230VAC. That’s less than the EeePC’s power brick charging a machine in standby, that’s about half of the consumption of the Livebox. It’s probably on par with a single LED lightbulb.
The PC? The one with the huge heatsink? It chews through around 200W (230VAC) when running. Every hour my PC is on would run the Pi for twenty one and a bit hours. Or, to look at it differently – 5 hour per kWh unit; ~1,752kWh per year; €0,13 per kWh gives about €228. The maths holds up – 228 divided by 21 (the difference per hour) is ten and a bit.
So there you go. Big PC is ~€228 a year to run if on 24/7. The Pi? ~€10 a year.

That is why I use ARM based hardware.

That is why I use ARM based hardware.

That makes me think about ARM based Chromebook offerings and wonder about those as a portable platform for RO

Has anyone tried/seen the Samsung 13.3inch Chromebook2?

Would Linux RISCOS version run on it?