Feature request: Cleaner interface for register editor

[awjackson]

I know this is probably an annoying type of request, but do you think you could come up with an internal interface for the register editor that doesn't involve letting code in the /ui-qt/ tree directly poke at data members of CPUcore et al? And hopefully enforce some sanity like not allowing you to set the high bytes of X/Y when the X flag is 1, or the high byte of the stack pointer when in 6502 emulation mode, or whatever comparable consistency requirements there are for the SuperFX.

A real problem with bsnes' architecture is how just about everything is public (in fact many of the core classes are actually "structs"!) and remote parts of the code have promiscuous knowledge of each other's internals. For example, it's absurd that the emulator actually knows and cares about which UI menu item you loaded a game from (SNES::Cartridge::Mode) and the BS-X cartridge and the SGB won't work if you load them as regular cartridges, even though all the information needed to map and run them is present in the memory-mapping XML. One of my design goals with bsnes-classic was to clean this mess up (without taking the drastic step byuu did of tearing up the entire UI and starting over, and then doing it again) and I don't want us to work at cross purposes. I understand your priority is adding as many debugging features as possible, but I'd like you to have access to the emulation and performance improvements I intend to make without those features breaking (this is why I warned you about the SA-1 mapping issue)

In particular, if you decide to add a PPU register editor that works like the current CPU register editor, I'm going to be in a very uncomfortable position.

[devinacker]

I don't plan to add any way to modify PPU state from the debugger (I do want some more "VSNES-like" features, but in a purely read-only way).

I'd consider changing the registers from private to protected and then adding pure virtual "getRegister/setRegister" methods of some sort to the ChipDebugger struct/class, and then letting CPUDebugger et al. handle any important details (fortunately aside from M/X flags and emulation mode for the CPU and SA-1, I can't think of any others offhand; there are a small number of SuperFX registers that have side effects when modified but that's all handled by the register classes already).

[awjackson]

Okay, as long as you don't plan to add any more direct diddling of SNES namespace classes from the debugger, cleaning up the existing ones isn't a super-high priority to me (though enforcing consistency with the M/X/E flags is a good idea) I don't plan on touching the CPU cores in the immediate future.

Once I add the "debugaccess" parameter to bus read/write, it should be possible to modify the PPU and other chips with MMIO registers from the hexeditor, though this will have to be implemented and checked for "safety" chip-by-chip. I can also enable reading write-only registers from the debugger.

After this is done we can think of adding pretty menus for each chip, that simply use mmio_read and mmio_write to get and set state.