Zap error opening taskwindow

If I press Ctrl+F12 when Zap has been seen but not yet run, I get
Internal error: undefined instruction at &000080C4
Pressing continue, Zap loads onto the iconbar, but the taskwindow doesn’t open.

I believe this is caused by about four non-32-bit instructions in ZapModules:!ZapTW.TaskWindow.

Which version of Zap are you running, please? Do you have Rick Murray’s “Ultimate” zap which fixes a lot of such issues?

Yes, I have 1.49 (18 Sep 2018) rick-05.

Thanks for the info. If I have time this weekend, I’ll take a look at it.

It bugged me.

Looks like the TaskWindow module is okay, it’s the TaskWindow starter that is faulty. Probably why I never saw it, as Zap auto-loads at boot on my machine.

Unfortunately there doesn’t appear to be any source for “TaskWindow” in the TaskWindow extension source archive, so I’ve had to patch it manually.

There are some odd things that I’m not really sure about (a couple of instances of using a conditional after a branch – ARM doesn’t work like that in 32 bit world), so I’ll provide a link to the “quick hack”, can you tell me if this is any better?

It’s “TaskWindow”, and it goes in ZapTW.

http://heyrick.ddns.net/files/ztwfix1.zip

(looks like there’s another copy of that in !ZapBasic – is it supposed to be there?)

Okay, dinner is on the side getting cold so I’ll leave it as this for now.

I think that won’t work Rick.

At offset 03D0 (or 83D0 if using ZAP to edit) there is

BLEQ &83F0
BEQ  &82DC

Which relied on the condition codes being preserved.

I would try:

ADREQ R14,&82DC
BEQ &83F0

Not very nice or readable, but gets the job done without any extra bytes.

Yes that works thanks :)

I found this commit https://github.com/jaylett/zap/commit/8ca473aba5198cb7221aa29f6e2bcbd645d5835d from 2003 where the task window bits were removed from ZapBASIC.

I found another problem. If I click on Zap to open a blank text file, and then press Ctrl+K twice I get undefined instruction.

I fixed it by changing
000198DC MOVEQ PC,R3
to
000198DC BICEQ PC,R3,#3

It was putting my poor processor into Thumb :(

In the source on github it’s char_del_dispatch in s.Mode0
https://github.com/jaylett/zap/blob/61a16b1a224cf2e1092f4979182ad19abfc04fc0/sources/!ZapSource/s/Mode0%2Cfff

I think that that only works by fluke Julie.
Looks to be like R3 is getting set to an unaligned value in the caller, which will be before the required instruction. By clearing bits 0 & 1 you will cause the cpu to execute the intruction before the intended one.
Depending on the data at that location it could cause some interesting results. The only way to really fix it is to find everywhere that it gets called from and ensure that R3 is correct. There are further accesses to R3 after the one that you fixed.

As Jeff says, there are numerous instances of MOVxx PC,R3 because R3 is a function pointer.

A quick test here, it looks like DELTOSTART and DELTOEND are commands that go wrong, the second time.

<time passes>

What?

Okay, unwinding this to DELTOEND and working forward from there, it looks like this:

Deltoend
        TST     R3,#1
        ADR     R3,Deltoend_main
Delto_common
        MOV     R0,#1<<31               ; it's a deletion
        ORRNE   R3,R3,#1
        LDR     R4,[R8,#w_flags]
        MVN     R5,#1<<31
        LDR     R6,[R8,#w_format]
        B       char_del_dispatch
Deltoend_main
        FNJSR
        [etc]

And…

char_del_dispatch
; To disable block editing, uncomment the following lines:
;       MOV     R0,#0
;       MOV     PC,R3
        LDR     R1,[R8,#w_info]
        TST     R1,#1<<10               ; block edit?
        MOVEQ   R0,#0
        MOVEQ   PC,R3
        _PUSH   "R0,R3-R10,R14"
        BL      get_selection
        MOV     R11,R8
        _PULL   "R0,R3-R10,R14"
        MOVCS   R0,#0
        MOVCS   PC,R3
        TEQ     R8,R11                  ; and in same window?
        MOVNE   R0,#0
        MOVNE   PC,R3
        _PUSH   "R0"

That looks awfully like it’s using bit 0 as some sort of flag. On older ARMs, MOV PC,Rx would write only the address and not any flags. Something that no longer holds true, unfortunately.

Does anybody with more experience with Zap’s internals know what this flag is? There is no obvious reference to it in char_del_dispatch, but it’s getting set somehow as the second operation is failing (due to setting it).

Hmm… Pressing ^Esc and repeatedly entering DELTOEND does not fault.

Okay, I’ve just built a version that leaves out the ORRNE line in Delto_common and it appears to work with no weird effects (so no idea what the flag was for).

Can you test this, let me know if it’s okay, and if so I can version bump it to a proper release.

http://heyrick.ddns.net/files/zdeltest.zip

It’s the “Zap” module. It goes in !Zap.Code.

Oh, and yes, I know the program version in the Info window is messed up. That’s because the “-deltest” suffix is too long and overruns the icon buffer. Don’t worry about it, it’s only for this test build. ;-)

I hadn’t realised that there were flags in R3!
In which case the BIC is a good solution, just need to find them all!

Does anybody with more experience with Zap’s internals know what this flag is?

Looking at the code, I guess the flag is used by the code at de17 and the add_yank_region. Since the deleted text is put in the clipboard my tentative guess would be that on the second call the the deleted text is to be merged in the clipboard with the text of the first call.

I hadn’t realised that there were flags in R3!

Yeah, it’s a bit facepalm inducing.

In which case the BIC is a good solution, just need to find them all!

Simpler to do what I did – find where the flag is being set and nuke it from orbit.

In rick-05, +&124C0 should be ORRNE R3, R3, #1. Make it a NOP. Or download my test build (above).

Simpler to do what I did

Hmm, I reckon that you could find all the “PC,R3” bits in no time!

I’ve given the above test build a spin and I see the following.

The * symbol indents gradually on each press of the return key.

Also, cut and paste crashed on me. Any updates?

EDIT The issue is no more!