Zap Disassemble

Using Zap v tnk-11 (vrpc-dl) to disassemble code.

Clicking select on Zap iconbar.
Clicking memu:Mode.Code (over main window).
(Changes window from Txt to Code)
clicking select on 00000000 line.
Press ‘Enter’ (small window should open at botton of Zap window)
ie 00000000: ANDEQ R0,R0,R0
(This line can now be edited – ie ‘NOP’)

There seems to be a change in the OS between 5.23 (12-May-2017 and 12-Feb-2018.
This small window now does’t open – when ‘Enter’ is pressed – but appears when you type ie ‘NOP’.

RO version 5.25 Apr 23 2018 also does the same.

Any idea – Thanks
[edit 12-Feb 2017 to 2018]

My personal build of RISC OS is:

*FX 0
RISC OS 5.23 (08 Aug 2017)
*

and Zap (“ultimate”, which is mostly 1.48 (17 Jun 2017) tim-01 with some mode fixes) behaves as expected, the little white window appears immediately. This is on a real Pi. I wasn’t aware that VRPC was able to run RO5… [ https://www.heyrick.co.uk/random/zap_ultimate.zip ]

Thanks for that – the change in the OS must be between 08 Aug 2017- 12 Feb 2018.

Slight typo in your original post Colin 12-Feb-2018 I think rather than 12-Feb-2017

Mid-November 2017 would represent a halfway point if you’re on a binary search for the affecting change.

But before that, perhaps Rick could try a recent RO build to eliminate the possibility that the difference for him is his tweak of Zap.

Are there any downdoads for November 2017 around – has anyone else tried out !Zap for around that time?

Were there any updates to the ‘Debugger’ Module?

Thanks

Are there any downdoads for November 2017 around

There were some temporarily here.

I have 23-Oct-17 in my collection if it’s any use.

On the Titanium, 13Aug17 good, 20Aug17 bad.

I have added two August 17 Pi roms, which are all that I have from that time, 01Aug17 and 20Aug17.

Now removed.

Rick. I know it’s not totally related, but I accidentally found another crash condition with the version of !Zap you posted. This is with a homebuilt April 10 ROM on Pi 3. This error seems to be reproducible. I was working on an ObjAsm file and accidentally pressed shift + numpad ‘*’. I tend to do this regularly. Zap just dies. Abort on Instruction fetch &001928C8

Thanks for the help – the change seems to come about between 13 Aug 2017 and 20 Aug 2017.

Is there a log of the above changes?

By the way I don’t have a RasPi :-(

Softloading ‘Debugger’ module 1.99 (24 Jan 2017) – on VRPC-DL RO 5.25 (23 Apr 2018).

!Zap seems to work as it should :-)

Softloading ‘Debugger’ module 1.99 Zap seems to work as it should

Presumably that’s because the ROOL Debugger module has reached 2.00 and now clashes with Debugger Plus which Zap is expecting, and Zap’s jumping off into no man’s land expecting some SWIs to be there that aren’t (or vice versa).

Presumably that’s because the ROOL Debugger module has reached 2.00 and now clashes with Debugger Plus which Zap is expecting, and Zap’s jumping off into no man’s land expecting some SWIs to be there that aren’t (or vice versa).

That fits with the bracketed dates that define the start of the problem for Zap and the CVS log for Debugger

So a Zap problem not an OS problem.

Presumably that’s because the ROOL Debugger module has reached 2.00 and now clashes with Debugger Plus which Zap is expecting

Zap’s Debugger Plus 2.09 (03 Apr 2002) is 26bit here.

the change seems to come about between 13 Aug 2017 and 20 Aug 2017.

ZeroPain 0.07 (19 Aug 2017) was launched with the 20 Aug 2017 ROMs. That in itself should not be an issue but were there attendant changes within the ROM? Debugger 2.00 is dated 15Aug2017.

But before that, perhaps Rick could try a recent RO build to eliminate the possibility that the difference for him is his tweak of Zap.

Using Zap 0.48 rick-01 (just put together the basic source and made a build), the pop-up window appears as expected for my homebrew version of RISC OS. It does not work correctly (little window only appearing when data entered) on last night’s build of v5.25 that I’m currently running.
Oddly enough, softloading a saved copy of Debugger 1.99 (makes the window appear). Hmmm?

Presumably that’s because the ROOL Debugger module has reached 2.00 and now clashes with Debugger Plus which Zap is expecting,

It doesn’t appear to check any version numbers. It tries the DisassemblePlus SWI, and if that fails it will fall back to a regular disassembly. The only odd behaviour is that it (X form SWI) tries to pass flags to SWI Debugger_63 – which as far as I can determine, has never been supported?
If anybody wishes to look, it’s Mode4 and Mode4dis in the code.

I was working on an ObjAsm file and accidentally pressed shift + numpad ‘*’. I tend to do this regularly. Zap just dies.

Yup. It looks like the code to delete the start of the word is bad. process_key goes to process_converted_key goes to exec_command goes to a mushroom cloud.

Pressing ^Esc lets one enter commands, and with this, it looks like DELWORDSTART and DELWORDEND are both bugged. I have disabled the code for these functions so that pressing Sh-Keypad* and Sh-Keypad# (which I don’t have on my keyboard!) doesn’t crash Zap.

Latest binaries here: http://heyrick.ddns.net/files/zap-rick01.zip
It’s just the Zap module (goes in !Zap.Code) and ZapRedraw (goes in ZapFonts in !Boot someplace, but this hasn’t been changed so you can ignore it).

Strange – Debugger Plus (called Debugger) is 26bit only.

Back to VRPC-DL RO5.25 (23-Apr-2018) – saving the Debugger module – and changing its number to v1.02 and reloading.
It now works!

Back to VRPC-DL RO5.25 (23-Apr-2018) – saving the Debugger module – and changing its number to v1.02 and reloading.
It now works!

I have just done the converse with !Zap 1.45 on OS4.39. It works with the ROM Debugger 1.61. Save that, overwrite the version number with 2.01 then softload it and it stops working.

At this point it would be good to re-read Sprow’s earlier post which made just this point.

Save that, overwrite the version number with 2.01 then softload it and it stops working.

I didn’t see anything that appeared to even look at the module version number. Hmm, maybe it’s elsewhere in Zap? If I have time, I’ll have a rummage around tomorrow.

Latest binaries here: http://heyrick.ddns.net/files/zap-rick01.zip

Works great. Thanks!
Instant relief when typing out long .hdr files.

Save that, overwrite the version number with 2.01 then softload it and it stops working.

I get the same behaviour here.

There is a part that checks for Debugger 2.00 to determine whether or not to try loading DebuggerPlus, however if Zap is not set to autoload the enhanced Debugger, it’ll never get called. I have commented out all of that code, makes no difference.

Using the time tested method of dropping in SWI 256+7, I can tell that “mode4_char” (the routine to open the minibuffer) is not even called with a debugger > 2.00. So I’ll keep trying to unwind this to work out what’s going on…

The errant version number checking turned out to be in the ZapBASIC module 1.39 at offset &EC4. The ‘fix’ is to increment the Debugger module version comparison number to #&300 from #&200, the values are BCD. (It will take a while for ROOL to get that far.) I do not have the source so the edit was done in StrongED, but once fixed, it could be done with Zap.

00000EB0 : E28F1078 : xPè‚ : ADR     R1,&00000F30
00000EB4 : E3A00012 : R@†„ : MOV     R0,#&12            ; =18
00000EB8 : EF02001E : ^@BÔ : SWI     XOS_Module
00000EBC : 68BD803F : ?ÄΩh : LDMVSIA R13!,{R0-R5,PC}
00000EC0 : EB00000C : L@@Î : BL      &00000EF8
00000EC4 : E3500C03 : CLP„ : CMP     R0,#&0300          ; =768
00000EC8 : 28BD803F : ?ÄΩ( : LDMCSIA R13!,{R0-R5,PC}
00000ECC : 735F0102 : BA_s : CMPVC   PC,#&80000000
00000ED0 : 737F0102 : BAøs : CMNVC   PC,#&80000000
00000ED4 : E8BD803F : ?ÄΩË : LDMIA   R13!,{R0-R5,PC}
00000ED8 : E92D4003 : C@-È : STMDB   R13!,{R0,R1,R14}
00000EDC : E28F1058 : XPè‚ : ADR     R1,&00000F3C

....

00000F30 : 75626544 : Debu : STRVCB  R6,[R2,#-1348]!
00000F34 : 72656767 : gger : RSBVC   R6,R5,#&019C0000
00000F38 : 00000000 : @@@@ : ANDEQ   R0,R0,R0

There is similar code in Zap itself, in s.ModeBits at line 2451. This code may never be called but if it is there will be another similar versioning anomaly in waiting.

With thanks to Sprow and Jeffrey for the pointers.

Okay, the observation is that the minibuffer is simply not being filled in with the instruction at all, with versions of Debugger apparently >= 2.00.
I’ve now tracked it down to the function mode4_return (to handle the Return/Enter key specially). This is being called, but I guess it is falling out early; and the behaviour of the MiniBuffer opening if you press another key is actually what happens anyway (try it without pressing Enter).

I’ll keep rebuilding dropping in SWI 256+7 in different places, to see where this is being wrong.

Looks like it isn’t Zap, it is the ZapBASIC module. Examining…

It would probably be better, if you’re changing both Zap and DebuggerPlus, to use an active method of presence detection rather than the passive groking of version numbers – the aforementioned +3F SWI perhaps, or similar?

It would probably be better, if you’re changing both Zap and DebuggerPlus, to use an active method of presence detection rather than the passive groking of version numbers

As far as I can see DebuggerPlus is totally obsolete in Zap, only the ROM based Debugger ever gets used. Code that used DebuggerPlus in the Zap module is switched off with a setting in the source code. I don’t have the sources for ZapBASIC hence the groking, with the sources something better could be done, as is the case for the Zap module.

A less than perfect situation which should suffice as ‘proof of concept’.

Creative numeric groking simply defers the issue to a later date.