(finally getting a chance to answer this...)
On Fri, 24 Jun 2005, atari2600 wrote:
>> 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)...
Some of it is, some is planned for the 2.0 release.
> #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.
I thought we wouldn't actually need to modify DASM (the symbol and list
files contain all you need for a non-bankswitched ROM)... but I don't
know how to have Stella figure out which symbols go in which bank.
Here are a couple of partial solutions:
1. Have Stella load a separate symbol file per bank. This means DASM users
will need to assemble each bank separately:
dasm bank0.asm -sbank.0.sym bank0.bin
dasm bank1.asm -sbank.1.sym bank1.bin
cat bank0.bin bank1.bin > wholerom.bin
(or on DOS/Win, use "copy /a" instead of "cat")
This would work but it's clumsy. Most (all?) authors currently write
their games as a single .asm file that assembles to the complete .bin,
so Stella won't be compatible with current practices :(
2. Modify DASM so that it knows about bankswitching. Right now it doesn't,
RORG directive notwithstanding. Then each symbol in the symbol file
(and each line in the listing file) would have an address of the form
"bank:address" (such as 0:f000 for bank 0, address $f000). There would
have to be a syntax for the programmer to declare global symbols, too
(such as TIA constants and RAM locations). Stella would directly
support the bank:address syntax in the debugger, so you could say
"break 1:f100" to set a breakpoint in bank 1 only at $f000. Each
label would know what bank it's in, so the value of "myLabel" might
be "0:fa00" (so you could say "break myLabel").
This also is incompatible with current practices...
> Associated with the above, putting breakpoints on specific source code lines. The debugger will halt when a breakpoint is reached.
Breakpoints are supported, amd will work like you say once we support
source-level debugging.
> Further to the above, conditional breakpoints -- for example, only break on the 100th time, or when the y-register is a certain value, etc.
Planned, probably won't make it into 2.0 though.
> 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.
We have these, but they're called traps. Watches are something else in
Stella: they're expressions that get evaluated & printed before every
prompt. For instance, "watch *myVar" will show the contents of myVar
before every prompt... "trap myVar" will break any time myVar is accessed
(read or write). There are also "trapread" and "trapwrite", for breaking
on only read or write accesses.
However... traps happen *after* an instruction is executed. "trap myVar"
will halt the CPU and enter the debugger... but the PC will point to the
instruction *after* the one that triggered the trap. This is because
we don't have any way of knowing whether the current instruction will
trigger a trap before we execute it... The only way to fix this would
be to store the entire state of the emulator before each instruction,
then load the last state if an instruction hits a trap.
> 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.
Planned, though probably not in 2.0.
> 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.
Can't change ROM yet: the emulation core doesn't support it. I'll have to
add a "changeROM" method to every one of the Cart classes (each bankswitch
type is a Cart class). Not difficult, but time-consuming. This will be
done before the 2.0 release.
> 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.
Planned for 2.0 release.
> 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.
This will not be easy. The TIA emulation in Stella runs one frame at a
time, causing the 6502 to execute code as needed. I may need help from
Brad to get this to happen.
> 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!
Semi-supported already. Multiple symbols can have the same value,
and can be used in input... but for output (such as the disassembly),
only the first symbol is used. So if I'm using an overlay where "lives"
and "temp" share the same address, and my source says "lda temp"... the
disassembly could say "lda lives" instead.
Source-level debugging will fix this problem: you'll see the actual line
of source, which will have the correct symbol name.
> 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.
Stella already supports saving and loading the entire emulator state. All
that's needed here is to (a) include the debugger state in the state file,
and (b) give the user a way to invoke the save/load state functions from
within the debugger. Actually, even if (a) doesn't get done, this would
still be useful (the debugger would keep its current state. If the ROM
hasn't changed, the break/watch/trap addresses will still be valid).
> As well as ROM, RAM modification, make sure that the debugger allows modification of the registers and flags!
Well, yeah :)
There's even a nice GUI for the regs already.
> 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).
Good idea. Not hard to do, will possibly show up in 2.0.
> 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.
Hmmm. Have to think about this one...
> 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.
Shouldn't be hard to implement.
> 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.
This will be difficult due to the way the TIA and M6502 internals talk
to each other.
> That's all I can think of right now, but the above should keep you busy until I think of more :)
Yah, that's a lot of stuff... all of it good though.
--
B.
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://stella.biglist.com
