Zap Disassemble

As noted elsewhere, I today found out that when running RISC OS 4.25, when I press F12 (amongst others) I get an error:

SWI &6 returned a bad error pointer

I’ve narrowed that down to the presence of the module HidePointer (!Zap.Code.Extensions.HidePtr.HidePtr). When I RMKill this module, the error goes away. This is probably due to the pointer block checking introduced in later RISC OS versions. I don’t have this problem under RISC OS 4.23 (RC5 titanium build).

I today found out that when running RISC OS 4.25,

Uh… 5.25?

I’ve narrowed that down to the presence of the module HidePointer (!Zap.Code.Extensions.HidePtr.HidePtr).

Hmm, I have made no changes to HidePtr. :-)

Ah, wait. Just looking at the source. I might have an idea of the problem. Hang on a tad, let me reboot into RISC OS 5.25…

Uh… 5.25?

Yes, of course… I seem to make that error a lot… :-S

Hmm, I have made no changes to HidePtr. :-)

No, I was aware of that but I should have made that clear. Sorry:) But as it was an issue with Zap I wanted to report it, but I don’t think there’s a central place to do that? So here seemed a logical place…

Ah, wait. Just looking at the source. I might have an idea of the problem. Hang on a tad, let me reboot into RISC OS 5.25…

That sounds promising! :)

Ah, wait. Just looking at the source. I might have an idea of the problem. Hang on a tad, let me reboot into RISC OS 5.25…

Nope. It was setting bit #1<<31 which was pretty weird for an OS_Byte, but trying that in a TaskWindow didn’t seem to upset anything.

The code seems to do some odd stuff, but that said – one does not pass addresses to OS_Byte, so surely if it is returning a duff error pointer, it’s the OS at fault? Unfortunately this doesn’t cause an exception so neither Debugger nor ZeroPain have anything to report. What’s causing the problem, and where? I don’t know. But I see some other things acting odd when HidePointer is running on RISC OS 5.25.

some other things acting odd when HidePointer is running on RISC OS 5.25.

For instance, putting the mouse over any NetSurf window reports “An unexpected Window Manager error occurred: SWI &80146 not known”.

Current best advice: Zap icon menu → Options → Misc → Autoload → Ensure “HidePointer” is not ticked, then Options → Save options. :-)

But did you manage to reproduce my problem?

For instance, putting the mouse over any NetSurf window reports “An unexpected Window Manager error occurred: SWI &80146 not known”.

Hm, I think it may have been mouse over NetSurf as well where I got the:

SWI &6 returned a bad error pointer

but I’ve not seen the error you are seeing.

Current best advice: Zap icon menu → Options → Misc → Autoload → Ensure “HidePointer” is not ticked, then Options → Save options. :-)

Ah, there is the setting, thanks :)

But did you manage to reproduce my problem?

Easily. Changing the pointer shape triggers it: SYS "OS_Byte", 106, 1

but I’ve not seen the error you are seeing.

It’s possible that an earlier version of the bad pointer error upset something, causing the error that I was seeing…

Ah, there is the setting, thanks :)

I have tweaked the update scripts for the rick-04 release to push HidePtr out of the way if it’s a RISC OS 5.25 system. In that way, it won’t be loaded because Zap won’t see it.

A big ‘Thank you’ @ Rick Murray.

Zap works now fine witout a crash anymore (Rpi3, Risc Os 5.23)

I got now my most preferred editor back!

Here’s the fault in HidePointer.

This code hooks to the ByteV event to trap when the pointer shape is changed (for example, ShellCLI sets it to zero to hide the pointer (that’s why pressing F12 caused the bad pointer eror)).
It starts off okay, then gets a bit weird, than goes all out crazy-gonzo.

; bytev interception
bytev           FNJSR                                   ; I'm fairly sure that some OS_Bytes take
                MRS     R12,CPSR                        ; flags as inputs

                TEQ     R0,#&6A                         ; select pointer shape
                BNE     bytev_done
                AND     R2,R1,#&7F                      ; mask shape number
                CMP     R2,#4
                LDRHI   R1,mouse_shape_old              ; invalid
                BHI     bytev_done

                LDR     R2,mouse_shape_old
                PUSH    "R2"
                AND     R2,R1,#&FF
                TST     R1,#1<<31
                STREQ   R2,mouse_shape_old
                STREQ   R2,mouse_shape
                BIC     R1,R1,#1<<31
                MVN     R2,#0
                STR     R2,ptr_state
                MOV     R2,R14
                BL      bytev_callothers
                PULL    "R1"

bytev_done      MSR     CPSR_f,R12
                FNRTS

; call other bytev claimants
; E r2 = previous routines  r12 = flags
bytev_callothers
                STMFD   R13!,{R14}
                MSR     CPSR_f,R12
                MOV     PC,R2

In case you hadn’t guessed, it’s bytev_callothers that blows up.

I just had to take a taxi-VSL to/from the hospital for my follow-up visit to the doctor, and the Sécu doesn’t pay for stuff like that (despite the doctor the first time around giving me the form for the taxi). So in a few days a bill for ~€100 will arrive. For ~50 minutes driving that many kilometres (25km each way). That’s a little under a tenth of my monthly salary. I’m so in the wrong profession… :-/ Anyway, my brain is too frazzled to even begin to work out what that code thinks it ought to be doing. I have a suspicion it might need some NOPs, but since hiding the pointer when typing is a minor thing, I’ve opted for just <cliché alert!>kicking the problem into the long grass, nay, the wilderness where the buffalo roam and the deer and antelope play</cliché>

A big ‘Thank you’ @ Rick Murray.

Zap works now fine witout a crash anymore (Rpi3, Risc Os 5.23)

I got now my most preferred editor back!

Not even a day goes by when another annoying bug throws itself at me…

When I’m coding, the auto-indent takes care of much of the code alignment, but there are times when I would like to add some whitespace and get stuff lined up. I abhor littering files with Tab characters. What is useful is the “As above” Tab mode. Like Edit.

Only, it blows up in Zap.

Make that past tense. ;-)

Turns out that a check was put into the function mode0 → mode0_splus that used R14 as a temporary for checking a flag…without having stacked R14. And it looks like the test didn’t work anyway as it kept on being triggered on my build of Zap when I stacked R14, so I just disabled the flag check entirely and now Tab As Above works correctly.

http://heyrick.ddns.net/files/zap-rick04.zip

It’s a full update of all the new bits. Run !Update if you have not already installed the rick-03 release. If you have already done that, you can just run !UpOnlyZap to copy only the Zap file (that has changed).

In both cases, the update script will push HidePointer out of the way if you’re using a RISC OS 5.25 machine.

Have fun!

I’ve never used HidePtr, so I’ve just had a look.

Rick said

It was setting bit #1<<31 which was pretty weird

HidePtr also claims ByteV, so it is using this as a flag to its own code. It flags whether to store the pointer number. Since it is its own code calling OS_Byte in this way, you might wonder why that bit of code can’t store the value instead – it’s because it saves that setting with the current and previous shapes.

The code is a bit odd in places, and archaic. I think I’d sit on PointerV rather than spamming OS_Word on a ticker.

pretty weird for an OS_Byte

“Byte” is a historical API name and somewhat misleading. The Kernel treats R0 the reason code as a byte (truncating), and will usually, but not exclusively, treat its parameters as bytes. It is capable of returning word-sized results, even when documented to be spread across two registers (one will be the bottom 8 bits, the other all the others – this is historical).

Naturally ByteV claimants can do anything (implementing OS_Byte 2018 for example)… as can any of the subsystems that some of the Kernel OS_Bytes call.

So, no, it’s not an exclusively bytewise API. In a way, OS_Word is more byte oriented than OS_Byte.

Just loaded zap-rick04 on my RPi3 and !Zap appears to be working again :-) I’m a Zap person. I’ve tried StrongEd many times over the years, but I always end up back using Zap (when I can get it to work). I think that the difference between Zap users and StrongEd users is just the way that our brains are wired – so probably too late to change that once you’re as old as me (58).

Many thanks Rick.

I think that the difference between Zap users and StrongEd users is just the way that our brains are wired to

I would imagine that there’s a bit of truth in this. I keep with Zap because it just does what I want. They isn’t to say that StrongEd cannot – and everybody, especially Fred, have been really great in pointing out how to make StrongEd do what Zap does. It can do it, only differently. For instance, “search all files for X and list occurrences in a window”. It’s a single tick box in Zap’s search box. In StrongEd, it’s somewhere else. Menu? Hotkey? I don’t recall. At any rate, press F4 and tick, oh wait, where is it?!?
I guess it’s probably the same for StrongEd users using Zap. ;-)

That said, some design decisions just don’t click. I don’t find StrongEd to be bad, a better example would be Ovation vs Impression. I got on with Ovation, used it a lot. Absolutely hated Impression. Can’t say exactly why except it’s layout was awful both to use and to look at. It doesn’t matter if it might have been the more powerful or faster if it was just annoying in use. Why d’you think I use RISC OS a lot instead of Windows? ;-) Windows is undoubtedly more powerful, however my phone suggested “ungodly” instead of “undoubtedly” which is, yeah, about right. Maybe one day the scrollbars will work sensibly… Maybe one day they’ll ditch the mindset that an application isn’t an application unless it has a window on the screen…

I’ve tried StrongEd many times over the years, but I always end up back using Zap (when I can get it to work). I think that the difference between Zap users and StrongEd users is just the way that our brains are wired

Interesting take on things because my primary reason for not regularly using Zap is not a preference for the UI of SE vs. Zap.
My reason is the bit in brackets “(when I can get it to work)”.

As far as I’m concerned anything that gives me regular failures, and every time I’ve tried Zap it’s given me interesting crashes, is basically not fit for use.
Yes, people might say I (and other sufferring users) should contact the maintainer – so is that many people, one person or currently no one?

I’ve had a few conversations with Fred about StrongED and even more about Transient (mostly “nagging” him into the TrapDelete development)

I suspect the main reason Zap users remain Zap users is that they are prepared to carry on despite the problems.

I suspect the main reason Zap users remain Zap users is that they are prepared to carry on despite the problems.

Yup, that’s probably it. Fair enough, Zap crashes every so often. That said, it has a much better track record than Firefox or, God help us, Safari…

I’d like it to be more reliable, but when I spot stuff like loading R13 from R13 with writeback, or using R14 as a temp register without stacking it, it does make me wonder what other oddities are lurking.

As far as I’m concerned anything that gives me regular failures […] is basically not fit for use.

Do you use a smartphone? App crashiness is rampant. I guess this is something one begrudgingly gets used to. As with Zap…

should contact the maintainer – so is that many people, one person or currently no one?

Officially, I think that’s currently nobody. However if you can give a reproducible bug report (pref. with Debugger dump or ZP log), I can take a look.

Debugging stuff like Zap (an app in a module) is somewhat tedious/painful under RISC OS, and it often amounts to trying to work out what the code is doing, then inserting one single call to SWI 256+7 and putting on headphones. When I get to a place where the crash happens and there’s no beep, I can work between that and the last beep place to narrow down the problem.
Yes, it’s a sorry state of affairs, innit? :-)

Do you use a smartphone? App crashiness is rampant.

I have a work issued iPhone SE.
It has the base install plus one App for the secure remote access key (two factor authentication basically) and the push mail forwarding my work mail.

It also has phone/text capabilities. I got used to Safari providing a base reference for all other browsers (base as in anything else is better, the only way is up) so it isn’t something I look at.

Officially, I think that’s currently nobody. However if you can give a reproducible bug report (pref. with Debugger dump or ZP log), I can take a look.

I’m not a user, if someone could give me a strong assurance that it wouldn’t crash I might check it out

Thanks for the work Rick on Zap – Note ‘Reporter’ works in the RMA.

Did think – a few new extra sounds like ‘swi 256+7’ would be nice – something like ‘swi Burp’ – copying a RO hardware producer naming:-)

[edit]
I wonder with the High Vector RO – you perhaps save the PC to the Zero page!!
STR PC,&0
To try and follow some code.

if someone could give me a strong assurance that it wouldn’t crash

If someone does, be sure to ask them how old the Earth is, and run if they give you a figure around “six thousand”.

Yes – but ’six thousand" whats!

Note ‘Reporter’ works in the RMA.

Certainly does (as well as in application space). At its simplest, using SWI “Report_Regs” will display values (in a scrollable window) for registers r0-r9 & pc, flags and Mode. Other registers need a macro to be used which depends on which assembler is being used.

Hmmm…

Wanted to get Zap to crash to look at something (as I deleted the previous crash file).

NOTIFYUSER $(@WINDOW)

replies “409”. Zap’s application space is 89MB.

Closing all files took a while (I hope it wasn’t closing in a FIFO order, or it would spend ages shuffling its heap for no useful reason!) but… still hasn’t crashed.

This is weird. Loading all the kernel source. Then all the Wimp source. Twice. Three times.

Am I sure I’m still using Zap? Surely it should have died on me by now? ;-)

[just looked at the source for CLOSEALL – yes, it counts from zero, so it’ll be going in a suboptimal direction!]

I came across this: https://www.raspberrypi-spy.co.uk/2014/09/top-5-reasons-the-raspberry-pi-sucks/
If you think the article is funny (how much for a Pi?!?), just wait ’til you get to the comments and see the ones with faulty sarcasm detectors. 8-)

As for Zap, I wanted to look at HTML mode and see why the comment to strip entities is failing, but it’s not going to happen mainly because I don’t “do Perl” so have no idea what’s upsetting it. I need Sed (which I found in the RO source stuff), plus two Perl utilities. It seems to be experiencing difficulty translating Unix style paths to RISC OS, or vice versa, and when I botch the paths to work, the mkent program says:

Identifier "::_<SDFS::RISCOSPi.$.Zap.modes.hotmeal.mkent" used only once: possible typo.

and mkwords says:

syntax error at SDFS::RISCOSPi.$.Zap.modes.hotmeal.mkwords line 9, near "sub mycmp ("
Execution of SDFS::RISCOSPi.$.Zap.modes.hotmeal.mkwords aborted due to compilation errors.
Return code too large

[ the source of this is in zap-master.sources.modes.hotmeal from the GitHub repo ]

If you think the article is funny

Amusing spoof. Complete with spoof comments

As for Zap, I wanted to look at HTML mode and see why the comment to strip entities is failing, but it’s not going to happen mainly because I don’t “do Perl” so have no idea what’s upsetting it. I need Sed (which I found in the RO source stuff), plus two Perl utilities.

Sounds like someone put together a scripted search and replace with SED doing the regular expression for pattern matching bits and the Perl utilities driving the interfacing from the user to SED.
There’s probably lots of other ways. Look at the SED syntax and decide how to send a command string to SED to do things with a specific regex pattern to a target file.

How about running the ‘Module’ through ‘ARMalyser’ have ‘ObjAsm/Link’ on the Iconbar.

You can then use Real ARM code :-))

[edit1] I presume 32bit means any Acorn machine RPC and later :-|