EFIDynoTuning Forum

I agree, the database engine is not the first issue. Several engines could easily do the job.

I had the idea that with Sqlite, there could be a file/database for each bin. Not really a true share as such, as users would have to download (upload?) file(s) and use it locally. Version control might become a big problem if uploads allowed.

A true online database is an idea too, but as you say, then the issue becomes how present the data in a way which is useful to all the apps, and make it a defined program interface for various app connections (and so on).

Don't know what best answer is !

NB> I didn't do transfer type work as you are, my career was more within a custom project and at the DB server end (so no web server experience).

tvrfan wrote: ↑2024 Dec 04, 20:38 - present the data in a way which is useful to all the apps
- make it a defined program interface for various app connections

This is what I do. Two perfect requirements. I can start with that.

wwhite wrote: ↑2024 Dec 04, 19:01 I've been thinking of having an online database for this subject.

The idea of an online database is good from the perspective of knowledge sharing. I had in mind hosting on GitHub beside the other stuff, but see that is less straight forward. The reason behind the GitHub idea, is that myriad privately hosted EEC resources have vanished from the web as people's circumstances change or forums crash or whatever. I see there is not much choice for free publicly hosted databases.

To me, the database engine(sqlite, postgresql, maridb, etc.) is a moot point.
sqlite is great for a non-shared database, can be accessed locally.

I don't know enough about the pro's and cons of each to make the best choice, so I don't have a preference, just exploring options.

Online database everyone could access.

I think the ability to have a functioning offline copy of the database will be needed by users.
Maybe a copy of it is held on GitHub beside the other stuff.

PostgreSQL would be overkill, sure it can handle XML, but also GEO data and as well as SOUNDS LIKE expressions for searching.

Soundex could be quite handy for importing less than perfect data sources, but is it going to work against PID/SYM names?
I'm thinking about the differences I see in TP XDF's from different authors.

It's super easy to me when the data is well defined in the spreadsheet.

BE definitions are well defined or at least consistent.
TP definitions seem loose enough that authors are putting the PID/SYM name in different places.
SAD DIR can be consistent fixed width fields, but the user could always process in excel if absolutely necessary.
SADX you get the choice of S6X (XML) or SQlite.
DMR files are CSV's.

It's a little tricky pulling abstractions out to create something meaning full for all the different tuning platforms and file types to be consistent across hardware strategies.

More than likely a lot of duplication at first, and then normalization later on, just regular database admin stuff.

Yes there are differences to take into account across EEC age and geographic region as well as strategies.
I think there might be some level of duplication that remains.

tvrfan wrote: ↑2024 Dec 04, 20:38 I had the idea that with Sqlite, there could be a file/database for each bin. Not really a true share as such, as users would have to download (upload?) file(s) and use it locally. Version control might become a big problem if uploads allowed.

Yes, there is SAD related data that is of no use to a definition and vice versa. SAD DIR entries to an extent are subset of definition entries.
User upload would seem necessary in order to grow the data set. Fields for the data source and user name would help with managing it.

BOOSTEDEVERYTHING wrote: ↑2024 Nov 15, 14:02 Here is an argument related question, I can not figure out how to define the args in this subroutine. Should they be byte, word then byte values? if so, how would I put that into my DIR file properly? thanks
Code: Select all
8ad5d: 10,09              rombk 9
8ad5f: ef,33,7e           call  92b95            Sxx92B95_RZA96CB3_36.6.4.1_SUBSTITUTE (
8ad62: 2e,00                    #arg 1              TEMP5L,
8ad64: 70,10                    #arg 2              1070,
8ad66: 01                       #arg 3              1,
8ad67: 08                       #arg 4              8,
8ad68: 0b                       #arg 5              b );
Here is how SAD grabbed them...
Code: Select all
args    8ad62 8ad68: UW N : UW N : O 2 UY : UY 

I agree with SAD, two words and 3 bytes.

You could update your Sub command in DIR to include options for the args.
You could use the options from the MSG args commands or the option I've chosen or do :O 3 Y for the last 3 bytes.

Code: Select all

SUB 92B95 "Sxx92B95_RZA96CB3_36.6.4.1_SUBSTITUTE" :UWN :UWN :Y :Y :Y     # SAME AS RZASA Sub_96CB3     #36.6.4.1  Substitute OUTPUT STATE CONTROL, SUBSTITUTE - CRAI8 36-276 {7}

I agree with SAD, two words and 3 bytes.

You could update your Sub command in DIR to include options for the args.
You could use the options from the MSG args commands or the option I've chosen or do :O 3 Y for the last 3 bytes.

Ok, I will do that. Thanks. I think I still do not get exactly what the arguments are doing. I think that is my issue. It uses a temp Reg, a value from R1070(undefined osc value) , but what are the final 3 bytes doing?

This may sound terrible too, but - are you comfortable with numbers/math ? Not everyone is, so forgive me if this is too basic.

I am horrible with math, I always have been. I think that is why I may be having some issues with some of this. I can recognize patterns very well. Just not sure what to do with them. LOL, There are a ton in Bank 1 of CRAI8 that I can see but have no idea what they are. So hopefully as I define more and more it will all come to light. I learn better by doing than by being told, so the way you guys have been presenting things to me has been great!!! I really appreciate all the help. I am a mechanic for Ford. The mechanical and electrical I get very well, I am doing this to make nice complete definition files for my vehicles but also to learn more in depth, how the vehicles actually do what they do and why.

BOOSTEDEVERYTHING wrote: ↑2024 Dec 06, 11:45 but what are the final 3 bytes doing?

Which temp registers are the 3 byte args loaded to?

jsa wrote: ↑2024 Dec 06, 16:00
BOOSTEDEVERYTHING wrote: ↑2024 Dec 06, 11:45 but what are the final 3 bytes doing?
Which temp registers are the 3 byte args loaded to?

the way I am looking at it is that everything is loaded to TEMP5L? So does that mean that the value for 1070 is loaded to TEMP5L and TEMP5H, and then the next two are loaded to TEMP6L and TEMP6H, and the next byte is loaded to TEMP7L? Or am I way off?

Also have a question about the SCPBITMAP registers....see one example below....
Should these be defined in the DIR file or are these temporarily loaded for the 5.3.1.1 Scp_pid_pid_defs subroutine only???

Code: Select all

scpbitmap_10 = pid_def(   chtil_cmd,            /* b0: cyl head temp (CHT) indicator */
                                                                                   /*      light is on(CHTIL_CMD) */
                                                             0,                    /* b1: CHT indicator light output fault */
                                                             swc,                  /* b2: speed warning chime is on */
                                                             swc_fault,            /* b3: speed warning chime output fault */
                                                             fpump_speed,          /* b4: hi speed desired for 2 speed fuel pump */
                                                             0,                    /* b5: Thermactor Air Bypass is supplying */
                                                                                   /*     secondary air (versus dumping it */
                                                                                   /*     overboard) for either upstream or */
                                                                                   /*     downstream of the forward HO2S(AM1) */
                                                             0,                    /* b6: Thermactor Air Diverter is */
                                                                                   /*     diverting secondary air to upstream */
                                                                                   /*     (versus downstream) of the forward  */
                                                                                   /*     HO2S(AM2)  */
                                                             0);                   /* b7: secondary spark plugs of Dual Plug */
                                                                                   /*     Ignition System are enabled (DPI_STATE)
   */
                                   scpbitmap_15 = pid_def(   tr1,                  /* b0: The TR1 digital input from the */

BOOSTEDEVERYTHING wrote: ↑2024 Dec 09, 10:33 the way I am looking at it is that everything is loaded to TEMP5L? So does that mean that the value for 1070 is loaded to TEMP5L and TEMP5H, and then the next two are loaded to TEMP6L and TEMP6H, and the next byte is loaded to TEMP7L? Or am I way off?

TEMP5L is the address value of Arg1, not the register that Arg1 is loaded into.

Hint, have a read about Call and Program Counter in the manuals.

Code: Select all

8ad5d: 10,09              rombk 9
8ad5f: ef,33,7e           call  92b95            Sxx92B95_RZA96CB3_36.6.4.1_SUBSTITUTE (

Post up the code where you think the args are loaded to registers.

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