Trying to decode the EEC

cougarnut281 · Post by **cougarnut281** » Thu Jan 03, 2008 8:56 pm

Hello, I have recently started attempting to learn how to make a workable definition out EEC binary files. I have come to a point where I have questions that must be answered before I can get any farther on this.

First off, I have no previous programing experience. I have downloaded Bill L.'s dissemblers as well as one from C.A.T.S. and have been playing with those for a bit. I have been trying to make a connection between the disassembled files and the strategy documents as well as trying to glean any additional knowledge from Tom clouds document and these forums.

I have gotten to a point where I am at a stand still. I am not sure what the key is to getting to the next step of learning. As of right now I don't understand Opcodes and what there significance is or what a label means in the disassembled file.

Any help or pointers you guys can give I would be extremely grateful for.

Frit · Post by **Frit** » Thu Jan 03, 2008 10:09 pm

Its hard to say where to start. Your best bet is to get a document on the 8061 processor. Also look for and read the document called eectch98.pdf which explains alot of everything that goes on in the EEC as well as the opcodes etc.

One tip to I can give you, is almost all of the work done with the numbers are done in the first 255 (0xFF) bytes which is the REG_## that you see through all the code. Typically those numbers are then moved into higher memory locations when its done with it so to speak. Also the addresses from 0xF0 (REG_F0) to 0xFF (REG_FE) hold pointers to memory regions that contain all the scalers, functions and tables you see in the tuner programs.

I'm sure others can other up some tips as well.

cougarnut281 · Post by **cougarnut281** » Thu Jan 03, 2008 10:57 pm

Frit wrote:Its hard to say where to start. Your best bet is to get a document on the 8061 processor. Also look for and read the document called eectch98.pdf which explains alot of everything that goes on in the EEC as well as the opcodes etc.

I have done so already and still don't fully understand what I am reading. This is all new to me but I think I understand that the opcodes are the instructions, like an if then statement in a higher programing language right? If that is true than what do these opcodes mean?

For instance if I read correctly 0x09 is SHLW which stands for shift word left. All this means to me is that when I see 0x09 in the file it may mean to perform this task. Is that correct?

One tip to I can give you, is almost all of the work done with the numbers are done in the first 255 (0xFF) bytes which is the REG_## that you see through all the code. Typically those numbers are then moved into higher memory locations when its done with it so to speak.

I don't understand what REG_## means, could you please explain. Sorry for my ignorance.

Also the addresses from 0xF0 (REG_F0) to 0xFF (REG_FE) hold pointers to memory regions that contain all the scalers, functions and tables you see in the tuner programs.

I am aware of these pointers but don't know how to read them. I have looked right at them and didn't know where to look for the info afterwords. Is this related to me not understanding the opcodes?

I'm sorry if this seems elementary to you but I am just starting to learn about programming in general so please bare with me on this.

Frit · Post by **Frit** » Fri Jan 04, 2008 1:00 am

If you have an opcode in the dissassembled file that says

SHL REG_80

then that means take the word value stored in register 80 which is memory address 0x80 and shift all the bits of that word left one, which is like multiplying by 2. A word takes two bytes of memory.

The eectch98 document lists all the opcodes and what they are. You should also look for documents that cover the Intel 8061 processor for more information.

The REG_## is a register or memory location that exists within the 8061 processor that is faster for it to use than the rest of the memory it has access to.

For the memory offsets from 0xF0, if you see a command like

ld REG_42, 0x50[REG_F0]

that means to load the number that is a word located at the address stored in register 0xF0 plus 0x50 into register 42 which is address 0x42.

In the GUFB strategy, 0xF0 will have 0x8C00 in it, so the above number that will go into REG_42 will come from the address 0x8C00+0x50=0x8C50

If your looking at a bin file directly with a hex editor, then you will need to look at 0x6C50 for the value, because most bin files you see actually start at 0x2000 and don't include the lower addresses.

Hopefully I just made things as clear as mud :( . Its not a simple thing to understand low level coding like this and has taken years for me to learn so its not elementary to me ;).

Frit · Post by **Frit** » Fri Jan 04, 2008 1:08 am

To get the memory offsets that get stored in 0xF0 etc, look at the disassembled code starting at address 0x2022 and you'll see the addresses that get loaded into 0xF0.

Here's what the GUFB code has.

2022 008C word $8C00
2024 5A8E word $8E5A
2026 D68F word $8FD6
2028 A893 word $93A8
202A 3094 word $9430
202C A897 word $97A8
202E 7E9A word $9A7E
2030 5A9E word $9E5A

so 0xF0 will contain the numbers of the address $8C00
and 0xF2 will contain the numbers for address $8E5A

and so on. Now keep in mind that the numbers are stored in low byte/high byte order. If you look at the line 2022 you'll see the numbers 008C...

That is how it is stored in memory directly.

so 0x2022 will hold 0x00 and 0x2023 will hold 0x8C. To get the number you want, flip them so you get 0x8C00, and ironically this is a word ;).

cougarnut281 · Post by **cougarnut281** » Sat Jan 05, 2008 1:42 pm

Clear as mud :D

One other question while I digest this info. What is a word or for that matter a double word?

Thanks for the help so far.

Frit · Post by **Frit** » Sat Jan 05, 2008 3:10 pm

All computers run on bits, and 1 bit will only be a 0 or 1. A byte is eight bits together, and if unsigned will hold 0 to 255 or if signed will be a number from -128 to 127.

A word is 2 bytes long or 16 bits. An unsigned word will go from 0 to 65535 (0x0000 to 0xFFFF) and a signed word will hold -32768 to 32767.

A double word is 2 words long, 4 bytes long 32 bits. An unsigned dword will go from 0 to 4294967295 (0x00000000 to 0xFFFFFFFF) and a signed dword will hold -2147483648 to 2147483647.

Typically the most left bit will be used to indicate if a number is negative( 1) or positive(0) if its a signed number.

So far I haven't seen the use of any dwords in the EEC code but I have only looked at the A9L and the A9U2 code.

cougarnut281 · Post by **cougarnut281** » Sat Jan 05, 2008 3:17 pm

Thanks, that is kind of what I thought but wasn't sure.

now I need to spend some time looking over my files and see if I can connect the dots.

ashyers · Post by **ashyers** » Wed Jan 09, 2008 1:49 am

How do you know if something is stored in hi/lo or lo/hi order? What are the effects if you get this portion incorrect? I'm trying to learn this stuff too and am playing with a Tweecer and Binary Editor and trying to get more useful data from the setup. This stuff is definately its own language!

TripleBlackVert · Post by **TripleBlackVert** » Wed Jan 09, 2008 8:38 am

start by contacting navybob ...

cougarnut281 · Post by **cougarnut281** » Wed Jan 09, 2008 9:26 am

Do you mean sailorbob? I couldn't find a navybob on the site.

Post by **cgrey8** » Wed Jan 09, 2008 9:46 am

Yeah, I'm pretty sure he meant sailorbob. Derek ought to slap him for that.

TripleBlackVert · Post by **TripleBlackVert** » Wed Jan 09, 2008 11:28 am

i'll slap myself ...

i'm not sure why i thought he went by navybob ... it might be that someone else has navybob for their user name on another site or something ...

as to it being its own language, you are absolutely right ... it's called machine code. the human readable version of it, assembly language, is human readable at least, but not much more understandable.

and you are just seeing the tip of the iceberg. wait until you get into the whole way the binary values in the scalars, functions, and tables are interpreted. some are interpreted as integers, others as floating point (either signed or unsigned) with <x> bits to the right of the the decimal ... and the <x> can and will change depending on the desired range of values the program supports for the given scalar/function/table. decoding that stuff is sure to be fun.

you are in for a bumpy ride ... have fun with it

Post by **cgrey8** » Wed Jan 09, 2008 11:32 am

I honestly thought you were just being funny. Either way, I got a chuckle from it.

Frit · Post by **Frit** » Wed Jan 09, 2008 12:53 pm

ashyers wrote:How do you know if something is stored in hi/lo or lo/hi order? What are the effects if you get this portion incorrect? I'm trying to learn this stuff too and am playing with a Tweecer and Binary Editor and trying to get more useful data from the setup. This stuff is definately its own language!

Simple, all the EEC or Ford computers are Intel based, so they are stored in lo byte/hi byte order. Some of the other car manufacturors are based on the motorola processors where are hi byte/lo byte order.

This comes into play when dealing with numbers that are larger than bytes, such as words etc.

When you get into DWORDS, each 2 byte section is stored as a lo byte/hi byte which makes it even more fun to decode ;).

svojohn · Post by **svojohn** » Wed Jan 09, 2008 6:23 pm

cgrey8 wrote:Yeah, I'm pretty sure he meant sailorbob. Derek ought to slap him for that.

I'm pretty sure that Derek uses navvybob as a user name on a different site. Maybe that's where the confusion comes from.

Post by **cgrey8** » Wed Jan 09, 2008 6:54 pm

svojohn wrote:
cgrey8 wrote:Yeah, I'm pretty sure he meant sailorbob. Derek ought to slap him for that.
I'm pretty sure that Derek uses navvybob as a user name on a different site. Maybe that's where the confusion comes from.

Ahh, that would make sense. The only 2 forums I frequent are this one and the V8-ranger forum. I occasionally check the TwEECer section at sbftech.com, but it's new and not very active at all.

Frit · Post by **Frit** » Wed Jan 09, 2008 8:55 pm

TripleBlackVert wrote:start by contacting navybob ...

Wulp.. its obvious I don't know what I'm talking about, so this advice is probably better.

I'm outta here.

TripleBlackVert · Post by **TripleBlackVert** » Wed Jan 09, 2008 10:55 pm

Frit wrote:
TripleBlackVert wrote:start by contacting navybob ...
Wulp.. its obvious I don't know what I'm talking about, so this advice is probably better.

I'm outta here.

Frit, I hope you don't think I saying anything about your knowledge of this stuff, because that was not at all my intention. I was just saying that sailorbob has the most experience that I know of with analyzing the code.

To be totally honest, I responded to the first post without reading the rest of the thread.

You clearly have a good working understanding of cpu architecture and assembly language, and, after reading the thread again, I think he needs the help you were providing the most right now.

cougarnut281 · Post by **cougarnut281** » Thu Jan 10, 2008 11:22 am

Frit, I agree with 'vert. Your postings have been most helpful and gave me a jump start on figuring this stuff out.

Frit · Post by **Frit** » Thu Jan 10, 2008 11:39 am

Sorry for my sarcasm.... but don't worry I'll keep helping the best I can :D .

cougarnut281 · Post by **cougarnut281** » Fri Jan 11, 2008 9:01 pm

Ok, I have been playing with what I have learned so far and can kind of read the coding. As for knowing what to look for that is another story.

My question is exactly that, how do I know what to look for to identify where my functions, scalars, and tables will be? Am I jumping to far ahead here or is this the next step because I am not sure if I may be missing something in between?

Frit · Post by **Frit** » Fri Jan 11, 2008 10:35 pm

Scroll up where I posted about the address's being stored into 0xF0. Starting at 0x2022 are 8 addresses that are actually pointers to "zones" that contain the scalers, functions and tables... all of them.

You need to look that up in your code to get those pointers. You might want to find a strategy that is close to yours that has been decoded and that may help you get started. I reference the GUFx strategies for GURE cause they are similar.

cougarnut281 · Post by **cougarnut281** » Sat Jan 12, 2008 10:13 am

How do I tell what is what in those memory regions? Is it just trial and error? Can I look at the intructions in the first parts of the .bin to find them? Are they always in the same order like reg_F2 is always spark etc?

TripleBlackVert · Post by **TripleBlackVert** » Sat Jan 12, 2008 10:44 am

this is the area where sailorbob has really done the most.

an eec editor has what is typically referred to as a definition file, which is essentially a map of the binary. in it, the address, type and size of the data structure for all the known scalars, functions, and tables (what i'll refer to as data pockets) are defined. there are different formats for the def files, clint's binary editor comes with some.

once you have a def file, then you can build a disassembly with that strategy's data pockets labelled. then you get to start looking at the what the code does with each data pocket. from that, you can start to piece together what is going on.

i started doing this a few yeara ago, but i didn't get too far, life got in the way, and i haven't gotten back to it

ashyers · Post by **ashyers** » Sat Jan 12, 2008 1:02 pm

Can any of you guys recommend a text or something that will give me some insight to some of the basic programing structure used in the EEC? I'm not looking for an EEC handbook, just something that will understand the more basic stuff and some of the vocabulary used in the machine & assembly language. I'd like to know more about how this stuff is written so I may interpret it a bit better. Hell, I can't even recognize any command lines!!!

Andy

Post by **cgrey8** » Sat Jan 12, 2008 1:21 pm

The closes thing you'll come to is any book written for assembly programming of the Intel 8096 processor. The Ford EEC uses an Intel 8061 processor in the older EECs and an 8065 in the newer ones. I have no clue if the 8065 is still being used or not. These processors were only used in automotive applications. But the 8061 processor shares a lot of programming similarity with the Intel 8096. In fact, there are some documents around that have a complete list of 8096 opcodes that might also help. I think there are some differences in the 8065, but I don't know what they are.

Point is, you aren't likely to find any publications on the Intel 8061/8065 since they were never main stream processors. But that doesn't mean that there isn't some info you can glean from texts written about the Intel 8096. In fact, I think the compiler/decompiler for deciphering the BINs is for 8096s.

I may be wrong on that one, but I think I'm remembering that right.

cougarnut281 · Post by **cougarnut281** » Sat Jan 12, 2008 1:51 pm

I do know that the bill's displays most of the 8096 opcodes in the .lst file so I have to go and cross them with 8061/65 depending on what it is.

Frit · Post by **Frit** » Sat Jan 12, 2008 3:19 pm

I think the first place to look is a book on assembler programming, even if its for a 8088 processor, which was very common back in the day. This will give you a good grasp of how programming a processor goes. After that you can look up a chart on the opcodes used with the 8061 series processor and have a good grasp of what it does.

I think the 8061 series has been superceded by the 80161 processors from intel now.

I'm working on decoding the GURE strategy which is similar to the GUFx, but of course everything is in different order etc. Its time consuming because I'm building up a directive listing for the GURE for the disassembler as I'm going.

Unfortunately there is no easy way to go about this, except with persistance and patience. The more you do it though the easier the code comes to you so to speak.

ashyers · Post by **ashyers** » Sat Jan 12, 2008 6:32 pm

I'll have to ask some of my buddies who do this for a living if they have any old info I may borrow. I guess that's an advantage to being near Silicon Valley. Thanks for the help. I'll post any good titles that I happen to dig up.

Andy

Trying to decode the EEC

Who is online