There's a "-d" option to gdb-bridge, which enables a RAM-dump before and after each debugger command that actually executes code (i.e cont, next, step, nexti & stepi), and a trace log of the 68000 bus cycles. This setting applies for all debug sessions until the gdb-bridge shuts down, and there's no way to change the setting in the middle of a debug session - you have to kill and re-start the gdb-bridge process. That kinda sucks, because it means you generate huge trace logs that you're probably not interested in, and saving two RAM dumps for every single-step operation slows things down so much it feels like you're debugging Scala[1] rather than C or 68000.

So (whilst I'm in the process of making a new release to fix a few recently-discovered bugs), I'm going to remove the "-d" option, and replace it with a couple of custom gdb commands: "monitor ramdump <fileName>" and "monitor trace <fileName>". The former will dump the current contents of WRAM (i.e 0xFF0000-0xFFFFFF) to the specified file. The latter will enable execution tracing for the next command that actually executes code. If you have any objections to that, tell me now.

[1]Actually, I'm being unfair. Loading the PC register with a random value after each single-step would yield a more Scala-like experience.