RISC OS 3.7 - Non SA

Anybody managed to successfully use (recently) the combination of RPCEmu, RISC OS 3.7, any non SA processor, networking and preferably on linux?

The combination always locks up or fails to boot for me. I did ask on the rpcemu list but never got a resolution. I assume the combo should work?

It’s a known bug, the workaround is to run the dynarec with SA processor, or run the interpreter version.

The file that causes the issue with non-SA on RPCEmu is in the 3.7 !Boot and it’s related to combination of self-modifying code complicated by timing issues.

Anybody managed to successfully use (recently) the combination of RPCEmu, RISC OS 3.7, any non SA processor, networking and preferably on linux?

Yes but only with ROOL’s !Boot. This with RPCEmu 0.9.1 on Ubuntu 18.04 in a VM on an iMac. It networks, with an old enough NetSurf.

It’s a known bug, the workaround is to run the dynarec with SA processor, or run the interpreter version.

How is the interpreter version built these days? I only get ‘rpcem-recompiler’.

Yes but only with ROOL’s !Boot.

Using ROOL’s boot here, on a windows Vmware guest, I then get no networking.

How is the interpreter version built these days? I only get ‘rpcem-recompiler’.

Zip archive for Windows install of v0.91 has both rpcem-recompiler.exe and rpcem-interpreter.exe

Zip archive for Windows install of v0.91 has both rpcem-recompiler.exe and rpcem-interpreter.exe

Windows?

Ok, I’ve downloaded and built v0.85 (pre the qt5 business) and all is good. Even the keyboard ‘arrow’ keys work :)

Windows?

You started with the line

preferably on linux

So I took it as “not exclusively Linux”
The Linux build has largely been a compile yourself job for as long as I’ve known.

The instructions on this page are pretty clear and if you have problems then asking on the mail list should get you the required info.

Ok, I’ve downloaded and built v0.85 (pre the qt5 business)

Also pre- numerous fixes and changes as it moved from .85 to .89 in increments so you might want to give building the 0.91 version a go.

You started with the line
preferably on linux

Yes, that wasn’t what I should have written, sorry.

Also pre- numerous fixes and changes as it moved from .85 to .89 in increments so you might want to give building the 0.91 version a go.

I did build both 0.90 & 0.91 and these were the versions I was referring to as ‘recently’. Perhaps you might consider 0.85 as revent? :)

Anyway, as I said, I built 0.85 and it works as it should, unlike the qt5 versions.

Anyway, as I said, I built 0.85 and it works as it should, unlike the qt5 versions.

You might want to feed that back to the developers who seem to be putting a lot of time in on the project in recent months (and longer, but there’s some significant stuff happened more recently)

Anyway, as I said, I built 0.85 and it works as it should, unlike the qt5 versions.

Please be precise with the versions you refer to. The last non-Qt version was 0.8.15. The Qt versions are 0.9.0 and 0.9.1.

Please be precise with the versions you refer to. The last non-Qt version was 0.8.15. The Qt versions are 0.9.0 and 0.9.1.

and the purpose of this post was?

As there is no version ‘0.85’, I think it was clear that I had downloaded and built 0.8.15. I made a typo, OMG!

Unless of course you’d built 0.8.5.

Incidentally the bug you reported is present in 0.8.15 and earlier, it’s not a regression in 0.9.x

Unless of course you’d built 0.8.5.

Well, I didn’t build 0.8.5. I just downloaded from the rpcemu site and 0.8.5 doesn’t appear there, but hey ho, it matters not.

I didn’t say it was a regression, I said that I downloaded and built 0.8.15 (despite my typo) which worked, i.e. I had ARM710 & networking. This was using the 0.9.0/1 cfg file from the download and build that did not give me ARM710 & networking.

I sense some alienation here from the last two posts. I don’t know why, but in my experience, it’s not uncommon in the RISC OS world.

I sense some alienation here from the last two posts. I don’t know why, but in my experience, it’s not uncommon in the RISC OS world.

I think it’s a bit unfortunate, but some people may be reacting in a slightly prickly way because of the way you’ve put things. There are so many combinations here (Windows/Linux, which version of RISC OS, which !Boot sequence, whether using the interpreter or dynarec, which version of RPCEmu) that it’s really important to be precise.

I’m not surprised that Steve Pampling mentioned Windows when in the previous post you stated “on a windows Vmware guest” (and if that was running RPCEmu in Linux then I must have got in a muddle about host/guest, so apologies if that’s the case).

I think you have found a combination that works, but I’m struggling to be sure what it is. Peter Howkins is one of the RPCEmu developers, and if he says that the networking problem is present in 0.8.15 and 0.9.x with certain combinations of processor type / emulation method then I’d trust him. If you think you have a working or non-working combination that doesn’t fit with his statements then it would be helpful to set out the variables in a single posting so we can be clear what’s going on and what you have tried.

and the purpose of this post was?

I always find it useful to know the precise versions that were tried when looking at a bug report.

As there is no version ‘0.85’, I think it was clear that I had downloaded and built 0.8.15.

It is never a good idea to guess when trying to interpret bug reports.

I made a typo, OMG!

You managed to repeat these kind of typos so many times (4 of 4 versions you mentioned were wrong) that I thought it would be a good idea to clear it up.

Going back to your bug report, I am still confused about the whole situation. Did you try to build the interpreter version with 0.9.1 and it didn’t work? Does your last posting mean that in 0.8.15 it even works with the recompiler version in ARM710 config? Maybe you could try to clearly sum up what you have tried and what works and what fails. “Did not give me networking” is a very unclear description – which type of networking did you configure? What does the logfile say?

Essential reading: https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

Essential reading: https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

Maybe, if I was submitting a bug, but I wasn’t, I was asking a question.

I wanted to be able to do some testing which required the combination of RISC OS 3.7, the ARM710 processor and networking.

So, to sum up, using Debian Stretch, on a vmware vm, running the Trinty Desktop Environment, I downloaded and built v0.9.0. I installed the RO 3.7 rom and changed the rpcemu settings to use the ARM710 processor. This combination booted to the desktop.

I installed the uniboot structure and this caused the whole thing to freeze. It also prevents rpcemu from booting.

I then did the same things as above with v0.9.1, with the same results.

In both cases above, only the recompiler version was built so I only tried that version. I asked above how is the interpreter version built these days but didn’t get an answer.

So, I downloaded the v0.8.15 source code from the rpcemu site. I built this version which produced one binary. I don’t know which type it is, I just ran ./congigure && make. This binary, ‘rpcemu’, using the rom, config file and hard disk image from the v0.9.1 build above, works in the way I had hoped. That is, I have configured it to use ARM710, I am using RO 3.7 and I have working, bridged networking.

Hopefully that’s cleared things up a tad.

So, to sum up, using Debian Stretch, on a vmware vm, running the Trinty Desktop Environment, I downloaded and built v0.9.0. I installed the RO 3.7 rom and changed the rpcemu settings to use the ARM710 processor. This combination booted to the desktop.

I installed the uniboot structure and this caused the whole thing to freeze. It also prevents rpcemu from booting.

I then did the same things as above with v0.9.1, with the same results.

Useful information for the RPCEmu developers.

It might even be useful for you to look at the Harinezumi utility/tool to log the point it gets to before locking up – it’s entirely possible it is down to a specific module with a bug or a bug in the dynarec triggered by said module.

It might even be useful for you to look at the Harinezumi utility/tool to log the point it gets to before locking up

The boot process doesn’t get far enough to use harinezumi. It’s a known bug. From Peter Howkins above;

The file that causes the issue with non-SA on RPCEmu is in the 3.7 !Boot and it’s related to combination of self-modifying code complicated by timing issues.

The boot process doesn’t get far enough to use harinezumi

Harinezumi takes over the boot, I think starting !System/CLib is the only thing that happens prior to loading Harinezumi.

In both cases above, only the recompiler version was built so I only tried that version. I asked above how is the interpreter version built these days but didn’t get an answer.

You got an answer, but it probably got lost.

The “How to compile on Linux” RPCEmu page has the answer:
https://www.marutan.net/rpcemu/linuxcompile.html

You need to change the makefile to produce either the recompiler or the interpreter version.

Harinezumi takes over the boot, I think starting !System/CLib is the only thing that happens prior to loading Harinezumi.

So, I could try changing to an earlier CLib I guess.

You got an answer, but it probably got lost.

The “How to compile on Linux” RPCEmu page has the answer:
https://www.marutan.net/rpcemu/linuxcompile.html

You need to change the makefile to produce either the recompiler or the interpreter version.

That is the info I followed and it doesn’t mention the interpreter version, it just states to change to ‘CONFIG += debug_and_release dynarec’, which I did. I also tried ‘CONFIG += debug_and_release dynarec interpreter’ but that only built the dynarec version. Maybe I needed to do TWO individual builds?

That is the info I followed and it doesn’t mention the interpreter version, it just states to change to ‘CONFIG += debug_and_release dynarec’, which I did.

Just use

CONFIG += debug_and_release