> So we're definitely open to feature requests.
OK, well I've used debuggers a fair bit. Things I'd like to see (without having reviewed Stella, I'm sure a lot of this is already present)...
#1 is to associate actual source code with the binary. That is, you can load up a symbolic binary and use that as your base for debugging. I am willing to modify DASM to achieve this goal.
Associated with the above, putting breakpoints on specific source code lines. The debugger will halt when a breakpoint is reached.
Further to the above, conditional breakpoints -- for example, only break on the 100th time, or when the y-register is a certain value, etc.
Watches -- this allows you to break when particular memory locations are modified or accessed. For example, it would be nice to break whenever a particular hardware register is accessed. Also, conditional watches -- same thing, but with conditions to control when the break happens. Imagine debugging a kernel -- and you want to break on the 262nd WSYNC. This sort of thing might be useful in that context.
Examine any memory location (particularly RAM). Modify any location. This is important, as it allows you to play "what-if" type scenarios without having to reassemble things. The modification of locations should allow RAM, or ROM to be changed.
The highlight changed values as requested already is important. Any watched values are displayed in a separate 'watched' window, and should immediatly be apparent via colour change if they change value.
I would like to see a counter showing the current cycle count on a scanline, if we happen to be doing a kernel. Also, the current cycle count inside blanking intervals, etc. Perhaps a cycle count attached to the source code that you are viewing, too. Again, DASM could be responsible for this, providing a symbolic binary to ease the process.
Attaching symbols to locations (eg: labels, etc) is good -- but don't forget that some games use overlays. Allow multiple symbols to be attached to a single location!
The '2600 is a small-enough platform that it would be nice to set and save 'waypoints'. The idea is that you can step through to a particular point, then save the entire state of the machine at a named waypoint. THen, at any stage you can abandon the current debugging and start again from any previous waypoint. This would be exceptionally handy for tricky problems, and multiple what-if scenarios. I'd also like to be able to save waypoints to disk, so that I can come back to them later.
As well as ROM, RAM modification, make sure that the debugger allows modification of the registers and flags!
It would be quite handy to keep a visual track of the stack usage -- particularly high and low-water marks. Perhaps keep warnings on stack overflow conditions (for example, if the stack ever overlays a variable).
Keeping a track of code usage would be nice. This could identify 'dead' code which is never executed, and perhaps lead to some space savings. Also, this could lead to a profiler -- identifying areas of code that should perhaps be candidates for optimisation.
I'd like to see a system where I could say "start timer" -- "stop timer" so that I could get a cycle count between points of code. That way, complex code that has variable timing could be analysed to give me a best-case, average, and worst-case timing -- just by playtesting. This could be most useful in my current project.
I'd love to be able to see a partial rendering of a scanline as I'm stepping through a kernel. So I could see exactly where the TV beam is, and what has already been displayed.
That's all I can think of right now, but the above should keep you busy until I think of more :)
Cheers
A
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://stella.biglist.com
