Disassembling Speed Density (SD) Injector Timing Table

This is where the BIN Hackers and definition junkies discuss the inner workings of the EEC code and hardware. General tuning questions do not go here. Only technical/hardware-specific/code questions and discussions belong here.

Moderators: cgrey8, EDS50, 2Shaker, Jon 94GT

Post Reply
wwhite
Gear Head
Posts: 1
Joined: Tue Sep 24, 2019 2:15 pm

Disassembling Speed Density (SD) Injector Timing Table

Post by wwhite » Thu Oct 10, 2019 6:26 pm

I've been hacking away at my Speed Density (SD) binary, and have run into a snag with me not understanding exactly what the following code is doing, or if i disassembled it incorrectly:

Code: Select all

??InjTTable??
22ea: 75,37,00,16,0a,10,20,4d,08,ff,94,00   struct Sub34,  0, 16,  a,Q1, 20, 4d,ff08,   94
22f6: 96,37,00,06,0c,10,20,4d,08,88,94,00   struct Sub35,  0,  6,  c,Q1, 20, 4d,8808,   94
2302: 75,37,00,17,0a,1c,10,4d,04,ff,94,00   struct Sub34,  0, 17,  a,Q2, 10, 4d,ff04,   94
230e: 96,37,00,07,0c,1c,10,4d,04,44,94,00   struct Sub35,  0,  7,  c,Q2, 10, 4d,4404,   94
How I got here, is following A9L master directives, and the InjTTable is similar, but has 8 entries, and " Initialise the 8 entry RAM table "

My code and bin only has 4 entries.
I am assuming this must have something to do with MAF vs SD, and/or batch fire vs sequential.

I know there will be more information needed, but thought someone might be directly familiar with this piece of code.

mpaton
BIN Hacker
Posts: 377
Joined: Mon Jun 23, 2008 1:39 pm

Re: Disassembling Speed Density (SD) Injector Timing Table

Post by mpaton » Fri Oct 11, 2019 1:26 pm

wwhite wrote:
Thu Oct 10, 2019 6:26 pm
I've been hacking away at my Speed Density (SD) binary, and have run into a snag with me not understanding exactly what the following code is doing, or if i disassembled it incorrectly:

Code: Select all

??InjTTable??
22ea: 75,37,00,16,0a,10,20,4d,08,ff,94,00   struct Sub34,  0, 16,  a,Q1, 20, 4d,ff08,   94
22f6: 96,37,00,06,0c,10,20,4d,08,88,94,00   struct Sub35,  0,  6,  c,Q1, 20, 4d,8808,   94
2302: 75,37,00,17,0a,1c,10,4d,04,ff,94,00   struct Sub34,  0, 17,  a,Q2, 10, 4d,ff04,   94
230e: 96,37,00,07,0c,1c,10,4d,04,44,94,00   struct Sub35,  0,  7,  c,Q2, 10, 4d,4404,   94
How I got here, is following A9L master directives, and the InjTTable is similar, but has 8 entries, and " Initialise the 8 entry RAM table "

My code and bin only has 4 entries.
I am assuming this must have something to do with MAF vs SD, and/or batch fire vs sequential.

I know there will be more information needed, but thought someone might be directly familiar with this piece of code.
I used to be more familiar. but I haven't dabbled in this area for years.

Nevertheless, decoding this is a worthy topic of discussion, so I have some pointers. I consider it worthy because it leads to an understanding o what is going on, and because it illustrates the real work of disassembly, rather than the rathole of writing disassemblers, or pretending that disassembly can be made easy.

Until you understand the coding conventions Ford used, this will never be easy.

I am not familiar with the term "InjTTable" that you have used.

However in the sense of a data table that controls when the injectors are turned on relative to a datum like cylinder TDC, this is NOT an injector timing table.

What it is, is a small part of the table that controls how the HSO is controlled. The HSO is well described in the docs on this site.

The full HSO table starts at 22C8 in your bin, and if you search for that address, you will see that it is referenced at these addresses

2A35
2C89
3157
369E

The outputs needing outputs driven at high speed are ignition and injectors. As the Speed Density bins need only 2 injector outputs, there are 6 more available than in the bins that use Sequential Injection. These tend to be used for other things that don't strictly need the speed of an HSO.

So if you examine the code that references the start of this HSO_Table, you will be able to see how the HSO turns each of its outputs off and on. As it is frequently run in the foreground, with all the attendant time constraints, it is not an especially easy decode.

The formatting of the output is close, but not exactly correct; it may mislead you, but seeing how the code uses this data will reveal all.

As in many cases with disassembly, I do not think the conversion from hex to decimal is at all helpful. I think anybody would see more patterns in the hex. Aside from, IMO, if you can't read hex, why are you trying to read assembler?

The value 94 you have at the end of each line (in hex, I note) tells me that you have not appreciated the fee information that is contained in this bin. This information is not in the GUFB document, but it is well described in the LHBH document.

Hopefully others will be encouraged by your endeavors.

Michael

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest