Aemulor 2.40

Just seen an announcement on icon bar that Aemulor has now been released as a free download for both low and high vector roms on the Titanium, Raspberry Pi, ARMX6, Beagleboard, Pandaboard and Iyonix machines (also IGEPv5, I think).

This means it is now free of charge on the Raspberry Pi which opens up a possible new user base.

Impression 5.78 was released at the London show this year so this looks like a nice piece of timing.

Adrian tells me they are Beta, especially as he doesn’t have every hardware platform to try them on.
AIUI Pi 0 and Pi 0 W needs the Pi 1 build
and Pi 2 V 1.02 the Pi 3 build.

I’ve been trying the new version on my RapidO Ig since yesterday:-)

Adrian tells me they are Beta

That seems the new normal for the Pi.

That seems the new normal for the Pi.

There. Fixed that for you.

That seems the new normal for the Pi.

I can’t resist optimising things.

I tested it last night, and with it I was able to run TextEase on my Pi 2, so it seems to work pretty well.

I was able to run a couple of the OS 3.1 bundled apps on my Pi 3. I don’t have a library of old apps so it’s fairly academic for me :)

I trust everyone that uses the new offerings will feedback here (and elsewhere) which applications have been tested.

This means it is now free of charge on the Raspberry Pi which opens up a possible new user base.
Impression 5.78 was released at the London show this year so this looks like a nice piece of timing.

So, now the “I need to stick with 26 bit because…” brigade can move to a supported OS, possibly on a much cheaper machine.

Just fired up !ChocksAway on my RPi3. !Chocks seems to work OK on the RPi3 apart from some slight screen ‘tearing’, although not tried anything to alleviate this yet (there are notes about setting correct modes etc. in the supplied ReadMe file). Sound seems to work OK on the RPi3 too :-) Note: This is a ‘special’ hard disc version of !Chocks I ‘created’ for my own use about 25 years ago – I got sick of waiting for those floppies to load – especially on the two player A5000 link-up !

Well done, and thanks very much Adian. Very useful piece of software – especially for any people converting old abandoned RISC OS software from 26-bit to 32-bit.

Aemulator seems very easy to use. Just one big module to load, and you’re off :-)

Ralph

I tried the new Aemulor on my Iyonix, which is running a softloaded 5.23 (26 May 2016) using High Vectors & ZeroPain.

I double-clicked on the module, which seemed to load ok, creating Choices.Aemulor and providing the expected commands and !Aemulor application in Apps.

However, when I double-clicked on !Aemulor there was an error message ‘Overlapping areas’ and that was all.

Anyone else noticed this?
I have also briefly tried the Pi1 version, and that seems to start ok.

‘Overlapping areas’

I am seeing that on my Iyonix with OS5.23 16-Jul-17, which to some minor surprise appears to be the latest beta available.

P.S. Having now set the configured boot drive to be the same as the drive that had the latest softload the Overlapping areas issue does occur with OS5.23 (14-Nov-17).

P.P.S. No such issue on the RPi3 or Titanium.

‘Overlapping areas’

Before we all clutter up the forum, yes there would appear to be a problem with the IYONIX pc build, and the same problem with the RPCEmu build (having just tried it this morning on a new RPCEmu installation – hats off to Peter for the fact that it took only a couple of minutes to download, build and set it up!)…obviously that’s the first thing that I need to investigate. That error is reported during Aemulor startup if there is already a dynamic area mapped when Aemulor tries to set up its emulated 26-bit areas at their old, fixed addresses. It can happen during development when an earlier build hasn’t properly removed itself….I’ll update you when I know more…

Well done Adrian. I can now run spreadsheet Eureka and Wordhound on my Pandaboard. Brilliant! Thanks very much, just what I wanted.

Is there a version of RO that works ok with the lastest download version of ‘Aemulor’ on the ‘Iyonix’?

Thanks

Well that depends on the version of Aemulor.

Adrian’s beta update of Aemulor works on the latest high vector ROM builds, though it does seem to have some issues as Adrian has acknowledged in this thread if certain other programs are running so is best used on it’s own for a single 26 bit application.

The last paid for version of Aemulor Pro only works on RISC OS 5.22.

I’ve just uploaded working versions for the IYONIX pc and RPCEmu. There’s a slight caveat for each – the IYONIX pc build is a bit speed-limited whilst I work out how I broke the faster XScale engine (may take some time, but I’ll upload again as soon as it seems happy), and the RPCEmu build does require a small source patch to the emulator because it does not emulate all of the hardware of the StrongARM MMU. Enjoy!

and the RPCEmu build does require a small source patch to the emulator because it does not emulate all of the hardware of the StrongARM MMU.

I was about to suggest that this might be useful as a full addition to the RPCEmu and then I recalled that you have more in the code store involving rewritten RPCEmu and began wondering whether that had progressed.

Enjoy!

A seasonal present for regular emulator users.

All in all, thank you Adrian for the time and effort you put into these things.

Big thanks to Adrian from Me2. :)

I was a bit puzzled when some fave S/W installed on my new Titanium didn’t work, and after some little while realised I had to actually let Aemulor know about it.

This is a tribute to how seamlessly Aemulor does its excellent work in the background that I’d quite forgotten it was there.

I was about to suggest that this might be useful as a full addition to the RPCEmu and then I recalled that you have more in the code store involving rewritten RPCEmu and began wondering whether that had progressed.

It was just a quick experiment a long time ago and no longer relevant. The Qt-targeted build which has been mentioned is much more relevant and interesting, and I have looked through some of the code with an eye to improving the performance of the interpreter (less relevant to x86/64 targets, but highly relevant to ARM-on-ARM emulation, of course). In addition to running old software, I think a machine emulator with tools specifically aimed at helping debug code (especially low-level system code) could be very useful, given that RISC OS has not exactly been designed to be robust against programming errors.

I should add that, after a bit more investigation, the reason for needing an extra patch in RPCEmu to support Aemulor is not a fault in the emulation, but rather that Aemulor needs currently to patch a location in the ROM image. On a softloaded ROM (since it is actually a copy in RAM) this may work (as it does on post-RPC machines) but on actual RPC+ROM hardware (and accurate emulations thereof!) I need to do some work to map a RAM page over the affected area, a la Acorn’s old patching mechanism.

I just found out that Aemulor supports RPCEmu but I’m not sure how to recompile to apply the patch. May I ask why the version available for RPCEmu is compiled without the patch in the first place? It just seems a little strange. :)

Why would you want to use Aemulor on RPCemu?!? Just use a 26bit OS instead!

Presumably to avoid having to shut down, swap ROMs, and boot up again. Or, at the very least, avoid messing with the boot sequence to stop the softload from running.

Bryan: I thought perhaps there’d be some cases where the emulation is better for software written for the Archimedes. The Readme mentions VIDC/IOC in particular. I figured it was worth a try.

Chris: My bad! I should have the read the previous posts (and info on the webpage) more carefully – I thought the patch was meant for the RPCEmu version of Aemulor, not RPCEmu itself – that makes more sense now! Does that mean I can simply patch the RO5.22 ROM image with a hex editor for the same effect?

Yes, I’d expect that patching the ROM itself would also work.

Thanks. Working now. :)