(Using Vice 3.10 (GTK3) on Arch Linux.)
There is something about the built-in monitor I find really confusing. The monitor command cpuhistory displays the most recent instructions the CPU has already executed, along with the state before that particular instruction (in the same line) had been executed. Also, the step command displays the state of the CPU after executing the instruction PC is currently pointing at. What is missing here is the state of the CPU right now along with the instruction that is about to be executed. The monitor command registers only tells half the story, as it only shows registers but not the instruction PC is pointing at.
Consider this example (slightly formatted for readability):
(C:$080d) chis 10
.C:e132 48 PHA A:e1 X:61 Y:0d SP:f8 N.-..... 3132966
.C:e133 A9 46 LDA #$46 A:e1 X:61 Y:0d SP:f7 N.-..... 3132969
.C:e135 48 PHA A:46 X:61 Y:0d SP:f7 ..-..... 3132971
.C:e136 AD 0F 03 LDA $030F A:46 X:61 Y:0d SP:f6 ..-..... 3132974
.C:e139 48 PHA A:00 X:61 Y:0d SP:f6 ..-...Z. 3132978
.C:e13a AD 0C 03 LDA $030C A:00 X:61 Y:0d SP:f5 ..-...Z. 3132981
.C:e13d AE 0D 03 LDX $030D A:00 X:61 Y:0d SP:f5 ..-...Z. 3132985
.C:e140 AC 0E 03 LDY $030E A:00 X:00 Y:0d SP:f5 ..-...Z. 3132989
.C:e143 28 PLP A:00 X:00 Y:00 SP:f5 ..-...Z. 3132993
.C:e144 6C 14 00 JMP ($0014) A:00 X:00 Y:00 SP:f6 ..-..... 3132997
(C:$080d) z
.C:080e CA DEX - A:00 X:01 Y:00 SP:f6 ..-..... 3133004
Where does X:01 come from? Well, it comes from the instruction at $080d, as we can see afterwards:
(C:$080e) chis 10
.C:e133 A9 46 LDA #$46 A:e1 X:61 Y:0d SP:f7 N.-..... 3132969
.C:e135 48 PHA A:46 X:61 Y:0d SP:f7 ..-..... 3132971
.C:e136 AD 0F 03 LDA $030F A:46 X:61 Y:0d SP:f6 ..-..... 3132974
.C:e139 48 PHA A:00 X:61 Y:0d SP:f6 ..-...Z. 3132978
.C:e13a AD 0C 03 LDA $030C A:00 X:61 Y:0d SP:f5 ..-...Z. 3132981
.C:e13d AE 0D 03 LDX $030D A:00 X:61 Y:0d SP:f5 ..-...Z. 3132985
.C:e140 AC 0E 03 LDY $030E A:00 X:00 Y:0d SP:f5 ..-...Z. 3132989
.C:e143 28 PLP A:00 X:00 Y:00 SP:f5 ..-...Z. 3132993
.C:e144 6C 14 00 JMP ($0014) A:00 X:00 Y:00 SP:f6 ..-..... 3132997
.C:080d E8 INX A:00 X:00 Y:00 SP:f6 ..-..... 3133002
So, looking at the output of the monitor session, we see JMP ($0014) followed by DEX. However, what has actually been executed was JMP ($0014) followed by INX. This is super confusing, at least to me. Sure, I could use disass, but this is far from ergonomic:
d will print enough to push the current content off the viewport and move the dot address.d 080d 080d is no fun to type and will still move the dot address. Also, in order to know that I would have to use 080d, I first need r to tell me the current PC because the dot address might already be off.r show the next instruction that is about to be executed without changing anything, especially without moving the dot address.r to reflect that change.With those changes applied, using r in that scenario might look like this (note the padding at the beginning of the r output for alignment):
(C:$080d) chis 10
.C:e132 48 PHA A:e1 X:61 Y:0d SP:f8 N.-..... 3132966
.C:e133 A9 46 LDA #$46 A:e1 X:61 Y:0d SP:f7 N.-..... 3132969
.C:e135 48 PHA A:46 X:61 Y:0d SP:f7 ..-..... 3132971
.C:e136 AD 0F 03 LDA $030F A:46 X:61 Y:0d SP:f6 ..-..... 3132974
.C:e139 48 PHA A:00 X:61 Y:0d SP:f6 ..-...Z. 3132978
.C:e13a AD 0C 03 LDA $030C A:00 X:61 Y:0d SP:f5 ..-...Z. 3132981
.C:e13d AE 0D 03 LDX $030D A:00 X:61 Y:0d SP:f5 ..-...Z. 3132985
.C:e140 AC 0E 03 LDY $030E A:00 X:00 Y:0d SP:f5 ..-...Z. 3132989
.C:e143 28 PLP A:00 X:00 Y:00 SP:f5 ..-...Z. 3132993
.C:e144 6C 14 00 JMP ($0014) A:00 X:00 Y:00 SP:f6 ..-..... 3132997
(C:$080d) r
ADDR A X Y SP 00 01 NV-BDIZC LIN CYC STOPWATCH
.; 080d 00 00 00 f6 2f 37 00100000 122 012 3133002
.C:080d E8 INX
(C:$080d) z
.C:080e CA DEX - A:00 X:01 Y:00 SP:f6 ..-..... 3133004
That is, using r between chis and z will then, finally, tell the whole story.