LGT-3-6 wrote:I don't believe this is completely correct. This doesn't appear to work the the 05 LGT roms I'm trying.. They point to AAC, and there lies garbage. Also I'm not sure what you're doing with PK, it makes perfect sense for it the be the LSN, it's the first 4 bits of a 20bit address, PC is the lower 16 bits.. No? I just started thumbing through the architecture :/

Well, this thread is for Motorola HC16 - a cpu which the 05 LGT doesn't have..I think you'd better read the forum a bit more before starting to work on the roms

SOB... I guess this explains why they have such horrible engine managment problems.. UGH..

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:

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.

I've found the IDA support group is excellent for this sort of stuff. I pointed out a few small bugs in one of their processor modules and they had a fix emailed to me by the next morning. Definitely good customer support from them.

You will get the correct address if you add a user defined offset of 20000h (Ctrl-R) to all nn,Z operands.It's not very difficult to write a .idc scripts that does it automagically..The nn,Y has to be done manually since Y is not static.

Anyone has an idea to solve this problem? Cause i solved the problem "manually" using CTRL-R but it's a huge stuff.It would be good to find a faster solution

IDA now has a free download version but its based on v5.0. Can someone recompile the HC16 module for v5? I have the SDK here but am having trouble getting it to compile. Any help would be appreciated as I'm trying to disassemble a different HC16 rom (neon) that hasn't been done before AFAIK.