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 http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
