[mpaton]

So that means you're not going to support any more than 4 banks?

[jsa]

Just released 3.08.
......
I have a couple of bins which seem to have two code banks (not allowed!!) but from names, may be a dump of original followed by modded version, so I have changed SAD to print first code bank found.

Thank you for the new version release.

Any of those oddball two code bank bins have something other than 8 and 1 for calibration pointers and _maybe_ number of tunes or something?

Code: Select all

2020: 08                  byte    8
2021: 01                  byte    1

[sailorbob]

I believe the 4TAB ecu has an 88k rom so I suspect both of the bin files you have are not correct.

[ranga83]

the 4tab_el_spark is a modified 4tab with the el falcon spark tables. and yes, it has bank 8 loaded into it twice, not sure why they did that but obviously wasn't ford that did it. my copy also has junk in the filler instead of "ff"

[tvrfan]

So that means you're not going to support any more than 4 banks?

Actually, I've written the code so that it should handle ALL 16 banks, so there !!
Well, yeah, OK, code does check for 0,1,8,9 in a few places, but for all addressing, it's full 20 bits, 16 banks capable.
Anyone got a (8065) bin with >4 banks ??

Frankly, it would be SO much nicer if EVERYONE STUCK TO A STANDARD FILE FORMAT and HAD THE BANKS IN THE SAME ORDER.
But like many things in life ....it's obviously too much to ask for.

[Hmmm.. irrelevant, but I can't seem to get smilies to work correctly ...Yes, side panel says they are on, but won't work]

[tvrfan]

Seriously but -

I've collected quite a few bins for my test set, I've got over 100 now. About time I did that really, as I'm still discovering new code tricks in them.

There are a couple where whoever did the dump had faulty hardware/connection, as it always has one of the bits set (so not useable),
A few where the filler has a value other than 0xff, or has a recurring pattern, but the real code and data are OK.
At least one where both the front 0x2000 and end filler area has a recurring pattern of values but again the main block is fine....
A couple with missing or extra bytes at the front....

and I've tried to cater for all of these ...

[tvrfan]

Thank you for the new version release.

Any of those oddball two code bank bins have something other than 8 and 1 for calibration pointers and _maybe_ number of tunes or something?

Code: Select all

2020: 08                  byte    8
2021: 01                  byte    1

I've not seen anything other than the 8 (regs) and 1 (set) yet. Earlier bins have no formal structure at all, and this setup at either 2020 or 2060 seems to be a de facto Ford standard. It's even in the handbook in the memory map.

Anyone got anything different ?

[mpaton]

Actually, I've written the code so that it should handle ALL 16 banks, so there !!
Well, yeah, OK, code does check for 0,1,8,9 in a few places, but for all addressing, it's full 20 bits, 16 banks capable.
Anyone got a (8065) bin with >4 banks ??

I'm sure many people do, possibly even yourself if you have an ECU with flash ROM in it.
Try enabling the flashing pin................

[tvrfan]

I'm sure many people do, possibly even yourself if you have an ECU with flash ROM in it.
Try enabling the flashing pin................

I only ever had a couple of older actual EEC-IV boxes as part of classic car and engine swaps/kits from several years ago.
Boxes were all UK/European ones, from before I moved to New Zealand.
Other than that, I've only ever had file images, and the [auto] disassembler idea became more of a 'brain challenge' thing (and still is).

If someone wants to send me a file image with Flash, I'll always be interested.....

[motorhead1991]

Seriously but -

I've collected quite a few bins for my test set, I've got over 100 now. About time I did that really, as I'm still discovering new code tricks in them.

There are a couple where whoever did the dump had faulty hardware/connection, as it always has one of the bits set (so not useable),
A few where the filler has a value other than 0xff, or has a recurring pattern, but the real code and data are OK.
At least one where both the front 0x2000 and end filler area has a recurring pattern of values but again the main block is fine....
A couple with missing or extra bytes at the front....

and I've tried to cater for all of these ...

I can send you the 3 that I have if you like - EFI-MA35 and EFI-SD20a (2 out of the 3 of those are on Github)

[jsa]

A piece of CARD.

Code: Select all

6cbd: c3,6e,96,3e         stw   R3e,[R6e+96]     LWord = R3e;
6cc1: a3,6e,96,38         ldw   R38,[R6e+96]     R38 = LWord;
6cc5: a0,a2,3a            ldw   R3a,Ra2          R3a = HWord;                     # Ra2*65536
6cc8: 0c,01,38            shrdw R38,1            LR38 >>= 1;       ## R38 /= 2    # (LWord+(HWord*65536))/2
                                                                                  # LWord/2 + HWord*32768
6ccb: 68,38,3a            sb2w  R3a,R38          R3a -= R38;                      # HWord*32768/65536 - LWord/2
                                                                                  # HWord/2 - LWord/2
6cce: c3,6e,74,3a         stw   R3a,[R6e+74]     Result = R3a;

[sailorbob]

This is just a bit of cute coding by Ford, in this particular instance using SHRDW has saved using SHRW twice (i.e. separately on 0x38 and 0x3A) as the value is 0x38 is not double word sized and the lowermost bits of 0x3A are zero.

[jsa]

Indeed, bit0 of R3A would have to be clear for the math to work like that.

Seems an obfuscated way to find the difference between 2 unsigned words and giving the result as a signed word. Hints at SHRW not working on a signed value if the order was subtraction then shift.

Presents a fair challenge for tvrfan to have SAD automaticly resolve.

[sailorbob]

It's not obfuscation, just a neat way of saving 8 state times. I doubt you could automate commenting this out in the disassembly due to its subtlety.

[jsa]

Hmmm subtlety. Hidden in plain sight. Obfuscation. All tarred with the same brush to some degree, I say .

Yes those wait states. Hats off to whoever developed that approach. How many other reasons are there to ensure 10 bit values are at the top of the word?

[tvrfan]

Actually, there's quite a lot of wait loops in low level coding, everywhere.

Trouble is the CPU is often faster than the hardware it's driving. On the slightly bigger machines I worked on, many of the peripherals used interrupts to communicate, but even then there often had to be a wait between reading/writing commands or data (etc.) Often (IMHO) it's actually to do with the memory sharing/scheduling between CPU and a device.

True Story -

I can remember a project with a high speed comms link (for its day) between dual computer suites.
When we had a project which used the same link between 3 systems, we got the same drivers, and I saw that the previous author of the driver had this weird 'reject next message' flag embedded in the code. Huh ?? After a bit of playing around I and a colleague discovered the hardware needed an extra delay because it wrote to memory data AFTER it generated an interrupt, resulting in it screwing up its CRC check if you read it too quickly (it was actually a HW design error). You could get around it by simply adding in three SHW 16 instructions in the right place in interrupt handler code. We could then show the throughput actually doubled (well 1.9), so that 'reject flag' code was being hit almost every single time to fix the CRC error, and it was only spotted because we were curious about the code. Bugger of it was I had to push hard because the so-called "op system experts" were an arrogant bunch and simply didn't believe me. And that was with a proper operating system too.

[tvrfan]

here's a great one to "do yer 'ead in" as they would say in dear old Blighty (UK slang)

I found this in 22CA whilst trying to get variable arguments to work, and spent AGES looking at it for why SAD wouldn't
pass on the function lookup attributes..... and then the light dawned......

Code: Select all

  
     SUBFunLU1:
86dbc: f2                 pushp                  push(PSW);
86dbd: 91,20,e0           orb   Re0,20           Re0 |= 20;
86dc0: 20,25              sjmp  86de7            goto 86de7;

   SSBFunLU1:
86dc2: f2                 pushp                  push(PSW);
86dc3: 91,20,e0           orb   Re0,20           Re0 |= 20;
86dc6: 00                 skip                   goto 86dc8;

   USBFunLU1:
86dc7: f2                 pushp                  push(PSW);
86dc8: 91,10,e0           orb   Re0,10           Re0 |= 10;
86dcb: 20,1a              sjmp  86de7            goto 86de7;

   SUBFunLU2:
86dcd: f2                 pushp                  push(PSW);
86dce: 91,20,e0           orb   Re0,20           Re0 |= 20;
86dd1: 20,0d              sjmp  86de0            goto 86de0;

   Sub263:
86dd3: f2                 pushp                  push(PSW);
86dd4: 91,20,e0           orb   Re0,20           Re0 |= 20;
86dd7: 00                 skip                   goto 86dd9;

86dd8: f2                 ???   

86dd9: 91,10,e0           orb   Re0,10           Re0 |= 10;
86ddc: 00                 skip                   goto 86dde;

   Sub264:
86ddd: f2                 pushp                  push(PSW);
86dde: 20,00              sjmp  86de0            goto 86de0;

86de0: 28,4e              scall 86e30            Sub265();
86de2: b2,3c,3c           ldb   R3c,[R3c]        R3c = [R3c];
86de5: 00                 skip                   goto 86de7;

   UUBFunLU1:                                                 ## this is the real func lookup subr 
86de6: f2                 pushp                  push(PSW);
86de7: 9b,3a,02,3c        cmpb  R3c,[R3a+2]      
86deb: 3d,e0,04           jb    B5,Re0,86df2     if (B5_Re0 = 1) goto 86df2;
86dee: db,0a              jc    86dfa            if (R3c < [R3a+2])  {
86df0: 20,02              sjmp  86df4            goto 86df4;             ## snipped here

why does SAD find the earlier ones correctly, and not the later ones ?
is it the embedded subr call ? (which is a get parameters, so this has signed/unsigned options for both embedded arguments and via old style registers)
I spent ages fiddling with the code and debug prints to find out why, no joy.......

AND THEN - 86dde - IT JUMPS BY ZERO! - A DUMMY JUMP !!! WTF ?? !!!

I can only guess that the above is probably a 'switch/case' like construct in the (true) source code, and so the compiler sets up a jump table for it, and 86dde is a 'fall through' or something like that, and it didn't get removed by the 'redundant code check' which most compilers have. It doesn't seem like an afterthought patch, but I guess it could be. So need an extra check for this....

I know there was a debate in 'C' coding as to whether 'switch+case' was faster or slower than a list of 'if-then', and that compilers often set up a 'jump table' (just like a pointer list in EEC-IV) for it, so I wonder....

Oh, and it does exactly the same for the Word and Byte lookups .....

So posted this as it's possibly even weirder than the redundant timing/delay opcodes....

So I've got A9L to work as a static analysis (as before) but with controlled emulation passes in subroutines for the embedded arguments, at the moment just gets bare bytes, but it gets the right number ! 22CA was the next candidate as it uses the [STACK+x] method to get arguments, with PSW pushes in there to get the correct bank(s), which is what I'm doing now....

So making some progress -

JSA - I'll possibly use CARD next, as I know it has 'if () then get 4 or 6 args' type code. That's probably the next challenge to sort out.

[edited for typos and made description better]

[jsa]

:crazy:

[motorhead1991]

I think I've seen this in m0m2 actually... Didn't think much of it, since that one is so underdeveloped.

[tvrfan]

Wouldn't be surprised if it's in a lot of binaries - if it's a compiler thing (which it could well be) then probably a whole family have it.

Sort of interesting on a different level - A9L does appear to have been 'hacked' afterwards (IMHO), with jumps inserted and odd bits which are never called, and ops like R0=popw which shortcuts the ret instruction.

That 22CA though looks quite neat (so far) otherwise.

automatic variable arguments - Did I say I'd got A9L working ? discovered that dreaded bit of code around 728x doesn't work right (It's got jumps to subr and shortcut return tricks) along with 22CA changes... DAMN.... I already had to come up with a trick to detect the pushflags....Oh well, more thinking required....

[cgrey8]

Just out of curiosity, does disassembling this stuff get easier as the processors get newer?

Expand the thought beyond EEC-V into modern processors. Does Ford still hand-author assembly in these things or have they embraced C/C++ which would make disassembling them, presumably, easier and more predictable since C/C++ has standard calling conventions and optimization techniques are fairly well known for each instruction set.

Or am I just dreaming?

[tvrfan]

Good question, I'm honestly not sure..

As far as I know.....

Higher level languages ('C' and upwards to things like Java) have some pretty good compilers, and they tend to have optimisation options for each main processor family. They already have a lot of 'code shortcut' optimisation tricks built in first (platform independent, based on logic of the code itself), and then a further pass/set for the actual target hardware (aka linker phase). Many 'base' libraries also have different versions for different CPUs too.

So I'm NOT convinced it's any easier, but yes, a commonly used family will have known optimizations, which might help somewhat.

Apparently, from what I have read, compilers for CPUs like multicore x86 architecture produce actual code in ways that help the CPU itself do its 'predictive branching' tricks to speed things up even further. I understand this is from the way jumps are interleaved/laid out in the final code.

From what I see of EEC-IV and V (and this is just my opinion) the earlier ones look more hand built, and the later ones look more regular, like a compiler output. But even then, where you get time delays/hardware interfaces, the compiler won't know, so probably little bits of hand coded stuff in these too.

From career knowledge of small to mid-sized process control stuff - they are mostly high level code, but often with hand built (as low level code/assembler) interrupt handlers and final stage of drivers for memory mapped devices, timing, and so on. Some were done even on top of a real time OS, in the same way. EEC-IV and V are very much like this setup, with its 'peripherals' (= input/output, specialist chips, etc) having defined memory addresses and timing rules.

I certainly don't claim to be expert here, so that's my best answer.

[jsa]

I got some time to give 3.08 a run today, after months of work over commitment.

Mucking around with URAL, I have pasted MSG to DIR, added a few SYM's, RBASE and tweaked a word to code.

I believe I have identified the console subroutine. I am failing to get SAD3.08 to disassemble the subroutine as it insists on outputting word and vector detail.

I have commented out SAD3.08 default vect from msg and put in my own vect and code

Code: Select all

# vect    d57a d5a9
vect  d57a d585
code  d586 d5b1

SAD 3.08 - note the Sub375:

Code: Select all

d57a: 06,d0               vect  d006             Sub363
d57c: 06,c0               vect  c006             Sub333
d57e: 06,e0               vect  e006             Sub1
d580: 09,d0               vect  d009             Sub364
d582: 09,c0               vect  c009             Sub334
d584: 09,e0               vect  e009             Sub2
   Sub375:
d586: fa,a3               vect  a3fa             Sub288
d588: 01,00               word     1             Zero
d58a: 0d,14               word  140d
d58c: 99,2a               vect  2a99             Sub29
d58e: 15,d7               vect  d715             Sub384
d590: 3b,3c               vect  3c3b             Sub58
d592: 24,1e               word  1e24
d594: 38,0a               word   a38
d596: 1b,47               vect  471b             Sub116
d598: 01,0e               word   e01
d59a: 20,06               word   620
d59c: 82,d7               vect  d782             Sub385
d59e: 02,07               word   702
d5a0: 82,a0               vect  a082             Sub277
d5a2: 82,0e               word   e82
d5a4: b1,0f               word   fb1
d5a6: 0d,c9               vect  c90d             Sub350
d5a8: b2,d5               vect  d5b2             Sub377

d5aa: ad,04,30            ldzbw R30,4            wR30 = 4;
d5ad: cb,31,7a,d5         push  [R30+d57a]       push([R30+d57a]);
d5b1: f0                  ret                    return; } }

SAD 3.07 with same DIR

Code: Select all

d57a: 06,d0               vect  d006             Sub363
d57c: 06,c0               vect  c006             Sub333
d57e: 06,e0               vect  e006             Sub1
d580: 09,d0               vect  d009             Sub364
d582: 09,c0               vect  c009             Sub334
d584: 09,e0               vect  e009             Sub2

   Sub375:
d586: fa                  di                     disable ints;
   Sub376:
d587: a3,01,00,0d,14      ldw   R14,[R0+d00]     R14 = [d00];
d58c: 99,2a,15            cmpb  R15,2a           
d58f: d7,3b               jne   d5cc             if (R15 != 2a) goto d5cc ;
d591: 3c,24,1e            jb    B4,R24,d5b2      if (B4_R24 = 0)  {
d594: 38,0a,1b            jb    B0,Ra,d5b2       if (HSO_OVF = 0)  {
d597: 47,01,0e,20,06,82   ad3w  R82,R6,[R0+200e] R82 = IO_Timer+CC_EXE_TIME;
d59d: d7,02               jne   d5a1             if (R82 = 0)  {
d59f: 07,82               incw  R82              R82++; }
d5a1: a0,82,0e            ldw   Re,R82           HSO_Time = R82;
d5a4: b1,0f,0d            ldb   Rd,f             HSO_Cmd = f;
d5a7: c9,b2,d5            push  d5b2             push(Sub377);
d5aa: ad,04,30            ldzbw R30,4            WR30 = 4;
d5ad: cb,31,7a,d5         push  [R30+d57a]       push([R30+d57a]);
d5b1: f0                  ret                    return; } }

bin and dir attached

[tvrfan]

<Sigh !!>

The vector list detect code is supposed to stop at anything which is detected (i.e. code or not vector data), so I've obviously managed to introduce a bug there, and/or the manual command doesn't work either, so I must have messed up the command merging also. I did change command bit due to a different bug. Thanks for spotting that, will add the bin to my local list.

Had to abandon and go back to a previous development version of SAD in my attempt to get variable arguments to work, very frustrated that I can't seem to get a robust solution. Some bins work, but some cause a loop, and can't get the mechanism right. Ah well, try again.

[jsa]

Speaking of arguments, the default output for the lookup subroutines is incorrect for URAL at least.

SAD by default is taking 2 bytes as the first argument, but really needs to take 2 words for the 2 arguments.

Looking at the AD_Cmd structure and associated subroutines it seems the SU naming of lookups is incorrect. In particular raw ACT & ECT volts to temperature conversion should be Unsigned Volts as the lookup input and Signed Temperature as the lookup output. So US subr name prefix rather than SU.

On my phone now, but will paste up another DIR with ADC SYM's when on PC.

[jsa]

DIR with ADC channels

[tvrfan]

Speaking of arguments, the default output for the lookup subroutines is incorrect for URAL at least.

SAD by default is taking 2 bytes as the first argument, but really needs to take 2 words for the 2 arguments.

Looking at the AD_Cmd structure and associated subroutines it seems the SU naming of lookups is incorrect. In particular raw ACT & ECT volts to temperature conversion should be Unsigned Volts as the lookup input and Signed Temperature as the lookup output. So US subr name prefix rather than SU.

On my phone now, but will paste up another DIR with ADC SYM's when on PC.

Yes ... Some bins have a flag set for signed, some have the flag set for unsigned, and some table lookups use the carry flag.
I would expect raw AD to be unsigned, so that does look suspicious.

I've realised as I go through 3.08 that there are several areas which I may have actually gone backwards, and I'm seeing this stuff as I examine
solutions for variable arguments. I spotted (yet another) error with conditional jumps, and a bank 0 problem in multibanks, and asking "why did I do THAT?"
.....Not Good......

[motorhead1991]

Sounds like I need to try 3.07 on my SD tunes... 3.08 works alright in the MAF bins

[jsa]

Tvrfan,
I seem to be only looking at suspicous bins, lol.

I have to agree, 3.08 has is a bit of a sidestep overall.

Well you must have been convinced at the time, we've all been there.

Motorhead1991,

3.07 and 3.08 give very similar results with the dir i use on card, but ural does not. Both are MAF bins.

Well worth a run through both and then compare the output.

Nether work particularly well on subroutines with certain argument arrangements. It all goes south when a variable number of arguments are involved or subroutines are nested and each level takes arguments.

Tvrfan is trying to overcome the challenge. I don't have any good suggestions for him.

That SD bin you sent me might be another good test case for TVRfan. Your only choice is too manually determine the arguments and change the dir accordingly.

When all else fails brute force it by stepping through argument qty one at a time until the output makes sense.

[jsa]

Another 3.07 vs 3.08.

In the attached zip;
KRAF5ZV.bin has ford WDS bank order.
LFQ1*.bin has come from some EEC with that bank order and is 256kb.
Both are LFQ1 catchcode and KRAFZV strategy, just obtained in a different manner.

1st run SAD3.07 handles LFQ1 better than the WDS version.

1st run SAD3.08 for both

Code: Select all

Cannot find a Start bank [bank 8]
abandoned !!