Important software compatibility notice

So you need to replace

Of course. Sorry about that.

why is PhotoFiler looking at the current task handle?

It wants to know if the current task is the Filer. It sets up filters to modify some filer actions – notably the creation and deletion of windows and the plotting of icons.

Would it be possible to modify the ZeroPain module so that it would run on an older Rom (ie using un-relocated zero page) so that it would log and allow zero page accesses? As a small-time developer, it would make it much easier to track down any small problems if I could run it on my (stable) RO5.22 machine (which I do not want to update to a non-stable development ROM).

I’m afraid not. You’d be able to get some test coverage by making the area inaccessible to user mode, but that wouldn’t help test for privileged code reading/writing to it. You’d probably also get a lot of false-positives from user-mode code attempting to legitimately read form zero page (e.g. things like the OS_ChangedBox buffer are stored there)

With ZeroPain running my Iyonix is stable enough for me to use it for day-to-day development (running Norcroft, Netsurf, StrongED, PDF, Sunfish). The biggest problem I’m seeing is that Sunfish crashes when dismounting mounts. I don’t think I’ve tried GCC but I’d expect it to be fine, considering it’s a unix port. Maybe install the new ROM on a spare SD card, or have two ROMs on the one card and swap between them by renaming?

it would make it much easier to track down any small problems if I could run it on my (stable) RO5.22 machine

You could try using Prot1K from Adrian Lees instead.

The latest ROM for the BB -xM seems to have broken alt-click on filer icon text. The writable text box opens & immediately closes. A new ZeroPain generated immediately after shows;

Time: Tue Jul 7 17:33:47 2015
Location: Application space
Current Wimp task: NetSurf
Last app to start: Filer_Action

R0 = 0066b190 R1 = 0050899c R2 = 006b0c3c R3 = 00000000
R4 = 00000000 R5 = 000dbba0 R6 = 00011170 R7 = 000001bb
R8 = 00000014 R9 = 00000000 R10 = 006b0208 R11 = 006b0c10
R12 = 006b0a2c R13 = 006b0a2c R14 = 0049ecb0 R15 = 0049ecb8
DFAR = 00000024 Mode USR32 Flags nZCv if PSR = 60000110

0049ec70 : e92ddaf0 : STMDB R13!,{R4-R7,R9,R11,R12,R14,PC}
0049ec74 : e24cb004 : SUB R11,R12,#4
0049ec78 : e24dcf71 : SUB R12,R13,#&01C4 ; =452
0049ec7c : e15c000a : CMP R12,R10
0049ec80 : bb0027e1 : BLLT &004A8C0C
0049ec84 : e59f3f8c : LDR R3,&0049FC18
0049ec88 : e24ddf71 : SUB R13,R13,#&01C4 ; =452
0049ec8c : e5933048 : LDR R3,[R3,#72]
0049ec90 : e3530000 : CMP R3,#0
0049ec94 : e1a09000 : MOV R9,R0
0049ec98 : e58d118c : STR R1,[R13,#396]
0049ec9c : e58d215c : STR R2,[R13,#348]
0049eca0 : 1a0000a7 : BNE &0049EF44
0049eca4 : e3a04000 : MOV R4,#0
0049eca8 : e5cd4136 : STRB R4,[R13,#310]
0049ecac : ebffb1b0 : BL &0048B374
0049ecb0 * e5d93024 * LDRB R3,[R9,#36]
0049ecb4 : e5900000 : LDR R0,[R0,#0]
0049ecb8 : e3130002 : TST R3,#2
0049ecbc : e58d0198 : STR R0,[R13,#408]
0049ecc0 : 0a000714 : BEQ &004A0918
0049ecc4 : e58d4160 : STR R4,[R13,#352]
0049ecc8 : e58d4124 : STR R4,[R13,#292]
0049eccc : e58d40fc : STR R4,[R13,#252]
0049ecd0 : e58d40f8 : STR R4,[R13,#248]
0049ecd4 : e59d415c : LDR R4,[R13,#348]
0049ecd8 : e59d518c : LDR R5,[R13,#396]
0049ecdc : e28d00b4 : ADD R0,R13,#&B4 ; =“¥”
0049ece0 : e58d41a0 : STR R4,[R13,#416]
0049ece4 : e3a0c001 : MOV R12,#1
0049ece8 : e3a04000 : MOV R4,#0
0049ecec : e58d00f4 : STR R0,[R13,#244]

Time: Tue Jul 7 17:33:47 2015
Location: Application space
Current Wimp task: NetSurf
Last app to start: Filer_Action

R0 = 0066b190 R1 = 004ef5c0 R2 = 006b0c8c R3 = 00000000
R4 = 00000000 R5 = 000dbba0 R6 = 00011170 R7 = 000001bb
R8 = 00000014 R9 = 00000000 R10 = 006b0208 R11 = 006b0c30
R12 = 006b0a4c R13 = 006b0a4c R14 = 0049ecb0 R15 = 0049ecb8
DFAR = 00000024 Mode USR32 Flags nZCv if PSR = 60000110

0049ec70 : e92ddaf0 : STMDB R13!,{R4-R7,R9,R11,R12,R14,PC}
0049ec74 : e24cb004 : SUB R11,R12,#4
0049ec78 : e24dcf71 : SUB R12,R13,#&01C4 ; =452
0049ec7c : e15c000a : CMP R12,R10
0049ec80 : bb0027e1 : BLLT &004A8C0C
0049ec84 : e59f3f8c : LDR R3,&0049FC18
0049ec88 : e24ddf71 : SUB R13,R13,#&01C4 ; =452
0049ec8c : e5933048 : LDR R3,[R3,#72]
0049ec90 : e3530000 : CMP R3,#0
0049ec94 : e1a09000 : MOV R9,R0
0049ec98 : e58d118c : STR R1,[R13,#396]
0049ec9c : e58d215c : STR R2,[R13,#348]
0049eca0 : 1a0000a7 : BNE &0049EF44
0049eca4 : e3a04000 : MOV R4,#0
0049eca8 : e5cd4136 : STRB R4,[R13,#310]
0049ecac : ebffb1b0 : BL &0048B374
0049ecb0 * e5d93024 * LDRB R3,[R9,#36]
0049ecb4 : e5900000 : LDR R0,[R0,#0]
0049ecb8 : e3130002 : TST R3,#2
0049ecbc : e58d0198 : STR R0,[R13,#408]
0049ecc0 : 0a000714 : BEQ &004A0918
0049ecc4 : e58d4160 : STR R4,[R13,#352]
0049ecc8 : e58d4124 : STR R4,[R13,#292]
0049eccc : e58d40fc : STR R4,[R13,#252]
0049ecd0 : e58d40f8 : STR R4,[R13,#248]
0049ecd4 : e59d415c : LDR R4,[R13,#348]
0049ecd8 : e59d518c : LDR R5,[R13,#396]
0049ecdc : e28d00b4 : ADD R0,R13,#&B4 ; =“¥”
0049ece0 : e58d41a0 : STR R4,[R13,#416]
0049ece4 : e3a0c001 : MOV R12,#1
0049ece8 : e3a04000 : MOV R4,#0
0049ecec : e58d00f4 : STR R0,[R13,#244]

Time: Tue Jul 7 17:33:47 2015
Location: Application space
Current Wimp task: NetSurf
Last app to start: Filer_Action

R0 = 0000000a R1 = 00000000 R2 = 006b0c8c R3 = 00000000
R4 = 00000000 R5 = 006a93d8 R6 = 0000000a R7 = 000001bb
R8 = 00000014 R9 = 00501b24 R10 = 006b0208 R11 = 006b0c40
R12 = 006b0c44 R13 = 006b0c28 R14 = 000edb60 R15 = 0049c174
DFAR = 00000000 Mode USR32 Flags nZCv if PSR = 60000110

0049c12c : e91ba800 : LDMDB R11,{R11,R13,PC}
0049c130 : 006a9320 : RSBEQ R9,R10,R0,LSR #6
0049c134 : 74757066 : LDRVCBT R7,[R5],#-102
0049c138 : 00000063 : ANDEQ R0,R0,R3,RRX
0049c13c : ff000008 : Undefined instruction
0049c140 : e1a0c00d : MOV R12,R13
0049c144 : e92dd870 : STMDB R13!,{R4-R6,R11,R12,R14,PC}
0049c148 : e24cb004 : SUB R11,R12,#4
0049c14c : e15d000a : CMP R13,R10
0049c150 : bb0032a3 : BLLT &004A8BE4
0049c154 : e59f5098 : LDR R5,&0049C1F4
0049c158 : e5953048 : LDR R3,[R5,#72]
0049c15c : e3530000 : CMP R3,#0
0049c160 : e1a06000 : MOV R6,R0
0049c164 : e1a04001 : MOV R4,R1
0049c168 : 1a000016 : BNE &0049C1C8
0049c16c * e5943000 * LDR R3,[R4,#0]
0049c170 : e35304fe : CMP R3,#&FE000000
0049c174 : 1a000015 : BNE &0049C1D0
0049c178 : e5d43030 : LDRB R3,[R4,#48]
0049c17c : e3130020 : TST R3,#&20 ; =" "
0049c180 : e20600ff : AND R0,R6,#&FF ; =“ˇ”
0049c184 : 1a000008 : BNE &0049C1AC
0049c188 : e5943018 : LDR R3,[R4,#24]
0049c18c : e2433001 : SUB R3,R3,#1
0049c190 : e3530000 : CMP R3,#0
0049c194 : e5843018 : STR R3,[R4,#24]
0049c198 : da000007 : BLE &0049C1BC
0049c19c : e5943010 : LDR R3,[R4,#16]
0049c1a0 : e4c30001 : STRB R0,[R3],#1
0049c1a4 : e5843010 : STR R3,[R4,#16]
0049c1a8 : e91ba870 : LDMDB R11,{R4-R6,R11,R13,PC}

@Jeffrey: Thanks, I suspected that would be the case, but I thought it best to get confirmation. I am currently softloading v5.22, so when I flash that I can then softload the new ROM more easily.

@Michael: Yes, I am using Prot1k … but it makes things (including Zap!) fail rather than logging, which is not desirable while developing. I have not found an UnProt1k, so I have rebooted several times today! And it is only 1k, not the full 4k.

I have made progress with the small problems with Organizer and Reporter – if anyone has been affected please let me know by email to the support address, with the version.

@Michael: Yes, I am using Prot1k … but it makes things (including Zap!) fail rather than logging, which is not desirable while developing. I have not found an UnProt1k, so I have rebooted several times today! And it is only 1k, not the full 4k.

I think the problem with Prot1k and ZeroPain is that ZeroPain does a check on startup using OS_Memory 24 to work out whether the first 16K of memory is user-readable or not. However for performance OS_Memory 24 doesn’t actually check the page tables for most areas – instead it just relies on the DA flags, or for non-DA areas it uses the hardcoded permissions that the OS applies to the area. Plus the OS doesn’t really understand the sub-page attributes, so even if it did check the page tables it might not spot that Prot1k has been fiddling with them.

If you recompile ZeroPain without the OS_Memory 24 check then it should run just fine, but since Prot1k only provides partial protection to zero page I’d say it’s still best to test on a real zero page relocation ROM.

Phase 2 of the testing process is due to begin on 1st Jan, 2016. ZeroPain will refuse to run on any ROM built on or after that date.

Is ZeroPain’s source in the repo? I hope so. The first thing I’ll need to do is to disable the timeout – perhaps the only way to keep Zap working. ;-)
Though it looks like an errant null reference, given that DFAR is zero and the Zap module is trying to LDR it? It happens twice at offset +&3235C when Zap (module) is loading, and several times reading address &14 at offset +&2E910 when a window is opened (the faulting instruction is “LDR R2,[R3,#16]”).

Starting the display configuration tool throws many errors in the International module (but then so does opening a TaskWindow, so…).

The first thing I’ll need to do is to disable the timeout – perhaps the only way to keep Zap working. ;-)

Well the source is available is it not?
Or, you could, you know, like, er, use a different editor…

Phase 2 of the testing process is due to begin on 1st Jan, 2016. ZeroPain will refuse to run on any ROM built on or after that date.

Is ZeroPain’s source in the repo? I hope so. The first thing I’ll need to do is to disable the timeout – perhaps the only way to keep Zap working. ;-)

Yes, the source is in CVS.

At some point we’ll probably have to put together a plan for how to support unmaintained software – probably a patcher of some kind, as that’s pretty much always going to be better than emulating the old behaviour (even if the emulation was only enabled for specific apps).

Well the source is available is it not?

It may come to that…
However, as countless cock-ups of far greater magnitude ought to have demonstrated (Shellshock, Heartbleed, etc), there is a big difference between having the source and knowing what to do with it.

Or, you could, you know, like, er, use a different editor…

When I find an editor that does the ancillary stuff that Zap does for me, that would be a start.
StrongEd – Can I change the font and the colours easily? I didn’t see this in the menus. Can it extract application workspace from a running application? Or modules/workspace directly from memory?
I’m not trying to find esoteric features, these are things that I use.

SystemDisc and NewsUK are two things affected by this change too. I’m unsure how or why NewsUK is affected, my guess was the FPEmulator but there are fixes for that…
I’ve got the ROM dated the 5th (I just downloaded it)

Time: Tue Jul 7 20:07:36 2015
Location: Offset 00001b64 in module Window
Current Wimp task: NewsUK
Last app to start: <NewsUK$Dir>.!RunImage

R0 = fa207fc0 R1 = 00019458 R2 = fb4077fc R3 = 0002c84c
R4 = fa207fbc R5 = 00000000 R6 = 00000028 R7 = 00000000
R8 = a0000113 R9 = 00019424 R10 = fa20021c R11 = fa207f94
R12 = fa207f98 R13 = fa207f78 R14 = fc41b784 R15 = fc41c390
DFAR = 00000028 Mode SVC32 Flags nZCv if PSR = 60000113

fc41c348 : e59f1014 : LDR R1,&FC41C364
fc41c34c : e51a2218 : LDR R2,[R10,#-536]
fc41c350 : e0822001 : ADD R2,R2,R1
fc41c354 : e7923103 : LDR R3,[R2,R3,LSL #2]
fc41c358 : e0831000 : ADD R1,R3,R0
fc41c35c : e2810024 : ADD R0,R1,#&24 ; =“$”
fc41c360 : e1a0f00e : MOV PC,R14
fc41c364 : fc428380 : MCRR2 CP3,8,R8,R2,C0 ; ARMv6 or later
fc41c368 : e1a0c00d : MOV R12,R13
fc41c36c : e92dd8f0 : STMDB R13!,{R4-R7,R11,R12,R14,PC}
fc41c370 : e1a04000 : MOV R4,R0
fc41c374 : e5b01004 : LDR R1,[R0,#4]!
fc41c378 : e24cb004 : SUB R11,R12,#4
fc41c37c : e3a05000 : MOV R5,#0
fc41c380 : e5b1701c : LDR R7,[R1,#28]!
fc41c384 : e2876028 : ADD R6,R7,#&28 ; =“(”
fc41c388 * e8960044 * LDMIA R6,{R2,R6}
fc41c38c : e3520000 : CMP R2,#0
fc41c390 : da00000f : BLE &FC41C3D4
fc41c394 : e1a00006 : MOV R0,R6
fc41c398 : ebffffe0 : BL &FC41C320
fc41c39c : e5963018 : LDR R3,[R6,#24]
fc41c3a0 : e5941008 : LDR R1,[R4,#8]
fc41c3a4 : e1530001 : CMP R3,R1
fc41c3a8 : 1a000004 : BNE &FC41C3C0
fc41c3ac : e5846000 : STR R6,[R4,#0]
fc41c3b0 : e0400006 : SUB R0,R0,R6
fc41c3b4 : e5a40004 : STR R0,[R4,#4]!
fc41c3b8 : e3a00000 : MOV R0,#0
fc41c3bc : e91ba8f0 : LDMDB R11,{R4-R7,R11,R13,PC}
fc41c3c0 : e1a06000 : MOV R6,R0
fc41c3c4 : e5970028 : LDR R0,[R7,#40]

StrongEd – Can I change the font and the colours easily? I didn’t see this in the menus.

The ‘Tick’ icon on the toolbar opens the configuration windows. A Select click opens the global choices and an Adjust click opens the mode choices. The Colours and Font sections in mode choices are what you need.

Please note that StrongED 4.69f8 only supports bitmap fonts of 8×8 and 8×16. StrongED 4.70a8 supports bitmap fonts of up to 32 pixels wide and any height.

Can it extract application workspace from a running application? Or modules/workspace directly from memory?

Yes. Click Adjust on the iconbar icon to open the modes menu, then click on Dump. The dialogue box that opens, allows you to grab applications, modules, etc.

This ought to be subtitled “Adventures in debugging”.

Here’s some code:

   // Now process the script file
   while ( !feof(scfp) )
   {
      if ( fgets(scrline, 255, scfp) != NULL )
      {
         // remember our position
         scriptstack[stackcount].offset = ftell(scfp);

         // pre-process the line
         Script_TidyLine();

         // pass it to the execution routine
         Script_Execute(scrline, FALSE);
      }
   }

And here’s the compiled result:

|L00019c.J18.Script_Run|
        MOV      a2,#&ff
        LDR      a3,[v2,#&2d4]
        MOV      a1,v1
        BL       fgets
        CMP      a1,#0
        BEQ      |L0001d8.J21.Script_Run|
        LDR      a1,[v2,#&2d4]
        BL       ftell
        LDR      a2,[v2,#&2d0]
        MLA      a2,v4,a2,v6
        STR      a1,[a2,#&40]!
        BL       Script_TidyLine
        MOV      a1,v1
        MOV      a2,#0
        BL       Script_Execute
|L0001d8.J21.Script_Run|
        LDR      a2,[v2,#&2d4]
        LDR      a3,[a2,#&c]!
        TST      a3,#&40
        BEQ      |L00019c.J18.Script_Run|
|L0001e8.J19.Script_Run|
        LDMDB    fp,{v1,v2,v4,v6,fp,sp,lr}
        B        Script_Return

What’s this line LDR a3,[a2,#&c]! ? That fails with ZeroPain and causes the program to abort (SigSegV).

Had to revert to my older ROM as the debugger (DDT) crashed instantly on the zero-page-moved ROM. Hmm…

Nicely, a debug build of my code looks utterly different to the non-debug code. There’s no point continuing here, so I’ll build a non-debug version and settype it as DebImage.

Right. On exit from the branch, register R5 is &1694C. The instruction to load R1 from R5+#724 sets R1 to &1CBE8. The next instruction, to load R2 from R1+#12 (with writeback?) sets R2 to be &421905.
This code is called again, and R5 is again &1694C, however this time R1 is subsequently set to ZERO. This will be where the fault is happening.
Strangely enough, the debugger (usefully!) does not fault memory accesses of that sort, as it will quite clearly be reading from somewhere it shouldn’t. I don’t seem to be able to get the debugger to break on accesses to that address either (is this possible?). I’m setting a watchpoint on address &12 with a trace on watchpoints; but then listing watchpoints says “No watchpoints set”. HUH?

Ah. Wow.
Through many MANY iterations of switching between source code and disassembly – which DDT makes rather painful, if you are single-stepping by ARM instruction, might it be useful to NOT keep reverting to displaying source code display?
Anyway, found that there is a time when the file handle can be zero (a bug in my code, but frankly I’m unhappy with that whole nested scripts thing and plan to rewrite a lot of it – much to use memory buffers and not keep reading stuff from files) and since parts of CLib are a bit poo, it looks as if feof() is converted into an inlined bit of code to read a bit of memory with no attempt to validate the input. Especially amusing since if the file handle is NULL, you’ll end up reading one of the hardware vectors and god only knows what will be the result. ;-)

Oh. Holy Hell. This is an embarrassingly STUPID fail. So I’m stepping though the script commands, right? And one of them is the command to call a menu. Now menus replace scripts. So what it does is to tidily exit the script processing and close the file. We jump through all the hoops involved in loading a menu (which can include sub-scripts). Then once that is done, we fall back to the callee routine, the original script loop, which promptly chokes because its file handle has been nuked. Only it works fine on older RISC OS (just reads junk from the processor vectors ;-) ).

The “fix”?

For now, change this:

         // pass it to the execution routine
         Script_Execute(scrline, FALSE);
      }
   }

to this:

         // pass it to the execution routine
         Script_Execute(scrline, FALSE);

         // trap if MENU command shut us down
         if (scfp == NULL)
            return; // nothing more we can do here
                    // (and we will already have been Returned)
      }
   }

Lessons and morals:

• Debugging sucks.
• DDT sucks a bit too.
  • Why does DDT keep reverting to source code view?
  • DDT ought to fault accesses to memory that is normally off limits to a user mode program (regardless of whether or not the memory can actually be read).
  • DDT needs to have a way to remember recently typed expressions; or be able to accept a comma separated list of variables to list them all (or maybe it can and the syntax is just unexpected?).
• That the dev tools choke with ZeroPain is kind of funny. It makes me feel better about my stupid fail.
• Note to self – use OS file routines with veneer code in preference to CLib file routines. I have experienced nothing but pain with CLib’s ones, mostly due to a complete inability to bother validating input. Remember I said about how the machine would stiff? That was fgets (I think?) when given a junk file handle.
• Debugging sucks. I thought I’d mention that twice, because writing code is the fun part. Debugging said code (especially if you realise you were running on recycled tea bags when you wrote the code) is the programmer equivalent of sticking pins into various parts of the anatomy. Not something you do “for the lulz”.
• Side effects of messing with module-scope variables can be…unpleasant.

Phew. Still, the thing is working now. ZeroPain had no complaints.

an Adjust click opens the mode choices. The Colours and Font sections in mode choices are what you need.

Ah, thanks for that.
Looks like Kappa is the closest equivalent to what I’m using with Zap.

Please note that StrongED 4.69f8

Hmmm, mine’s 4.69b5. ;-)

Is it possible to:

• Automatically switch to ASM display for code files (module, absolute, etc)?
• Turn off that blinking red highlight?
• Colourise code depending on what the element is, rather than just what the instruction is?
  For example, the line “LDMIA R13!,{R0-R11,PC}” would be displayed in StrongEd as mid-grey on black (as that’s the closest I could seem to get). In Zap, it is: “[mid grey]LDMIA [cream]R13[white]![dark grey]{[cream]R0[white]-[cream]R11[white],[cream]PC[dark grey]}”

I find it easier to read the component-colourised code, for instance the white ‘!’ for writeback stands out, while the generic parameter wrappers {} being darker grey are present, but don’t detract from that which is important, the registers. The registers (and (C/S)PSR) are uniquely cream. SWI numbers (or names) and branch addresses are uniquely orange. SWI instructions are uniquely cyan. Load/store instructions are mid grey, branches a darker grey, and generic instructions (the “anything else category”) are white, execept co-processor stuff which is uniquely dark blue. Comments are green and italicised, and condition codes (when specified) are underlined. Undefined instructions are red and italicised.

I notice also that when reading a module from memory, the address on the left shows the last four digits of the address and all of the link addresses are absolute. For example, the first branch of the ZeroPain init code in Zap is BL &00001A00 while StrongEd shows it as BL &201DC734. Is it possible to change the addresses to be relative to the start of the code?

Yes. Click Adjust on the iconbar icon to open the modes menu, then click on Dump. The dialogue box that opens, allows you to grab applications, modules, etc.

Mmm, nice touch, separating RAM and ROM modules. I like that.

Looks like Kappa is the closest equivalent to what I’m using with Zap.

Excellent – that’s all of my own creation, but a long time ago. It gives me an excuse to come in as a user and reassure you that StrongED will do all that you want, so far, but you might have to investigate modifying a mode file or two if you have exacting requirements. No doubt you did something like that during your use of Zap.

Automatically switch to ASM display for code files (module, absolute, etc)?

Yes. That is decided by a rule in the modewhen file and is the default. For typed files it is straightforward, but the mode can be forced by a header line at the start of a file if necessary.

Turn off that blinking red highlight? [caret/cursor?]

Just an option in choices. I have not had it flashing for a couple of decades. ;-)

Colourise code depending on what the element is, rather than just what the instruction is?

I have used my own colour scheme for so long I have forgotten what comes as standard, but that does require some setting up. The more recent versions make this much more flexible.

@Rick

I’ve created a new thread StrongED queries in the General section to continue this discussion so that this thread can stay focused on ZeroPain and zero page access.

Last app to start: <Obey$Dir>.SetHome Obey$Dir
bq. That is !UnixHome, the SetHome absolute just needs a recompile, source is included in the UnixHome application.

I’ve recompiled it an uploaded the new version to the packages section of www.riscos.info, you can download the zip file from:
http://www.riscos.info/packages/SupportDetails.html#UnixHome
Or you can get it with PackMan.

Looks like WeatherUK 1.01, DDEUtils 1.73 and FTPc 1.48 (7 Dec 2011) have ZeroPain issues.

That’s my first ZeroPain PipeDream bug fixed! Nasty timing-dependent one too, in chart file reloading. Would have really helped to have a debugger that worked (see Rick’s post)…

4.53/02 should be making its way over via PackMan soon.

The zero page relocation is a very good thing, even if it does stop us using the old trick of STR Rm,[Rn,-Rn] (Rn!=PC) that has come in oh-so-handy in years gone by when debugging interrupt code.

FileSwitch pain.

Time: Thu Jul  9 16:37:14 2015
Location: Offset 0000c84c in module FileSwitch
Current Wimp task: NetSurf
Last app to start: BASIC -quit "SDFS::RISCOSpi.$.Library.GoToWork2"

R0  = 00000005 R1  = fb415ea4 R2  = 00000000 R3  = 00000060
R4  = fa207f7c R5  = 00000000 R6  = 00000000 R7  = fa207dfc
R8  = fa207dac R9  = fb413dc4 R10 = fb4157f0 R11 = fa207fb4
R12 = 200001d4 R13 = fa207d30 R14 = 00000002 R15 = fc051d70
DFAR = 00000000  Mode SVC32  Flags nzcv if   PSR = 00000113

fc051d28 : e31e0501 : TST     R14,#&00400000
fc051d2c : 0a000002 : BEQ     &FC051D3C
fc051d30 : e49de004 : LDR     R14,[R13],#4
fc051d34 : e128f00e : MSR     CPSR_f,R14
fc051d38 : e8bd8006 : LDMIA   R13!,{R1,R2,PC}
fc051d3c : e20ee0ff : AND     R14,R14,#&FF       ; ="ˇ"
fc051d40 : e24f20a8 : ADR     R2,&FC051CA0
fc051d44 : e7d221ae : LDRB    R2,[R2,R14,LSR #3]
fc051d48 : e20ee007 : AND     R14,R14,#7
fc051d4c : e1a02e32 : MOV     R2,R2,LSR R14
fc051d50 : e3120001 : TST     R2,#1
fc051d54 : 1a000002 : BNE     &FC051D64
fc051d58 : e49de004 : LDR     R14,[R13],#4
fc051d5c : e128f00e : MSR     CPSR_f,R14
fc051d60 : e8bd8006 : LDMIA   R13!,{R1,R2,PC}
fc051d64 : e51b2040 : LDR     R2,[R11,#-64]
fc051d68 * e4d2e001 * LDRB    R14,[R2],#1
fc051d6c : e4d2e001 : LDRB    R14,[R2],#1
fc051d70 : e33e0024 : TEQ     R14,#&24           ; ="$"
fc051d74 : 1a000002 : BNE     &FC051D84
fc051d78 : e49de004 : LDR     R14,[R13],#4
fc051d7c : e128f00e : MSR     CPSR_f,R14
fc051d80 : e8bd8006 : LDMIA   R13!,{R1,R2,PC}
fc051d84 : e33e0000 : TEQ     R14,#0
fc051d88 : 1afffff7 : BNE     &FC051D6C
fc051d8c : e4d1e001 : LDRB    R14,[R1],#1
fc051d90 : e33e0000 : TEQ     R14,#0
fc051d94 : 1a000002 : BNE     &FC051DA4
fc051d98 : e49de004 : LDR     R14,[R13],#4
fc051d9c : e128f00e : MSR     CPSR_f,R14
fc051da0 : e8bd8006 : LDMIA   R13!,{R1,R2,PC}
fc051da4 : e33e0024 : TEQ     R14,#&24           ; ="$"

--------------------------------------------------------------------------------

Time: Thu Jul  9 16:37:14 2015
Location: Offset 0000c850 in module FileSwitch
Current Wimp task: NetSurf
Last app to start: BASIC -quit "SDFS::RISCOSpi.$.Library.GoToWork2"

R0  = 00000005 R1  = fb415ea4 R2  = 00000001 R3  = 00000060
R4  = fa207f7c R5  = 00000000 R6  = 00000000 R7  = fa207dfc
R8  = fa207dac R9  = fb413dc4 R10 = fb4157f0 R11 = fa207fb4
R12 = 200001d4 R13 = fa207d30 R14 = 00000000 R15 = fc051d74
DFAR = 00000001  Mode SVC32  Flags nzcv if   PSR = 00000113

fc051d2c : 0a000002 : BEQ     &FC051D3C
fc051d30 : e49de004 : LDR     R14,[R13],#4
fc051d34 : e128f00e : MSR     CPSR_f,R14
fc051d38 : e8bd8006 : LDMIA   R13!,{R1,R2,PC}
fc051d3c : e20ee0ff : AND     R14,R14,#&FF       ; ="ˇ"
fc051d40 : e24f20a8 : ADR     R2,&FC051CA0
fc051d44 : e7d221ae : LDRB    R2,[R2,R14,LSR #3]
fc051d48 : e20ee007 : AND     R14,R14,#7
fc051d4c : e1a02e32 : MOV     R2,R2,LSR R14
fc051d50 : e3120001 : TST     R2,#1
fc051d54 : 1a000002 : BNE     &FC051D64
fc051d58 : e49de004 : LDR     R14,[R13],#4
fc051d5c : e128f00e : MSR     CPSR_f,R14
fc051d60 : e8bd8006 : LDMIA   R13!,{R1,R2,PC}
fc051d64 : e51b2040 : LDR     R2,[R11,#-64]
fc051d68 : e4d2e001 : LDRB    R14,[R2],#1
fc051d6c * e4d2e001 * LDRB    R14,[R2],#1
fc051d70 : e33e0024 : TEQ     R14,#&24           ; ="$"
fc051d74 : 1a000002 : BNE     &FC051D84
fc051d78 : e49de004 : LDR     R14,[R13],#4
fc051d7c : e128f00e : MSR     CPSR_f,R14
fc051d80 : e8bd8006 : LDMIA   R13!,{R1,R2,PC}
fc051d84 : e33e0000 : TEQ     R14,#0
fc051d88 : 1afffff7 : BNE     &FC051D6C
fc051d8c : e4d1e001 : LDRB    R14,[R1],#1
fc051d90 : e33e0000 : TEQ     R14,#0
fc051d94 : 1a000002 : BNE     &FC051DA4
fc051d98 : e49de004 : LDR     R14,[R13],#4
fc051d9c : e128f00e : MSR     CPSR_f,R14
fc051da0 : e8bd8006 : LDMIA   R13!,{R1,R2,PC}
fc051da4 : e33e0024 : TEQ     R14,#&24           ; ="$"
fc051da8 : 1afffff7 : BNE     &FC051D8C

--------------------------------------------------------------------------------

Time: Thu Jul  9 16:37:14 2015
Location: Offset 0000c934 in module FileSwitch
Current Wimp task: NetSurf
Last app to start: BASIC -quit "SDFS::RISCOSpi.$.Library.GoToWork2"

R0  = 00000001 R1  = fb415ea4 R2  = 00000000 R3  = e08ba058
R4  = 0009a066 R5  = 00000033 R6  = 00000000 R7  = fa207dfc
R8  = 0000001c R9  = fb413dc4 R10 = fb4157f0 R11 = fa207fb4
R12 = 200001d4 R13 = fa207d2c R14 = 00000002 R15 = fc051e58
DFAR = 00000000  Mode SVC32  Flags nzCv if   PSR = 20000113

fc051e10 : 028dd004 : ADDEQ   R13,R13,#4
fc051e14 : 08bd800e : LDMEQIA R13!,{R1-R3,PC}
fc051e18 : e31e0501 : TST     R14,#&00400000
fc051e1c : 128dd004 : ADDNE   R13,R13,#4
fc051e20 : 18bd800e : LDMNEIA R13!,{R1-R3,PC}
fc051e24 : e20ee0ff : AND     R14,R14,#&FF       ; ="ˇ"
fc051e28 : e24f2e19 : ADR     R2,&FC051CA0
fc051e2c : e7d221ae : LDRB    R2,[R2,R14,LSR #3]
fc051e30 : e20ee007 : AND     R14,R14,#7
fc051e34 : e1b02e32 : MOVS    R2,R2,LSR R14
fc051e38 : e3120001 : TST     R2,#1
fc051e3c : 1a000002 : BNE     &FC051E4C
fc051e40 : e49de004 : LDR     R14,[R13],#4
fc051e44 : e128f00e : MSR     CPSR_f,R14
fc051e48 : e8bd800e : LDMIA   R13!,{R1-R3,PC}
fc051e4c : e51b2040 : LDR     R2,[R11,#-64]
fc051e50 * e4d2e001 * LDRB    R14,[R2],#1
fc051e54 : e33e0024 : TEQ     R14,#&24           ; ="$"
fc051e58 : 1a000002 : BNE     &FC051E68
fc051e5c : e49de004 : LDR     R14,[R13],#4
fc051e60 : e128f00e : MSR     CPSR_f,R14
fc051e64 : e8bd800e : LDMIA   R13!,{R1-R3,PC}
fc051e68 : e33e0000 : TEQ     R14,#0
fc051e6c : 1afffff7 : BNE     &FC051E50
fc051e70 : e5d1e000 : LDRB    R14,[R1,#0]
fc051e74 : e33e003a : TEQ     R14,#&3A           ; =":"
fc051e78 : 0a000004 : BEQ     &FC051E90
fc051e7c : e33e0024 : TEQ     R14,#&24           ; ="$"
fc051e80 : 1a000008 : BNE     &FC051EA8
fc051e84 : e49de004 : LDR     R14,[R13],#4
fc051e88 : e128f00e : MSR     CPSR_f,R14
fc051e8c : e8bd800e : LDMIA   R13!,{R1-R3,PC}

I have been having problems understanding the debug info below from a users Iyonix, which is running RO5.23 from Jul 5th, with the ZeroPain module. Can anyone explain why the code is aborting, rather than being trapped by ZeroPain because it is (wrongly) reading zero page?

It almost looks as if it has been failed for an unaligned load, as an identical load with r0=8 was just trapped by ZeroPain.

Internal error: abort on data transfer at &FC19694C

Address &FC19694C in Module   BASIC @ &FC1921F8 + &4754
pc  = &FC19694C  Flags=&20000010=nzCv if  Mode=User 32 bit
r0  = &001B 
r1  = &0003 

FC196940 : ANDS    R1,R0,#3
FC196944 > LDMNEIA R0,{R0,R2}
FC196948 : MOVNE   R1,R1,LSL #3
FC19694C : LDREQ   R0,[R0,#0]
FC196950 : R0,R0,LSR R1

Note that the Basic code has been ‘working’ (or not failing, at least) for years, so the abort is an effect of the new ROM.

ZeroPain does work in other cases, but if the culprit program is Basic the logs provide very little help to identify where the problem is.

This, plus the Abort rather than logging, is causing more pain than I expected!

It almost looks as if it has been failed for an unaligned load

Correct. For simplicity I didn’t bother to add support for unaligned loads (except LDRB).

It looks like it’s crashing in VARINT, which I believe is used for the ! operator. But since this is BASIC, I’d expect it to give you a line number of where the problem is.

Correct. For simplicity I didn’t bother to add support for unaligned loads (except LDRB).

So the Iyonix now effectively aborts unaligned loads to ZeroPage?

It looks like it’s crashing in VARINT, which I believe is used for the ! operator.

Yes, that was my suspicion.

But since this is BASIC, I’d expect it to give you a line number of where the problem is.

Indeed it does now for an abort, I just could not understand why it was aborting!
The Readme does not clarify that ZeroPain doen not trap unaligned loads even on processors which allow them, but causes an abort
However, when ZeroPain does trap an access, it does NOT give the Basic line number.

The mixture of ZeroPain traps and aborts was confusing me. I should be less confused now. Thanks. Despite the pain, this is the right thing to do!

Correct. For simplicity I didn’t bother to add support for unaligned loads (except LDRB).

So the Iyonix now effectively aborts unaligned loads to ZeroPage?

Correct.

The Readme does not clarify that ZeroPain doen not trap unaligned loads even on processors which allow them, but causes an abort

Yeah, I can probably improve the wording of that section.

However, when ZeroPain does trap an access, it does NOT give the Basic line number.

I think I’ll look at fixing that, since it does make the current version a bit useless for logging aborts from BASIC.

Correct. For simplicity I didn’t bother to add support for unaligned loads (except LDRB).

I think that is a shame. It means that the Basic statement A% = !B% on a Pi is ZeroPained if B% = 8 or 9 (because the Basic module will not do unaligned loads), but on an Iyonix 8 is ZeroPained and 9 Data Aborts (because the Basic module does do unaligned loads)

it does NOT give the Basic line number….I think I’ll look at fixing that,

That would be useful … but I am sure you are aware of the complications with LIBRARYs!