[S12Cat]

Good day.
I'm new in EEC tuning. Making bin dumper now. I want to build def files for some european Fords, 4 and 6 cyl's.
So I thought that EEC IV have some code patterns for fuel table lookup and the same for spark.
Want to ask experienced EEC hackers - have you noticed such things or EEC IV have it's own code sequence in each strategy and ECU for seeking in this tables?

Also want to know, how to find MAF transfer function quickly.

Thanks.

[S12Cat]

Nobody knows?

[andyt12]

People know but its not that easy or simple to explain.

There is no common pattern to find your tables, each strategy is different.

One way is try to find similar done definitions and bins and search that way, if you can find something very close then this will be the quickest way.

You can also find a good commented disassembly to use for comparison of your own. You will find the functions to lookup MAF and such are very similar on all eec's.

If your doing disassembly then you want to first find the Table and Function routines. They are the same or very similar in all eec's.
Once you found the lookups then find the Calibration pointers @ 0x82062, there should be 8 of them 16bit in size and are loaded into REG_F0 to REG_FE. Once you got them then look though the code for calls to table lookups, the instruction 1 or 2 before it should be AD3W, would look like so

AD3W REG_3A,REG_F0,#$0198

So adding 0x0198 and the value at calibration pointer in REG_F0, which would be @ 0x82062 as explained above, would give you the address of a table or function, in my case its 0xC000 + 0x0198 = 0xC198. You can work this backward also to confirm a table address.

Some of the time you will see the row and column scalers lookup before the table.

The above is based on EECV but IV is basicly the same for what I've explained.

Im far from an expert just same basic understanding of it all.

It takes a lot of time and dedication to understand this stuff.

[teal95]

You will be able to get pretty close if you can find a disassembly that's pretty close to you the date of the one you want to play with. For the most part Ford just kept adding routines as necessary. So each later build was slightly longer with code chunks moved to higher memory addresses as needed. A good example of this is the progression in the '87/8 Thunderbird TurboCoupe EECs. As sections were added from the LA to the LA2 and LA3 routines were moved to higher sections of memory. If you can find it the shift tables for the LB, LB2 and LB3/8UA just moved to slightly higher addresses as each point. Functions can be found pretty easily as they will all start with FF XX, YY XX,...00 00 with the 00 00 repeated several times depending on how many points there are in the function versus how much space was left. The previous example was for an unsigned byte value. For an unsigned word it would be FFFF XXXX, YYYY XXXX. For signed values replace the first FF with 7F. The challenging part is tracing the cal to the function to figure out what it does.

Also realize Ford completely changed there method of function calls ~1990. I can't remember at the moment what the earlier method was (IIRC the passed values were placed in scratch registers) while the later version put the passed values immediately after the subroutine call. This makes disassembling a pain because after every subroutine call there is a chunk of data that isn't code. I'm pretty sure the guys cracking the stuff have pretty much automated the cracking at this point.

steve

[91bird]

You will be able to get pretty close if you can find a disassembly that's pretty close to you the date of the one you want to play with. For the most part Ford just kept adding routines as necessary. So each later build was slightly longer with code chunks moved to higher memory addresses as needed. A good example of this is the progression in the '87/8 Thunderbird TurboCoupe EECs. As sections were added from the LA to the LA2 and LA3 routines were moved to higher sections of memory. If you can find it the shift tables for the LB, LB2 and LB3/8UA just moved to slightly higher addresses as each point. Functions can be found pretty easily as they will all start with FF XX, YY XX,...00 00 with the 00 00 repeated several times depending on how many points there are in the function versus how much space was left. The previous example was for an unsigned byte value. For an unsigned word it would be FFFF XXXX, YYYY XXXX. For signed values replace the first FF with 7F. The challenging part is tracing the cal to the function to figure out what it does.

Also realize Ford completely changed there method of function calls ~1990. I can't remember at the moment what the earlier method was (IIRC the passed values were placed in scratch registers) while the later version put the passed values immediately after the subroutine call. This makes disassembling a pain because after every subroutine call there is a chunk of data that isn't code. I'm pretty sure the guys cracking the stuff have pretty much automated the cracking at this point.

steve

In what way has the code cracking been automated?

[teal95]

Being as the guys who sell the def files will typically release large chunks of them that are related I would have to guess that they would have somewhat automated the process. As I tried to explain the cals are all closely related with more code added as time went on. I know if I was doing it I would be playing with the disassembler to get it to do as much of the work as possible so I didn't have to do everything by hand.

steve

[tvrfan]

Actually, I reckon you can sort of do it, but you need to be sneaky.

I've spotted that the actual code used to read tables and functions doesn't change much, right from early boxes like mine (1985 Ford Granada, UK), through to A9L and things like the EARS binary. this is because what the code does is almost exactly the same.

I have been working on an 'intelligent' analyser/ dissasmbler, which spots the signature of various bits of code, and then is able to work out the data addresses - it sort of works..

I have a full analysis listing (not really a true disassembly but a HELL of a lot easier to read) of my EEC box, and I'm working on the A9L in same format if anyone is interested.

[cgrey8]

I am. I've been wanting to write something that does that for a long time. I just haven't had a strong enough excuse or reason to actually motivate me to do it.

[tvrfan]

OK then, attached is where I'm up to with the A9L.

This printout is produced by a tool I've been working on for a long time, on and off.

It can resolve names for straight and indexed variables, and adds a 'C' like program comment to aid understanding - it also can do embedded variables, with a suitable
dir file. I added the concept of a 'structure' (again like 'C' code) so it can do the
byte/word/subroutine mixes (e.g at 2296).

This is NOT FINISHED, but if it's of use, then great.
file is zipped to save space (standard winzip, and WinXp on understands it, I think.
(I'm more of a UNIX man myself...)

Andy.

[cgrey8]

Is there any chance you'll have a tool that is capable of disassembling, allowing editing, and will reassemble including recalculating line numbers and "fixing up" jump values?

[tvrfan]

Good question, but I have to say I haven't really gone that way [yet]. Sorry.

I was especially interested in understanding how the code worked, probably because I'm too much of a code geek...

I'll have a think about the idea though.... I guess I'm half way there if the disassembly
works....


A.