Suggestion - Better options for CP/M disassembly with mame

[peteri]

This is a suggestion / did I miss something issue feel free to ignore

I've been trying to disassemble and debug some CP/M code running on an Osborne 1 emulated in mame.

There are a few issues with this:

• To start the system up I need to interact with the mame emulation before starting to debug, at the very least I need to hit return in the emulator to get the system to boot from floppy.
• It would be nice to extend SKIP to allow me to tell DeZog not to disassemble CP/M and do just the code I want.
• I need to type in a CP/M command to start things up, although I could use equivalent of "autoexec.bat" to fix this.
• In an ideal world I could debug Z80 code in an Apple ][ with Z80 softcard but that does require some fancy banking support for both processors and I feel is a bit out of scope.

Currently I'm telling the mame debugger to put a break point at 0100H and sending a continue command which at least makes debugging work reasonably well although I do have to do a "Move program counter to cursor" when the breakpoint fires.

            "commandsAfterLaunch": [
                "-exec send Z0,100,0",
                "-exec send c"
            ],

It would be nice if the PC got reset to 100H after the breakpoint. There doesn't seem to be a way to manage breakpoints or control running code from the debug console.

It might be nice if I could have a command sequence something like

-breakpoint 0x100 count 2 
-run
-disassemble 0x100

The count would be useful to allow the breakpoints to fire twice (once for the command prompt, once for my code)

Any suggestions here, did I miss something? Or should I just have a quick attempt myself?

IMPORTANT: I'm just making some suggestions here for my use case. Feel free to ignore me, I just want to make sure I've not missed something.

[maziac]

Hi,

"although I do have to do a "Move program counter to cursor" when the breakpoint fires" that is because DeZog is not aware of that breakpoint. I.e. what you do with "-exec send ..." completely bypasses dezog.

You cannot set a (dezog) breakpoint other than via the UI by placing at the file line. As a workaround you can create a file that can be used for reverse engineering as well: In the launch.json add e.g.:

            "revEng": [
                {
                    "path": "reveng.list"
                }
            ],

And in the revenge.list file add the address:

0100

Now place a breakpoint next to line (next to 0100). Anyhow this does not support a 'hit count' either.

I'm not sure if my suggestion here is any better than what you've tried already.

For the disassembly: dezog will always create a disassembly if no source or list file is available for the PC position. Otherwise vscode would point nowhere and stepping etc. would not be possible anymore.

[peteri]

Thanks for the reply, sounds like I've not missed some functionality that's already in place.

It's not a bad experience, just adds a tiny bit of friction when starting to debug, what doesn't help is the code has a lot of jp(hl) and code flow is sometimes by putting new return addresses on the stack, but that is very much a Microsoft issue (it's their Macro-80 assembler I'm working on).

TLDR: just wanted to check I wasn't being too stupid and missing a feature.

[peteri]

Closing this issue with thanks for the reply.