I realize that this is an old post, but I'm really hoping there is someone that can lend a hand here.
First, I was wondering if the issue in IDA has been fixed in newer versions?
cboles wrote:* there is an intentional non-standard ordering of operands for the BRCLR and BRSET opcodes. this is becaise IDA doesn't seem to follow branches if the code addresses are in an operand position greater than 3 (which happens when you use indirect addressing with X, Y, and Z). as a fix, i turned what should be:
BRCLR yOffset, Y, #bitmask, branchaddress
and changed it to
BRCLR yOffset, Y, branchaddress, #bitmask
Secondly, I'm having an issue getting the addressing down. It seems that sometimes the program is storing the contents of an accumulator to a memory location that seems to be part of a subroutine, specifically, an opcode, rather than storing it to a memory location that seems to be just that, a memory location. Is this a way of changing the logic that has been programmed, or am I reading it wrong?
Another issue I am having with the addressing is the offsets. For instance, I've been trying to figure the NPS out which according to the logger defs for RR is a switch at byte 0x000062 bit 7. So I created a custom def to log memory location 0x000062 as opposed to each individual bit. The number changed accordingly, depending on what I did. So that is obviously the correct location, however in IDA it seems to be stored elsewhere. The same location(0x000062) is set to what seems to be a pre-determined number using this code:
- Code: Select all
lde #36h
ste 62h, Y
Can anyone explain how this index addressing works? Also, why it is being set in the program when I've logged it and found that it is changed by sensor input(even though I haven't been able to find any logic to support his idea, I know it to be true from logging)?
Thanks in advance to anyone that can lend a hand here, this has been kicking my ass all week and I am determined to learn this.
Andy