Menu
▾
▴
#942 Monitor watch
This command does some strange things:
.C:1000 78 SEI
.C:1001 EE 20 D0 INC $D020
.C:1004 AD 20 D0 LDA $D020
.C:1007 4C 01 10 JMP $1001
(C:$1011) watch d020
WATCH: 1 C:$d020 (Stop on load store)
(C:$1011) sw reset
Stopwatch reset to 0.
(C:$1011) g 1000
#1 (Stop on load d020) 000 011
.C:1001 EE 20 D0 INC $D020 - A:00 X:00 Y:0A SP:f
3 N.-..I.. 10
.C:1004 AD 20 D0 LDA $D020 - A:00 X:00 Y:0A SP:f
3 N.-..I.. 10
(C:$1004) x
#1 (Stop on store d020) 000 011
.C:1001 EE 20 D0 INC $D020 - A:00 X:00 Y:0A SP:f
3 N.-..I.. 10
.C:1004 AD 20 D0 LDA $D020 - A:00 X:00 Y:0A SP:f
3 N.-..I.. 10
notice how it breaks on INC $D020 (load and store) correctly, but doesn't break on LDA $D020 (load) ?
It almost seems like this bug https://sourceforge.net/p/vice-emu/bugs/221/ hasn't been fixed properly,
and also notice how two lines are displayed when there should only be one line?
strange indeed that it doesn't break on the LDA - thats a bug
however, it is correct that the INC throws two (actually three) lines - what the INC does is a load, then a dummy store (original value), then a store (new value), and the monitor reflects that.
single stepping shows some interesting things:
from what I can tell it misses the LDA $D020 because break on load/store breaks on the line after (the PC is at $1004 when the load/store break happens), so the question is then why it does that.
Found two more variations of this bug:
.C:1000 78 SEI
.C:1001 A9 00 LDA #$00
.C:1003 8D 20 D0 STA $D020
.C:1006 EE 02 10 INC $1002
.C:1009 60 RTS
this should now break on $1000, $1001, $1003, $1006, $1009 (exec) and twice on $1002 (load and store) but...
the other monitor watch bug happens when branching across a page boundary:
.C:0fff 60 RTS
.C:1000 78 SEI
.C:1001 A9 00 LDA #$00
.C:1003 F0 FA BEQ $0FFF
On 21.07.2018 23:15, robozz wrote:
This is not a bug, the monitor correctly triggers on the read access at
$10FF generated by the CPU during the branch instruction.
A real 6502 only has an 8 bit ALU to calculate the target address, so it
needs an additional cycle due to the underflow and during that cycle the
partial result is visible on the address bus.
-ik
Checked a bit, it looks like part of the issue is solved - and the confusion about the dummy accesses is removed by having it optional (using the "dummy" command)
however, there still is some strange behaviour - when singlestepping it looks like watchpoints trigger too late (as seen in the original post).
my guess is that the reason is that the watchpoint breaks into the monitor "before the next instruction" instead of "after the current instruction"
I'm coming at this fresh. So, with the attached patch_1.diff against r41011, I've fixed the weird double output. I haven't committed it yet because i'm not sure what things to test to make sure it's not breaking something else. I'm also not sure I understand what else is wrong here.
But - there is something a bit weird. When it breaks on a load/store within the instruction, the command prompt lists the address of the next instruction, not the currently executing instruction. However, when it breaks on execution of a particular address, then the prompt shows the address of the instruction about to execute. Is that what we want?
can you give an example? I think what we want is
also, dont forget to test with both "x" and "z" given the original examples - there might be subtle differences
My post includes examples - prompt is 1004 rather than 1001 when it breaks on watching d020:
but if i used a regular break on 1007, the prompt shows 1007:
It's the disassembly, not the prompt, that's different. The prompt always shows the PC register, which anticipates the next instruction. Your first example disassembles the current instruction, while your second example disassembles the next instruction,
Actually, I recently learned that the prompt doesn't show PC, it shows the address that will be used for the next monitor command if an address is not supplied. This should illustrate:
Note the prompt (C:$e5e2), showing the address of the next instruction after the output of the d command - not PC. Then the z command executes e5d1, and shows e5d4 as the next address of interest. So in light of that, the output I posted makes sense. It's also not the case in my example above that PC == 1004 - it's not finished executing the instruction at 1001.
here's a better illustration:
So, as a first step to get these things under control i knocked up the beginning of a test bench for the monitor: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/Monitor/testbench/
Refer to the included readme for details, how to add tests etc. Obviously more tests would be good, so feel free to provide some :)
As for this ticket: