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.