MONITOR / Upward scrolling

[flimbo72]

Hi everyone.

This must be a bug in the system monitor.
Scrolling upward occasionally causes erroneous disassembling.
Here's an example on a section of code from a game I'm developping.

SCROLLING DOWNWARD (correct disassembly)

REGULAR.png (10.21 KiB) Viewed 5725 times

SCROLLING UPWARD (buggy disassembly)

BUGGY.png (10.47 KiB) Viewed 5725 times

Scrolling up, the byte at $0B64 gets duplicated and the opcodes that follows are misinterpreted.

Giacomo

[TomXP411]

This does not surprise me. There's no way to know for sure what the numbers in memory mean when you scroll up: is the next byte up an opcode, an operand, or data?

I'm assuming some basic tests are made: if the byte preceding the one displayed is not a 1-byte opcode, then the monitor would look at the byte before that. if that byte is a 2-byte operation (1 opcode + 1 operand), then the display is a 2-byte sequence. Otherwise, it tries to interpret 3 bytes as a 3-byte sequence (1 opcode + 2 operand bytes).

This system is not perfect, and it probably will result in interesting results like this. I can only suggest not relying on upward scrolling to read data at lower addresses. Instead, do a new .D at a previous, known address and work forward to intersect the top of your current position.

[DragWx]

Chiming in to say that this happens on pretty much every 6502/z80 debugger I've used; scrolling upwards just isn't smooth, but that's with the benefit of being able to refresh the whole listing, rather than just letting wrong lines slip through.

Improving the UX could be as simple as just keeping an invisible buffer of 16 earlier bytes from what the top line of disassembly is. It's hard to predict where the true start of the previous opcode is, but after 16 bytes, it's usually stable enough to be correct.

[Ed Minchau]

This does not surprise me. There's no way to know for sure what the numbers in memory mean when you scroll up: is the next byte up an opcode, an operand, or data?

I'm assuming some basic tests are made: if the byte preceding the one displayed is not a 1-byte opcode, then the monitor would look at the byte before that. if that byte is a 2-byte operation (1 opcode + 1 operand), then the display is a 2-byte sequence. Otherwise, it tries to interpret 3 bytes as a 3-byte sequence (1 opcode + 2 operand bytes).

This system is not perfect, and it probably will result in interesting results like this. I can only suggest not relying on upward scrolling to read data at lower addresses. Instead, do a new .D at a previous, known address and work forward to intersect the top of your current position.

It's as you describe on the META/L editor too, but that's not the problem he's showing. The monitor did it twice, at 0B64 and 0B69, duplicating a byte as parameter and subsequent command.

[flimbo72]

Backward deassembling is certainly trickier, but Ed Minchau got my point: as shown above, the X16 monitor duplicates bytes at $0B64 and at $0B69, causing deassembly errors. I think it's a bug in the monitor.

Giacomo