RPi5 out

Emulating a RiscPC – seems rather uninteresting

But it is something that we have – and a lot of us actually use – right now, works, uninteresting or not.

Interesting – why? I understand (sort of) the nostalgia leading to having an actual RiscPC. But what’s the advantage in having an emulated RiscPC rather than a Pi (of whatever variety)?

Interesting – why? I understand (sort of) the nostalgia leading to having an actual RiscPC. But what’s the advantage in having an emulated RiscPC rather than a Pi (of whatever variety)?

I suspect only that RPCEmu exists and is being used by people, whilst none of those telling us to drop IOMD support from the ROM have yet to show us RISC OS running on a Pi emulator…

But what’s the advantage in having an emulated RiscPC rather than a Pi

There isn’t any particular advantage to emulating an ancient machine with all its limitations.
However, the RiscPC emulator exists. That alone is a pretty big advantage.

I’m all for leaving the RiscPC in the past where it belongs, but where’s the emulator (any functioning emulator) for more recent machines?

The Pi exists, too, and isn’t expensive. Even I can afford a couple of them!

Okay, no emulated Pi – but why not an actual physical Pi?

why not an actual physical Pi?

Yeah, those too, and for many years to come. But when you have your laptop away from home…

Ah, okay. Understand that now! Not something I generally do, but understandable.

Okay, no emulated Pi – but why not an actual physical Pi?

I have a large number of Pi’s, most with RISC OS, but mostly I run RPCEmu on x86 laptops, because that’s the machines I use all the time, and switching between two physical machines is just inconvenient (and that’s even when I am sitting in front of my KVM switch where some of the Pi’s are connected).

Now if RISC OS had a good high-performance cross-platform remote desktop capability, things might look different.

I wrote a little text in Archive about the subject.

As some of you know , I have some emulation projects going on:

CPU emulation on bare metal 64bit arm.. I have done a proof of concept and will transplant my RISC OS to unicorn port to it. I plan to support hardware directly from RISC OS

Emulation similar to pyro. I guess it will not be like Pyromaniac in features ( Pyro is a fantastic project!!). I have done a bit work on this , and recently got c-modules to work. Offloading most kernel to host system ( in C) is pretty cool. This emulator will go into my Genode project when time allows.

Multicore:

I have my now defunct BSD on second core project. I haven’t done anything on this after we dumped the use of u-boot. It is still possible to do but requires some more thinking in bootstrapping it and for storage (filesystem) for the second system.

I have also explored having RISC OS the second system and that worked quite well. But that requires a cpu that can run RISC OS .. so pretty much doomed.

VNCserver on a Pi 4 is usable across the LAN.

That’s with the ROOL stack, completely unusable last time I tried ROD.

Okay, no emulated Pi – but why not an actual physical Pi?

That’s not a lot of use when I need RISC OS on my laptop…

Druck. VNCserver works fine on the ROD stack and the Pi 4. I use it daily.

Now if RISC OS had a good high-performance cross-platform remote desktop capability, things might look different.

I am currently sitting at a Pi 4 running 5.28 and using RDPclient connected to Windows XP PC. It works very well and also works very welll to a Windows 7 PC.

And, of course, VNC connects to other RISCOS machines as well.

> Druck. VNCserver works fine on the ROD stack and the Pi 4. I use it daily.

Interesting I have Pi400 and a 27" intel iMac, sometimes I need work that’s on the pi to be shown in Zoom so I use Apple vnc for that and the results are appalling to say the least. I would never try driving it from the Mac keyboard and mouse, using its own seems ok. The inevitable questions about what distro is THAT make it worth while though.

Interesting discussion, thanks folks.

I use a switch (different brand) to flip between the Pi and the Mac. It’s not perfect: I use the Mac keyboard because the Acorn one doesn’t have all the keys the Mac wants, but then the Pi doesn’t have all the keys it wants. Occasionally I actually swap keyboards over, or even use the trackpad instead of the mouse with the Mac. But it’s rarely necessary to bother with either.

And as I never feel the need for RISCOS when I’m away from the desk it doesn’t bother me that I don’t have it on the laptop. But I do now understand other folks’ interests better.

I have also explored having RISC OS the second system and that worked quite well. But that requires a cpu that can run RISC OS .. so pretty much doomed.

Absolutely not! :)

To dedicate one instance of an OS to each available core/CPU is (basically) the definition of an AMP system. The advantages are: RISC OS apps will continue to work (not sure they will on a SMP/PMT system); the giant lock problem is a bit easier to solve (especially with tricks as RAM discs for secundary systems); while it’s not as flexible as SMP, AMP is cool, because you’ll use similar mechanisms than on a cluster (so you path the way to RISC OS clusters}; It’s not incompatible with a light threads approach (in a way, light threads are a limited subset of the main API dedicated to threads running on other cores. So it could be done with a limited CLI only instance of RISC OS).

So, IMHO, this project is really essential.

A nice idea, but have you used the Arduino IDE recently?

What I (and Eben; see latest Archive) suggest, is the possibility to emulate an Archimedes on the RP2040. Seeing what was done for the RePalm project, and how fast is the Thumb→ARM32 JIT layer (made as a HAL), we could go even further, with a RPC Emulation, or a RISC OS 5 compatible device.

Of course, it’s bit crazy, but not so crazy:

• RISC OS working on a 50 cents microcontroller (with a lot of side components)!
• Preparing RISC OS for more powerful RP microcontrollers (with less additional components).
• Can be done and will be still RISC OS, compatible with RISC OS apps.
• Could run apps compiled to bypass JIT, for native speed (native thumb code).

Etc.

So yes, it’s crazy. But IMHO, much less than a new 64bit OS made from scratch and without apps. I could also argue that making RISC OS for high end systems, while cool for hardcore users, is pointless. Linux – or even Windows – will do it better, faster, with much more available software. RISC OS on Pi4? Cool, fast. Does it have a fast web browser? No. Does it have LibreOffice? No. Raspberry Pi OS does all of this and much more.

So yes, I wan’t more and more (Pi5, WiFi, AMP, SATA…). But I know too that the main competitive advantage of RISC OS is its capacity to provide a desktop on very low end systems, as Pi0. And this is not something Linux or Windows can do. It’s a real market opportunity (and perhaps the only one).

Virtual Risc PC is streets ahead of RPCEmu and Pyromaniac.

Surely VRPC’s inability to run RO 5 entirely disqualifies it from further consideration? Also, it’s proprietary software. (FWIW, having used both, I didn’t personally find it superior to RPCEmu in any meaningful way, rather the reverse. I’m not qualified to comment on architectural differences however).

Findamentally important is that existing RISC OS applications must continue to work not just those written in BASIC.

Absolutely agree.

Surely VRPC’s inability to run RO 5 entirely disqualifies it from further consideration?

Not at all. My Raspberry Pi 4’s inability to run 5.30 is no grounds to disqualify it from further consideration.

What this thread does highlight is that effort needs to be spent on current issues rather than talking about wild ideas for the future.

What this thread does highlight is that effort needs to be spent on current issues rather than talking about wild ideas for the future.

This is true. Finish what’s started, because what we have works, before venturing into something entirely new. Of course, if it were a parallel project, that would be different.

VRpc DL seems to work with ro4 ro5 and presumably ro6.

VRpc DL seems to work with ro4 ro5 and presumably ro6.

I stand corrected. However, in performance terms, the latest RPCEmu is generally faster on the same hardware (a 2.5GHz i3-powered Acer laptop running Win7 at the time), according to ROmark:

(VRPC-SA listed first)
Processor – Looped instructions (cache): 160% vs. 523%
Memory – Multiple register transfer: 2412% vs. 5928%
Rectangle Copy – Graphics acceleration test: 621% vs. 790%
Icon Plotting – 16 colour sprite with mask: 448% vs. 273%
Draw Path/Draw Fill: nothing to choose
HD Read – Block load 8MB file: 6463% vs. 147693%
HD Write – Block save 8MB file: 6157% vs. 73347%

The two areas where VRPC-SA shows a clear edge is in FS Read/Write: 1145% vs. 70% and 652% vs. 68% respectively.

VRPC-SA was running RO4.03, screen res. 1360 × 686, RPCEmu was v.0.9.4 running RO5.29, screen res. 1360 × 768.

I have no idea how difficult it would be to produce a PiEmu version of RPCEmu, but as far as I know the latter is the /only/ full-featured RO emulator currently able to run on pretty well any platform regardless of 32/64-bit status, and is therefore worthy of serious consideration as a possible future solution.

!Chocks Away (Extra Missions) runs just fine of my new Raspberry Pi 5 using the Archimedes Live! (WASM) emulator on Chromium. Screen update rate for !Chocks on the RPi5 seems to be about comparable to an A5000 even when the screen of full of aircraft (with A5000 selected).

Note that I removed the rubbish copy protection on !Chocks 30 years ago to allow it to run directly from an A5000 hard drive. At the time we had four A5000s at work (for work use honest – logging proprietry data using custom build interface cards (podules). Lunchtimes was the only time that anybody else ever showed any interest in the A5000s, when we used to play !Chocks in 2-player mode using the A5000 serial ports.

Hmmm… I wonder if the A5000 serial port is emulated on Achimedes Live ?

Ralph

Edit:Typo corrected.

Note that I removed the rubbish copy protection on !Chocks 30 years ago to allow it to run directly from an A5000 hard drive.

+1.

I had Chocks a billion years ago. And, yup, dealt with the copy protection because… I have a harddisc and you want me to keep running this thing from a slow floppy? Grr, nope!

The one I didn’t get around to cracking was the colour code nonsense in Interdictor (II?), but since it could be copied to harddisc and run from there, the code stuff was just an annoyance rather than a road block.

But, yeah, a lot of my early work with ARM code was in defeating copy protection (hmmm, which one was it that hijacked FileV to unscramble data as it was read from disc?). Always seemed weird to me that publishers would be so blatantly hostile to those who coughed up money for their product…
…especially when Debugger/Zap and judicious use of the NV condition would quickly rectify a lot of that nonsense.

using the Archimedes Live! (WASM) emulator on Chromium.

The emulator is a bit weird on Android (it isn’t really aimed at such devices) but it does sort of work (even on a middle-of-the-road Xiaomi)… Kind of impressive.