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

*SHOW *Resol* returns nuffink! Don’t tell me my Pi’s ethernet hardware’s shot…please…

Looking at the contents of !Boot.LOADER, I see that the CMOS file is dated just about the time NetSurf (and presumably my network connection) died…could that have got a relevance? The file is clearly not totally corrupted, since the machine boots and other stuff’s working fine.

Sounds more like the network is just not starting up. Maybe due to a boot error. I got the same messing about a while ago on this thread
https://www.riscosopen.org/forum/forums/4/topics/9390?page=1
Where placing an empty obey file called Monitor in !Boot.choices.boot.predesk fixed the boot error. Not saying that’s necessarily your issue, but I would certainly watch the boot very carefully to see if there are errors before the network is set up.

Sounds more like the network is just not starting up. Maybe due to a boot error.

I had a reason for suggesting ping to a known available IP (google DNS)

I also had a reason for referring earlier to the effects of partial Zap installs.

A boot error does seem highly possible, since I was putting !ZapUser and friends into !Boot at the time the network disappeared. Will watch the boot sequence – although it all disappears so fast I can’t be sure of seeing anything even if it’s there.

Thanks Will – and sorry Steve, I must have missed your post.

Couldn’t see the boot reports – gone too quick – but removing !!DeepKeys and !Country from PreDesk has fixed NetSurf okay.

Now to see if !Zap still works, or whether I need to find somewhere else to put them.

!Zap appears to be happy without DeepKeys or Country – presumably I’m losing some functionality, but so far nothing I normally use.

Couldn’t see the boot reports – gone too quick – but removing !!DeepKeys and !Country from PreDesk has fixed NetSurf okay.

Which implies one or both is 26 bit, not 32 bit, the system is rejecting the module as it should, but since the boot sequence is crappy¹ it will have just given up at the first error.

You needed Harinezumi! :-)

I have DeepKeys 2.06 on my Pi. No idea what !Country is, I don’t seem to have this. Was it in Choices:Boot.PreDesk?

¹ And yet again this boot issue raises its head… Hi Steve! ;-)

The Install file in zap_ultimate.zip tells me where to put them, but doesn’t itself have a copy of them, so I dug them out of an old !Boot and bunged them in there. Should have realized that was foolish. Their purpose is described in that file, but I don’t remember the details and I’m on the Mac at the moment.

I can do DeepKeys, as I have a copy that works. It is yet another way of telling specific keys apart (like Page Up vs Shift-Up).

A lot of stuff deleted as I found a 32 bit version of !Country, so am using that.

[Zap is also available in French and German; Zap est aussi disponible en Français et Allemand ¹; Zap ist auch in französischer und deutscher Sprache erhältlich ²]

¹ Si le français est mauvais, c’est ma faute.

² Wenn der Deutsche falsch ist, beschuldige Google!

Okay. Zap Ultimate Edition has been (properly) “born”:

https://www.heyrick.co.uk/random/zap_ultimate.zip

The resources have been put into an !Boot folder for draggy-droppy, and !Zap is also draggy-droppy. So installation is now drag two objects then reboot (you could manually run the things, but rebooting is just quicker).

Everything has been checked for 32 bit correctness.

Here are the changes:

• !!DeepKeys and !Country added.
• Extension → ExtBasAsm has been removed. I miss it, but there you go.
• Extension → Debugger has been removed. I miss that too, but it’ll be really outdated now.
• Extension → IClear has been updated to latest version.
• Extension → KeyExtend deleted – empty folder.
• Module → !ZapBasAsm has been removed. 26 bit. Can’t find any sources.
• Module → !ZapDS has been removed. 26 bit. Source exists, but relies heavily on ExtBasAsm.
• Module → !ZapInform has been removed. 26 bit. Can’t find any sources.
• Module → !ZapMan has been removed. 26 bit. Not looked for sources.
• Module → !ZapSAsm has been removed. 26 bit. For David Holden’s SAsm. Legacy, so not going to look for sources.
  

So… Who fancies being a guinea pig for the two-drags distribution of Zap?

I don’t use Zap but I figured that I’d at least download/install it and make sure that it doesn’t immediately crash on ARMv8. It doesn’t :)

When installing, the first time you open the zip you get “Filing system or path ZapUser: not present” so presumably Zap’s !Boot is trying to do something with the not-yet-seen ZapUser app. I haven’t looked to see what it’s doing, but is it practical to move it into !Run instead?

Okay. You got me. I’ll uninstall the version I’ve got just now and give the new one a whirl… 8~)

I’m keeping the version I’ve got just now in a safe hideaway meantime, since it works…
- and your French looks fine to me, and I’m used to Google’s krapp Germaine…

So… Who fancies being a guinea pig for the two-drags distribution of Zap?

Sterling work Rick! All pleasant & correct – I can’t (obviously) vouch for every aspect of functionality being poifick, but so far so good!

Many, many thanks! Hugely appreciated!

When installing, the first time you open the zip you get “Filing system or path ZapUser: not present” so presumably Zap’s !Boot is trying to do something with the not-yet-seen ZapUser app. I haven’t looked to see what it’s doing, but is it practical to move it into !Run instead?

I would assume that a “if not exist” in there could actually create/copy the required items. That said, putting it into the !Run would be more style guide compliant IIRC.

Has anyone checked this version on RO4.x (for legacy use)

I would assume that a “if not exist” in there could actually create/copy the required items.

Note that this happened when opening the archive. A good reason why one should defeat the boot action when opening archives.

Has anyone checked this version on RO4.x (for legacy use)

Don’t have RO4. ;-) The installation file does say that for legacy systems you’re better off with the last official release…

A good reason why one should defeat the boot action when opening archives.

A good reason why the !Boot file should contain virtually nothing in the way of instructions. This comment of course made me look at a couple of “official” boot files and find the not quite right boot in Maestro:

IconSprites <Obey$Dir>.Themes.!Sprites Set Alias$@RunType_AF1 Run <Obey$Dir>.!Run %%*0 Set File$Type_AF1 Music

Which I believe should actually have something like:

Set Maestro$Dir <Obey$Dir> IconSprites <Maestro$Dir>.Themes.!Sprites Set Alias$@RunType_AF1 Run <Maestro$Dir>.!Run %%*0 Set File$Type_AF1 Music

Which is lifted directly from the !Run file of the same app.

Zap should of course follow the minimal pattern and do nothing that alters, or requires alteration of, the host system when simply !booted. Such items creating or requiring an altered state belong in the !Run file. The fact that Zap has done things wrong for years is no recommendation for it to continue to do so.

Don’t have RO4. ;-) The installation file does say that for legacy systems you’re better off with the last official release…

I do, on one of the RPC’s.
Still coming back into active mode after a fortnight re-tox so I may not give an answer quickly. Mostly just reading a book or two and listening to the breeze in the trees (after London’s constant buzz that’s nice)

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.”

Handles the same file perfectly happily if you set the type to Text (and then set if back to Obey afterwards, in general!)

Clive:

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.”

I think “Describe” is supposed to quit the application afterwards? Best to either “Quit” or “Continue” as you prefer. “Continue” is better as it leaves things more intact for…

https://www.heyrick.co.uk/blog/index.php?diary=20170817 ¹

Half way down the page, the part “How did I track down these errors?” is what you’ll need to look at. I am asking you this because… I used Zap’s Obey mode colouriser to look at many Obey files in the course of development, so I can tell you it works fine on my Pi 2.

Abort on instruction fetch – it’s not an invalid instruction, it’s more an invalid address, like maybe it’s trying to branch to or reload an address that’s an invalid address.

What I’ll need to help see if I can find anything is:

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

Oh, also, my ZapObey module is version 0.47 (20 Aug 2005), same as the one in the latest ZapUltimate. You will find it at !Zap.Modules.!ZapObey.ZapObey.

Steve:

A good reason why the !Boot file should contain virtually nothing in the way of instructions.

Yeah, there’s a lot of rubbish in Zap’s !Boot that doesn’t look like it belongs. I left it alone for now. I’d rather have it complain about missing resources once before it is installed, than risk breaking something by sanitising the !Boot file.

Zap should of course follow the minimal pattern and do nothing that alters, or requires alteration of, the host system when simply !booted.

;-) One could argue that setting a system variable and loading some sprites (normal correct boot behaviour) and maybe claiming a filetype or two is altering the system. ;-)

I’m being pedantic. Zap’s !Boot is silly. This I know.

Still coming back into active mode after a fortnight re-tox so I may not give an answer quickly.

My holiday is over too. Wait half a year for it, then “pfft!” it’s gone. :-(

Still hoping to win a mil on the lottery so I can “retire” and sit in my deck chair and read lots of free Kindle books (deDRM’d and put onto a decent reader device)…in the rain, no doubt…well, my e-reader claims to be waterproof…

All:

I’ve dropped ZapUltimate on my website so it’ll be quicker than serving it from my Pi. URL in the previous message amended to point to it.

¹ Enjoy the error message.

Hmmm. I try to load an Obey file into Zap. Zap “may have gone wrong”. Click Continue, Zap remains on icon bar. Try to load a text file, Zap says it may have gone wrong. Click Continue, same again. Quit Zap from the icon bar, “Zap may have gone wrong.” Click Continue, now I get “Unknown Zap Redraw encoding reason code”; Continue again, “Zap may have gone wrong”; eventually click Quit (not on icon bar) – “Zap may have gone wrong” but now Quit does quit.

After Zap finally quits, I can’t open a TaskWindow: it says "Application may have gone wrong. Click Continue to try to resume, or Quit to stop application. So I click Quit or Continue, and Zap appears on the icon bar, totally cheerful: will load a text file no bother, and I can now open a TaskWindow.

Hi,

If you (eventually!) quit Zap and reload it, whatever is or was in memory at the time of the failure may be completely different. As you can see from your memory dump, R12-R15 are in application space (&8xxxx) which doesn’t correspond to your previous error status – and is likely the final time Zap threw up, not the first.

Try this:

Make Zap blow up, “Continue” and then press F12 to see what the registers are. You said earlier that the problem was somewhere around &2xxxxxxx which is what we want to be looking at. If this is the case, do a *Spool <filename> and then enter the commands I gave you. This should (hopefully) provide information on where the error is happening. Only blow up Zap once, any further errors will overwrite what we want to be looking at.
Don’t forget to do a final *Spool when you’re done, or RISC OS will attempt to record all VDU activity upon returning to the Desktop!

As a workaround to make this error go away: quit Zap. Go into !Zap.Modules and rename the !ZapObey application to be something like _!ZapObey so that it won’t be found or booted. Then Obey files should appear just like text files (as Obey colourisation mode will no longer exist).

I too have similar issues with !Zap, but with tank7 and RISC OS SD15 on a Pi3.

As we know !Zap crashes on opening *Obey files. My experience of the Task Window error is that 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 to reflect Pi3

I don’t get any problems with editing Obey files, they appear correctly coloured, whether using Zap 1.44 (30-Aug-2002) [TEST 10] on VRPC or 1.48 tim-01 on VRPC or 1.48 (13-Sep-2011) tnk-7 on ARMX6/Pi/Titanium – should I?

I note version 1.48 tim-01 does not have the toolbox tab when editing BASIC programmes.

As we know !Zap crashes on opening *Obey files.

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

My experience of the Task Window error is that if I open !Zap first

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

I too have similar issues with !Zap, but with tank7 and RISC OS SD15.

I think you need to specify the hardware in use too. Chris is not seeing the problem with VRPC, ARMX6, Titanium or Pi (without being specific on the model of Pi)