SAD 806x Disassembler

[ranga83]

4tad is a 2 bank eecv. Unique australian bin. Dereks says the files are 88kb. However the files i have got from an IDS are 112kb.
The first bank holds the calibration id and ford copyright along with the ram addresses afaik. The 2nd bank has the code and parameters.

[Pym]

4tad is a 2 bank eecv. Unique australian bin. Dereks says the files are 88kb. However the files i have got from an IDS are 112kb.
The first bank holds the calibration id and ford copyright along with the ram addresses afaik. The 2nd bank has the code and parameters.

Thank you for the information.
What do you think about provided file, Bank 1 is missing or inserted inside Bank 8 ?

[ranga83]

If the provided file is 256kb. Then it has been filled. As the brand of j3 i use here in oz uses a full 256kb binary. The 4tad provided should be in 0,1,8,9 format.

[ranga83]

There is no information in bank 1 other than the copyright and calibration id. Located at 0x19f00 and bank 8 starts at 0x22000

[Pym]

There is no information in bank 1 other than the copyright and calibration id. Located at 0x19f00 and bank 8 starts at 0x22000

Ok I see it,
so we are talking about a 2 banks 8065 binary, with an "empty" Bank 1, Calibration elements in Bank 8 (pointers are accessed by default on Bank 1 on all 8065 binaries),
no rbnk instruction, even for checksum calculation and a code like late 8061. Yes this is an EEC IV 8065 pilot, relabeled EEC V.
I will manage Bank 8 like 8061 one and identify its Bank 1.
Please find attached an early 8065 binary, you will see the difference.

[jsa]

Interruption vectors tell it is a 8065, but if you look at code, it is clearly not, it is a late 8061.

I have not looked at enough 8065 to pick up on those nuances.

I will do something to manage it

Cool. Hopefully not too many other odd bins to cover.

[ranga83]

the 4tad is the first aussie eecv 104pin ecu. the next model car went back to the 60pin ecu but was still "eecv" .

[Pym]

the 4tad is the first aussie eecv 104pin ecu. the next model car went back to the 60pin ecu but was still "eecv" .

EEC V 60pin, never heard about, good to know, I will look at the related binary too.
None of them is OBD2 compliant ?

[ranga83]

No not obd2 compliant. The later au falcons ran a 104pin 4 bank eecv that have the obd2 plug but wasnt standard obd2 protocol so most scantools couldnt read them

[ranga83]

Gotta love the aussie engineering tho. Had to be different to everywhere else. The 4tad is an inline 6 4.0litre wasted spark coilpack, batch fire injection. The 6dbd is the same 4.0 but distributer. The au is basically the same setup as the 4tad but has a variable cam timing variant. All 3 have eec trans control

[sailorbob]

this is an EEC IV 8065 pilot, relabeled EEC V.

The 4TAD ecu is an eec-v, it is just not using the 8065 in memory expansion mode.

[Pym]

The 4TAD ecu is an eec-v, it is just not using the 8065 in memory expansion mode.

So let me call it Pilot, because it should not be often the case.

But I am really interested with EEC V with 60 pin J1. Could be a really good start for an upgrade.

[sailorbob]

Australia did not adopt EOBD until 2006 so Ford Australia did not implement the OBD-II related code when it first introduced the eec-v and hence it was not necessary to use the 8065 in memory expansion mode.

I do not think that an early description in the pocket reference guide should be carried over to replace how Ford decided to name the eec-v when it went into mass production. IMHO it is only going to confuse matters.

Any way, whilst interesting as it is, this is going a bit off topic so sorry for my contribution to that.

[Pym]

Version 1.2 is in progress, I still have things to add or review and do not want to generate N versions, so it will not be provided now.
But to summarize a bit, things that were asked ...

Can the text output file name be saved in the s6x file so that the text file is tied to a binary file.

=> No valid proposal for now, except managing an history of used files
Waiting ...

Free selection of a new S6x File

=> Activated on 1.2

Another minor feature request, the called/jumped from address next to or near the subroutine is handy in the output file.
I realise it could get messy when called/jumped from multiple places. Maybe a line/s directly below the SubName and before code line/s.

=> No valid proposal for now, except an Html output with Hyperlinks (but who will work on it ?)

[d00], [c80], d006, ... addresses

=> Managed on 1.2 for 8061, [d00], [c80] are "known" and have their own labels, [d00] fixed label was removed from 8065 management.
The others will receive a prefix, but can be translated through S6x Registers for 8061 only.
Call 1000(); is still not managed, I do not understand it.
=> Still to be done for 8065 on following code (it is on a 2 banks binary without Bank 0) when it will be understood (or named)
1 658d: f4 bank0
1 658e: c3,01,00,1f,00 stw [1f00],0 [1f00] = 0;

Ok, I see Calibration Init. It would be nice to see the R and its value in the tree somewhere.

=> Added on 1.2 on Comments of the Calibration Init routine, smart place I think

4TAD and other 8065 2 banks with fake Bank 1

=> Managed on 1.2

[jsa]

Can the text output file name be saved in the s6x file so that the text file is tied to a binary file.

=> No valid proposal for now, except managing an history of used files
Waiting ...

viewtopic.php?f=30&t=2582#p33291

Hmm, yes, the one strategy multiple binaries conundrum. I do not see how to save to a Strategy_Name_I_choose.s6x. Always seems to save to Name_of_Bin.s6x.

With a 1_Startegy_All_Bins.s6x, multiple text file entries could be the solution.
GHAJ0 > CARD > CARD_Some_Name.txt
GHAJ0 > ANTI > ANTI_Some_Name.txt

Not valid or missed?

Another minor feature request, the called/jumped from address next to or near the subroutine is handy in the output file.
I realise it could get messy when called/jumped from multiple places. Maybe a line/s directly below the SubName and before code line/s.

=> No valid proposal for now, except an Html output with Hyperlinks (but who will work on it ?)

Did you see this? Validity issues?
viewtopic.php?f=30&t=2582#p33316

HTML just adds a layer of unnecessary complexity.

All other items look good.

[sailorbob]

Calibration elements in Bank 8 (pointers are accessed by default on Bank 1 on all 8065 binaries)

The 8065 defaults to ROM bank 8 on power up and reset. Calibrations that have data in other banks use the Memory Bank Select Register at 0xn0011 to redirect the addressing and set this register as one of the first things done in the code.

[decipha]

i think hes referring to bank 1 not needing a banksel for loading data

[Pym]

The 8065 defaults to ROM bank 8 on power up and reset. Calibrations that have data in other banks use the Memory Bank Select Register at 0xn0011 to redirect the addressing and set this register as one of the first things done in the code.

i think hes referring to bank 1 not needing a banksel for loading data

Yes, I have always thought Bank 1 was defaulted for memory read at hardware level on 8065, never paid attention at "b1,11,11" operation. If it had been "b1,01,11", probably.

[Pym]

Not valid or missed?

Did you see this? Validity issues?
HTML just adds a layer of unnecessary complexity.

I am still searching for an easy way to manage text files and history,
without adding additional actions to quickly generate an output.
I keep your idea for now and will see how to manage it.

For Goto sources, I do not want to add too much information for now in text output.
As an example I have chosen to double operations when used with and without "fe" instruction and I am not really happy with the result.
Html is the best solution to display or hide information on demand,
but I see no one here, wanting to work on a disassembly outside a text editor,
at least this is the case for me.

[sailorbob]

never paid attention at "b1,11,11" operation. If it had been "b1,01,11", probably.

In register 0xn0011 the lower nibble determines the ROM bank to use for data reads (program flow is controlled by the ROMBNK instruction). I believe the upper nibble may indicate which RAM bank the stack is located in.

[Pym]

In register 0xn0011 the lower nibble determines the ROM bank to use for data reads (program flow is controlled by the ROMBNK instruction). I believe the upper nibble may indicate which RAM bank the stack is located in.

So by default, inherited from 8061, Memory Bank is Bank 8 until update of BANK_SEL register. Do I need to manage it or could you confirm that except dual banks with Empty bank 1, you have never seen any other bank used to read memory ?

[sailorbob]

There are no banks with the 8061 so the power up & reset default to ROM bank 8 on the 8065 is new rather than a carry over from the earlier MCU.

I am not sure what you mean by 'manage it' but I would assume that it is possible that all four ROM bank flags are used in the PSW depending on the PCM hardware and its coding. That said, I have only seen ROM banks 0, 1, 8 & 9 being used.

I have also seen values of 0,1 and 8 used for the upper nibble of 0xn0011 but I have no idea what bit 7 may be being used for so I am not sure how that fits with my idea of the upper nibble indicating which RAM bank the stack is located in

[jsa]

Html is the best solution to display or hide information on demand,
but I see no one here, wanting to work on a disassembly outside a text editor,
at least this is the case for me.

Yes hyperlinks would be nice to jump around the code and also html to expand/contract sections. Could open a big can of worms with that sort of functionality.
Makes copy and paste to forums and other such things messy.

I find it tedious searching for the froms, and wish for an equivalent of the goto in the output. I end up adding some froms as comments, so I am used to the extra text.

I think those here will take whatever they are given that works better than previous options.

[jsa]

Call 1000(); is still not managed, I do not understand it.

I only have a best guesstimate, and I am open to a better explanation.

Code: Select all

bcc1: a3,01,00,0d,14    ldw   R14,[d00]      R14 = CC_PRESENT;              # Called from L2085
bcc6: 99,2a,15          cmpb  R15,2a                                        # [RD00]=0x2A=Engineering Console Present
bcc9: d7,3b             jne   bd06           if (R15 != 2a) goto bd06;      # Console Not Present goto LBCEC
bccb: 3c,24,1e          jb    B4,R24,bcec    if (B4_R24) goto bcec;         # Bit4 of R24 Set 1 at L2082. L2085 Calls LBCC1
bcce: 38,0a,1b          jb    B0,Ra,bcec     if (B0_IO_STATUS) goto bcec;   # HSO PORT CAM or OUTPUT HOLD BUFFER FULL goto LBCEC
bcd1: 47,01,0e,20,06,7c ad3w  R7c,R6,[200e]  R7c = IO_TIMER + CC_EXE_TIME;
bcd7: d7,02             jne   bcdb           if (IO_TIMER == CC_EXE_TIME)  {
bcd9: 07,7c             incw  R7c            R7c++; }
bcdb: a0,7c,0e          ldw   Re,R7c         HSO_TIME = R7c;
bcde: b1,0f,0d          ldb   Rd,f           HSO_CMD = f;
bce1: c9,ec,bc          push  bcec           push(bcec);                    # Push 0xBCEC on to stack
bce4: ad,04,30          ldzbw R30,4          R30 = (uns)4;                  # Load Word R30 with Byte 0x04
bce7: cb,31,b4,bc       push  [R30+bcb4]     push([R30+bcb4]);              # Push on to stack BCB4+4=BCB8=E006
bceb: f0                ret                  return;                        # Return to L2088 otherwise LE006 for Engineering Console present

bcec: a3,01,80,0c,14    ldw   R14,[c80]      R14 = [c80];                   # Jump from LBCC9 if console not present or Jump from LBCCB if B4 R24 Set 1
bcf1: ad,04,30          ldzbw R30,4          R30 = (uns)4;                  # Load Word R30 with Byte 0x04
bcf4: a3,31,a8,bc,42    ldw   R42,[R30+bca8] R42 = [R30+bca8];              # R42=4+BCA8=BCAC=1000
bcf9: c6,42,00          stb   0,[R42]        [R42] = 0;                     # Store 0x00 into address 1000
bcfc: 36,14,07          jnb   B6,R14,bd06    if (!B6_R14) goto bd06;        # B6 of [c80] clear 0 so goto LBD06
                                                                            # Default [c80] at startup likely to be 0x00
bcff: a3,31,ae,bc,14    ldw   R14,[R30+bcae] R14 = [R30+bcae];              # B6 of [c80] Set 1 so R14=1200
bd04: 20,04             sjmp  bd0a           goto bd0a;

bd06: a1,22,20,14       ldw   R14,2022       R14 = 2022                   ; # From LBCFC. R14=2022=C000
bd0a: 3c,24,01          jb    B4,R24,bd0e    if (B4_R24) goto bd0e;         # B4 R24 Set 1 at L2082. L2085 Calls LBCC1
bd0d: fb                ei                   enable ints;                   # B4 R24 Clear 0 so enable interupts
bd0e: a1,f0,00,18       ldw   R18,f0         R18 = f0;                      # Jump from BD0A
bd12: b3,01,20,20,1a    ldb   R1a,[2020]     R1a = [2020];
bd17: a2,15,1c          ldw   R1c,[R14++]    R1c = [R14++];
bd1a: c2,19,1c          stw   R1c,[R18++]    [R18++] = R1c;
bd1d: e0,1a,f7          djnz  R1a,bd17       R1a--;
                                             if (R1a !=  0) goto bd17;
bd20: 3c,24,34          jb    B4,R24,bd57    if (B4_R24) goto bd57;         # B4 R24 Set 1 at L2082. L2085 Calls LBCC1
bd23: a3,01,00,0d,14    ldw   R14,[d00]      R14 = CC_PRESENT;              # Check for console again
bd28: 99,3b,15          cmpb  R15,3b                                        # Checked against 0x2a at LBCC6 now against 0x3b ??????
bd2b: d7,03             jne   bd30           if (R15 != 3b) goto bd30;      # Console not "3b"
bd2d: ef,d0,52          call  1000           1000();                        # Console is "3b". At LBCF9 1000()=0x00.
                                                                            #  What has console done with 1000() or
                                                                            #  what does Call do with 0X0000


Maybe I should log 0x1000 and see if it is 0x00 normally.

[sailorbob]

In GHAJ0, the parameter at address 0x0D00 is called 'console_status' and the routine at address 0xBCC0 is called 'console_call'. Address 0x1000 is the 'lansdale_tester_entry' which I'm guessing is another development device or test device (there's reference to it in the LHBH1 strategy document).

[motorhead1991]

Tried this yesterday, and so far, I'm impressed. The tree view is really handy, and being able to sync with SAD is awesome too.

Another neat feature would be to be able to export a SAD dir, so the two stay in sync as coexisting programs.

[jsa]

Address 0x1000 is the 'lansdale_tester_entry' which I'm guessing is another development device or test device (there's reference to it in the LHBH1 strategy document).

Thanks Sailorbob.

Another neat feature would be to be able to export a SAD dir, so the two stay in sync as coexisting programs.

I agree, in the short term, or at least until SAD806x is good enough to make SAD redundant or a directive is not needed with any bin.

[jsa]

I have a couple more feature requests;

Hex to Binary value output option for the listing file

Code: Select all

4321: 57                byte                                                # Bin  1010111


Or take it 1 step further, HSO for example

Code: Select all

4321: 57                byte                                                # O/P Hi, No Int, Ch7


Default name for elements with the location address as the suffix rather than sequential numbers. Sub2000 rather than Sub0001.

[Pym]

I have a couple more feature requests;

Hex to Binary value output option for the listing file

Code: Select all

4321: 57                byte                                                # Bin  1010111


Or take it 1 step further, HSO for example

Code: Select all

4321: 57                byte                                                # O/P Hi, No Int, Ch7


Default name for elements with the location address as the suffix rather than sequential numbers. Sub2000 rather than Sub0001.

As you have already noticed, I have not managed bit flags at all, I did not want to reproduce TunerPro principle and separate them from scalars.
But yes it has to be done like an option on scalars, with dedicated labels bit by bit. Like this, TunerPro Import/Export Bit Flags could be managed and SAD Directive Bit Flags too.
I keep it in my to do list.

[jsa]

Ok. Have a look at the EEC reference for HSO_CMD, as it is a little different to bit flags.

[jsa]

Hello Pym,

Looks like SAD806x has not handled L4960, what do you make of
%P2%!=%P1% ?

This is GHAJ0 Code.

Code: Select all


8 4959: 71,fd,e7             an2b  Re7,fd             Re7 &= fd;           
8 495c: 21,86                sjmp  4ae4               goto Sub0114;       

Sub0100:
8 495e: 28,24                scall 4984               Sub0101();           
8 4960: d7,03                jne   4965               if (%P2% != %P1%) goto 4965;



[decipha]

any chance of an update to this?

I can post my rzasa disassembly and current rzasa xdf. If you could use that as a master template it should have every PID just about mapped out. I even included parameters in my rzasa xdf at the bottom that arent part of rzasa but are used in older strategies to make it easier.

I even have a ~ on parameters in rzasa that change equation in older strats too. I use rzasa as my master template for every def I make so I always keep RZASA as complete as possible as a master database of all ford PIDs. It just makes it easier for me so I dont have to keep track of everything.

also any chance of you doing code matching in the disassembly? using rzasa as a base 95% of the code is identical between most 4 bank eec-v's, it would save me thousands of hours going through each one. If the disassembler could match the code and apply the pid names based on the known names in the rzasa disassembly it would make it completely automated.

Also another big thing, if it exports the PIDs in the xdf file in order by memory address, that would save a bunch of time and confusion not to mention make it better organized and easier to fix problems.

How do you handle parameters that are nested in code vs base+offset look ups?

[motorhead1991]

any chance of an update to this?

I can post my rzasa disassembly and current rzasa xdf. If you could use that as a master template it should have every PID just about mapped out. I even included parameters in my rzasa xdf at the bottom that arent part of rzasa but are used in older strategies to make it easier.

I even have a ~ on parameters in rzasa that change equation in older strats too. I use rzasa as my master template for every def I make so I always keep RZASA as complete as possible as a master database of all ford PIDs. It just makes it easier for me so I dont have to keep track of everything.

also any chance of you doing code matching in the disassembly? using rzasa as a base 95% of the code is identical between most 4 bank eec-v's, it would save me thousands of hours going through each one. If the disassembler could match the code and apply the pid names based on the known names in the rzasa disassembly it would make it completely automated.

Also another big thing, if it exports the PIDs in the xdf file in order by memory address, that would save a bunch of time and confusion not to mention make it better organized and easier to fix problems.

How do you handle parameters that are nested in code vs base+offset look ups?

If this happens, I'll put PAAD6 (FLH2) through it for my own uses.

I'd hate to undercut CoreTuning and their fantastic support, but there are limits to what a BE database can do...

[decipha]

if it becomes automated it could crunch out every eec-v strategy in a matter of minutes

[motorhead1991]

This doesn't look like normal output for a disassembled table (or any table for that matter), any hints? It looks like this with a directive added as well.

EDIT:
Nevermind, figured it out

[motorhead1991]

Ran PAAD6 through 806x and it did a fine job of identifying things. Now I need to come up with the labels for everything.

[Pym]

Seriously, notification through emails works whenever it wants, sorry for being late in my answers.

I am almost ready to provide next version 1.2, correcting many issues, but certainly creating new ones.
The main evolution is the management of signatures, requiring to put in place advanced routines (Signatures will generated routines and routine could initiate signatures, blabla).
Many other asked things were added, but not everything, some principles were rebuilt from 0, but it has not being tested at 100% yet, I will say pair versions are king of beta version, more stable in their next impair version.
I have still in my to to list a huge thing, Structure auto detection, but no time or will to work on it, it will wait.
In my to do list too, another thing that can be updated quickly to deliver this version, VID block real addresses and sizes for EECV (for example I have written "PATS code at bad address or too short").
If you want to discuss on it, here or by PM, it will keep me much time on analysis.

[Pym]

No answer at all about VID Block, I have not searched more. Nothing new since one month.
Anyway, please find attached last version 1.2.
Main changes are following ones :
- Automatic CC/EC/KAM translations on 8061
- 8065 Pilot (single Bank) management added
- BitFlags management added
- Automatic numbering modified as option
- Unidentified elements are now identified as single byte structures
- Advanced routine and signatures added
- SAD Dir export functionality added (really basic one)
- Many, many other things

You may experience issue to open previous version saved S6x files, so try creating a new one for now.
I will tell you later on what need to be modified on previous S6x files to make them compatible.

Do not pay attention to version number on or inside tool, this is the right version.

[jsa]

Thank you Pym.

[decipha]

the vid block is pretty useless for disaasembly, what info do u need about the vid block?