Feature requests: WRAM init values, modified data/registers

[adejr]

It would be helpful in some cases if there were an option to populate WRAM with a user defined pattern such as 0xcd or 0xbaadf00d on init in place of the random values currently used. This would make reads of uninitialized data much easier to identify.

This feature should be relatively trivial to implement and I would have provided an example patch but I couldn't get bsnes-plus to build last time I tried (toolchain configuration issues on my side. Maybe next time I make an attempt.)

Longer term and likely more complex to implement:

In the same vein in conjunction with memory usage data the memory editor could be made to colorize not just code/data/unknown but also static/modified. This could also apply to registers although the register data is currently displayed in plain text boxes along the debugger window.

The question then would be "modified in comparison to what?" Given the debugger with step/over/out functionality the default might be to reset on each step depending upon type. On "jsr func_addr" stepping over might display all differences between before jsr and after rts.

Given such an implementation it would also make sense to be able to display the list of blocks of modified offsets and allow for entries to be cleared or deleted individually in place of automatically. Such a read-out might be most easy to implement as a log of writes where any address appearing in the log would be considered modified until the log was cleared.

[adejr]

I see some of my "longer term" suggestions have already been discussed in terms of a write/memory log which makes sense as they are obvious and require significant GUI work.

Another idea which may be easier to implement is breakpoint names/comments. Currently the message printed is "Breakpoint %i hit (%i)."

With an additional name/comment in the breakpoint editor window the output could have that string added if not null: Breakpoint 2 hit: "load_palette_row()" (12).

[devinacker]

It would be helpful in some cases if there were an option to populate WRAM with a user defined pattern such as 0xcd or 0xbaadf00d on init in place of the random values currently used. This would make reads of uninitialized data much easier to identify.

This option already exists: check the config file (%appdata%/.bsnes/bsnes-qt.cfg on Windows, ~/.bsnes/bsnes-qt.cfg otherwise) for the values snes.random and cpu.wramInitValue. Currently only single-byte values are supported, though.

Another idea which may be easier to implement is breakpoint names/comments. Currently the message printed is "Breakpoint %i hit (%i)."

With an additional name/comment in the breakpoint editor window the output could have that string added if not null: Breakpoint 2 hit: "load_palette_row()" (12).

This is probably closely-related enough to support for actual symbolic debugging support, which is planned as part of a debug GUI revamp which is going to be part of the next release (there's probably going to be a project board for it at some point soon once it's in progress).

[adejr]

This option already exists: check the config file (%appdata%/.bsnes/bsnes-qt.cfg on Windows, ~/.bsnes/bsnes-qt.cfg otherwise) for the values snes.random and cpu.wramInitValue. Currently only single-byte values are supported, though.

I figured it must be stashed away somewhere. It would be a useful function to have on the GUI at some point depending upon how often the configuration is read in. Obviously editing the config and doing a full restart of the program is a bit of a headache. At the moment I've managed by using export/import and filling the wram data externally.

This is probably closely-related enough to support for actual symbolic debugging support, which is planned as part of a debug GUI revamp which is going to be part of the next release (there's probably going to be a project board for it at some point soon once it's in progress).

I agree as any changes to the breakpoints window would require the comment functionality to be adapted anyway. So including any such change along with others would make sense albeit significantly delaying such a simple change.

I still think a comment in the breakpoint list would be a nice feature. MSVS calls this feature "labels".

[devinacker]

I figured it must be stashed away somewhere. It would be a useful function to have on the GUI at some point depending upon how often the configuration is read in. Obviously editing the config and doing a full restart of the program is a bit of a headache.

I suppose it could be added to the "advanced" settings tab sometime. The config file is only actually read once when starting the program, but these options in particular are applied whenever (re)loading a ROM or doing a power cycle, so simply adding the option(s) to the GUI would take care of that headache pretty easily.

I'll probably still keep the actual value as a single byte for the time being just for the sake of simplicity, but hopefully that should still be useful.

(It's probably also worth mentioning that having snes.random enabled actually randomizes much more state than just RAM, especially for the accuracy core, primarily to enforce the amount of hardware initialization required on the actual console.)