1 - Debugger messes up with stack read breakpoints. You can't launch the game (and you can't close the emulator as well) until you press Run as many times as amount of adresses in that breakpoint, or until you delete this breakpoint and press Run. I thought it is because of ANROM, and tested batte toads and double dragon, but this bug happend with about 20% chance. Other mappers seems to be ok (but who knows), because this is the first time I had this bug.
It doesn't mater if debugger was opened before adding breakpoints. Adding stack breakpoint again won't cause this bug.
2 - The last one of .deb breakpoints turns into a 0000 adress breakpoint, if you don't open a debugger and add a breakpoint through hex editor and it triggers.
3 - If you have enabled breakpoints in .deb file, bebugger won't trigger them until you open its' window, if you close and open emulator again.
Correction
If debugger was already opened, stack breakpoint won't be buggy.
If you don't delete .deb and leave enabled breakpoint, stack breakpoint will cause this bug after you close emulator, open it and open debugger.
If you don't delete .deb and leave disabled breakpoint, it won't be buggy ater closing + opening emulator and debugger
I only got it to happen once.
I didn't investigate the .deb file.
The basic bug was that the breakpoints data structure gets wrecked, so I guess, from there, anything can happen.
In r3362 I solved something I saw which smelled very, very bad. Maybe it will fix your problem.
It almost did :)
Stack breakpoint still has a first false triggering, but at least I can press Run and the game continues right away, and emulator can be closed no problem.
Good enough for me, thanks.
I'll discuss "false triggering" more if you wish, but please write up a completely separate description so it's less confusing. I can't figure out what you mean.
Ok. I mean that this breakpoint still triggers, although there is no reason to, because nothing in the code is really reading stack adresses.
https://youtu.be/TqU9tNscvTc
And it happens only in the first time you add this breakpoint within one emulator opening. If I don't close the emulator and add breakpoint again, it won't trigger
Last edit: BZK 2017-04-30
fixed in r3363, i hope
yep, it worked, sweet)
thank you
Debugger doesn't show comments at zero page addresses (screen 1)
Also, I have a request. Can you please make debugger to show addresses, which have been commented? (like at screen 2, part 2). First of all, I want to see right away where my jumps will go to, instead of reading 20 08 90 bytes and realise that jump is to $9008 (screen 2, part 1), or instead of clicking on a comment to see address near Seek To button. Second, the same reason is for indexed opcodes, I don't want to calculate its final address myself by adding "opcode address + X" in my head, so I can go search this byte in ROM file to change it if I need to. And third, it takes time (and 5 of 30 allowed bytes in comment's name) to write address in comment's name by myself, if I want to see those addresses in debugger, like at screen 2, part 2.
Last edit: BZK 2017-09-14
So in a nutshell, you don't want symbolic names to replace addresses but instead add to them?
I agree with BZK that it's not perfect to have to figure out the original address by reading raw bytes. But it looks like it needs to be optional: replace the address or append to it.
Yes, that's correct.
Hate to bother you, but is there any progress on my request? I need to make about 1000 comments for ram addresses, and I don't want to redo this again later on, so I need to know will this be done or not.
Also what about the first issue (screen 1)? I have to use older version to see those in debugger.
Last edit: BZK 2017-11-30
there's been no progress. don't expect progress.
you won't have to re-enter anything, the issues are purely about display.
I will have to re-enter (edit to be more precise). Because if I enter
"$9019 X_cam_pos",
it will look like this (in case request will be done)
"$9019 $9019 X_cam_pos"
ugly stuff
And if I enter simple "X_cam_pos", well, this is not an option for me, read above
Last edit: BZK 2017-12-01
ok, but you can fix that in about 20 seconds with a regex
Last edit: zeromus 2017-12-01
maybe I could, if I knew what it is and how to use it)
How can a guy who enters 1000 addresses be so lazy? find any search engine (you may have heard of one called google) or any programmer chatroom (and they'll probably do it for you)
okay, okay, geesh)
Fixed in r3379. You better find every bug, or else I will make fun of you in this bug thread for not finding every bug in your feature.
I'll do my best :) thank you
Comments shouldn't appear for #bytes.
Also space is bigger now (yellow).
I don't understand what's going on. Show me more context.
I've added a comment for $00FF.
A9 FF means LDA #FF, not LDA $00FF, so #FF should't show any comments, because it is a byte, not an address.
The same is for LDA $0100 = #FF.
About space.
Last edit: BZK 2017-12-01
try r3380. I can't promise every spurious space will be removed, but I removed that one.
Bytes don't show comments now, that's good.
That space is the same as r3379. But it is not a big deal anyway
Last edit: BZK 2017-12-04