confirmed - the bug is likely located in the new style cpu core and thus affects dtv, c64(sc) and vic20 .... it can simply be checked by doing "mmsh %11111111 e000 ffff" after a reset - it will not show any Xs :)

that said, it works as expected in x64 (and probably the other emus that use the old cpu core)

Here is a working patch.
NEED TO BE CHECKED but works.
---cut---

monitor: mmsh: fix opcodes/instr attributes before mmsh

Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>

Index: vice/src/6510dtvcore.c

--- vice/src/6510dtvcore.c (revision 26784)
+++ vice/src/6510dtvcore.c (working copy)
@@ -1513,6 +1513,7 @@
FETCH_OPCODE(opcode);

#ifdef FEATURE_CPUMEMHISTORY
+ memmap_mem_read(reg_pc);
/* FIXME JSR (0x20) hasn't load p2 yet. The earlier LOAD(reg_pc+2) hack can break stealing badly on x64sc. */
monitor_cpuhistory_store(reg_pc, p0, p1, p2 >> 8, reg_a_read, reg_x, reg_y, reg_sp, LOCAL_STATUS());
memmap_state &= ~(MEMMAP_STATE_INSTR | MEMMAP_STATE_OPCODE);
---cut---

good catch - fixed in r26881, thanks for reporting!

i am reopening this bug - the problem is not really fixed and exists in both x64 and x64sc (and likely other emulators). executed adresses will be marked as such, but they should also get marked as read, and not only the first byte of the respective opcode. to fix this probably the FETCH_OPCODE macros must be rewritten accordingly.

(C:$e5cd) a c000 lda $c010
.c003 sta $c020
.c006 jmp $c006

(C:$c009) mmzap
(C:$c009) x
(C:$c006) mmsh %00000111 c000 c050

(X64)
addr: IO ROM RAM
c000: -- --- --x
c003: -- --- --x
c006: -- --- --x
c010: -- --- r--
c020: -- --- -w-

(X64SC)
addr: IO ROM RAM
c000: -- --- --x
c003: -- --- --x
c006: -- --- r-x
c010: -- --- r--
c020: -- --- -w-
(C:$c006)

> "Executed addresses will be marked as such; but, they also should get marked as read."

I disagree. I think that the eXecute and Read markers should be completely independent. "x" should show that a location was accessed for code; while "r" and "w" should show that a location was accessed for data. In other words, an address should be marked with "r" only if it was read by an op-code, not by the Program Counter. Otherwise, a programmer couldn't tell when a piece of code examined itself.

well yes, perhaps... x implies read anyway :) however the main problem remains, it must either be incorporated into the opcode fetch macro, or the current hack must be extended accordingly (not sure how to find out about the length of the opcode at that point... if its known, then its trivial to fix)

Well, in short I think the whole memmap stuff is a big ugly hack ;) I would try to implement some sort of "profiler" functionality by extending watchpoints instead of trying to fix this anyway.

I just like to ask one thing, whoever works on this memmap stuff, please don't spread out this mess too much if possible.

confirmed, still looks like this

addr: IO ROM RAM
c000: --- --- --x (uninitialized exec)
c003: --- --- --x (uninitialized exec)
c006: --- --- r-x (uninitialized exec)
c010: --- --- r-- (uninitialized read)
c020: --- --- -w-