[XantheFIN]

What technic guys uses to figure out that when disassembler leaves that register number? How to find correct rbase 'word' or number or value.

Code: Select all

abe2: b3,72,99,14         ldb   R14,[R72+99]   HSO_IPEND2 = [R72+99];

ENVY.bin in my post


i'll likely want to know how to continue. Deeply sorry if answer is somewhere in forum.


Update: Thanks!

[ender11]

I guess thet use "eec emulator", available somewhere. insert breakpoint when you need it and viola!
haven't tested that myself.

[tvrfan]

I'll cover basics again, just to make sure there is no confusion..... (0x means in hexadecimal)

This instruction says, add 0x99 to the value in Register 72, and treat result as an address, and get the byte value in that address.

A lot of the binaries have set(s) of data pointers which never change - I think this may be a neat way to introduce a new data calibration via cal console, because it only requires one of those registers to be changed to point to a new data block. But these are commonly registers 0xf0 - 0xfe.

Other common uses -
A data structure pointer - R72 is set to the start of a data structure, and then various offsets used to get at the elements.

KAM - R72 and R74 are used as pointers in several binaries, to point to KAM data, typically as a data structure.
If it's the KAM, these pointers are set very near the start of the code (0x2000), in the init routine, and they never change after that.

R14 is an interrupt pending status register (for high speed outputs and counters) so I would guess this is part of output queue processing, possibly
as part of injector or ignition timing data, or learned trim/adjust ?? (just my guess) This would probably be kept in the KAM as well ......

I can show some of the A9L examples if it will help....
Hope this helps !!

[tvrfan]

I had a quick look at the binary, and that looks like an 8061, not an 8065, so that source code bit is WRONG!!

If that's from my SAD program, then it got the CPU type wrong, which is interesting, as it seems to work OK on my (old) testbed version...

So R14 is a general register of no special purpose on 8061....

will have a deeper look....

[tvrfan]

yep, looks like R6c through to R76 are KAM or RAM pointers ....

Code: Select all

8414: a1,80,01,6c       ldw   R6c,180        R6c = 180;
8418: a1,80,02,6e       ldw   R6e,280        R6e = 280;
841c: a1,80,03,70       ldw   R70,380        R70 = 380;
8420: a1,80,04,72       ldw   R72,480        R72 = 480;
8424: a1,80,05,74       ldw   R74,580        R74 = 580;
8428: a1,c0,07,76       ldw   R76,7c0        R76 = 7c0;
842c: a1,30,11,48       ldw   R48,1130       R48 = 1130;

and this seems to be the only place R72 is set......
(or have I got this all wrong and you really want to know what it actually gets set to ??? )

[XantheFIN]

Thanks! Makes more sense now for me. I got a bit paranoid what to do... I have seen that some are

ECT = Ra9
ACT = Raa
..


As i don't have QuaterHorse i want go via disassembly learn what code is doing... Now after 11? months when i first time started TunerPRO.

Oh.. i had error on dir file. Thats why 8065. My bad.




P.S. First time when i turned off extra Spark Tables by typing full of 110 degrees (had error X/2.. X/4) it DID use them and got max 55 advance in idle. With 60 value works ok.
P.S. Thanks ender11, i had totally forgot eec emulator. And now found better than that Deec Emulator. That which can be found from Yahoo group.

[ender11]

oke, is it possible to make SAD treat given registers as a constants? looks like it is some "rbase" parameter. let's try...

[tvrfan]

Yep, that was the idea of the 'rbase' command, so if you add the lines

rbase 6c 180
rbase 6e 280
rbase 70 380
rbase 72 480
and so on, SAD will automatically do the address resolution for you, so the [R72+99] as shown at top will be shown as [519].
Also, if you add a symbol for 519, the symbol name will be shown.

adding

SYM a9 "ECT"
SYM aa "ACT"

will then replace those register addresses with the name wherever they are used.....

[sailorbob]

[R72+99] = 0x519

[R72+99] = 0x419

[ender11]

what about timers lists? are they autodetected currently?

[tvrfan]

[R72+99] = 0x519

[R72+99] = 0x419

Errr...... [R70+99] = 0x419...... [R72+99] = 0x519 ????? ... (or has my brain finally gone ?)

[tvrfan]

what about timers lists? are they autodetected currently?

That's on my list of things to do, not there yet.......have a test version, but not working right yet.
Can't release current test version with timer lists, as it screws up on A9L, because some developer deserves a special place in hell for doing a JUMP to a subroutine which has embedded parameters instead of a CALL. [Grrrrrr !!!]

NB. The last released version of SAD did do this right, but failed for some other stuff in multibanks, bacuase of another 'clever' trick. Fixing up THAT trick, and some others also, breaks the JUMP fix....I'm falling over Catch 22 situations too often....Damn.....

[sailorbob]

Errr...... [R70+99] = 0x419...... [R72+99] = 0x519 ????? ... (or has my brain finally gone ?)

Short indexed addressing is signed. It's why you'll often see the address register using a 0x0*80 address, nice and convenient.

[tvrfan]

Errr...... [R70+99] = 0x419...... [R72+99] = 0x519 ????? ... (or has my brain finally gone ?)

Short indexed addressing is signed. It's why you'll often see the address register using a 0x0*80 address, nice and convenient.

See, I just *knew* I was right................my brain has finally gone...........................

I had to go and check that SAD did this right and it DOES, so it was a brainfart moment from me.

with an rbase command .....

Code: Select all

abe2: b3,72,99,14       ldb   R14,[R72+99]   R14 = [419];

Thanks Bob for that correction, I totally forgot about the signed byte !!

[ender11]

okthen, 2 more questions:
SAD gives it in the list:

Code: Select all

561a: ef,8f,de          call  34ac           UUByteLU(9408,18);
561d: a2,60,18,00       #args
5621: 39,3e,07          jb    B1,R3e,562b    if (!B1_R3e)  {
5624: ef,85,de          call  34ac           UUByteLU(8c40,18);
5627: 40,01,18,00       #args

and then

Code: Select all

8c34: 00,80             word  32768
8c36: 33,33             word  13107
8c38: ec,11             word  4588
8c3a: f6,28             word  10486
8c3c: 62,10             word  4194
8c3e: 38,00             word  56

8c40: ff,e0,4b,e0,3f,c0,38,a6 ?? 255,224, 75,224, 63,192, 56,166  -7937, -8117,-16321,-22984,
8c48: 2c,69,00,4b       ??     44,105,  0, 75  26924, 19200,


   Func45:
8c4c: 7f,00  func              127,  0
8c4e: 80,00  func             -128,  0
8c50: 80,00  func             -128,  0
8c52: 80,00  func             -128,  0
8c54: 80,00  func             -128,  0
8c56: 80,00  func             -128,  0
8c58: 80,00  func             -128,  0

doesn't give a "func" name and no nice arrangement. why?
ps: and this is in the _msg file:

Code: Select all

sub  34a1  "SUByteLU"   :E 2 f0 X N  :W X N  : F 81 1 1
sub  34ac  "UUByteLU"   :E 2 f0 X N  :W X N  : F 1 32 1
sub  3517  "SUWordLU"   :E 2 f0 X N  :W X N  : F 81 1 2
sub  351c  "SSWordLU"   :E 2 f0 X N  :W X N  : F c1 1 2
sub  351f  "USWordLU"   :E 2 f0 X N  :W X N  : F 41 1 2
sub  3522  "UUWordLU"   :E 2 f0 X N  :W X N  : F 1 1 2

[tvrfan]

That's a good question !!

SAD has identified the subroutine doing the function lookups, got the address right by the looks of it (via an encoded address) and yet it's managed not
to assign the actual data.

I think that's a bug in the code - I saw it do that on a multibank bin, and didn't figure out exactly why until very recently, so I suspect
it's the same problem. What happens is the program misses processing of a subroutine branch from an if/then (e.g. from 5261), and so doesn't assign the data structure correctly. The fact that it's after a bit flag (JB/JNB) is one of the triggers. Doesn't seem to happen very often (as far as I know !)

You can fix this temporarily by adding a func command in the directives (copy one of the UU ones from msg file and changing the addresses is easiest)

Well spotted !!

Second - I made special names for the lookup subroutines to say what they are - UUbyteLu is unsigned in, unsigned out, byte function lookup, the E2 is an encoded address/offset based on register (rbase) Rf0, and the F string is the way SAD tracks it as a special lookup subroutine....
Not very neat, but I couldn't think of another way.... apart from the 'F' part, the extended command matches data structure commands.

[ender11]

every UUbyteLU in the lst shown with address, no names assigned to unsigned-unsigned byte functions, so it doesn't relate to branch. even if I put in the _dir

Code: Select all

sub  34ac  "UUByteLU"   :E 2 f0 X N  :W X N  : F 81 1 1 

it doesn't work.

[tvrfan]

I don't think I was clear in my last post..., what I meant was to add the data struct in, not the subroutine, so add

func 8c40 8c5f :Y : Y

which means " a data function starting at 8c40, ending at 8c5f, and consisting of two columns of bytes"

(end address in probably wrong, adjust it to fit your output)

I tried an ENVY.bin in my latest test version , but perhaps it's different version to yours. I got very different addresses in mine - listing attached in case it's any help. (No it's still not perfect, some bits still missed, could be code or data - looks like code from a quick view, and I didn't put all the rbase comands in either)

[ender11]

well, this is 0GGA rom. here it is attached with _dir file.
I have an idea -- may be, that's because of cscan directives? decompiling in wrong order? say, it found lookup functions in first step, then it looks for additional code, find another one lookup function, but don's assign it as a special function.
or, maybe, directives order makes sense?
besides that, this ROM decompiled pretty well