You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there a reason why monitor takes a starting address and a length instead of a starting address and an ending address? It seems to me the latter would make more sense since you often know the starting and ending address of where your program modifies memory. This eliminates the need to do some hex subtraction to figure out the appropriate length.
This also makes monitoring the entire memory more intuitive in my opinion, since currently $0000 with length $ffff is missing memory location $ffff. To see the last memory location you need a length of $10000, which doesn't make sense given that all 6502 addresses are 2 bytes.
This came about when I discovered the bug detailed in #16.
The text was updated successfully, but these errors were encountered:
I agree that this could be done differently - one might even offer both alternatives and pick up the most recently changed one to compute the other. But I think it's aesthetic and a close call, and not really a bug. Feel free, of course, to put a good fix into your own branch. If you do allow both and if the code isn't too twisty, and it turns out to be quite intuitive to use, it might be good to merge it back here.
Is there a reason why monitor takes a starting address and a length instead of a starting address and an ending address? It seems to me the latter would make more sense since you often know the starting and ending address of where your program modifies memory. This eliminates the need to do some hex subtraction to figure out the appropriate length.
This also makes monitoring the entire memory more intuitive in my opinion, since currently $0000 with length $ffff is missing memory location $ffff. To see the last memory location you need a length of $10000, which doesn't make sense given that all 6502 addresses are 2 bytes.
This came about when I discovered the bug detailed in #16.
The text was updated successfully, but these errors were encountered: