Zap Disassemble

So who is going to fork James’ Zap GitHub repo and takes over coordination of all the Zap fixes floating around?

It would probably be better, if you’re changing both Zap and DebuggerPlus,

Not touching DebuggerPlus. ;-)

However…

to use an active method of presence detection rather than the passive groking of version numbers

Yes, that is rather unpleasant. It would have been much better if some sort of identification flag could have been presented to Zap.

My plan, given that:

• DebuggerPlus never made it to 32 bit
• There’s a perfectly decent version of Zap for 26 bit machines
  ..is to yank out most of the DebuggerPlus stuff and look to supporting the format flags now available in the standard Debugger (via a system variable). This will mean changes to the menus and such, so is unlikely to nicely co-exist with the DebuggerPlus options.

Code that used DebuggerPlus in the Zap module is switched off with a setting in the source code.

It looks like the code switch does a lot more than toggle DebuggerPlus. Zap pretty much works with both (trying the Plus, and falling back if that didn’t work). I think, without that switch, the Assembler mode is stupid and barely different to a straight output from Debugger. :-/

The problem for ZapBASIC was a side effect. A function calls the Debugger to get the current instruction as text. It then calls another function which checks the module version and, if present, does an undocumented (?) SWI (that Debugger_63 again). This also happens in Zap. Unfortunately in ZapBASIC, most of the function that deals with setting up the minibuffer is on a VC conditional, and the failing SWI sets V. So I’ve left the version number checking alone for now and simply disabled the code that would have set V. This may or may not break use with DebuggerPlus on 26 bit systems, but I’m not bothered as these builds are not aimed there…

The ‘fix’ is to increment the Debugger module version comparison number to #&300

That’s not a good fix, though, as it is just pushing a possible problem until further down the line. Granted, both RISC OS and myself may cease existing before v3.xx is reached, but still. ;-)

So who is going to fork James’ Zap GitHub repo

I’ve downloaded it, and am dealing with the filename mess (comma filetype suffix) as the need arises. It’s not a managed repository, it’s a directory on my SD card…

and takes over coordination of all the Zap fixes floating around?

My versions are based upon tim-01 which I believe is the most recent prior. I left things for a while to see if somebody who has already played with Zap would be willing to continue… silence. So I guess it’ll be me. But there’s no repo and nor will there be (never got the damned things to work with RISC OS). If you want a zip of all the sources in a DDE buildable form, just ask. I’ve not done one yet as most of the extensions are in Git-munged form. Stuff that still needs to be sorted out…

So: Here’s my update that works with a faked Debugger v2.50. Zap and ZapRedraw should be the same so you can ignore these if you picked up rick-01 yesterday.
Place ZapBASIC inside !Zap.Modules.!ZapBASIC.

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

The Zap distro from GitHub is a horrible mess due to the issue of filetypes not being known on non-FileCore systems.

To aid with this, has anybody written a utility that will take a bunch of files (recursive into subdirectories) that has names like thingy,fff and whatever,fec and strip the comma-stuff and apply the indicated filetype?

Lua:

local dir, sys in (require "riscos")

local function set_type(pathname, filetype)
  assert(0 <= filetype and filetype <= 0xFFF, "Filetype out of range")
  local e, err_msg = sys("OS_File", 18, pathname.."\0", filetype)
  if not e then return nil, err_msg end
  return true
end

local function rename(pathname, new_pathname)
  local e, err_msg = sys("OS_FSControl", 25, pathname.."\0", new_pathname.."\0")
  if not e then return nil, err_msg end
  return true
end

local function set_types(dirname)
  for leaf, ftype in dir(dirname) do
    local pathname = dirname.."."..leaf
    if ftype == 0x1000 or ftype == 0x2000 then
      set_types(pathname)
    else
      local name, ftype2 = leaf:match("^(.+),(%x%x%x)$")
      if name then
        if set_type(pathname, tonumber(ftype2, 16)) then
          rename(pathname, dirname.."."..name)
        end
      end
    end
  end
end


set_types(arg[1])

Nick Roberts’ Rename has a built-in function to strip ,xyz from filenames.

Rename – is able to change say ‘file.txt’ to ‘file’ and sets the file type to &FFF.

Nick Roberts’ Rename has a built-in function to strip ,xyz from filenames.

Thanks for that. I probably would have taken ages to work out the syntax, but it had a ready-made example to do exactly what was necessary.

The next questions:

• Does anybody know what the “coopt” library is, and where I can download it?
• Ditto for “libgnu”, where would I find that and its header files? I’ve rummaged all around GCC 3.4.6 (the last one that made sense) and didn’t turn up anything.

This is because MakeMenus and MenuConf never got translated to 32 bit, so editing the menus is more annoying than it would otherwise be; and both of these programs refer to weirdo libraries that I’ve never heard of before…

If anybody would like a copy of the Zap font editor Zed, I’ve built a copy and placed it at http://heyrick.ddns.net/files/zap-zed.zip

I think I’ve found the sources to libgnu at http://zap.tartarus.org/downloads/ds/GNU/32/src/ (libgnu.zip) but I can’t build them as the latest AOF compatible version of GCC is broken (alignment checking ON it reports “UnixLib detected recursion of signal SIGSEGV. Exiting.” and with checking OFF it reports “”main.c", line 1901: main: Assertion failed: BOGUS_UPDATE_STATUS".

Useful.

If I can’t find 32 bit friendly versions of these libraries (which surely exist as the other configuration tools have been converted), I’ll need to give up on this.

Thanks for all the help with Zap VRPC-DL RO5.25.

I did try changing the module number to 1.99 in the ROM – but ended up with a red screen at startup – does the ROM do a check on startup?

Ended up putting a 1.99/2.02 Debugger module in predesk.

When starting up in RO4.02 mode – Debugger Plus gets loaded.

(if needed I have a If32bit and If26bit utils in the Library dir)

If Rick can’t find the Libs he is looking for – perhaps FF8 ‘MakeMenus’ & FF8 ‘MenuConf’ can be ‘what I call hand patched’ to 32bit.

but ended up with a red screen at startup – does the ROM do a check on startup?

It may do a CRC or checksum?

When starting up in RO4.02 mode – Debugger Plus gets loaded.

There’s an option in the configuration to toggle whether or not it gets loaded. Iconbar menu → Misc → Autoload.

perhaps FF8 ‘MakeMenus’ & FF8 ‘MenuConf’ can be ‘what I call hand patched’ to 32bit.

I doubt it. They’re written in C, and converting 26 bit CLib to 32 bit CLib is somewhat different to patching in a different SWI name. I’ve not had any success with hacking C programs like that.

For now, it seems to suffice to quit Zap, edit the live menu structure, and restart Zap. The primary difference is the count and offsets are applied by MakeMenus, though the basic file layout is the same (it’s not as if it translated it into a binary format – thankfully).

David said

As far as I can see DebuggerPlus is totally obsolete in Zap

I’m going to quibble about the word ‘obsolete’. Unless you mean that the built-in debugger does everything that DebuggerPlus does, then it is not obsolete.

It may well have been disabled in the 32b version, but the 26b Zap has a long list of debugging options that DebuggerPlus implements:

• LDMFD/LDMDB
• Optional APCS-R
• ADRL/ADRX/LDRL
• NOP
• HS/CS
• Shifted form in TEQ
• Upper/Lower case registers

etc – so it may not work but is it ‘obsolete’?

Steffen nobly said

So who is going to fork James’ Zap GitHub repo and takes over coordination of all the Zap fixes floating around?

<Audience breaks out in appreciative applause>

Well done Steffen for volunteering! I’d be very grateful for a start. ;-)

I toyed with doing it myself but came to my senses. I have too much to do.

Rick said

[sensible stuff]

Is DebuggerPlus beyond fixing? Do you want me to look at it?

Is DebuggerPlus beyond fixing? Do you want me to look at it?

I’m curious whether DebuggerPlus could be made obsolete by adding the features to the standard Debugger module.

Do you want me to look at it?

There’s almost no flag preservation at all in there. It’s a simple 32b conversion.

Is source available? If not I can make one.

I have too much to do.

Followed by…

Do you want me to look at it?

;-)

It looks like the “most recent build” is the one sitting on my harddisc. As I said earlier, I can make archives, but no repo.

Is DebuggerPlus beyond fixing?

Yes. It doesn’t do the rather useful exception dump stuff, it probably doesn’t understand anything post-StrongARM, and I doubt it does anything to do with Thumb either (not that Debugger is hot there). Debugger will, at least, understand some VFP too!

It will likely be a lot more useful/beneficial to look at tweaking Debugger to do what DebuggerPlus used to offer.

We’re partway there:

*Set Disassemble$Options meh
Valid options are: [-arm | -apcs] [-sb | -v6] [-sl | -v7] [-fp | -v8] [-r13 | -sp] [-r14 | -lr]

(note how it’s not in the Debugger$ namespace! ;-))

So Debugger can now use APCS register naming, or standard with sb/sl/fp/sp/lr options (so could do R0-R12, SP, LR).

What I think we need, off the top of my head and likely missing stuff:

• Support for Long references (ADRL, LDRL) so these appear with the second instruction as “ADRL” with the correct address, not as an ADR followed by an ADD.
• Ditto LDRL/STRL.
• Choice of FD for STM/LDM using R13.
• etc

Edit:

• Extra bonus points: Flagging stuff that is bogus. SWP for ARMv8, plus stuff like STR R10, [R10, #-4]! and LDMFD R13!,{R0-R2,R13,PC}…

Is source available?

There was a time when DebuggerPlus was far better than Debugger.
This is no longer the case, so I really do think bringing some of its functionality to Debugger would be the sensible move.

However… http://old-www.moreofthesa.me.uk/progs/Debugger.zip
Source in the ‘s’ directory.

@edwardx
Nice to see Lua being used :). However your code falls into trap – very easy to do when using riscos.dir.
It is what I call sawing through the branch while you are still sitting on it ; in technical terms, altering the state, in this case of the filer, from within a loop over a filer structure. What you should be doing is generating a list of the renaming commands as you scan the directory structure, and only execute them after you have safely finished the scan. Mind you, I have never seriously tried to test this, but I think it is common sense. I suspect that OS_GBPB will throw a wobbly if you rename a file in a directory while you are iterating over it.

Rick said

Yes.

I came not to praise DebuggerPlus, but to bury it.

Gavin pointed out

I suspect that OS_GBPB will throw a wobbly if you rename a file in a directory while you are iterating over it.

The behaviour is undefined. Anything can happen, including getting the same file again and missing another entirely. It is delegated (of course) to the underlying FS and it is not stateful.

Technically there’s no reason to believe that consecutive reads will necessarily deliver every file once and once only even now. If we ever get true multithreading (as opposed to some Tube-like compromise) all bets are off with those GBPB calls.

I came not to praise DebuggerPlus, but to bury it.

Like many things, it was good in its day.

Much like RISC OS then. And myself.

nemo said…

Well done Steffen for volunteering! I’d be very grateful for a start. ;-)

I toyed with doing it myself but came to my senses. I have too much to do.

As a passionate hater of Git and even more so GitHub, along with nothing more than a generic “I am a RISC OS user” interest in Zap (I am a StrongED guy since Guttorm made StrongEd 2), I might not be the ideal choice…

A propos too much to do, I have to get that CDVDBurn release done ASAP. After that, I only have a few more projects to finish, so ask me again in 20-30 years.

ask me again in 20-30 years

:-D Honestly, you should see my to-do list.

I am a StrongED guy

This means war.

I probably should have stayed in bed on this miserable rainy Sunday and watched DVDs… but… I didn’t.

I broke Zap instead. :-)

Here’s what’s new in the “rick-03” release:

• Rebuilt ZapMJE and ZapObey and reapplied the earlier fixes, now it’s building as a part of Zap and not a standalone hack.

• Clicking on a bitmap font SIZE will no longer kill Zap…and quite possibly the entire machine (thanks to Jan).

• Various menu modifications for stuff that’s different in a 32 bit world (UK only, at the moment).

• Print code changes to remove SWP instruction (thanks to Jan).
  • Printing seems a bit rubbish with SPrinter and a disaster with PrintPDF – both with and without the fix. Did this ever work!?

• Quick print code now outputs to a file in !Scrap instead of writing directly to Printer: (which is by default Parallel: but something in the Desktop boot changes it to Null: which is much safer). At any rate, “printing” to a file is more logical when the older methods are pretty much obsolete (ie network printer (and by network they mean ECONET!)).

• Code mode no longer works with DebuggerPlus¹ – it now works with Debugger. You now have the option to (globally) choose whether to see disassembly in ARM style or APCS style. There’s also an alternative names option (show R13/R14 as SP and LR in ARM mode, or show sb,sl,fp as v6-v8 in APCS mode).

• A snazzy little Obey file to install all the bits to save you doing it by hand.

It’s working nicely here. Hope it works as nicely for you too.

http://heyrick.ddns.net/files/zap-rick03.zip
(note: these updates are for RISC OS 5 ONLY)

¹ It still likely makes loads of calls to unimplemented SWIs (such as Debugger_Flags), but these have no side effects so I’ve left them as-is.