Felix
Felix copied to clipboard
laoo
Debug UI fixes
Don't add watch if already exist Allow multiple debug controls of allowed types Apply breakpoints after reset Enable/Disable breakpoints
Did not check in detail, but does it allow "CPU" view of the memory? (using $fff7 to select bank)
Did not check in detail, but does it allow "CPU" view of the memory? (using $fff7 to select bank)
Sorry I am not sure to understand "CPU" view. Do you mean what's after fff8 ? The interrupt vectors addresses ? Or after messing with MAPCTL ?
Did not check in detail, but does it allow "CPU" view of the memory? (using $fff7 to select bank)
Sorry I am not sure to understand "CPU" view. Do you mean what's after fff8 ? The interrupt vectors addresses ? Or after messing with MAPCTL ?
Right, after messing with MAPCTL. So a pure Mikey, pure SUZY, pure RAM (that is SUZY's view) and a view a "lda $fxxx" would see.
Sorry guys, I'm genuinely busy with too many things, but I'm following the progress. I haven't accepted this PR yet as it's complicated matter. The last main PR with debug windows introduced many sharp edges which I am struggling to figure out how to smooth them. And THIS PR introduces even more. For example I'm not sure it'll give good user experience. At least multiple windows need to have proper config serialized. And by "proper" I mean each window should remember disassembling address / address from which the data is displayed etc. Not just the number of windows. I don't like that the context menu is missing too... It's just much work to articulate each one issue I see.
Regarding MAPCTL driven view of the memory maybe there could be a switch whether to view only RAM or the locations selected by MAPCTL. On the other hand I think that it would be a good idea to have separate views for Mikey/Suzy hardware locations.
I agree that windows should remember its settings. One of the worst about handybug is to restore every thing after relaunching the emulator. A Mikey \ Suzy only window is great. Just think about tinkering with the sound registers in an easier way.
I believe then SysConfig would need to be refactored first for something simpler, more generic. The current manual string concat/parsing isn't extremely convenient to add dynamic configs.
I believe then SysConfig would need to be refactored first for something simpler, more generic. The current manual string concat/parsing isn't extremely convenient to add dynamic configs.
I agree. It was initial approach for simple needs. How about XML? I can change it to pugi_xml reading/writing. I prefer XML as it's documenting itself (opposed to json).
In favour of XML as well. On the other hand, simple formats like Linux config files are more readable [MEMWINDOW1] addr=$1000 width=16 ascii=true
opposed to
<memwindow>
<\num = 1>
<\addr = $1000>
<\width = 16>
<\ascii = true>
<\memwindow>
It's a matter of flat structure vs tree structure. I'm not sure which is more suitable it our case. I was thinking about XML as I'm working with XML configs in my day-job and it's more natural for me. Maybe more flexible. Readability is subjective. For sure XML is way more readable than JSON. I know there are libraries that can serialize to both XML and ini file (boost::property_tree naming one)
I'd say, since this is not the funniest part, you should go the way the easiest. So if you know XML handling in and out, go for it. But JSON is a pain. It is pure M2M.