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

and finally to Jeffrey Lee for making Debugger do more useful things. :-)

I think “last but not least” rather than “finally” would be the least one could say there!

I think “last but not least” rather than “finally” would be the least one could say there!

:-) I guess the interpretation of that depends upon whether or not you are assigning relative precedence to the four people (well, three people and a dev group) named.
I was not, each played a part in making this fix realistically possible. Each should get equal credit, but that would just be a bunch of blurry pixels, like when your dot matrix printer wasn’t set correctly for the line ending protocol so everything printed on the same line until the paper disintegrated and left a splogey ink mess on the roller… ¹

Remember, of course, the final name mentioned was Jeffrey – without whom the history of RISC OS would look more like the history of [insert favourite forgotten operating system here]. There’s no question of “least” in any way.

☺

¹ Giving my age away again!

Giving my age away again!

Remember chain printers? I remember the chain breaking on one at uni. Those chains fairly shifted, and they were not lightweight… splodgy mess on the roller? What roller? Where?

Remember chain printers?

Seen one languishing in a cupboard, if you mean the sort of printer that would survive a nuclear war, and had the letters bolted to something that more resembled a Land Rover’s drive belt.

Never saw it in use, dot matrix replaced it. Was it as noisy as it looked like it would be?

Giving my age away again!

I think I’m one of the youngest here (34), but I remember running into that issue once or twice :)

Was it as noisy as it looked like it would be?

No. They were much noisier than that. I attribute my (imaginary) deafness to them, and I wasn’t a frequent visitor to that building. Those who worked there wore ear defenders, and I suspect they still went (actually) deaf.

There were four of them – two in each of two rooms, one at each end of the building.

Fortunately no-one was in the way of the broken chain, which exited the machine with considerable force. I wasn’t there at the time, but heard the story and saw the damage to both machine and the door the chain hit.

Nostalgia ain’t what it used to be…

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.

You may be amused to hear that Arthur 0.30 had the exact same bug – a missing ALIGN before the code for OS_CheckModeValid, meaning calling that SWI executed one instruction of random data before the real code. Fortunately it was our old friend, ANDEQ, which wouldn’t have interfered with the low screen mode numbers of Arthur even with Z set (I think mode 32 would have started to be a problem).

I haven’t checked which version of Arthur or RISC OS this got fixed in.

As this thread is still fresh, here are two more errors from Zap on RPI3.
With solutions.
There is a SWP hidden in the zap module (!Zap.code.zap) at offset &29B4 (zap_ultimate distro, in older versions do a search for SWP)
STMDB R13!,{R11,R14}
MOVVC R11,#0
ADDVSS R11,R0,#0
ADD R1,R12,#&0338
MOV R0,#0
SWP R0,R0,[R1]
TEQ R0,#0
SWINE XZapRedraw_LoseFont

The source is !Zapsource.s.Redraw, label is pnt_lose_font
The error can be provoked by activating printers.!Printers, !FontPrint and !PrintPDF;
then loading or typing a (text) file into !Zap;
click Menu—>Display—>Font—>Font display settings—>Anti-aliased DSA and click;
Then: Menu—>File—>Print—>Fancy : and an undefined instruction error pops up, F12 + *where tells you it is at &29B8 in module zap (the SWP instruction is at &29B4)
The code there changes font when !Zap has to print something to the printer.

If swapping this memorycontent is not required to be atomic, the following may be equivalent:

STMDB R13!,{R11,R14} \unchanged
MOV R11,#0
LDR R1,[R12,#824] \824=&338
STR R11,[R12,#824]
ADDVSS R11,R0,#0
MOVS R0,R1 \same effect on NZVC as TEQ
ADD R1,R12,#&0338
SWINE XZapRedraw_LoseFont\unchanged

When I started to search for the culprit, by changing fonts etc, another error popped up, this time in ZapRedraw.
Provoke it by loading/ typing in some text in !Zap,
press Menu, → Display —>Font→Bitmap font—>
and then change the x/y parameters by clicking in menu Font list, e.g.08X16 to 08X12.
The error is Abort on data transfer at .. and is at offset &55F0 in ZapRedraw.

This module is in ZapFonts.ZapRedraw
its source is !ZapRedraw.s.ListFonts at label get_font_by_name:

MOV R11,#1 ; count number of dots
l$l LDRB R14,[R0],#1 ;
STRB R14,[R6],#1 ;
CMP R14,#‘.’ ;
ADDEQ R11,R11,#1 ;
CMP R14,#32 ;
BHS l$l

TST R2,#lff_encodings ; go through the list
LDREQ R6,[R12,#list_of_fonts] ;
LDRNE R6,[R12,#list_of_encodings] ;

A character is written at R6, but R6 is already overwritten 5 instructions later.
The code that calls get_font_by_name is at label decode_menu, sublabel loop$1, there we find:
LDRB R6,[R7,#-1]!
So R6 looks like being a byte, can hardly be zeropage-safe then, and writing of the string at R6 is perhaps not needed anyway.
R6 also is not listed in the registers mentioned in the comment before get_font_by_name.
So I changed this ‘STRB R14,[R6],#1’ for a NOP instruction, and the bitmap fontlist worked again.

1$1 LDRB R14,[R0],#1
MOV R7,R7 \ ‘NOP’ instead of STRB R14,[R6],#1, or remove it in the source
CMP R14,#‘.’
ADDEQ R11,R11,#1
…etc
Have other people on this forum also experienced these errors/fixes?

Thanks for these fixes. I’ll see if André makes a tim2 version of the modules (if not I’ll have to see if I can build the modules myself)…

Have other people on this forum also experienced these errors/fixes?

I think the sad fact is that very few people use Zap any more – I have difficulty believing that code colourisation failed on the Pi 2, which has been around for two and a half years now (Feb 2015) and in that time the issue never seemed to be raised (I searched the forum for ZapMJE, etc)… Hmm.

I have difficulty believing that code colourisation failed on the Pi 2, which has been around for two and a half years now (Feb 2015) and in that time the issue never seemed to be raised (I searched the forum for ZapMJE, etc)… Hmm.

I think the fact that there were various elements of strange behaviour on various newer systems meant that 32 bit users had reason to look elsewhere for the functionality.
For example, how many zero page problems were there causing little niggles¹ that couldn’t be tracked down?

¹It is interesting how many software maintainers have fixed zero page errors that absolutely must have caused intermittent problems but no one quite knew why they occurred. Jeffrey instigated a lot of fix work on broken software as a side effect when he created the ZeroPain module. People who don’t use 32 bit systems actually have reason to thank him.

I think the sad fact is that very few people use Zap any more

I certainly still use it by preference. I have simply learnt to live with the various niggles. The ability to report problems and get them fixed ceased a long time ago.

I have tried StrongEd several times, but just cannot get my head around it, and so end up reverting to Zap. I guess I need to have yet another go 8(.

The ability to report problems and get them fixed ceased a long time ago.

Second life? Start reporting and see whether Rick can find the problem.

Am a user of both StrongEd and Zap.
So well done Rick – with the updates to Zap.

Zap used to get upset loading ‘Message’ files – used to crash out :-(

Back along – there was a useful function on a loaded ARM prog – where ADRL was modified to below.

ADRL r0,address ;pointed to address
ADD r0 etc ;did nothing ie nop

I’d got used to having to use StrongEd, which is okay, but it’s absolutely wonderful to have Zap back! BASIC colourization worked; text files worked; Obey files crashed but are now sorted. I’ve not tried other types of files yet – the only other type I’m really likely to use are CSV spreadsheet files, and data files of various, possibly unknown, formats.

Steve:

I think the fact that there were various elements of strange behaviour on various newer systems meant that 32 bit users had reason to look elsewhere for the functionality.

What – nobody went and moaned on the forums? Or was the moaning on comp.sys.acorn.* instead? I’d have missed that, if it was…

For example, how many zero page problems were there causing little niggles that couldn’t be tracked down?

Loads, I’m sure…

Ditto for the ARMv7 changes where we’re discovering stuff like LDM Rx!, {R...Rx...R} that you have to wonder how it ever worked in the first place.

Start reporting and see whether Rick can find the problem.

I’m going to kick this one over to André Timmermans for the time being. The reason for this is that while I could make the modifications (I have Andrés sources), there is the obvious danger if we have one build by Tank, another by André, and a third by me, and they all get out of step with each other. We probably need a CVS or something. :-)

Chris:

I have tried StrongEd several times, but just cannot get my head around it, and so end up reverting to Zap.

StrongEd is so very like Zap, but yet so very different. I guess the problem is that while it broadly seems to offer the same sort of functions as Zap, but uses totally different ways to how Zap does things.
A good example is “List of found”, for times when you want to search an entire selection of code (such as the entire kernel source) to see where a function is and what calls it.
Both editors can do this. In Zap you press “F4” and select “to Window” and “All files” and then enter the search phrase as usual. In StrongEd, it is Edit→List of Found (or press F2) and choose your options, though Simple engine and All scope usually does the job. But there’s a lurking gotcha. In Zap, Adjust-clicking on a match will remove it from the window, so if you are doing something lengthy like changing all of this label to be that label (as was necessary when rebuilding ZapMJE), the list can be kept tidy by removing each item from the list as it is dealt with. In StrongEd…Adjust-click goes to a list item, and closes the list window… I’m not sure there is a way to remove items from StrongEd’s list?
Another thing is that StrongEd’s assembler colourisation is ridiculously simplistic compared to Zap. I can have SWIs in blue and branches in light grey and ‘normal’ instructions in white, but in StrongEd this colour counts for the entire line, while in Zap the instruction is coloured, then the registers/numbers/punctuation are coloured according to what they are (different from the instruction colouring). This makes reading disassemblies a lot easier in Zap. Also, pressing Return on an instruction permits one to edit the instruction that is at the cursor location. Maybe StrongEd can do this as well? Pressing Return in StrongEd adds… a single &0A character, while pressing Delete/Backspace deletes entire instructions (either before or after as applicable for the key pressed). Zap deletes instructions with Ctrl-Delete because it’s not something you’d want to use much, and I think the only way to add a random byte to disassembly mode is to switch to a different mode… because it’s not something you’re ever likely to want to do in that context. [using StrongEd 4.69f9]

On the other hand, StrongEd is able to quit and reload and come back with all the files in the same places on the screen. That’s a nifty feature.

This isn’t to say one editor is better than the other as I’m sure for everything Zap can do better, StrongEd can do something different better. What this chunk of text does is highlight some of the differences in how the two behave when doing the same things – thus hopefully helping to highlight why using one or the other isn’t as simple as loading the alternative.

Colin:

Back along – there was a useful function on a loaded ARM prog – where ADRL was modified to below.

That wasn’t Zap, that was DebuggerPlus…

Allows you to set various MemoryI and Debugger_Disassemble features.
Available switches:
    -FDwithR13   use FD with R13, eg. STMDB R13 -> STMFD R13
    -APCS        use APCS-R register set and recognise C function entry
    -LFMstack    use stack notation with LFM & SFM where possible
    -LFS         use LFS and SFS in preference to LFM & SFM
    -QuoteSWIs   put quotes around SWI names
    -UseDCD      use DCD instead of 'Undefined instruction', and BRK where
                 DCD &x6000010 would be used
    -UseVDU      use VDU x instead of SWI OS_WriteI+x
    -ANDEQasDCD  use DCD instead of ANDEQ, MOV Rn,Rn (same register) etc.
    -UseADRL     use ADRL/ADRX instead of ADR then ADD/SUB on same reg
    -UseADRW     use ADRW instead of ADD/SUB Rn,R12,#m and LDRW, STRW,
                 LDRBW, STRBW instead of xxxx Rn,[R12,#m]
    -LongMul     append L to UMUL, UMLA, SMUL, SMLA (thus using the
                 'official' forms)
    -UseLDRL     use LDRL instead of ADD/SUB Rn,Rm,#o + LDR Rn,[Rn,#p] and
                 ADD/SUB Rm,Ra,#o + LDR Rn,[Ra,#p]! and STRL instead of
                 equivalent STRs.
                 (The LDRWL form is enabled by this *and* UseADRW)
    -UseNOP      use NOP instead of MOV R0,R0
    -OldPSR      use the old PSR suffixes _ctl, _flg, _all
    -Wide        disassemble for wide display
    -HSLO        use HS and LO instead of CS and CC
    -Shift       use x<<y comments where possible for numbers >= 8192.
                 This affects arithmetic and logic instructions. y is
                 restricted to multiples of 4 if possible, unless x=1
    -Lower       force all register names to lower case
    -ConstShift  display non-standard constant (x ROR y) as #x,y
                 This affects arithmetic and logic instructions with
                 constants for which a simpler representation is possible,
                 e.g. 16 ROR 2 == 4 ROR 0.

All the switches take a single character parameter: "0" or "N" (off), or "1"
or "Y" (on). To leave a switch unchanged, don't include it in the command.

Use *DisassemblerFlags on its own to display the current state.

This explains all the seemingly useless options in the mode menu for the disassembly.

I kind of wish the current incarnation of Debugger could do some of these things, specifically -FDwithR13, -ANDEQasDCD, -UserADRL, -UseNOP, and -ConstShift.

What – nobody went and moaned on the forums? Or was the moaning on comp.sys.acorn.* instead?

I bet if you really search there will be stuff where the response from a known developer/user was essentially “works for me”¹ and thereafter all goes quiet because of course no one else can reproduce the error.

¹ Which if you think about it would be the case when a edge use case intermittent fault occurred due to a zero page error:- works for most instances but an obscure combination on the machine of the fault reporting user actually regularly triggers the reported error.

A good example is “List of found”, [..] to see where a function is and what calls it.

You just place the cursor in the function name and do Ctrl-F (for current text) or Ctrl-Shift-F (for all texts). This works for every ‘word’ in a text.

If you want to jump to a function’s definition then use Ctrl-G or Ctrl-Shift-G.

In StrongEd…Adjust-click goes to a list item, and closes the list window… I’m not sure there is a way to remove items from StrongEd’s list?

A Shift-Select click will remove a line from an LoF. Shift-click on a filename and all matches for that text will be removed. This also applies to throwback windows.

Another thing is that StrongEd’s assembler colourisation is ridiculously simplistic compared to Zap.

StrongED 4.70a12 (latest test release) will colour assembler in similar fashion to Zap. This version supports annotations for embedded function names and Clib calls too.

Also, pressing Return on an instruction permits one to edit the instruction that is at the cursor location. Maybe StrongEd can do this as well?

Yep, just press Space. If you want to use Return then just change the keybinding.

Great to see Zap getting some TLC!

Rick, are you still working on this?

Rick, are you still working on this?

Not at the moment. I’m waiting to see if I hear anything from André or Tank regarding Jan’s fixes posted above, because I really don’t want to create “yet another incarnation” of the Zap(Redraw) module(s) if I can help it. That would make three…

That would make three…

Good point! Less than ideal.
One version would be best.

Jan de Boer:

and then change the x/y parameters by clicking in menu Font list, e.g.08X16 to 08X12.
The error is Abort on data transfer at .. and is at offset &55F0 in ZapRedraw.

Many many many thanks for this fix.

The bug was horrific on my Pi2 – a total and instant system freeze; which would mean debugging to see what was wrong would have been extremely tedious/difficult.

Armed with your fix, it’s all working again. :-)

Can anyone advise a bystander like me where you need to go to get the latest and greatest version of Zap these days? Is there a single location for patches and so on?

Can anyone advise a bystander like me where you need to go to get the latest and greatest version of Zap these days? Is there a single location for patches and so on?

For 26 bit machines: Stick with the existing distributions, you can find the v1.47 beta at http://zap.tatarus.org/

For 32 bit machines: The most recent build I know of is the rick-04 build that I made yesterday ;-) which incorporates earlier fixes by André and tank. https://www.heyrick.co.uk/blog/index.php?diary=20180501 (updates an existing installation, plus a dump of the sources so they’re “out there”). If you don’t want to read the crap I’ve written, the links are at the bottom of the page. But do enjoy a nice cuppa while you’re there…

For 32 bit machines without an existing installation, I would imagine the simplest method might be to install my “zap ultimate” ( https://www.heyrick.co.uk/random/zap_ultimate.zip) and then upgrade it to rick-04 from the above link.

I have not made a ‘normal’ 32 bit installation of all the latest bits yet. I do wish to make a new Zap Ultimate for 32 bit systems, it just isn’t going to happen today.