Important software compatibility notice
Steve Pampling (1551) 8170 posts |
Ah, but Martin Würthner may be “around” to explain, or even suggest what in the artworks render module that bombs1 in this interesting fashion. 1 Assuming here that AWRender is the most likely culprit |
Chris Mahoney (1684) 2165 posts |
Or just turn it off in PhotoFiler’s Choices window :) |
Rick Murray (539) 13840 posts |
That may work too, but given the behaviour, I’d prefer to knock out the offending code entirely…for now.
All of the ArtWorks files in $.Documents.Images and $.Documents.Images.Artworks of the Pi SD image (that I used to test this) work fine in Ovation. Given that the API is not documented, it may be as simple as some oddity in behaviour that is tripping up PhotoFiler. Consider, for instance, if the renderer module passes flags or other things to the callback function and it is getting misinterpreted as a memory claim or somesuch? Unfortunately the debug functions are null stubs, which complicates debugging. Shame. |
Chris Mahoney (1684) 2165 posts |
Fair enough; I was thinking more from the perspective of end users that may not have a copy of ObjAsm. You’re obviously not in that group :) |
Colin Ferris (399) 1814 posts |
With ref to module running in SVC mode (seem to remember that Arthur or RO2 – it was the other way round – ref code from a old podule – forcing the code into SVC mode at the start of a SWI jump table) What about leaving a NOP code in the lead up to a SWI jump table – that could be easily changed to make the code run in USR mode – using !Zap. |
Rick Murray (539) 13840 posts |
Are you sure that it was the SWI handler and some other sort of jump table? I ask because the SWI instruction automatically puts the processor into SVC mode.
To be done properly it would need three instructions and care. Read CPSR, modify the mode flags, push it back. You can’t stack whatever register you’re corrupting either, as R13 won’t be the same. Hmm, does RISC OS cope with being returned to in USR mode…? |
Colin Ferris (399) 1814 posts |
If I have got this correct:- Looking at a old Module – it seems to be using - SWI OS_EnterOS ;enter svc mode thought to replace teqp pc,#0 with teq pc,pc |
Jon Abbott (1421) 2651 posts |
It will be in SVCxx at SWI entry, so that code isn’t required. That said:
If you want to check for 32bit this way, you need to ensure a flag is set first, otherwise USR26 with no flags and IRQ/FIQ enabled will equate true. TEQ PC,PC twice will ensure Z is set the first time for example. Depending on how the code handles re-entry, the only time you’d want to touch the PSR is to disable IRQ over the call. |
Jeffrey Lee (213) 6048 posts |
The recommended way to get back to user mode is via SWI OS_LeaveOS, as that will allow any pending callbacks to trigger. But it will require you to check for the presence of CallASWI 0.10 in order for it to work on non-RISC OS 5 machines. https://www.riscosopen.org/wiki/documentation/show/CallASWI But if you want to do it in assembler, the correct way of doing it would be: teq pc,pc msreq cpsr_c, #%10000 ; 32bit system. This is a conditional MSR CPSR_c, so must be followed by an idempotent instruction to avoid the StrongARM MSR bug. teqnep pc,#0 ; 26bit system. Might be ARMv2 so use TEQP instead of MSR. mov r0,r0 ; ARM2 compatibility: avoid using banked register after changing mode using TEQP (or similar)
Wrong. If you’re in a USR26 mode with Z as the only PSR flag that’s set, the first TEQ will set Z=0 (and preserve NCV as zero). So you’ve just set yourself up for the PSR=0 case which the second TEQ will fail on. TEQ R0,R0 followed by TEQ PC,PC is a correct way of checking for 32bit modes. Unfortunately it looks like the 32bit docs on iyonix.com are no more, but they are readily available on the Internet Archive |
Evert Jan Henken (2788) 12 posts |
WimpWorks V2.38 Nutpi doesn’t work with ROM 5.23(18-Sep-16). And I get a zero pain logfile with the following content: Time: Thu Oct 6 16:19:23 2016 R0 = 00000082 R1 = 0005ed94 R2 = 00000001 R3 = 00000081 0005fa10 : ca00000a : BGT &0005FA40 R15 = 0005fa58 = +57a58 in application memory USR stack: |
Andrew Flegg (1574) 28 posts |
Sorry about that. It’s a zero page bug. We’re working on a fix and will get it patched as quickly as possible. We’ll get a new version over to the ROOL folks to update the NutPi image for future versions and also make an upgrade available through our website if you haven’t upgraded yet (or have noted down the registration details). If you have upgraded, or don’t have your registration details, get in touch via email (as Evert has done) |
Andrew Flegg (1574) 28 posts |
v2.39 is now available through the upgrade page If you have already upgraded to the new ROM and cannot start WimpWorks to get your key, get in touch with your NutPi proof-of-purchase and we’ll sort you out. Sorry again for the inconvenience. |