Re: [stella] emulators w/ debug features

Subject: Re: [stella] emulators w/ debug features
From: Glenn Saunders <cybpunks2@xxxxxxxxxxxxx>
Date: Sat, 04 Jan 2003 09:15:03 -0800
At 04:37 PM 1/3/2003 -0500, you wrote:
What do you mean by `next generation'? What features should it have? What
should it do that a `current generation' debugger can't do?

Work well in Win2K, for one thing.

Other than user interface, how is a `next generation' debugger different
from this? It doesn't materially matter whether you single step by pressing
S or by clicking on `next step', they're still the same operation.. what
operations does `next generation' imply?

A lot of things specific to the 2600. PCAtari was supposed to show you where you were on the television at any opcode but I never got that to work. It would be highly instructive to have a visual line and cursor indicator to reference the current scanline and current horizontal position of the electron beam. Since the emulator has to simulate this internally I don't see why it can't be done. I realize that emulators build a whole frame before blitting it to the framebuffer, so it would involve some changes to the drawing while in debugging mode.

Just imagine how much easier it would be to debug timing for things like asymmetrical playfields if you could literally see the correlation between your code's timing and the graphics getting built single-stepping as you go.

Also, it would be important to tie the emulator in with a DASM source listing so the emulator wouldn't have to disassemble blindly. I'd like to see labels and comments in there if possible. Then I'd want to be able to single step through the code in a way that I can see more than the current address. I'd want it to be a full scrollable listing. And in another pane you'd have your usual listing of processor and hardware registers. In that pane I'd want to be able to customize (through either a config file or preferences GUI) it to display in hex, decimal, or binary (in a graphical style, not necessarily 1s and 0s) for any metric including rules governing the display of address ranges in RAM (since graphics always gets stored there temporarily). I'd also need another two windows for RAM and stack. I'd like stack variables to be clickable so I can easily RTS (assuming the bytes aren't there due to a push) back to the calling address in the source listing. Same thing with the source listing. When appropriate I should be able to double-click a JSR or JMP and scroll to the destination address.

It's not as important to be able to modify memory on the fly because that's more meaningfully done via changing the sourcecode and reassembling. This was a bigger deal back then when assembling took a while. I agree it's nice for quick experimentation, though.

Archives (includes files) at
Unsub & more at

Current Thread