Important software compatibility notice

Okay, this is rather horrible.

I know nothing about how the ArtWorks render module works, nor do I have any documentation on it. So going blind and playing around, and plenty of reboots later, I find that I can get it sort-of working as follows:

Towards the end of the s.Thumbnails code, you’ll see a call to XAWRender_RenderAddress, followed by setting up some data blocks into registers, then:

        MOV    r14, pc
        MOV    pc, r10

Modify as follows:

        MOV    r14, pc
        MOV    pc, r10

        MOV    r0, r0
        MOV    r0, r0

Now the machine won’t stiff the moment you see an ArtWorks file. Instead one or two may be rendered and then the Filer will crash horribly (and take the machine down with it, yay!).

That’s one step forwards, one step back.

For what it’s worth, the reason for the stiffing is because ArtWorks appears to return after the instruction following the BL, which meant that the LDMFD was missed, which left five words on the stack and, well, you can guess what happens if the stack gets out of whack. Especially when it’s the SVC stack ‘cos we’re a module. ;-)

So for now, the simplest option is to simply nobble ArtWorks support. To do this, set the flag in Hdr.Options to 0. It’ll be obvious which one. ;-)
However, in order to get it to build, you’ll need to bodge the data block to be a size that can be used in an immediate MOV, so open up Hdr.Workspace and look for this line:

sizeof_workspace                * @

Add the right amount of junk prior so the MOVs will work, as follows:

  [ ARTWORKS = 0
BodgeSizeofWorkspaceToFit       # 136
  ]
sizeof_workspace                * @

Then rebuild, and just accept that – for now – something is very VERY wrong with ArtWorks support, and since it isn’t a publicly documented API…….

something is very VERY wrong with ArtWorks support, and since it isn’t a publicly documented API…….

Ah, but Martin Würthner may be “around” to explain, or even suggest what in the artworks render module that bombs¹ in this interesting fashion.

¹ Assuming here that AWRender is the most likely culprit

So for now, the simplest option is to simply nobble ArtWorks support. To do this, set the flag in Hdr.Options to 0.

Or just turn it off in PhotoFiler’s Choices window :)

Or just turn it off in PhotoFiler’s Choices window :)

That may work too, but given the behaviour, I’d prefer to knock out the offending code entirely…for now.

Assuming here that AWRender is the most likely culprit

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.

That may work too, but given the behaviour, I’d prefer to knock out the offending code entirely…for now.

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 :)

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.

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

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.

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

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…?

If I have got this correct:-
(Inside a SWI – shouldn’t it be in svc mode already?)

Looking at a old Module – it seems to be using -

SWI OS_EnterOS ;enter svc mode
do something
Teqp pc,#0 ;back to usr mode.
nop

thought to replace teqp pc,#0 with

teq pc,pc
msrne cpsr_c,#0
msreq cpsr_c,#%10000

It will be in SVCxx at SWI entry, so that code isn’t required. That said:

teq pc,pc

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.

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)

TEQ PC,PC twice will ensure Z is set the first time for example.

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

WimpWorks V2.38 Nutpi doesn’t work with ROM 5.23(18-Sep-16).
WimpWorks does work well with RC14 with ROM 5.21, but because i am using a Raspberry Pi 2 with the Raspberry DSI Touchscreen i had to upgrade the PCLoader and ROM 5.21 to ROM 5.23. This works well but WimpWorks V2.38 gives an error by startup:
Internal error: abort on data transfer at &0005FA5C, in user code.

And I get a zero pain logfile with the following content:

Time: Thu Oct 6 16:19:23 2016
Location: Application space
Current Wimp task: WimpWorks
Last app to start: BASIC -quit @00009000,0001FC85

R0 = 00000082 R1 = 0005ed94 R2 = 00000001 R3 = 00000081
R4 = 20621699 R5 = 00000080 R6 = 0000000d R7 = 0005fc70
R8 = 00008700 R9 = 00000081 R10 = 00000082 R11 = 00000021
R12 = 00000041 R13 = 00048dcc R14 = 0005f9c4 R15 = 0005fa58
DFAR = 0000000d Mode USR32 Flags nzCv if PSR = 20000110

0005fa10 : ca00000a : BGT &0005FA40
0005fa14 : e5819084 : STR R9,[R1,#132]
0005fa18 : e2811080 : ADD R1,R1,#&80 ; =“Ä”
0005fa1c : ef0600ce : SWI XWimp_GetIconState
0005fa20 : 6a000009 : BVS &0005FA4C
0005fa24 : e2411080 : SUB R1,R1,#&80 ; =“Ä”
0005fa28 : e28f6040 : ADR R6,&0005FA70
0005fa2c : e591701c : LDR R7,[R1,#28]
0005fa30 : eb000006 : BL &0005FA50
0005fa34 : e28f6f4d : ADR R6,&0005FB70
0005fa38 : e591709c : LDR R7,[R1,#156]
0005fa3c : eb000003 : BL &0005FA50
0005fa40 : e1520005 : CMP R2,R5
0005fa44 : e2822001 : ADD R2,R2,#1
0005fa48 : daffffca : BLE &0005F978
0005fa4c : e8bd9fff : LDMIA R13!,{R0-R12,PC}
0005fa50 * e4d60001 * LDRB R0,[R6],#1
0005fa54 : e4c70001 : STRB R0,[R7],#1
0005fa58 : e3500020 : CMP R0,#&20 ; =" "
0005fa5c : aafffffb : BGE &0005FA50
0005fa60 : e1a0f00e : MOV PC,R14
0005fa64 : 00000081 : ANDEQ R0,R0,R1,LSL #1
0005fa68 : 20621699 : MLSCS R2,R9,R6,R1 ; ARMv6T2 or later
0005fa6c : 0005ed94 : Undefined instruction
0005fa70 : 6e6f4321 : CDPVS CP3,6,C4,C15,C1,1
0005fa74 : 6e617473 : MCRVS CP4,3,R7,C1,C3,3
0005fa78 : 4f0d7374 : SWIMI &0D7374
0005fa7c : 43454a42 : MOVTMI R4,#&5A42 ; ARMv6T2 or later
0005fa80 : 00000d54 : ANDEQ R0,R0,R4,ASR R13
0005fa84 : 00000000 : ANDEQ R0,R0,R0
0005fa88 : 00000000 : ANDEQ R0,R0,R0
0005fa8c : 00000000 : ANDEQ R0,R0,R0

R15 = 0005fa58 = +57a58 in application memory
R14_usr = 0005f9c4 = +579c4 in application memory
Function call to 0005fa50 = +57a50 in application memory

USR stack:
00048dcc : 2100000d :
00048dd0 : 0001a00c :
00048dd4 : 616c63a4 :
00048dd8 : 4f286d69 :
00048ddc : 352b254a :
00048de0 : 3a293231 :
00048de4 : 257955e7 :
00048de8 : 8c312d3d :
00048dec : 00008700 :
00048df0 : 00048e1c :
00048df4 : 00000000 :
00048df8 : 00008100 :
00048dfc : 00015b35 :
00048e00 : fc1afb88 :
00048e04 : 00000000 :
00048e08 : 00008700 :
00048e0c : 0000003a :
00048e10 : 00015b35 :
00048e14 : 00015b35 :
00048e18 : fc1afb1c : – fc1afb20 return to fc1afb1c?
: : | fc1afb20 = BASIC +9068
: : | = CALLARMROUT +0
: : | fc1afb1c = BASIC +9064
: : | = CALLARMGO +4
00048e1c : 000000f2 :
00048e20 : 00013d5f :
00048e24 : 00013d53 :
00048e28 : 0002710a :
00048e2c : 00000005 :
00048e30 : 00000000 :
00048e34 : 00000000 :
00048e38 : 000270fa :
00048e3c : 00000005 :
00048e40 : 00000000 :
00048e44 : 00000000 :
00048e48 : 000270ea :
00048e4c : 00000005 :
00048e50 : 00000000 :
00048e54 : 00000000 :
00048e58 : 000270da :
00048e5c : 00000005 :
00048e60 : 00000000 :
00048e64 : 00000000 :
00048e68 : 000270c8 :
00048e6c : 00000005 :
00048e70 : 00000000 :
00048e74 : 00000000 :
00048e78 : 000270b8 :
00048e7c : 00000005 :
00048e80 : 00000000 :
00048e84 : 00000000 :
00048e88 : 000270aa :
00048e8c : 00000005 :
00048e90 : 00000000 :
00048e94 : 00000000 :
00048e98 : 00027096 :
00048e9c : 00000005 :
00048ea0 : 00000000 :
00048ea4 : 00000000 :
00048ea8 : 00027084 :
00048eac : 00000005 :
00048eb0 : 00000000 :
00048eb4 : 00000000 :
00048eb8 : 00027076 :
00048ebc : 00000005 :
00048ec0 : 00000000 :
00048ec4 : 00000000 :
00048ec8 : 00027067 :
00048ecc : 00000005 :
00048ed0 : 00000000 :
00048ed4 : 00000000 :
00048ed8 : 0002705c :
00048edc : 00000004 :
00048ee0 : 00000000 :
00048ee4 : 00027050 :
00048ee8 : 00000004 :
00048eec : 00000000 :
00048ef0 : 00027044 :
00048ef4 : 00000004 :
00048ef8 : 00000000 :
00048efc : 0001c648 :
00048f00 : 00000004 :
00048f04 : 00000000 :
00048f08 : 00027034 :
00048f0c : 00000004 :
00048f10 : 00000000 :
00048f14 : 0001c784 :
00048f18 : 00000004 :
00048f1c : 00000000 :
00048f20 : 00000000 :
00048f24 : 000000f2 :
00048f28 : 000133c1 :
00048f2c : 000133bd :
00048f30 : 0001bf74 :
00048f34 : 00000080 :
00048f38 : 00008100 :
00048f3c : 0001bf60 :
00048f40 : 00000080 :
00048f44 : 00008100 :
00048f48 : 0001bf54 :
00048f4c : 00000004 :
00048f50 : 00000000 :
00048f54 : 0001bf44 :
00048f58 : 00000004 :
00048f5c : 00000000 :
00048f60 : 0001bf31 :
00048f64 : 00000080 :
00048f68 : 00008100 :
00048f6c : 0001bf24 :
00048f70 : 00000004 :
00048f74 : 00000000 :
00048f78 : 0001bef0 :
00048f7c : 00000004 :
00048f80 : 00000000 :
00048f84 : 0001bf14 :
00048f88 : 00000004 :
00048f8c : 00000000 :
00048f90 : 00000000 :
00048f94 : 000000f2 :
00048f98 : 0000918e :
00048f9c : 00009177 :
00048fa0 : 0001bef0 :
00048fa4 : 00000004 :
00048fa8 : 00000000 :
00048fac : 0001bedf :
00048fb0 : 00000005 :
00048fb4 : 00000000 :
00048fb8 : 00000000 :
00048fbc : c001bed0 :
00048fc0 : 0001bea8 :
00048fc4 : 00008100 :
00048fc8 : 00008100 :
00048fcc : 00008100 :
00048fd0 : 00000000 :
00048fd4 : 00000000 :
00048fd8 : 00000000 :
00048fdc : 0004b000 :
00048fe0 : 0001a388 :
00048fe4 : 0000004a :
00048fe8 : 00000000 :
00048fec : 00000000 :
00048ff0 : 0001a360 :
00048ff4 : fc1aa188 : – fc1aab04 return to fc1aa188?
: : | fc1aab04 = BASIC +404c
: : | = FACTOR +0
: : | fc1aa188 = BASIC +36d0
: : | = EXPRBLNK +0
00048ff8 : 00008700 :
00048ffc : 40000000 :
00049000 : 70616548 :
00049004 : 00006fb4 :
00049008 : 00017968 :
0004900c : 00019000 :
00049010 : 00000094 :
00049014 : e890003c :
00049018 : e89103c0 :
0004901c : e1520008 :
00049020 : aa000004 :
00049024 : e1560004 :
00049028 : aa000002 :
0004902c : e1530009 :
00049030 : aa000000 :
00049034 : e1570005 :
00049038 : a3a00000 :
0004903c : e1a0f00e :
00049040 : 00000000 :
00049044 : 00000000 :
00049048 : 00000000 :
0004904c : 00000000 :
00049050 : 00000000 :
00049054 : 00000000 :
00049058 : 00000000 :
0004905c : 00000000 :
00049060 : 00000000 :
00049064 : 00000000 :
00049068 : 00000000 :
0004906c : 00000000 :
00049070 : 00000000 :
00049074 : 00000000 :
00049078 : 00000000 :
0004907c : 00000000 :
00049080 : 00000000 :
00049084 : 00000000 :
00049088 : 00000000 :
0004908c : 00000000 :
00049090 : 00000000 :
00049094 : 00000000 :
00049098 : 00000000 :
0004909c : 00000000 :
000490a0 : 00000000 :
000490a4 : 00006f14 :
000490a8 : 00006f0c :
000490ac : 0000000d :
000490b0 : 00000010 :
000490b4 : 00006f0c :
000490b8 : 000001cc :
000490bc : 6f666562 :
000490c0 : 00006572 :
000490c4 : 00000000 :
000490c8 : 00000003 :
000490cc : 00000019 :
000490d0 : 00000000 :
000490d4 : 00000007 :
000490d8 : 0000002c :
000490dc : 0000002c :
000490e0 : 0000001b :
000490e4 : 00000000 :
000490e8 : 00000000 :
000490ec : 00000000 :
000490f0 : 00000020 :
000490f4 : 00000000 :
000490f8 : 00000000 :
000490fc : 00000000 :
00049100 : 00000042 :
00049104 : 11111100 :
00049108 : 11111111 :
0004910c : 11111111 :
00049110 : 00000044 :
00049114 : 11111100 :
00049118 : 11111111 :
0004911c : 11111111 :
00049120 : 00000044 :
00049124 : 88111100 :
00049128 : 11111111 :
0004912c : 11111181 :
00049130 : 00000044 :
00049134 : 88111100 :
00049138 : 11111111 :
0004913c : 11111f8f :
00049140 : 00000044 :
00049144 : 88111100 :
00049148 : 11111111 :
0004914c : 11111888 :
00049150 : 00000044 :
00049154 : 88f11100 :
00049158 : f111111f :
0004915c : 1111f888 :
00049160 : 00000044 :
00049164 : 88888100 :
00049168 : 81111888 :
0004916c : 11118888 :
00049170 : 00000044 :
00049174 : 88888100 :
00049178 : 8f111888 :
0004917c : 111f8888 :
00049180 : 00000044 :
00049184 : 88f11100 :
00049188 : 8811111f :
0004918c : 11188888 :
00049190 : 00000044 :
00049194 : 88111100 :
00049198 : 88f11111 :
0004919c : 11f88888 :
000491a0 : 00000044 :
000491a4 : 88111100 :
000491a8 : 88811111 :
000491ac : 11888888 :
000491b0 : 00000044 :
000491b4 : 88111100 :
000491b8 : 88811111 :
000491bc : 11888888 :
000491c0 : 00000044 :
000491c4 : 11111100 :
000491c8 : f1111111 :

WimpWorks V2.38 Nutpi doesn’t work with ROM 5.23(18-Sep-16).

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)

WimpWorks V2.38 Nutpi doesn’t work with ROM 5.23(18-Sep-16).

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.