ADFFS 2.41 on the Pi 2 running RiscOS 5.21 help needed please

[JonAbbott]

Ok Jon - I've never actually played Sunburst so there's no urgency at all as far as I'm concerned! I just wanted to make you aware in case it was a clue to some wider underlying issue.

If you PM me your eMail address, I'll send you an updated version to play test.

[jms2]

Hi Jon

I've been experimenting further with recording my own disc images from the few originals that I have - I know this functionality has been present for a long while, but I'd not used it before. I imaged the discs for Pandora's Box today, and these work on my real Archimedes machine. I don't have SparkFS installed on it (yet) so I found I had to manually click on the F10274 obey file using !Sparkplug, then it would boot from the disc images.

However, this image does not run on the Pi with ADFFS 2.61 - I just get a blank screen with a cursor, no loading screen at all. This game is listed as being compatible, so maybe changes in the latest version of ADFFS have broken something?

Also... I have a Zarch image which reports itself as having the wrong ID number - it is pointing to Zalaga instead. It works if I manually run the correct obey file. Is there a way of poking the correct byte into it to correct the ID number?

[JonAbbott]

I don't have SparkFS installed on it (yet) so I found I had to manually click on the F10274 obey file using !Sparkplug, then it would boot from the disc images.

I'll send you the next build of ADFFS to test later, it doesn't require SparkFS to boot floppies.

this image does not run on the Pi with ADFFS 2.61 - I just get a blank screen with a cursor, no loading screen at all. This game is listed as being compatible, so maybe changes in the latest version of ADFFS have broken something?

It's possibly a different version, email the images to me and I'll take a look.

I have a Zarch image which reports itself as having the wrong ID number - it is pointing to Zalaga instead. It works if I manually run the correct obey file. Is there a way of poking the correct byte into it to correct the ID number?

Not easily, your best route is to create a new image from it, with correct metadata.

[jms2]

Ok Jon, I can re-image Zarch, and I'll PM you my Pandora's Box images.

[Trapper]

Does anyone know if Aemulor will be patched to run on 5.23?

I've been emailing Neil today as I swapped my Pi from a v2.2 to a v1.0 to see if Aemulor would work on 5.23 RC15 with the older ARM CPU. It didn't.

He did ask if I'd upgraded recently, so they must know there is a problem. It's a bit frustrating, but I suppose that is the problem with such a tiny community and a microscopic number of developers. Apps don't keep pace with the OS, especially with ROOL who are making daily changes.

[JonAbbott]

A few years back, RISCOS 5 relocated page zero to get the internal OS variable space out of application space. At the time myself, Adrian Lees (Aemulor dev) and Jeffrey Lee (RISCOS dev) had a detailed discussion about what was required for ADFFS and Aemulor to continue working with Page Zero protection active and Jeffrey added extensions to the OS to allow both to continue working in a more future prof manor, by using legal OS calls, instead of direct access to essentially undocumented variables in Page Zero.

I don't believe Aemulor was updated at the time to match those OS changes, it's something Adrian is now looking at releasing so I expect a 5.23 compatible version will be available soon.

Aemulor will also need updating to support ARMv7, this added a lot of complications to getting old software working. Not knowing how Aemulor's CPU handing works, I couldn't say how big a job supporting ARMv7 would be. It was around six months of solid programming on my part to add ARMv7 compatibility to ADFFS, but that may be a bad comparison as code running under ADFFS is running natively on the CPU, I believe Aemulor might use a buffer to build up code as its interpreted which would allow alignment checking to be added at the time the instructions are interpreted.

[hubersn]

ARMv7? I guess you mean ARMv8. Aemulor had ARMv7 compatibility since the release of the BeagleBoard version a few years back.

Not sure how much effort ARMv8 needs - apart from the SWP problem, was there any other problem?

[JonAbbott]

Not sure how much effort ARMv8 needs - apart from the SWP problem, was there any other problem?

It needs to handle alignment exceptions and several deprecated instructions that no longer work on Pi2. For Pi3 it needs SWP and a few more deprecated instructions.

[hubersn]

Not sure how much effort ARMv8 needs - apart from the SWP problem, was there any other problem?

It needs to handle alignment exceptions and several deprecated instructions that no longer work on Pi2. For Pi3 it needs SWP and a few more deprecated instructions.

I still don't understand what difference there is between BeagleBoard/PandaBoard/Wandboard/IGEPv5 (Cortex-A8/A9/A15) and Pi2 (original Cortex-A7 Pi2 of course). Are there differences wrt alignment exception handling and deprectated instructions?

And IIRC, Aemulor on non-XScale does full ARM emulation (formerly known as "ARM610 mode"), so should be (comparatively) easy to adjust to handle more problematic instructions. I think Adrian never finished the planned JIT after discovering the special XScale trick to speed up emulation.

Have fun
hubersn

[JonAbbott]

Are there differences wrt alignment exception handling and deprecated instructions?

Yes, there's a number of "implementation defined" instructions and some behavioural differences with instructions. For example, LDR R0,[R0],#0 may work on one chip but generate a fault on another. Other examples might be the inclusion of R13/PC in an STM reglist, which are deprecated on ARMv8 - thankfully they still work on the Pi3 though!

Aemulor on non-XScale does full ARM emulation (formerly known as "ARM610 mode"), so should be (comparatively) easy to adjust to handle more problematic instructions. I think Adrian never finished the planned JIT after discovering the special XScale trick to speed up emulation.

I suspect Adrian probably used the on-chip breakpointing so 90% of the code will be running natively. The ARM1176 (Pi1) also supports breakpoints, so will probably be doing a similar thing. Unless it implements an Abort handler however, Pi2/3 would need to be fully emulated to catch alignment faults. Page Zero would certainly fail if there's no Abort handler to deal with them, which may be why it's yet to be updated for High Vectors.