MAME gdbstub limitations

[ramiropolla]

Hi,

I see that you've stumbled upon a few limitations of the gdbstub implementation on MAME (only 1 connection, no paging). I didn't implement this at first because I didn't know how to test it, and I didn't know how other debuggers behaved (for example, what gdb stub commands do debuggers send to request paging or to close/open a new connection). I'd like to address these issues upstream.

Can you explain how it could be improved from an user point of view?

Thanks,
Ramiro

[maziac]

Hi,

One connection only is fine, but the problem was that after disconnecting I cannot reconnect.
This was one major problem that I worked around by restarting mame for each debug session.
Although it works, it is slow as it takes quite some time for mame to start.

From protocol level I was missing a few things as well.

The main description can be found here. (These were my notes implementing the gdb protocol to talk with the gdbstub.)
https://github.com/maziac/DeZog/blob/main/design/EmulatorInterface.md#mame
There is a chapter "DZRP vs GDB Remote Protocol". The DZRP is used by dezog to communicate with other emulators (CSpect, the internal simulator) or the ZX Next HW. Every emulator only supports a subset of DZRP.
(See https://github.com/maziac/DeZog/blob/main/design/DeZogProtocol.md#important-note)
Especially the sprites and table related are ZX Next features and not required for MAME (at least until ZXNext is supported by MAME).
But what is very crucial are these commands:
CMD_WRITE_BANK, CMD_SET_SLOT (set a bank).
CMD_READ_STATE, CMD_WRITE_STATE are nice to have to get back to an earlier saved state.

So the main problem is to read the memory banks/paging information. I must admit that the MAME addressing scheme is very sophisticated and I do not fully understand it.
Especially how to map this to a much simpler banking scheme like for the ZX128k for example.
BTW I was also trying to get the banking information through Lua but did not succeed either.

Furthermore, I think we have to distinguish 2 use cases:
a) reverse engineering
b) original development
The main difference is that for a) all software can be placed in ROM and does not need to be changeable.
For b) it would be required to load data, sent from dezog, into the ROM pages. Otherwise the user could never apply a change.

If you want to look into the software more deeply.
The communication to mame is handled here:
https://github.com/maziac/DeZog/blob/main/src/remotes/mame/mamegdbremote.ts
(Note: in the terminology of dezog a 'Remote' means the emulator, i.e. mame)