Alfa bin files

[DieselBob]

So when the Oval executes it's from the 2 byte address? Or the address plus 1?

[festy]

Here's an example:
the instruction at 0034 is an lcall, so prior to it's execution 0034+3 is pushed onto the stack, then PC is set to 027d (the 2 bytes following the 0x12).
Next cycle, the code at 027d is executed (just a reti in this case), so the "return address" PC is popped from the stack (0034+3, ie 0037) so that's the address of the next instruction to be executed. There's no offset like with relative addresses etc, the address passed to the lcall is the called address, and the instruction directly following the lcall+addr bytes is the next following the return from the lcall.

Code: Select all

X0032:  setb    T2_INT          ; 0032   d2 2f      
        lcall   X027d           ; 0034   12 02 7d   
tf2_vec_end:
        ljmp    X0245           ; 0037   02 02 45   

X027d:  reti                      ; 027d   32        

The exception to this is if the the stack is modified during the lcall-ed function.
As ret/reti pop the 2 most recent bytes off the stack for setting the PC, if the stack is changed then your return address won't be where you expect it to be.

[DieselBob]

No worries that's what I thought.
I have lcall's that reference code that is part of an operation not an operational address.
Bit confused and that's one less option

[festy]

have you got a data area being disassembled as code somewhere previous that's throwing the disassembler off?
What sort of addreses are you seeing this at? I'll see if I get the same thing...

[DieselBob]

At work I'll post something when I get home or in the morning

[DieselBob]

Ok heres a couple of annoying examples

Code for Address X001e
mov 0c3h,a ; 0014 f5 c3 uC
nop ; 0016 00 .
clr 0c0h.3 ; 0017 c2 c3 BC
clr 2ch.3 ; 0019 c2 63 Bc
mov a,rb3r1 ; 001b e5 11 e.
mov 7ah,a ; 001d f5 7a uz
cjne a,#1,X0032 ; 001f b4 01 10 4..
push dph ; 0022 c0 83 @.
push dpl ; 0024 c0 82 @.
ljmp X21ae ; 0026 02 21 ae .!.

Unreferenced address
Line 14885: X001e equ 1eh

Calling Code
Line 4818: X21c3: ljmp X001e ; 21c3 02 00 1e ...

Unreferenced address
Line 3358: lcall X054e ; 1644 12 05 4e ..N
Line 5958: lcall X054e ; 2990 12 05 4e ..N
Line 6646: lcall X054e ; 2e9c 12 05 4e ..N
Line 6741: X2f41: lcall X054e ; 2f41 12 05 4e ..N
Line 6764: lcall X054e ; 2f63 12 05 4e ..N
Line 6883: X3056: lcall X054e ; 3056 12 05 4e ..N
Line 6969: lcall X054e ; 3103 12 05 4e ..N
Line 8236: lcall X054e ; 3a04 12 05 4e ..N
Line 8243: lcall X054e ; 3a14 12 05 4e ..N
Line 8245: lcall X054e ; 3a1a 12 05 4e ..N
Line 8253: lcall X054e ; 3a28 12 05 4e ..N
Line 8258: lcall X054e ; 3a32 12 05 4e ..N
Line 8265: lcall X054e ; 3a42 12 05 4e ..N
Line 8267: lcall X054e ; 3a48 12 05 4e ..N
Line 8338: X3acd: lcall X054e ; 3acd 12 05 4e ..N
Line 8361: X3af0: lcall X054e ; 3af0 12 05 4e ..N
Line 10415: lcall X054e ; 5ec7 12 05 4e ..N
Line 10784: lcall X054e ; 61af 12 05 4e ..N
Line 10793: lcall X054e ; 61bb 12 05 4e ..N
Line 11766: X68d6: lcall X054e ; 68d6 12 05 4e ..N
Line 12468: lcall X054e ; 6dbf 12 05 4e ..N
Line 12485: lcall X054e ; 6ddb 12 05 4e ..N
Line 12686: lcall X054e ; 6f1b 12 05 4e ..N
Line 12777: lcall X054e ; 6fac 12 05 4e ..N
Line 13305: lcall X054e ; 7372 12 05 4e ..N
Line 13689: lcall X054e ; 764f 12 05 4e ..N
Line 14913: X054e equ 54eh

Code for X054e
mov dpl,a ; 0538 f5 82 u.
mov r1,#84h ; 053a 79 84 y.
mov a,@r1 ; 053c e7 g
mov dph,a ; 053d f5 83 u.
mov a,#0 ; 053f 74 00 t.
jnb 2ch.0,X056f ; 0541 30 60 2b 0`+
jb 28h.1,X056f ; 0544 20 41 28 A(
jb 2dh.0,X054f ; 0547 20 68 05 h.
mov a,b ; 054a e5 f0 ep
jnb acc.2,X0552 ; 054c 30 e2 03 0b.
X054f: mov a,r0 ; 054f e8 h
sjmp X056f ; 0550 80 1d ..

Theres others that I'm working through most are external - example the chip in the lower right corner on the eprom side when the plug up, pins to the ignition controllers, havent tracked them back to the external RAM or the processor yet. Started to trace the board then realised its at least 3 layers

[festy]

I just started disassembling the bin, and the first thing that jumped out at me was:

Code: Select all

00007AD5                 mov     iram73, #0x46 
00007AD8                 mov     iram74, #0x66 
00007ADB                 mov     DPTR, #0x4316
00007ADE                 mov     iram75, #0x40 
00007AE1                 mov     iram76, #0x31 
00007AE4                 ret

That's one of the precursers to the map lookup.
I haven't seen the map lookup routine yet, but it's probably something vaguely like:

Code: Select all

mov A, iram75
mov DPH, A
mov A, iram76
mov DPL, A
clr A
movc A,@A+DTPR           ; @4031[+0] = 02
mov R2, A                    
mov A, iram73 
mov DPH, A
mov A, iram74
mov DPL, A
mov A, R2
movc A, @A+DPTR         ; DPH of map index
mov R2, A
inc A
movc A, @A+DPTR         ; DPL of map index
mov DPL, A
mov A, R2
mov DPH, A                  ; DPTR pointing to  map at 0x4cfb

Then you'd have all the 2d/3d determination, axis lookup etc.
Using that example lookup routine, you'd land on the map at 4CFB, which is
3b 04 05 19 32 9c 0e 0f 15 1b
and
3b = RPM/40
04 = 4 columns in X axis
axis data = 9c 32 19 05 or
800,1000,2000,4000

A couple of other things I recognised quickly:
serial debug routine is at 094E I think, and 10FD is the iram test that should be called by the reset vector.
43DB looks like the list of the DTC codes, and R6,R7 are used for the "snapshot" data that's recorded with a DTC (i.e. rpm, load for some faults, whatever is relevant to the DTC).
I would have expected to find a routine to "check if the DTC # stored in the B reg was already logged" at 8F8D and a check of the number of stored DTCs at 8FA4, maybe there's some DPH trickery going on, or address line shuffling?
Have you checked that all the CPU's A lines go to the correct eprom lines?

Actually, I think I just worked it out while typing this - A15 isn't connected to the eprom? That would make 8F8D -> 0F8D and 8FA4 ->0FA4, both of which are function entry points

[DieselBob]

So the advice to take 8000h from any address above 8000h looks to be good.
I saw the routines in the 7000 region so many with different layouts got a bit much, tried a couple must have been other functions dont remember trying the specific ones in the area you pointed out, still working with the R functions.
I was heading in the riight direction, not getting much success so had a big doubt thing going on.
Thanks for taking a look.

[DieselBob]

just had a hunt for the iram shift to the acc. Its not finding a reference but there is another function.
7a61 has the First Map Table Index Entry Address.
7ae5 for the injector constant (Guessing here).

[festy]

just had a hunt for the iram shift to the acc. Its not finding a reference but there is another function.
7a61 has the First Map Table Index Entry Address.
7ae5 for the injector constant (Guessing here).

I'm wondering if there's some memory access trickery going on somewhere, I see there's a lot of movxs reading from DPTR (so assume the xram is >2k in size?)
The iram addresses for the table lookups can be accessed both directly and indirectly, but I couldn't see any obvious indirect reads to those locations.

What's the part # on the processor? It might be a 8052 variant with 384 bytes of iram instead of the usual 128/256, which would then use some smoke and mirrors to access parts of the iram (that might look like sfr reads and not iram reads)...

As for the injector constant - I won't say that there isn't one, but I've never found such a thing in the motronics that I've worked on. They use the AFM transfer maps to scale the injectors, and there's usually a map or two (2d, 3x1 size or similar) full of 0x80s that I have a feeling may be related to injector scaling but not sure.
The 'load' value represents injection mS, translated by X*0.05. The load value is determined from the AFM map, so scaling that effectively scales the injectors.
...but I could be wrong, there may well be a constant there somewhere - and I guess the AFM->load calc probably makes use of a scaler somewhere that would serve as a form of injector constant