[Dave2302]

Hi Guys,

New to this, I need help creating Def files for 2 European EECV ECU's, one is a 1995 "EXIT" ABARO strategy and the other is a 1997 "RUTH" ATAFF strategy.
Both ECU's are external PATS module and pin out's almost the same except the RUTH runs internal coil drivers, (no EDIS module).

I have never done this before, my "Geek level" is at "Dummy" atm, but I am on a rapid upward learning curve and am prepared to commit the time to this.
I do realise it is an awful lot of work, I know that it can take an experienced guy at least 100 hours to create a def file.

Regards

Dave

[cgrey8]

The best starting point I can suggest is to first read over Tom Cloud's eectch98.pdf that goes into the hardware intricacies of the EEC including common (but not guaranteed) memory layout, peripheral controls, and assembly mnemonics. Before you can even begin to understand assembly, you have to understand the breakout of the EEC.

Here's a link I found by googling his name and that file:
eectch98.pdf

To get this file to download, I had to right-click and save link as a file, then launch the file manually. Simply clicking the file didn't work for me. I kept getting a message that the file was damaged or some-such. But saving the file to my HD, then launching it seems to work fine.

Next, is understanding the assembly. And there's no easy way to do this. The brain damage must be spent just staring at the information, searching, and asking questions. Add to this, Ford didn't make it easy to disassemble their code. So most disassemblers require a good bit of hand-holding to get a clean disassembly. If your strat is similar to some other strat that the disassembler has been taught to figure out, then you will be better off. Otherwise, you'll need to create a directive file for a disassembler to teach it what it needs to know to do a proper disassembly of your BIN file. And of course in order to do that, you need to be able to read enough assembly and know some of the "tricks" Ford did that are problematic to disassemblers and thus what needs to be communicated to the disassembler for it to break the BIN out correctly.

And once you get a clean disassembly, then the REAL hard part begins...making heads or tails of the code, what it's doing, and where the pieces of the tune are that you care about. Part of understanding the code is understanding that the data in the BIN has a conversion to data that means something to you. Since these are very old 16-bit processors, you won't find FLOAT type values in these defs. Instead what you'll find is values that range from 0-255 or 0-65535 and have to be converted to a value that makes sense (RPM, kg/hr, degrees advance, LAMBSE values, etc). There is a pattern to how Ford converted a lot of their values. So once you have a fully broken out def file (such as GUFB) that you can compare to, you have a heads-up as to what the conversions might be. For instance, the conversion used for RPM or spark advance is likely to be the same as GUFB. The conversion to kg/hr may be the same, it may be a little different, but often there'll only be a few options for how things get converted. GUFB also has another benefit. There's a strategy document for it that you can read to help you understand what the code's intention is. Since your strats will not have the benefit of a strategy doc, you'll have to do your best at identifying common code between your BIN and a known BIN. And the differences that are not common anywhere else will be up to you to figure out what they are doing, why, and how best to describe their associated data in your def file.

Even though you will be dealing with EEC-V, I would suggest you start simpler with say a GUFB tune. Start disassembling it. Look at the code. Then compare it to the def file. Notice how the def file points to things in the code. For example, notice that most of the BIN files are 56k, not 64k. 56k files are single bank tunes and are refereed to as unbuffered. 64k represents the entire memory space and includes the 0x2000 buffer in the file, even though there's nothing meaningful in that area of the file. So when dealing with unbuffered tunes, address 0x1000 in your BIN is actually 0x3000 in "code." So if you see something trying to jump to an instruction or data location at say 0x34FE, that's actually 0x14FE in your BIN if your BIN file is unbuffered.

Getting familiar with intricacies and details like this will be just part of the "getting your feet wet" of EEC disassembly and def development.

And then finally once you got an idea of where some important pieces of your BIN are, what the conversions are, and how they need to be displayed in BE, you begin making your own def file. Use an existing def file as a template or just copy/paste and change the important info.

[Dave2302]

Thank You so much...................

That post is a mine of useful information in itself, although some of it was a bit beyond me atm.

But 2 weeks ago all of it would have been way over my head, so I have learned a fair bit so far

Thank you,

Regards Dave

[cgrey8]

Once you've read through the eectch98 doc, you'll have a better idea as to what some of this stuff means. But one thing most BIN hackers find useful is the Intel 8096 document, which is a very close cousin to the 8061 and 8065 used in Ford EECs. Intel made the 8061/5 specifically for Ford and never released it as its own product for the public. But as you might expect, they didn't invent the thing from scratch. They borrowed heavily from their arsenal of intellectual property used to make publicly available processors and the 8096 is the closes cousin to these Ford processors hence why the 8096's documents come in handy.

There are other EECGeek threads, most of which will contain some information useful to you at some point. I've tried to keep all the info in this part of the forum specific to the technical nitty-gritty of Ford EECs as it relates to def file development. But for the time being, I would recommend you test out that new disassembler tvrfan has been working on. He spent an immense amount of time getting it to recognize as many of Ford's "tricks" without a directive file as possible. Last I heard, most of them the disassembler could handle. But there were a few that there just isn't a clear way to decipher without human intervention to look at the assembly and figure out what needs to be done based on how the code is written. There's also a thread down below talking about stack pointer shenanigans. That's another EXCELLENT read for you because stack pointer manipulation is the main reason inferior diasassemblers barf on successfully disassembling Ford tunes. Once you get your mind wrapped around what stack manipulation is, where it is commonly done, and WHY, you'll be almost to the point to where you can begin to make sense of the code.