+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  68000 stuff.
Pages: [1]
Author Topic: 68000 stuff.  (Read 2 times)
KingMike
Guest
« on: July 01, 2008, 12:58:49 pm »
Using Gens Tracer, having a problem understanding a piece of code that I need to find some compressed data.
Code:
MOVE.L ($00FF81A4),A0 ;loading an index into a pointer table
MOVE.L (A0),A0  ;reading a relative pointer table
ADDA.L #$01,A0 ;adjusting relative pointer to absolute address of data
;(even though the table is nowhere near the data, data at ~$18000, table at about ~$C0000)
LEA ($00FF491A),A1 ;now A0 has the pointer to some compressed data.
If I'm reading this right, ADDA.L should increase A0 by 1, but in the trace log, I see A0 is increased by 0x18000. I'm not seeing 0x18000 in any of the other registers, could it be pulled from memory or something (even though the 1 looks like an immediate value).
RedComet
Guest
« Reply #1 on: July 01, 2008, 01:53:26 pm »
Could you post a link to the trace log so I can see the registers? The only thing that immediately comes to mind is that you might be logging the first instance of each instruction and that's somehow causing it. I can't say for sure until I see the log though.
KingMike
Guest
« Reply #2 on: July 01, 2008, 04:54:22 pm »
Code:
00:0ED2  20 79  MOVE.l  ($00FF81A4),A0           A0=00FF8E28 A1=00FFFC64
00:0ED8  20 50  MOVE.l  (A0),A0                  A0=000C0030 A1=00FFFC64
00:0EDA  D1 FC  ADDA.L  #$01,A0                  A0=00001C80 A1=00FFFC64
00:0EE0  43 F9  LEA     ($00FF491A),A1           A0=00019C80 A1=00FFFC64
00:0EE6  61 00  BSR     #$FFFFFC36 [00:0B1E]     A0=00019C80 A1=00FF491A
00:0B1E  48 E7  MOVEM.L {d0-a7}[ff 20],-(A7)     A0=00019C80 A1=00FF491A
From a full trace (hook_pc from $0200 (standard entry point in Genesis games) to -1 (never reached, that is everything) starting from when the game runs. Full trace is about 130MB, so repeated code is not filtered out (filtered trace would be only around 400K).

Edit: removed the registers that are uninteresting here to unbreak the board layout - KaioShin
« Last Edit: July 01, 2008, 05:21:07 pm by KaioShin »
KaioShin
Guest
« Reply #3 on: July 01, 2008, 05:17:28 pm »
I'll leave the math to you, but the ADDA instruction extends the source to a signed value. Here is the explanation from the 68000 opcode reference:

Quote
Add the source operand to the destination address register and store the result in the destination address register.
The source is sign-extended before it is added to the destination.
For example, if we execute ADDA.W D3,A4 where A4 = $00000100 and D3.W = $8002,
the contents of D3 are sign-extended to $FFFF8002 and added to $00000100
to give $FFFF8102, which is stored in A4.
RedComet
Guest
« Reply #4 on: July 01, 2008, 05:57:14 pm »
I don't know what it could be. I would double check the immediate value at $EDC and make sure it's actually 0x00000001. Could be a bug in gens_tracer. I've found a few of them over the past year or so.
KingMike
Guest
« Reply #5 on: July 02, 2008, 07:47:00 am »
Didn't think to check that, but that's the answer. The hex actually is 0x00018000.
Thanks.
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC