EFIDynoTuning Forum

Couple of notes for the current discussions.

SAD produces all its output in plain text. It's bad enough getting it to decode correctly before even considering fancy formats!! (Maybe in the future...)

PIVOT TABLES ?? My other half thinks they are a total waste of time, and reckons everything you can do in a pivot table can be done with more straightforward (and easier?) cell logic formulae like IF-THEN-ELSE and collection filters and sometimes adding a 'type' column to filter with. She has a strong background in finance, so I believe her (I have never done much in excel myself, so I'm just passing this on...).

If the bin allows for 12 injectors, then it's highly likely there will be other 'sets of 12' numbers and values (lists and structures) elsewhere, also for ignition timing and knock etc. so something to look out for.

Pointers - If structures start at cyl 1 (i.e. no 'zeroth' entry) it's faster to give a 'false' start address of (real start- cell size) than to subtract one from cyl number, so you may see a pointer which points to well before the data structure (so that data_start + 1 cell) is actually the true start. Does that make sense to you ?? I have a couple of A9L examples I can show you.

Ok. I misunderstood how it would reference the injector table I guess. So I guess I would just add a sym name for Injector #1 of tb1327a for the 12Fa3 address? Or something else? What would be the best way to define that?

A9L pointer example - oh damn, looking at it, it's a bit more complex than I want to show.
here is a cut down example -

data is

Code: Select all

3da0: fa,02          word   2fa          ## 4 cyl value
3da2: fc,01          word   1fc          ## 6 cyl value
3da4: 7d,01          word   17d          ## 8 cyl value

so you have a look up preset of 'Num_cyls' set somewhere in ROM, value 4,6 or 8

Fastest way to get this data is to 'cheat' by using pointer = 0x3d9c, which is 0x3da0 - 4.
So load num_cyls into R30 and do THIS

Code: Select all


3df7: af,fe,07,30         ldzbw R30,[Rfe+7]      wR30 = Num_cyls;                  # from ROM preset
3dfb: a3,31,9c,3d,36      ldw   R36,[R30+3d9c]   R36 = [R30+3d9c];                 # correct value for number of cyls

So code has used a pointer of 3d9c to get to that data structure at 3da0 ..... so I hope you can see the 'trick' in there.

Yeah, not looking to re-invent SAD's output files, or its input files for that matter either. There will be cases where a database/template or whatever is not workable so SAD input and output files need to remain.

The Ford docs call Fn1327A a table.
In a definition it could be defined as either a series of scalars or a table.
How many users who can't be bothered reading the Ford docs will mess up by incorrectly editing the table starting at 0x12FA2??
Do you want cylinders 9 to 13 visible in your definition??
Could a user decide to use the strategy on a V10 or V12 engine??

I'm inclined to leave the table defined as per the strategy doc, starting at 0x12FA2, Tb1327A.
Add SYM's for each injector and see how it looks.
SYM 12FA3 "Tb1327A_1" etc or however you see fit.

I'm inclined to leave the table defined as per the strategy doc, starting at 0x12FA2, Tb1327A.

This makes sense. I was just trying to make it show up in the LST file correctly. I’ll look through and see if I can find references to any of the other positions in the table. It would be nice to have it defined as completely as possible. I know it isn’t absolutely necessary for building a definition file but it would be nice to see a completely disassembled Bin file in SAD for reference purposes. Maybe to have all of the calibration parameters that ford had when they made the file? Maybe for use for development purposes or something? Who knows. LOL. I am trying to learn and be helpful at the same time. LOL. I definitely want everything defined exactly the same as in the CRAI8 docs. Easily searchable for reference and easy to understand. Even for a novice like myself.

So code has used a pointer of 3d9c to get to that data structure at 3da0 ..... so I hope you can see the 'trick' in there.

Sorry…I do not see it. How did you determine that you needed to add 4 to the pointer to get to the structure? Sorry if that’s a stupid question. Just trying to determine how I could find the same info in crai8 or any other file for that matter.

Yeah, not looking to re-invent SAD's output files, or its input files for that matter either. There will be cases where a database/template or whatever is not workable so SAD input and output files need to remain.

I definitely don’t want to do that at all. Just looking for ways to standardize everything so it’s data is easier to use on many different platforms. I guess so everything is called the same thing in most software.

wwhite wrote: ↑2024 Dec 11, 14:57 I think all your TEMP#L variables are confusing, at least to me. R3c maybe a temp, but I missed the increment reading your code.
I'd remove all the TEMP#L.

TEMP & TMP names have come from DMR files. I 'think' the E indicates foreground or background so it does add something useful.
I agree it takes some getting used to after years for R##.
The ++ is an issue for non temporary names as well. I think I've mentioned to TVRfan previously that appending the ++ for incremented SYM names is desirable.

This code snippet is easier to read, to me, and you can see that R3c = Rf4 + 0x891 = 0x2712 + 0x891 = 0x2fa3, Bank 1.
That is correct. It is not so correct that the WORD is addressed as an odd number.

Yeah, there is what the books say and then there is what happens in code. It could be the processor design changed somewhat from what the documents stipulate.
I'm currently of the view that word even boundaries apply to uP Registers but all bets are off for RAM and ROM.
GHAJ0 has ROM/DCL/DUCE on the M-Bus, and DUCE requires odd word access over the M-Bus, so odd words have been in the wild since the early '90's.

This is immediate address mode, you'll see myriad examples like that.
The immediate value 891 just happens to be on an even boundary, but it's not always the case.

Code: Select all

97883: 45,91,08,f4,3c     ad3w  R3c,Rf4,891      R3c = 12fa3;

This on the other hand is reading a byte from address 0x12FA3 then padding it up with zero's to a word

Code: Select all

9789a: ae,3d,36           ldzbw R36,[R3c++]      wR36 = [R3c++];

Code: Select all

   S.0x1957C:
1957c: 05,fa              vect  8fa05            Sub_8fa05

Can this be a word and a Vector? It is referenced as a word in the LST file several times. Here is one example.

Code: Select all

   # SJump from L087F0                                                           Sxx087D9
     # SJump from L087F4                                                           Sxx087D9
087f8: b3,d6,0c,34        ldb   R34,[Rd6+c]      TMP1L = TR_LIM_TRAC;
087fc: 99,80,34           cmpb  R34,80           
087ff: db,22              jc    08823            if (TMP1L < 80)  {
08801: a1,00,00,38        ldw   R38,0            TMP3L = 0;
08805: a1,7c,95,34        ldw   R34,957c         TMP1L = S.0x1957C;
08809: c3,d2,7a,34        stw   R34,[Rd2+7a]     BGS_ASYNC_PTR_2_RASTER_ASYNC_TASK? = TMP1L;
0880d: f2                 pushp                  push(PSW);
0880e: fa                 di                     interrupts OFF;

     # JB    loop from L0880F HSO_BUFF_FULL = 1                                    Sxx087D9
0880f: 3f,0a,fd           jb    B7,Ra,0880f      if (HSO_BUFF_FULL = 1) goto 0880f;
08812: 11,1f              clrb  R1f              CAM_SLOT_SELECT = 0;

Or is it telling it to go to the subroutine referenced by the vector?

It is a vector, which is a word.
There are many different interpretations.
I say it is a vector list of subroutines, where the vector points to the location of the subroutine.
So, in your example, the location is loaded into R34(TMP1L), the stored in BGS_ASYNC_PTR_2_RASTER_ASYNC_TASK.

Probably a call/jump at some point that goes to BGS_ASYNC_PTR_2_RASTER_ASYNC_TASK.

EFIDynoTuning Forum

EEC V file conversion

Re: EEC V file conversion

Re: EEC V file conversion

Re: EEC V file conversion

Re: EEC V file conversion

Re: EEC V file conversion

Re: EEC V file conversion

Re: EEC V file conversion

Re: EEC V file conversion

Re: EEC V file conversion

Re: EEC V file conversion