Re: Opcode decoding for disassembler
Posted: Wed Apr 17, 2019 7:45 pm
Using a branch to transfer execution from $80XX to $7FXX is valid, though I doubt you'd ever see it in a game with SRAM. I think the most likely time to see this is on FDS, but there RAM is continuous from $6000-DFFF.
Branches aren't commonly used to jump across very distinct memory regions like that (PRG to RAM, or between PRG banks.) Not impossible that someone would want to, but extremely unlikely to do it with a branch. JMP or JSR is probably what you'd see doing that.
However, to get back to your question: branches and jumps may target RAM, or other places. Regardless of that, your disassembly should show what the code does whether or not it "makes sense". Often the point of doing a disassembly is to find a bug that was caused by just such a lapse of sensibility. The disassembler's function should be plain, not subject to complex interpretation of a code's intention.
In most disassembly environments, it's important that the user can either identify bytes as belonging to code or data to be disassembled into opcodes or not, or failing this be able to reposition their current view of the disassembly to align on something they know is an instruction. In something like FCEUX, it just does a naive disassembly from the top of what's in view, and if there's something "weird" there usually it can be fixed by moving the view up or down a byte or two until the code comes into alignment. Because of all the 1 byte instructions, naively disassembled 6502 code tends to self-align after a few lines anyway. If this is an offline tool, just give the user ways to specify what part of the file is code or data.
I think conceptually it's valid to think of a branch operand as analogous to an immediate one, sort of in the way that ADC can take an immediate and add it to A, a branch can take this "immediate" and add it to PC? If you want correct terminology though, this is not the name to use, and # is not the notation to use either.
For a disassembly, the standard thing is to use either a label or just the address as the operand, i.e. show where the branch goes, not the actual value of its operand. "BEQ label" or "BEQ $7F05"
Branches aren't commonly used to jump across very distinct memory regions like that (PRG to RAM, or between PRG banks.) Not impossible that someone would want to, but extremely unlikely to do it with a branch. JMP or JSR is probably what you'd see doing that.
However, to get back to your question: branches and jumps may target RAM, or other places. Regardless of that, your disassembly should show what the code does whether or not it "makes sense". Often the point of doing a disassembly is to find a bug that was caused by just such a lapse of sensibility. The disassembler's function should be plain, not subject to complex interpretation of a code's intention.
In most disassembly environments, it's important that the user can either identify bytes as belonging to code or data to be disassembled into opcodes or not, or failing this be able to reposition their current view of the disassembly to align on something they know is an instruction. In something like FCEUX, it just does a naive disassembly from the top of what's in view, and if there's something "weird" there usually it can be fixed by moving the view up or down a byte or two until the code comes into alignment. Because of all the 1 byte instructions, naively disassembled 6502 code tends to self-align after a few lines anyway. If this is an offline tool, just give the user ways to specify what part of the file is code or data.
I think conceptually it's valid to think of a branch operand as analogous to an immediate one, sort of in the way that ADC can take an immediate and add it to A, a branch can take this "immediate" and add it to PC? If you want correct terminology though, this is not the name to use, and # is not the notation to use either.
For a disassembly, the standard thing is to use either a label or just the address as the operand, i.e. show where the branch goes, not the actual value of its operand. "BEQ label" or "BEQ $7F05"