EFIDynoTuning Forum

I wouldn't expect the same function to be signed in one strategy and unsigned in another, but never say never.
I don't know why you have commanded unsigned functions as signed.
Looking at suwFn46F_N it is clearly signed input.
Looking at the maximum input values, the rules are;

Code: Select all

ff,7f   Word size signed input.
7f      Byte size signed input.

ff,ff   Word size unsigned input
ff      Byte size unsigned input

SIGNDX, SIGNDY, SIGNDSLP being set to 1 also indicates signed lookup.

There are some subroutines that don't appear in any strategy document or manual either. The manuals describe how the hardware works, not the purpose of subroutines. The strategy documents stick to describing the processes relevant to implementation of the tune. The strategy documents don't get into common subroutines like startup, lookup, rolav, console and more. Out of the thousands of strategies, there are four publicly posted on github, who knows what is covered in documents for all the other strategies. It is also common to find subroutines for one strategy in a document for another strategy bin.

This is from NGVB5R6, which is an aussie multi bank bin from around 2000, yet it is a match for GUFB single bank from around 1989. So it might be necessary to check the other docs at times.

Code: Select all

###### STARTUP_DELAY LOGIC FOR FIXED IDLE INJECTOR TIMING GUFB 6-94

     # Call  from L88637                                                           
     # Call  from L8994A TMP1L = 0x12B00                                           
     # Call  from L89DFB                                                           
     # Call  from L8BAE8                                                           
     # Call  from L8CAAD                                                           
   Sbg870B7_Idl_Inj_Tmg_Dly:
870b7: b3,66,bb,48        ldb   R48,[R66+bb]     TMP9L = TCSTRT;                   # [63B] TCSTRT
870bb: 9b,f4,02,48        cmpb  R48,[Rf4+2]      
870bf: de,0b              jlt   870cc            if (TMP9L >= CTHIGH)  {           # [1283A] 
870c1: b3,66,de,48        ldb   R48,[R66+de]     TMP9L = ATMR1;                    # [65E] ATMR1
870c5: 9a,38,48           cmpb  R48,[R38]                                          # [12B00] 
870c8: d3,3e              jnc   87108            if (TMP9L < [TMP1L]) goto 87108;
870ca: 20,3a              sjmp  87106            goto 87106; }


     # JLT   from L870BF TCSTRT <                                                  
870cc: 07,38              incw  R38              TMP1L++;                          # 0x12B01
870ce: b3,66,bb,48        ldb   R48,[R66+bb]     TMP9L = TCSTRT;                   # [63B] TCSTRT
870d2: 9b,f4,03,48        cmpb  R48,[Rf4+3]      
870d6: da,16              jle   870ee            if (TMP9L > CTLOW)  {             # [1283B]
870d8: b3,66,de,48        ldb   R48,[R66+de]     TMP9L = ATMR1;                    # [65E] ATMR1
870dc: 9a,38,48           cmpb  R48,[R38]                                          # [12B01] 
870df: d3,27              jnc   87108            if (TMP9L < [TMP1L]) goto 87108;
870e1: 07,38              incw  R38              TMP1L++;                          # 0x12B02
870e3: b3,66,df,48        ldb   R48,[R66+df]     TMP9L = ATMR2;                    # [65F] ATMR2
870e7: 9a,38,48           cmpb  R48,[R38]        
870ea: d3,1c              jnc   87108            if (TMP9L < [TMP1L]) goto 87108;  # [12B02]  
870ec: 20,18              sjmp  87106            goto 87106; }


     # JLE   from L870D6  < TCSTRT <                                               
870ee: 07,38              incw  R38              TMP1L++;                          # 0x12B02
870f0: 07,38              incw  R38              TMP1L++;                          # 0x12B03
870f2: b3,66,de,48        ldb   R48,[R66+de]     TMP9L = ATMR1;                    # [65E] ATMR1
870f6: 9a,38,48           cmpb  R48,[R38]                                          # [12B03] 
870f9: d3,0d              jnc   87108            if (TMP9L >= [TMP1L])  {
870fb: 07,38              incw  R38              TMP1L++;                          # 0x12B04
870fd: b3,66,df,48        ldb   R48,[R66+df]     TMP9L = ATMR2;                    # [65F] ATMR2
87101: 9a,38,48           cmpb  R48,[R38]                                          # [12B04] 
87104: d3,02              jnc   87108            if (TMP9L >= [TMP1L])  {

     # SJump from L870CA TCSTRT >=  & ATMR1 >=                                     
     # SJump from L870EC   & ATMR1 >=  & ATMR2 >=                                  
87106: f8                 clc                    CY = 0;
87107: f0                 ret                    return; } } } } }


     # JNC   from L870C8 TCSTRT >=  & ATMR1 <                                      
     # JNC   from L870DF TCSTRT <  & ATMR1 <                                       
     # JNC   from L870EA  & ATMR1 >=  & ATMR2 <                                    
     # JNC   from L870F9 <TCSTRT< & ATMR1 <                                        
     # JNC   from L87104 <TCSTRT< & ATMR1 >=  & ATMR2 <                            
87108: f9                 stc                    CY = 1;
87109: f0                 ret                    return;

So for some subroutines it is necessary to look at what it is doing and name it accordingly. That is what I've done with RZASA. It's loading the calibration pointers and looking for a calibration console. I've deduced the cal console part from the manuals, looking at GUFB console sub and what ever else I could find on the web.
You might find this helpful;
https://github.com/OpenEEC-Project/Usef ... t_1988.pdf

aice_fg_mwr might have come from something Decipha has done previously, I'm not sure at the moment. Searching for AICE in the various document may help identify more. I would not be surprised that aice_fg_mwr is not specifically covered as a subroutine in any particular strategy. AICE handing will be common across a metric shitload of strategies, so including it in all of them would be a big waste. There may well be some document that covers the subs that are common across great swathes of hardware, I'm not aware of it's public availability.

I wouldn't expect the same function to be signed in one strategy and unsigned in another, but never say never.
I don't know why you have commanded unsigned functions as signed.

Ok, that makes sense. I was just transferring them over from RZASA assuming they should be the same, that is my mistake. I will try and go through and correct what I can find as I am trying to identify more. I figured if a function was signed or unsigned in one strategy that it would carry over to another. I will start paying better attention to that as I move things over. I have actually stopped using the RZASA dir file recently, and started using the Strategy doc for CRAI8 only to compare and identify subroutines. It is a bit easier to figure out exactly what is going on that way, I think....LOL!

So, I am a bit clearer on the function naming, if it is signed in and signed out it would start with ss? and unsigned in and signed out would be us? etc?
and the ones with word in and word out would continue with a single w (sswfn=signed word in signed word out) ? is that correct so far? I want to make sure that what I am doing is somewhat universal so anyone could pick it up and know what's going on. I am actually now thinking of putting some sort ok key at the beginning of the function, table and subroutine sections. I have also been putting the ranges next to variables I am identifing but noticed that some have odd round about ways of identifying what units they are in, some say seconds but then it has a resolution that makes it milliseconds. Here is an example below of what I am talking about....

Code: Select all

            RAM TIMER bg_tmr;
                          /* Background loop timer. 
                          Resolution: 0.000977                 Units: SECOND      Init. Value: 0.000000
                          Timer Type: FREE RUN                 Direction: UP
                          Clip Min.: 0.000000                  Clip Max.: 63.999001*/
            RAM TIMER clock_sec;
                          /* Dacable clock in seconds with a 60 second rollover period. 
                          Resolution: 0.000977                 Units: MS          Init. Value: 0.000000
                          Timer Type: FREE RUN                 Direction: UP
                          Clip Min.: 0.000000                  Clip Max.: 63.999001*/

the RAM_TIMER_bg_timer for example says the units are seconds, but the resolution is the same as the RAM_TIMER_clock_sec and it states MS units are used, but they have the same resolution and upper and lower clips. Should I assume then that both are in MS intervals? I may also make some sort of key for this as well, just to clarify everything.
I am hoping to make this a very complete DIR and CMT file for CRAI8 and AOL1. I do not really see any out there that are absolutely complete, and that may not be needed for tuning purposes, but will hopefully help people like me that are trying to learn the processes. To make it as comparable to the Strategy Docs as possible, to make it easy to follow along.
The way you have defined the timers is a good example,

Code: Select all

SYM  1528 "EAM_ANTP_TMR"            #[UW]                #mSec          #Word Timer [1C] {1}
SYM  152A "IAC_EAM_TMR"             #[UW]                #mSec          #Word Timer [1C] {1}
SYM  152C "FN_GEN_TMR"              #[UW]                #mSec          #Word Timer [1C] {1}
SYM  152E "OL_TMR"                  #[UW]                #mSec          #Word Timer [1C] {1}
SYM  1530 "SCP_TMR"                 #[UW]                #mSec          #Word Timer [1C] {1}
SYM  1532 "IAC_MON_TMR"             #[UW]                #mSec          #Word Timer [1C] {1}
SYM  1534 "PUTMR"                   #[UW]                #mSec          #Word Timer [1C] {1}
SYM  1536 "TSLPIP"                  #[UW]                #mSec          #Word Timer [1C] {1}
SYM  1538 "TM_TCS_RES"              #[UW]                #mSec          #Word Timer [1C] {1}
SYM  153A "TM_STRT_SFT"             #[UW]                #mSec          #Word Timer [1C] {1}
SYM  153C "NDS_TMR"                 #[UW]                #mSec          #Word Timer [1C] {1}
SYM  153E "ACPERIOD_TMR"            #[UW]                #mSec          #Word Timer [1C] {1}
SYM  1540 "TRAC_TMRSCP"             #[UW]                #mSec          #Word Timer [1C] {1}

I get the label, that these are unsigned word values, in millisecond intervals, and the {1} is who identified it in the dissaembly. What I do not understand is the [1C], So I want to be as clear on everything as possible in the dir file so that anyone could look at it and know exactly what all the labels mean. I have also started adding the clip values and starting values to the dir file as I identify timers, i will have to go back through and get the ones I haven't added to this point later. I have been doing the same with the flags and all other items I have been finding in the Docs. Hopefully this will help? Not sure if it is of any help at all for putting it in the tuning software later to identify upper and lower boundaries and what the value is to start with.

I don't know why you have commanded unsigned functions as signed.
Looking at suwFn46F_N it is clearly signed input.
Looking at the maximum input values, the rules are;

Maybe this is where I am confused...
suwFn- Is this not signed word input, unsigned word output? Maybe I am just confused a bit...

Code: Select all

SYM 17114 "suwFn46S_T"                                                  # {7}
FUN 17114 1712F :SW :UW #[SW=flo(x*1)] [UW=flo(x*1)]                    #TOT> {7}

Defined as above....

Code: Select all

   ROM fox_type FN46S_T;
                          /* Engagement EPC at finish of engagement ramp for a forward to reverse engagement; function of TOT,
                           ps 
                          Resolution: 0.500000                 Units: PSI         Base Value: 
                          Min. Value: 0.000000                 Max. Value: 127.500000 Cal. Level: RCON
                          XY Pairs: 7               X Input: TOT        X Input Units: DEGREES*/

unsigned output as seen above....

Code: Select all

            RAM F32 tot;
                          /* Transmission oil temperature, deg F. 
                          Resolution: 0.125000                 Units: DEGF        Init. Value: 60.000000
                          Min. Value: -4096.000000             Max. Value: 4095.875000 Reg. Type: RAM */

Signed input as seen above....

Code: Select all

   suwFn46S_T:
17114: ff,ff,00,00        func      -1,     0
17118: 00,00,00,00        func       0,     0
1711c: 00,00,00,00        func       0,     0
17120: 00,00,00,00        func       0,     0
17124: 00,00,00,00        func       0,     0
17128: 00,00,00,00        func       0,     0
1712c: 00,00,00,00        func       0,     0

Is the first column not input and second output?
This is everything I need to identify everything about what the function uses, correct?

Also am a bit confused on the subroutine below....Why is it **WFn?

Code: Select all

SLU948A9_92C62_**WFn

Thank you again for all the help!!!!!!! And patience during this learning process. I honestly cannot thank you enough!!!!!!

Yes you have the SS, SU, US and UU right.
Yes W for word and Y for byte, for now at least, not sure if SADV5 will bring a change.
Yes Fn is a function and Tb is a table.

A key or glossary is a good idea. That said the naming convention tends to follow SAD's letters where appropriate.

TVRfan and I have talked about some sort of database that holds parameter names along with associated units, scaling and other stuff that needs to go into a directive. The data would be common to many strategies. The idea being to take the symbol name then lookup the database for all the parameters that are relevant. It gets cumbersome to hold it all in DIR, however I'm interested to see what you come up with if you have a go at it.

This is from RZASA DMR. Binpoint ties in with your CRAI8 bg_tmr example. 2^16 / 2^10 = 64. 1 / 2^10 = 0.0009765625.
So you see the documents are NOT 100% error free. They are binary milliseconds.
You should assume nothing is correct, and go from there, you won't be disappointment or caught out.

Code: Select all

Parameter  Strategy  Address	Kind  #Bytes/Flag-bit  U/S/F  Binpoint
BG_TMR     RZASA     x0075A	RAM    2                 U    10
CLOCK_SEC  RZASA     x0075C	RAM    2                 U    10

[1C] Can't be too important, LOL, I don't recall at the moment and cant find why I did that. I suspect it has something to do with the decode groups in the timer structure. Yes more information always helps.

The Data at 17114 is clearly unsigned input. It is 1st column unsigned word input / 2nd column unsigned word output.
"Fn46S_T" is loaded into the lookup address reg R36 at L9253B.

Code: Select all

9249a: 45,e2,13,fc,28     ad3w  R28,Rfc,13e2     TEMP2L = suwFn46S_T;
9249f: a3,fd,bc,10,2c     ldw   R2c,[Rfc+10bc]   TEMP4L = TMDRVREV;
924a4: 20,5a              sjmp  92500            goto 92500; }

9253b: a0,28,36           ldw   R36,R28          TMP2L = TEMP2L;
9253e: a3,e4,90,38        ldw   R38,[Re4+90]     TMP3L = NEBART;
92542: ef,64,23           call  948a9            SLU948A9_92C62_**WFn ();

** in the context of these lookups are wildcards. Have a look at my DIR comments next to the sub command. Have a look in RZASA at L92C16, I have comments that explain exactly how bits set prior to call, determine un/sign. You have the cmt file enabled in RZASA right! They can be signed or unsigned.

You have the cmt file enabled in RZASA right!

Yes, but as of late, I have been using just the strategy doc for CRAI8 to identify the subroutines and labels, so I have not been comparing as much to RZASA. Apparently, I need to add another monitor and have all of them pulled up at the same time and try to compare...LOL. Perhaps, I am still a bit confused as to how to identify a signed and unsigned variable. Maybe I will dive into that a bit more and see if anything more sinks in. A database would be great, If I knew how to build one. Perhaps you could start one so I can start putting things into it that I find? Like you said, It is making the DIR file a bit untidy.

Code: Select all

suwFn46S_T;

So, this function shows in the docs that it uses signed input, but in the code it only uses the signed portion of the input range? or the document is just plain wrong? Or it can use either depending on how it is compiled into the strategy? Sorry if that is a bit run on... just trying to understand.

I also have another question about functions...
Here is the function from CRAI8 Doc..

Code: Select all

fox_type FN312S;
                          /* Change in the transient fuel puddle mass ber change in aircharge. 
                          Resolution: 0.000244                 Base Value:        Units: UNITLESS
                          Min. Value: 0.000000                 Max. Value: 15.999000 Cal. Level: RCON/VECTR 
                          XY Pairs: 10              X Input: ECT        X Input Units: DEGF*/

Here is the Doc definition from CRAI8...

Code: Select all

RAM S32 ect;
                          /* Engine coolant temperature, deg F. 
                          Resolution: 2.000000                 Units: Degrees     Init. Value: 60.000000
                          Min. Value:-256.000000               Max. Value: 254.000000 Reg. Type: RAM*/

Here is the start of my entry in the DIR file>>>>

Code: Select all

SYM 1315C "suwFn312S"                                                   #Change in the transient fuel puddle mass ber change in aircharge. {7}
FUN 1315C 13183 :SW :UW #[SW=flo(x*1)] [UW=flo(x*1)]                    #X Input:ECT Units:DEGF Units: UNITLESS 0-15.999 Resolution: 0.000244 XY Pairs: 10 {7}

Here it is in the LST file..

Code: Select all

858dc: 02,2c              cplw  R2c              TEMP4L = ~TEMP4L;
858de: 0f,46,24           norm  R24,R46          TMP0L = normalize(TEMP0L);
858e1: 4c,26,2c,24        ml3w  R24,R2c,R26      TEMP0L = TEMP4L * TEMP1L;
858e5: 0c,46,24           shrdw R24,R46          TEMP0L >>= TMP0L;
858e8: fa                 di                     interrupts OFF;
858e9: a0,a1,2a           ldw   R2a,R1a0         TEMP3L = CYL_AIR_CHG;
858ec: c0,c3,2a           stw   R2a,R1c2         TFC_CHG_?? = TEMP3L;
858ef: c0,bb,24           stw   R24,R1ba         AISFU_?? = TEMP0L;
858f2: c0,bd,26           stw   R26,R1bc         AISFM_?? = TEMP1L;
858f5: fb                 ei                     interrupts ON;
858f6: a3,f5,fe,09,34     ldw   R34,[Rf4+9fe]    TMP1L = S.0x13110;
858fb: 6c,26,34           ml2w  R34,R26          TMP1L *= TEMP1L;
858fe: 0f,46,34           norm  R34,R46          TMP0L = normalize(TMP1L);
85901: a0,a5,38           ldw   R38,R1a4         TMP3L = AHISL_TICK;
85904: b1,07,3d           ldb   R3d,7            TMP5H = 7;
85907: 29,ae              scall 85ab7            Sxx85AB7_RZA92FA3_NORMALIZING_ROUTINE_?? ();
85909: c3,d6,fc,34        stw   R34,[Rd6+fc]     [1047c] = TMP1L;
8590d: bc,77,2a           ldsbw R2a,R77          TEMP3L = ECT;
85910: a1,5c,31,36        ldw   R36,315c         TMP2L = suwFn312S;
85914: a0,2a,38           ldw   R38,R2a          TMP3L = TEMP3L;
85917: 10,09              rombk 9
85919: ef,51,ee           call  9476d            SLU9476D_92B26_SUWFn ();
8591c: 6c,3c,28           ml2w  R28,R3c          TEMP2L *= TMP5L;
8591f: c0,cb,2a           stw   R2a,R1ca         R1ca = TEMP3L;
85922: a1,bc,31,36        ldw   R36,31bc         TMP2L = uuwFn313TD;
85926: a0,1d,38           ldw   R38,R11c         TMP3L = N_J1979_01_0C;
85929: 10,09              rombk 9
8592b: ef,f3,ee           call  94821            SLU94821_92BDA_UUWFn ();
8592e: a0,3c,2a           ldw   R2a,R3c          TEMP3L = TMP5L;
85931: 45,0a,0c,f4,2e     ad3w  R2e,Rf4,c0a      TEMP5L = ?yTb1322DL;
85936: 45,6a,0b,f4,3c     ad3w  R3c,Rf4,b6a      TMP5L = ?yTb1323D;

My question is... When figuring out the math, how do I determine what formula to use exactly? Math is definitely not my strong suit at all...Sorry.

We are well aware of the screen real estate issue. I typically have 3 text editing windows open side by side for various combo's of LST, DIR and CMT... still need more space but not sure I can fit an 8k TV screen on my desk LOL. This is a prime reason why adding all information into DIR becomes cumbersome, too much screen real estate becomes necessary. Really need to keep dir and lst down to core information.

You've made me aware that you probably had comments disabled so they did not print in the rzasa lst for any time you were looking at rzasa alone. So loading up lst, dir and cmt with more info...will the newb actually take any notice of it??

I'd suggest it would be a good idea to transfer the information to the startegy you are working on, then you won't need as many files open.

Database...
1. Which database type/style/format do you know how to read and write data to and from?
2. Which database type/style/format should we use?
3. Should the database be free / open source?
4. Should the database be editable by a simple text editor?
5. Should the database be editable/accessible from Excel?
6. Should the database be editable/accessible from SAD?
7. Should the database just be an Excel spreadsheet?
8. Should the database just be XML?
9. Should the database be a fully fledged relational type?
10. If relational, should it include native xml/(xdf) support?
11. If relational, should the database have tools for browsing, reading, writing and exporting data by a novice?
12. If relational, should the tools be free / open source?
13. Which operating systems should the database work on?
14. If relational, which operating system should the tools run on?
15. If relational, should the tools support fixed with fonts?

BOOSTEDEVERYTHING wrote: ↑2024 Nov 13, 08:11

Code: Select all

   ROM fox_type FN46S_T;
                          /* Engagement EPC at finish of engagement ramp for a forward to reverse engagement; function of TOT,
                           ps 
                          Resolution: 0.500000                 Units: PSI         Base Value: 
                          Min. Value: 0.000000                 Max. Value: 127.500000 Cal. Level: RCON
                          XY Pairs: 7               X Input: TOT        X Input Units: DEGREES*/

unsigned output as seen above....

Code: Select all

            RAM F32 tot;
                          /* Transmission oil temperature, deg F. 
                          Resolution: 0.125000                 Units: DEGF        Init. Value: 60.000000
                          Min. Value: -4096.000000             Max. Value: 4095.875000 Reg. Type: RAM */

BOOSTEDEVERYTHING wrote: ↑2024 Nov 14, 08:33
Code: Select all
suwFn46S_T;
So, this function shows in the docs that it uses signed input, but in the code it only uses the signed portion of the input range? or the document is just plain wrong? Or it can use either depending on how it is compiled into the strategy? Sorry if that is a bit run on... just trying to understand.

jsa wrote: ↑2024 Nov 14, 04:18 The Data at 17114 is clearly unsigned input. It is 1st column unsigned word input / 2nd column unsigned word output.
"Fn46S_T" is loaded into the lookup address reg R36 at L9253B.
Code: Select all
9249a: 45,e2,13,fc,28     ad3w  R28,Rfc,13e2     TEMP2L = suwFn46S_T;
9249f: a3,fd,bc,10,2c     ldw   R2c,[Rfc+10bc]   TEMP4L = TMDRVREV;
924a4: 20,5a              sjmp  92500            goto 92500; }

9253b: a0,28,36           ldw   R36,R28          TMP2L = TEMP2L;
9253e: a3,e4,90,38        ldw   R38,[Re4+90]     TMP3L = NEBART;
92542: ef,64,23           call  948a9            SLU948A9_92C62_**WFn ();

That code snip is disassembly from your CRAI8 dir posted above.
Fn46S_T has not come from my RZASA and I have not spotted a sub the same either.
Is it really TOT??
What about NEBART??
Have you followed the code sequence??
Is it really Fn46S_T??

Searching for NEBART in strategy docs finds;
LHBH1 17-20 & 17-25
CRAI8 33-19, 33-20, 33-21 & 33-25

Math...
Well how pedantic do you want to be?
How well do you understand accuracy VS resolution?

A 16 bit word can represent 2^16 = 65536 values starting from zero.
That divides up into 65536-1 = 65535 increments.
An 8 bit byte can represent 2^8 = 256 values starting from zero.
That divides up into 256-1 = 255 increments.

Your ECT example says;
Resolution: 2
Min value: -256
Max value: 254
255 x 2 = 510ºF range
256 + 254 = 510ºF range
So
2^8 x 2 - 2 = 510
2^bitsize x resolution - resolution

Your FN312S example above;
Resolution: 0.000244
Min Value: 0.000000
Max Value: 15.999000
65535 x 0.000244 = 15.99054
2^16 x 0.000244 - 0.000244 = 15.99054
15.99 / 65535 = 0.00024399176
2^16 / 2^12 = 16 so Binary Point 12
16 / 65535 = 0.00024414435
16 / 65536 = 0.00024414063

[SY=flo(x*2)] will work for ECT, at least on a calculator.
[UW=flo(x*0.000244)] will work for the output.
[UW=flo(x/4096)] which is /2^12, is close.
[UW=flo(x/4098)] which is 1/0.000244 rounded, is close too.

So you can see that your example output resolution and max value have been rounded in some way, so not 100% accurate but 12 bits of decimal resolution.

Obviously the information is WRONG in some way, functions don't have byte in, word out, but that is how the math works for the example you have given.

There are manufacturing tolerances and install environment impacts that reduce accuracy of real world values. You will see definitions with more complex math but it doesn't gain much in real world accuracy. In reality you get resolution but not accuracy to the level of resolution. One bit or more error is likely for ECT.
I'm inclined to keep the math in DIR, and by extension in definition, as straight forward as possible. If you want real accuracy get a NATA traceable instrument and calibrate your ECU/installation, but then what is the uncertainty of the NATA traceable instrument...and so it goes.

Honestly, the functions could very well be completely wrong. It is very possible that it could be NEBART. I will dive deeper into that before going any further with my disassembly. I may have taken a wrong turn somewhere while trying to identify them. Thank you for pointing that out. I am very new and am open to any and all pointers or criticisms you may have for me. I do not take things to heart, so fire away.

Recently I have not been comparing LST files to each other. I have only been comparing my LST file for CRAI8 to the CRAI8 strategy document. Do you suggest I go back to also comparing the RZASA LST file as well? I was thinking I would get as much doe as possible with the Strategy Doc and then go back to comparing the LST files again, to add to the RZASA DIR and CMT files after I get further identifying the subroutines in CRAI8.

As far as the comment files go, when I was starting out, comparing it apples to apples was easier, now that I can understand it a bit more the CMT files have been a huge help. I agree with a streamlined approach to all of the files as well. I am adding data to the DIR file because I really honestly, just do not know any better...LOL!

Database: All of what you asked is way over my head for sure. I can edit and add to a spreadsheet, but have absolutely no experience with database files. I would leave all of that up to you, if you are willing. I would love to be able to add to the database and contribute in any way I possibly can. I did not know disassembly at all when I started and I feel like I can at least understand a bit of it now, so hopefully, I can pick up the database stuff as well.

WOW!!! Most of the math is definitely over my head for sure. Super precise accuracy is really not necessary. I just want to be able to add the formulas to a definition file when the disassembly is complete.

How well do you understand accuracy VS resolution?

Not well apparently, I assume resolution would be the more important of the two in a definition file?

I'd suggest it would be a good idea to transfer the information to the startegy you are working on, then you won't need as many files open

I am sorry, I do not know what you mean by this. Where would I put the info? Is that not why we are discussing a database? Sorry if I may be over thinking this a bit.

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