Page 1 of 1

RISCOS with Page Zero relocation

Posted: Mon Jul 06, 2015 9:42 pm
by JonAbbott
I've not tested ADFFS on the latest ROM beta, but in theory it should work as it already intercepts all reads/writes to page zero, provided they generate a normal Abort.

Now that this is implemented in the RISCOS betas and is planned to go live in RO 5.24, I'll be able to remove the LDR interpreter and recode the page zero read handler via Aborts, which will be a lot quicker. It's quite a big rewrite though, so I'm not sure when I'll get round to recoding it.

The proposed reenabling of unaligned loads also shouldn't affect ADFFS as it turns it off whilst running, however, if RISCOS is recompiled to make use of unaligned loads, this project is dead in the water. Most legacy software requires support of rotated loads, particularly C compiled code - if there's no way to detect them, ADFFS can't fix them.

Re: RISCOS with Page Zero relocation

Posted: Sat Jul 18, 2015 9:17 pm
by swirlythingy
JonAbbott wrote:if there's no way to detect them, ADFFS can't fix them.
Didn't you just mention you had an LDR interpreter? It'd be ridiculously slow, but...

Re: RISCOS with Page Zero relocation

Posted: Sat Jul 18, 2015 10:55 pm
by JonAbbott
LDR's are interpreted only once to see if they're touching Page Zero, if not the instruction is copied. Yes it's hideously slow, hence why I want to get rid of it.

I think the way forward is to switch the CPU to Abort on misaligned read/writes and interpret them when they trigger an Abort. Ironically the biggest impact will be on the OS once it's recompiled to use them - it's ironic because the reason ROOL state for the switch to ARMv7 mode is to speed the OS up.

I've now tested ADFFS with Page Zero relocated and wouldn't recommend using it until the next release, as it does read Page Zero when swapping discs. This is corrected in the next release, following a recent RISCOS extension to allow ADFFS to get the items in question legally.

Re: RISCOS with Page Zero relocation

Posted: Thu Oct 08, 2015 6:44 pm
by JonAbbott
To confirm, 2.50 is not currently compatible with Page Zero relocation, but the next release should be.

However...I won't be recoding the LDR Page Zero access handler to take advantage of Page Zero relocation until a later date, so there won't be any speed benefit from running on RISCOS 5.23.

I might roll the recoding into ARMv7 compatibility - which will seriously slow games down. Once recoded, under ARMv5 there will be no emulation of instructions - they'll all be running natively. Under ARMv7 however, it may have to emulate all LDR's and STR's as I'm not sure if alignment exceptions can be used - it all depends on what happens with RISCOS in this area.

Re: RISCOS with Page Zero relocation

Posted: Thu Apr 14, 2016 10:39 pm
by JonAbbott
JonAbbott wrote:I won't be recoding the LDR Page Zero access handler to take advantage of Page Zero relocation until a later date, so there won't be any speed benefit from running on RISCOS 5.23.

I might roll the recoding into ARMv7 compatibility - which will seriously slow games down. Once recoded, under ARMv5 there will be no emulation of instructions - they'll all be running natively. Under ARMv7 however, it may have to emulate all LDR's and STR's as I'm not sure if alignment exceptions can be used - it all depends on what happens with RISCOS in this area.
The Page Zero access handler has now been recoded to require Page Zero relocation on machines past IOMD and unaligned memory access support added. We've verified it works on ARMv5 in Strict mode over the past few months with ADFFS handling all unaligned memory accesses.

ARMv7 compatibility has also been coded, testing however has highlighted odd CPU behaviour, at this stage I'm unsure if it's an OS cache flush problem, CPU errata or undocumented differences with certain instructions. As far as I'm aware, I've implemented fixups for all the documented changes in ARM ARM that affect LDR, STR, LDM and STM.

In summary, the next release requires a High Vector build of RO5 (ie 5.23) and around 50% of games that work on the Pi, work on the Pi2.

There's no plan for Pi3 support as the OS doesn't currently support it fully.