[diaspora]

I'm looking at a subroutine in the Ninja Gaiden ROM. At the start of the subroutine, there are 3 instructions that the code/data logger has logged as data, so I assume they're local variables for the subroutine. The first "code" byte of the subroutine is at DD34, so I set an execute breakpoint there so I could see what other routines call this one. But by mistake, I typed in DD32 instead, which should be one of the data bytes. To my surprise, the breakpoint triggered anyway, so it seems that DD32 actually is executed as code, even though the CDL has it logged only as data. The debugger disassembly has the 3 bytes from DD31-DD33 grouped into one instruction, and listed as data. But when the DD32 breakpoint is triggered, a new line appears in the disassembly comprised of only bytes DD32 and DD33 (and it's logged as code, too). Then if I scroll the disassembly window at all, that line disappears, and it goes back to listing DD31-DD33 on one line together, logged as data.

So my question is, if DD32 and DD33 are really executed as one code instruction, why does the disassembly group them together into one instruction/line with DD31, and why are they logged as data?

[snarfblam]

At DD2C there is a table that is accessed here:
07:DCF9:BD 2C DD  LDA $DD2C,X

The table is five bytes long:
1E 1B 1C 21 1F

There is an instruction that immediately follows the table:
07:DD32:A9 00     LDA #$00

Now, here is how the disassembler works: it starts by looking at the first byte at the offset you specify (the up button on the scroll bar moves back one byte at a time) and assumes everything is ASM. It does its best to interpret the data as code. So if you scroll up to DD31, it will see that 1F byte, which corresponds to the ORA absolute,X opcode, which accepts two bytes for its operand. The A9 00 that follows (which is supposed to be an LDA #$00) is incorrectly interpreted as the address $00A9, because the disassembler has no way of knowing better. (It could take the CDL into account, but that could potentially do as much harm as good.)

Or, to put it more simply, if you have the data byte 1F, followed by the instruction LDA #$00, that will take the form of 1F A9 00, and if you have the instruction ORA 00A9,X, that will take the form of 1F A9 00. You can see why the disassembler would mistake one for the other, since they are in reality identical.

why are they logged as data?

I doubt that anything but the first of the three bytes is logged as data, but if you're seeing something different, maybe post a screenshot or the relevant part of the CDL. It could be a bug with FCEUX of some sort.

[diaspora]

Thanks, that cleared up everything. The first byte is indeed the only one logged as data. I thought that because the disassembly showed a d next to the line, it meant the whole line was data, but apparently it only applies to the first byte.