Alfa bin files

[DieselBob]

The 1.7 MAP table starts at x4600 and runs to x5289.
This lines up nicely with the actual table entry points so i'm thinking that my 8k is at the end of the EPROM image.....

[festy]

After a bit more poking around I realised that there's 2 mcus in this ECU - I was looking at what I'm pretty sure is a 8052, but after tracing the I/O busses I now think it's not the mcu that executes the eprom code - there's a plcc68 IC that seems to match the pinout of an 80x96...
And when I disassemble the eprom as MCS-96 code, it looks a hell of a lot better than with an 8051 target
So in that case the 0000-1FFF space is mapped to SFRs, internal RAM, external RAM, stack etc which means what I downloaded was just a memory dump and not the internal eprom routines
looks like I have another instruction set to learn before I can go any further with this

[DieselBob]

Got another question...
IF the processor loads at 8000 making the 0000 read from an address of 8000 what do all the lcalls lower than 8000 read????
By taking 8000 from the bad addresses they all reference unmaked code entry points, sooo....
Now I'm lost again about the hard coded addresses reading below 8000????

[festy]

Does it load some/all the rom to xram at any point? Do you know where the xram is mapped to?

BTW - I can't remember how far you got with the ram addresses and calcs for each parameter, but if you're still working on them then this might help

Code: Select all

Scale is X (H)
0x3B : 8 bits :  Engine speed
------------------------
Scale is X (L)
0x3C : 8 bits :  Engine speed
------------------------
Scale is X
0xA4 : 8 bits :  Vehicle speed
------------------------
Scale is  (X=0) ? X : ((0xFF-(X>>8))*512 + ((0xFF-(X&0x00ff))/2))*0.001
0x5B : 8 bits :  Injection time
------------------------
Scale is  (X=0) ? X : ((0xFF-(X>>8))*512 + ((0xFF-(X&0x00ff))/2))*0.001
0x5C : 8 bits :  Injection time
------------------------
Scale is  (X=0) ? 0 : (78-(X*0.75))
0x50 : 8 bits :  Spark advance
------------------------
Scale is  X*0.05
0x40 : 8 bits :  Engine load
------------------------
Scale is  ((X&0xff00)<0xfa00)?(X>>8)*0.2:(X&0x00ff)*1.6
0xB3 : 8 bits :  Air flow rate
------------------------
Scale is  ((X&0xff00)<0xfa00)?(X>>8)*0.2:(X&0x00ff)*1.6
0xB4 : 8 bits :  Air flow rate
------------------------
Scale is  ((X&0x00ff) * 2**8 + (140 * (X>>8))) * 2**(-16) * 100
0x0248 : 8 bits :  Idle actuator opening
------------------------
Scale is  ((X&0x00ff) * 2**8 + (140 * (X>>8))) * 2**(-16) * 100
0x0256 : 8 bits :  Idle actuator opening
------------------------
Scale is  (X-128)*0.8
0x0211 : 8 bits :  Lambda sensor integrator
------------------------
Scale is  (X-128)*0.8
0x0201 : 8 bits :  Self-adaptive FRA parameter
------------------------
Scale is  (X-128)*2
0x0207 : 8 bits :  Self-adaptive TRA parameter
------------------------
Scale is  X*0.39
0x026C : 8 bits :  Evapor. ctrl valve opening
------------------------
Scale is  (X*96)/230.4
0x0341 : 8 bits :  Throttle valve absolute position
------------------------
Scale is  (X*96)/230.4
0x0342 : 8 bits :  Throttle valve relative position
------------------------
Scale is  (X*96)/230.4
0x0346 : 8 bits :  Idle posit. learnt
------------------------
Scale is (bitmask)
0x20 : 8 bits :  Conditioner enable request
------------------------
Scale is (bitmask)
0x20 : 8 bits :  Conditioner compressor
------------------------
Scale is  (bitmask)
0x20 : 8 bits :  Anti-theft
------------------------
Scale is  (X=0) ? 0 : (78-(X*0.75))
0x0223 : 8 bits :  Lambda sensor status

(sorry for the crappy formatting, it's just debug output from something I'm working on)

[DieselBob]

What happened..
Got all the MAPS and what looked like ADC and some other lookups from 4000h. to 5c00h
Then ran into the adreessing problem.
Made an excel sheet to table the MAPS and print them for migrating to a Haltec.
Should work with any bin that has the same MAP lookup table like the motronics.
Then tried the addresses minus 8000 this called all the unreferenced entry points.
Now i still have no dptr addresses that point to any of the MAP data????
Sorry for the dumb questions but i'm obviuosly missing something basic thats created a bigger problem........
Still working through the maths using random numbers to learn the system.
Found some equations for converting to real world numbers some appear to work others are way off.

[festy]

Your DPTRs won't point straight to the maps, you also need to reference the map "offset" table.
The map offset tables are a series of bytes like 00 01 02 06 08 - these are entry points to the maps for various car configurations (i.e. high/low octane, auto/manual etc).

On the ML4.1 it uses ram 77/78, 79/7A, R2 and R5 for the map lookup, and the final map DPTR is set in the lookup function with individual movs to DPH and DPL iirc, so searching for "mov DPTR, xxxx" instructions won't help tracking them down.
I can post a (semi) commented table lookup routine from the ML4.1 if that helps?

[festy]

...and why Haltech? It's a great candidate for 12p

[DieselBob]

The code would b a massive help.
Tried to tell him about a 808 and $12p, he's an engineer - and a good one - don't think he realy understood how much work vl400 has done and how versatile it is.

[DieselBob]

ok some observations from a beginer

Change the SFR's and other descriptors to something that makes sense to you....
Understand how the Registers work lol they are used by everything...
Study the call structure...
Work out the difference between internal/external RAM ROM PROGRAM space and DATA space
Study the SFR's... and realise that they can be set with the REGISTERS .......
The interupt system is disabled by default......

and a question
Does a LCALL or similar function load the SP with a 2 BYTE value and jump to the SP value + 1 ???
Still having trouble with some of the addresses

[festy]

Does a LCALL or similar function load the SP with a 2 BYTE value and jump to the SP value + 1 ???
Still having trouble with some of the addresses

LCALL pushes PC+3 onto the stack (i.e. the adress to return to), then sets PC to the 16 bits that follow the LCALL opcode, which causes the code at that address to be executed.
LCALL is 3 bytes long (opcode 0x12 + 2 bytes for address) hence the return address pushed onto the stack is 3 bytes past the 0x12.