Has anybody managed to get ZapMJE to compile with the DDE?

(without being specific on the model of Pi)

pretty much all of them

I’ve never seen this… [using many versions of Zap since forever]

crashes if you attempt to load an Obey file

Just me and Clive then… [As we know !Zap crashes on opening *Obey files]

So this happens if Zap is not already loaded?

This is what I’m seeing – correct. [Task Window error – if I open !Zap first (!Zap is displayed on the iconbar) or if I open a C file and then open a TaskWindow I don’t get the error]** Edited for clarity

I’ve never seen Zap crash on opening Obey files either. Currently using Zap on a BBxM with RO 5.23 (22-Jul-17).

Which reminds me to update RO again – I’m getting a bit behind!

Further report on !Zap – works happily on Text files and BASIC programs, crashes if you attempt to load an Obey file. Seems to let you Describe the problem and then Continue – it remains on the icon bar – but won’t load anything until you quit it and restart it. Description is “Abort on instruction fetch at &203035CA” – not sure whether it’s always the same location, but it’s always “Abort on instruction fetch.”

Same crash here (location varies). I’m on a Pi 3, and I dragged a TaskObey file to Zap’s icon bar icon.

I dragged a TaskObey file to Zap’s icon bar icon

I tried that, and shift-clicking on the Obey file. Same effect.

I’ll try Rick’s suggestion about getting the regs via F12 instead of trying to get a TaskWindow in a minute.

So this happens if Zap is not already loaded? Or all the time?

All the time, whether Zap’s already loaded or not.

Registers obtained after an Obey file Zap crash, via F12, ShowRegs:

R0 = 0000000D R1 = 00000001 R2 = 20212CB4 R3 = 0002E91C
R4 = 000000F4 R5 = 000000E8 R6 = 000000F4 R7 = 0000298BC
R8 = 203916D4 R9 = 20391830 R10 = 0000000D R11 = 20212CB4
R12 = 202E5074 R13 = 000086C4 R14 = 203FB9F8 R15 = 2039192A
Mode USR32 flags set: nzCvqjggggeAift PSR = 20000110

Do the same thing again, most regs are the same again, but R3, R7, R8, R9, R14 & R15 are different, but in the same ballpark in each case. Flags & PSR the same.

Thank you – but registers is only part of the story. What’s there is the rest:

• *ShowRegs
• *MemoryI PC-8
• *Memory SP-8 +16
• *Where

Does the workaround of renaming !ZapObey make this problem go away?

Sorry – will finish the story shortly! Not tried the workaround yet, still digging! That workaround sounds fine, would make things easier than having to set and reset filetypes! Never having seen colourized Obey files, I’m perfectly happy with them just being displayed like text files… but I will check that it works shortly too.

Same regs again (I hadn’t really thought about the reg contents – R15 raises big questions straight away: that’s a halfword address! Thumb…! ???)

PC-8:
20379EC0: Menu: 756E6540: STRVCB R6,CR14,#-1357]!
20379EC4: s...: 00000073: ANDEQ R0,R0,R3, ROR R0

SP-8 +16:
(ASCII data): D22EFCFE FCFDFEFE FEFEFEFD FEFEFEFE FEFEFEFE FEFEFEFE

So we’re clearly well away with the fairies here!

Does the workaround of renaming !ZapObey make this problem go away?

Yes! Which keeps me perfectly happy, but if there’s any further digging you’d like me to do, I’m up for it – but not today, as I’ve got guests who might get up soon…

Sounds like a stack imbalance – the PC it thinks it’s pulling… Isn’t.

But why isn’t it happening to everybody?

I’ll try Zap not loaded and TaskObey later on, so if I can get it to happen here.

But why isn’t it happening to everybody?

ZapObey seems to be fine on the ARMiniX (ARMv7) but aborts immediately on a RPi3 (ARMv8).

The abort address is strange, it’s not a multiple of 4. Wrong address loaded into PC?

Try:

*Set Debugger$AnnotatedFile $.excdump
*Set Debugger$DumpOptions -file annotated

And then make it crash.

It might be able to pull enough of a useful stack trace for you to be able to work out where it was just before it branched into thumb mode.

https://www.riscosopen.org/wiki/documentation/show/Debugger%20Exception%20Dumps

I didn’t know Debugger did that. Awesome! :-) :-)

Error dump on opening an Obey file (Pi3 RC15)

Error block: 80000001 Internal error: abort on instruction fetch at &2036F4AA
R0 = 0000000d
R1 = 00000000
R2 = 2031bfc9
R3 = 2031bfc8
R4 = 00000001
R5 = 2031bfcd
R6 = 00000000
R7 = 202c9034
R8 = 2036f254
R9 = 0002ce98
R10 = 0000000d
R11 = 2035a8b4
R12 = 202c89d4
R13 = 000087c4
R14 = 20303c58
R15 = 2036f4aa
CPSR = 20000110
R13_usr = 000087c4
R14_usr = 20303c58
R13_svc = fa208000
R14_svc = 20317384
SPSR_svc = 70000110
R13_irq = fa102000
R14_irq = a0000113
SPSR_irq = a0000113
R13_abt = fa301fa8
R14_abt = 2036f4aa
SPSR_abt = 20000110
R13_und = fa402000
R14_und = fc15dd34
SPSR_und = 20000113
OSMem16: 2 = fa100000, 00002000, 00002000
OSMem16: 5 = fa200000, 00008000, 00008000
OSMem16: 8 = fa300000, 00002000, 00002000
OSMem16: 11 = fa400000, 00002000, 00002000
Memory: fa100000 - fa102000
Memory: fa200000 - fa208000
Memory: fa300000 - fa302000
Memory: fa400000 - fa402000
Memory: 00000108 - 0000010c
OSRSI6: 69 = 00000108

R15 = 2036f4aa = ZapObey +256
R14_usr = 20303c58 = Zap +1fe84 = call_given_mode +38
          Function call to 20303b94 = Zap +1fdc0 = init_comms +60

USR stack:
000087c4 : 00000064 :
000087c8 : 20303e74 : - R14: 20303e74 (ASM call to 20303c20)
         :          : | 20303e74 = Zap +200a0
         :          : | = kill_modes +3c
         :          : | 20303c20 = Zap +1fe4c
         :          : | = call_given_mode +0
000087cc : 00000000 :                                            - R1
000087d0 : 2031bfc9 : - Return to 2031bfc9?                      | R2
         :          : | = Zap +381f5                             | 
         :          : | = report_error +64                       | 
000087d4 : 2031bfc8 : - Return to 2031bfc8?                      | R3
         :          : | = Zap +381f4                             | 
         :          : | = report_error +64                       | 
000087d8 : 00000001 :                                            | R4
000087dc : 2031bfcd :                                            | R5
000087e0 : 00000000 :                                            | R6
000087e4 : 000086c4 :                                            | R7
000087e8 : 20303c58 : - 20303b94 return to 20303c58?             | R8
         :          : | 20303b94 = Zap +1fdc0                    | 
         :          : | = init_comms +60                         | 
         :          : | 20303c58 = Zap +1fe84                    | 
         :          : | = call_given_mode +38                    | 
000087ec : 2036f4aa :                                            | R9
000087f0 : 0000000d : - Return to 0000000d?                      | R10
         :          : | is system workspace                      | 
000087f4 : 2035a8b4 :                                            | R11
000087f8 : 2031245c :                                            | R14: 2031245c (ASM call to 20303e38)
         :          :                                            | 2031245c = Zap +2e688
         :          :                                            | = clean_up +24
         :          :                                            | 20303e38 = Zap +20064
         :          :                                            | = kill_modes +0
000087fc : 2031bf44 : - R14: 2031bf44 (ASM call to 20312438)
         :          : | 2031bf44 = Zap +38170
         :          : | = ExitHandler +14
         :          : | 20312438 = Zap +2e664
         :          : | = clean_up +0
00008800 : 0070615a :
00008804 : e3a02001 :
00008808 : 00000054 :
0000880c : 0e603940 :
00008810 : 000005e7 :
00008814 : 000005e6 :
00008818 : 00000004 : - Return to 00000004?
         :          : | is system workspace
0000881c : 2035ef59 :
00008820 : ffffffff :

**Snipped

End of dump

Error dump on opening a TaskWindow (Pi3 RC15):

Error block: 80000000 Internal error: undefined instruction at &000080C4
R0 = 00008300
R1 = 00008624
R2 = 0000001f
R3 = ffffffe0
R4 = 00000000
R5 = 300f9c60
R6 = 00000000
R7 = 000004f3
R8 = 000084d8
R9 = 300fb824
R10 = fa208000
R11 = fa207f18
R12 = 000084f4
R13 = 00008b18
R14 = 0000842c
R15 = 000080c4
CPSR = 20000110
R13_usr = 00008b18
R14_usr = 0000842c
R13_svc = fa208000
R14_svc = 000080c0
SPSR_svc = 20000110
R13_irq = fa102000
R14_irq = 80000113
SPSR_irq = 80000113
R13_abt = fa301fec
R14_abt = 000080c4
SPSR_abt = 00000113
R13_und = fa401fbc
R14_und = fc0280a8
SPSR_und = 20000110
OSMem16: 2 = fa100000, 00002000, 00002000
OSMem16: 5 = fa200000, 00008000, 00008000
OSMem16: 8 = fa300000, 00002000, 00002000
OSMem16: 11 = fa400000, 00002000, 00002000
Memory: fa100000 - fa102000
Memory: fa200000 - fa208000
Memory: fa300000 - fa302000
Memory: fa400000 - fa402000
Memory: 00000108 - 0000010c
OSRSI6: 69 = 00000108

R15 = 000080c4 = +c4 in application memory
R14_usr = 0000842c = +42c in application memory
          Function call to 000080b0 = +b0 in application memory

USR stack:
00008b18 : 201e5e94 :
00008b1c : 201e5ea8 :
00008b20 : 000082c0 : - R14: 000082c0 (ASM call to 0000835c)
         :          : | 000082c0 = +2c0 in application memory
         :          : | 0000835c = +35c in application memory
00008b24 : 00d4ffe5 :

**Snipped

End of dump

Error message only triggers when !Zap isn’t on the iconbar. Also I did try renaming !StrongEd and rebooted, but it didn’t resolve anything.

On reflection happy to snip the trailing memory addresses on both messages. On this message from 00008b28: to 00008f14: On the one above from 00008824: to 00008bc0: (**Edit – both files have been trimmed)

On reflection happy to snip the trailing memory addresses on both messages.

Yeah, it should be safe enough to trim anything after the last annotation/comment. Because it has no idea how large the user mode stack is, it just dumps 1K of data. (and I still need to improve it so that it includes some disassembly around PC / R14)

Error dump on opening a TaskWindow (Pi3 RC15):

Error message only triggers when !Zap isn’t on the iconbar. Also I did try renaming !StrongEd and rebooted, but it didn’t resolve anything.

It’s probably the long standing bug in the TaskWindow module that you’re triggering here, it was already present in Acorn days.

IIRC, if you open a TaskWindow with a command that includes the -ctrl switch then it will crash when the TaskWindow server isn’t running.

Zap and StrongED both use utilities to add the -ctrl switch so they get notified of Ctrl key combinations. Whichever is set as TaskWindow server, there’s an abort when it isn’t running and you open a TaskWindow.

ZapObey – may be a moot point, as I can’t seem to find any sources for ZapObey.

I’ve looked around in http://zap.tartarus.org/downloads/ for the author directories (ds, james, etc) and also the code for 1.47. Don’t see it. Hmmm…?

ZapObey – may be a moot point, as I can’t seem to find any sources for ZapObey

Are they here? https://github.com/jaylett/zap

Thanks, it is at https://github.com/jaylett/zap/blob/master/sources/modes/obey/s/module%2Cfff. A shame that this stuff has been GitHub munged. But…

I had mostly figured out the problem by working out where the mode setup table was, and this was confirmed by looking at the source.

After “menu_file” was defined, there should be an ALIGN but that was missing so the address of “Initialisation” was set two bytes too early.

I’ve done a binary patch to ZapObey to point to the correct address. If ZapObey failed for you, please try http://heyrick.ddns.net/files/zapobey.zip

It works on my Pi 2, but then it always did. ;-)

I’ve done a binary patch to ZapObey to point to the correct address. If ZapObey failed for you, please try http://heyrick.ddns.net/files/zapobey.zip

That worked for me! :-)

(Pi3 RC15)

Excellent work that man! Works for me too. (Also Pi3 RC15.)

I wonder if there’s any mileage in ROOL hosting the CVS version?

Information about the original CVS version is here → https://github.com/jaylett/zap/blob/master/README.md

After “menu_file” was defined, there should be an ALIGN but that was missing so the address of “Initialisation” was set two bytes too early.

ooh, the alignment issue was a bit old hat (beagleboard era IIRC)
Maybe those reporting no error have the alignment exceptions setting different to those reporting the error.

I don’t think VRPC has an alignment setting so it can’t be that. Perhaps it is also a 26bit/32bit issue – does !ZapObey run OK under Aemulor?