Any ARM Debuggers Ported to RO5 ?

I’ve been playing with Theo van der Boogaert’s !ARM_Debug on my RiscPC. Seems to work pretty well in USR or SVC modes. ARM_Debug can single-step through (ram-based) modules :-) I’ve been using ARM_Debug to single step through Paul Thomson’s Debug v1.00 as posted by Rick on his ‘Heyrick’ website. Using one debugger to single-step through another debugger – amazing it works really ;-)

I’m wondering if there’s any chance or porting !ARM_Debug to RO5. This would be a very useful tool for 32-bitting old 26-bit utilities and apps.

Colin (of this parish) mentioned that he was attempting to 32-bit ARM_Debug a couple of years ago – any news ? Is there a fundamental reason why the methods used by ARM_Debug cannot be ‘easily’ ported to 32-bit. Assuming that Theo doesn’t mind etc…

Is anybody else working on porting one of the other 26-bit debuggers ?

Ralph

In the absence of any reply, I’ve started 32-bitting !ARM_Debug myself. !ARM_Debug is a well written programme and mainly comprises a BASIC WIMP front end and a module to do the breakpoints and single-stepping in modules or application code. Drucks !ARMalyser is really useful for finding the main items that require attention (TEQPs etc.). I decided to 32bit the RO3.7 SA version of !ARM_Debug rather than the RO4 SA version, although there’s probably little difference between them.

Untangling the 26bit RO3.7 PC (i.e. R15) with status and control bits into the 32bit PC and PCR registers has been a lot of work, as any debugger will be doing a LOT or manipulation of these registers. They are very inter-twined on the 26bit RO3.7 version of !ARM_Debug, as you would expect.

Theo van der Boogaert is the original author of !ARM_Debug. Theo calls the module single stepper the “singlestepper” in his help file. He has added a lot of functionality over the years – largely for his own use, according to his notes.

The !ARM_Debug ‘singlestepper’ module runs on the RPC 3.7 in mode 31, which is 800 * 600 in 16 colours. Unfortunately mode 31 is not supported by RISCOS 5.28. I’ve had a quick ‘hack’ at changing some of the colours (see below) just so I can test stuff out (e.g. you can just see from R15 that there’s still lots of stuff to test and errors to fix). Is there a way to get the 4bpp (16 colour) 800 * 600 mode to run on the RPi running RO5.28 ? Can I use ColourTrans_WritePalette for instance ?? Any suggestions on best way forward welcome – I don’t particularly want to convert all the sprites to 256 colour sprites.

Here’s a current screenshot of the singlestepper module at a break:

Edit. Sorry, I need to work out how to attach images to the forum…

I don’t think you can upload an image, you might be able to link to one online.

Is there a way to get the 4bpp (16 colour) 800 * 600 mode to run on the RPi running RO5.28 ?

No, the hardware doesn’t support it. You can possibly workaround it whilst you’re working on the debugger by having ADFFS loaded and letting it emulate the mode for you. How that will interact with !ARM_Debug I don’t know – it depends on how well behaved it is. If it shuts down IRQ/FIQ its certainly not going to work.

Ultimately, you’ll want to switch it to a 24bit mode and adjust the code accordingly.

Isn’t changing mode significantly perturbing the machine state you’re trying to debug?

Ultimately, you’ll want to switch it to a 24bit mode and adjust the code accordingly.

Just out of interest, given that the 16 colour modes are paletted, would it work to switch to a 256 colour mode and have the first 16 colours set up as for a 16 colour mode?
As long as it doesn’t try poking the screen memory directly….?

Given that it will be plotting 4-bit sprites, probably untransformed, you end up with two sprite pixels per screen pixel in a 256 colour mode. Yuk. Could set a blending palette! (Why are there sprites in a debugger, he asks?)

Best thing would be to for a minimum of a 256 colour mode. All you need to do is run all the sprites through one of the ChangeFSI powered batch processing apps to convert them all in one go.

Beware that Pinebook Pro only supports 16M colors. Isn’t the resolution hard-coded to that of its LCD screen?

I would have suggested that everyone just uses 16M colours, but someone would be along saying they can’t do that on their A4 loptop¹.

^{1 Other ancient machines are also being kept going, just to make sure we can never move on :)}

A module that could just replacate the low colour modes would be handy.

The simplest solution would be to create a lookup table using ColourTrans_SelectTable , which can be used with OS_SpriteOp 52 to plot <=8bpp sprites in any screen mode.

Thanks for all the suggestions and comments.

The sprites on the ARM_Debug singlestepper module are just there to provide various on-screen buttons (for mouse control), and also to show whether the N,Z,C,V,I,F flags etc. are clear or set.

Stuart’s comments about the sprite scaling are correct – the Mode 31 sprites are all half the size they should be. And ‘bright pink’ instead of multiple shades of grey. Not pretty but doesn’t really affect my getting the single stepping working correctly. All of the control buttons already have keyboard single-letter shortcuts (e.g. ‘S’ for single step etc.).

I’m running my RiscPC side-by-side with my RISC OS RPi to check whatever code I select is stepping through correctly and following all the correct branches etc.

Cameron’s suggestion sounds promising – I’ll have a look into this when I’ve added all the extra code required for the PCR register(s) in the single-stepping routines.

Ralph

Here’s a ‘rookie’ question…

!ARM_Debug uses a sprite file named ‘Sprite31’ that contains 90 sprites. The ‘31’ denotes the screen mode in the old RISC OS manner.

When I drag ‘Sprite31’ to ChangeFSI with output set to a 256 colour mode, ChangeFSI only outputs the very first sprite in the file ‘Sprite31’ and seemingly ignores the other 89 sprites. Why doesn’t ChangeFSI convert all the sprites in an input sprite file ? Or am I missing something really obvious ?

Ralph

Because ChangeFSI interprets a sprite file as having one image inside of it.

A handful of minutes with BASIC ought to get you…

• Load the sprite file, and create another large enough
• Save each one in turn to temp
• Call CFSI to convert it
• Pick up the result, load it into the other sprite file
• Save the other sprite file

Then just let it chunder through the sprites until they’ve all been converted.

A handful of minutes with BASIC ought to get you…

And then a bit of toolbox wrapper code and you get a drag and drop GUI :-)

Not far down the road – write a suitable prompt for ChatGPT and it will do it for you

write a suitable prompt for ChatGPT and it will do it for you

I have yet to get anything from ChatGPT that actually builds and/or works correctly if it’s larger than a smallish function. Sometimes it gets “sort of” the right idea, sometimes it just messes up badly while confidently telling you it’s the right answer.

See https://heyrick.eu/blog/index.php?diary=20230306 (about two thirds of the way down) and https://heyrick.eu/blog/index.php?diary=20230919

Suffice to say, I’m not a fan of “just get an LLM to do my work for me”. It can help, certainly (see https://heyrick.eu/blog/index.php?diary=20230920) but it still needs a biological entity to make sense of what the Artificial Idiocy claims is correct.

And then a bit of toolbox wrapper code and you get a drag and drop GUI :-)

Isn’t Toolbox a bit overkill? It’s just going to be “accept a sprite file dragged to it, open a window, icon to set the new sprite name, and a draggable icon to set where to save it”. Anybody who’s ever dealt with a Save box or a drag-load will have already written most of the necessary code. ;)

By the way, where does one get !ARM_Debug from? Google is… not terribly helpful. It’s not helped that there’s a well known artist with a very similar name. I tried Bing, but that took “arm” and “debug” as separate things and, well, you can imagine how helpful that was.

Wayback time…

https://web.archive.org/web/20070712233605/http://home.wanadoo.nl/tvdb/

make sense of what the Artificial Idiocy claims is correct.

You’re thinking that if ChatGPT had a vote, then it would wear a red baseball cap?

You’re thinking that if ChatGPT had a vote, then it would wear a red baseball cap?

If a customer knows what he wants and is able to specify the requirements comprehensively and without ambiguity, chances are the programmer may deliver a satisfactory solution.

The same is true with AI. Tell it what you want clearly and unambiguously and you may get lucky.
I have found it works with python, though I restrict my prompts to a single function at a time.

I wonder if the Prog could be controlled over the SerialPort – from another Arc or Pc – change the Sprites for extra characters.

[Edit]

Something running on second machine like !Hearsay

I suppose two Arc emulators can’t talk to each other.

Well, after much ado I eventually went for Druck’s suggestion for changing the sprites to a 256 colour mode. This took about an hour to do ! And half an hour of that was moving the new 256-colour sprite files to my RO3.7 RPC to combine all the files into one sprite ‘Sprites32’ file using RO3.7 !Paint. Drag and drop a load of sprite files into a sprite container file does not seem to work on !Paint on RO5 (5.28 10-Feb-2024).

I spent about 3 days going down the OP_SpriteOP 52 route, and almost got this working. However, !ARM_Debug originally uses OS_SPriteOp 28 calls which uses current graphics coordinates whereas SpriteOP 52 uses user coordinates (i.e. the same at SpriteOP 34). Easily solved I guess, but by then I just decided to try another option. FWIW one of the sprites is essential as it blanks out the register values each time they are updated – when the sprite is the wrong size the register values all get written on top of one another, and are unreadable.

I’ve been concentrating so far on the module break and single stepper, and this is now largely working OK apart from the PCR flags (not finished this yet). Theo calls the module break a hard break – as it temporarily inserts a Branch into the target module code, which points into the debugger module. After than the single-stepper uses ‘soft’ breaks, and each target instruction is actually run in the debugger module address space.

Lots of work still to do…

Ralph

Any ideas how you could send a screen through the Serial port to another machine?

One easy way would be to output the register information in an ASCII serial format to display on (say) a DEC VT100 terminal. And run a VT100 terminal emulator on the target machine. Very old school I guess, but easy to implement and low risk. You could even use the keys on the VT100 terminal to advance the programme etc.

Although this would be fairly slow, even on a relatively fast serial link.

Back to the 1960s…

Ralph