Search found 437 matches

by jsa
2024 Dec 10, 15:55
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 691
Views: 393450

Re: EEC V file conversion

Assuming your flag naming is correct I've made changes to CMT and DIR as follows.

CMT; insert in sequence with existing comments.

Code: Select all

0629C \n\n###### Do \s100E
062A1 # [ 100E]
062A4 \n\n###### Do \s1146
062AD # [ 1146]
062B0 \n\n###### Do \s101D
062DD # [ 101D]
062E0 \n\n###### Do \s101E
0631B # [ 101E]
0631E \n\n###### Do \s10ED
0633F # [ 10ED]
06345 # [ 10ED]
0634C # [ 10ED]
0634F   \n###### Do \s12FF
0635C # [ 12FF]
0635F \n\n###### Do \s10ED
06373 # [ 10ED]
0637A # [ 10ED]
06380 # [ 10ED]
06387 # [ 10ED]
0638F   \n###### Do \s2FC
0639F # [  2FC]
063A5 # [  2FC]
063A8   \n###### Do \s17C2
063D7 # [ 17C2] 
063DB \n\n###### Do \s17C3
063E8 # [ 17C3]
063EC \n\n###### Do \s1021
06413 # [ 1021]
06416 \n\n###### Do \s1022
06429 # [ 1022]
0642C \n\n###### Do \s1023
06462 # [ 1023]
06465 \n\n###### Do \s1024
06480 # [ 1024]
06483 \n\n###### Do \s17B8
0649E # [ 17B8]
064A2 \n\n###### Do \s17B9
064F5 # [ 17B9]
064F9 \n\n###### Do \s17BA
0651A # [ 17BA]
0651E \n\n###### Do \s17BB
06539 # [ 17BB]
0653D \n\n###### Do \s17BC
06568 # [ 17BC]
0656C \n\n###### Do \s14FE
06583 # [ 14FE]
06586 \n\n###### Do \s101F
0659B # [ 101F]
0659E \n\n###### Do \s1114
065AC # [ 1114]
065AF \n\n###### Do \s17BD
065E2 # [ 17BD]
065E6 \n\n###### Do \s17BE
0661D # [ 17BE]
06621 \n\n###### Do \s17BF
0664C # [ 17BF]
06650 \n\n###### Do \s17C0
06663 # [ 17C0]
06667 \n\n###### Do \s17C1
0667C # [ 17C1]
0668E # [ 178A]
06693 # [ 178B]
066A0 # [ 178C]
066B0 # [ 10F0]
066BF # [ 10EE]
DIR; insert in sequence with existing commands

Code: Select all

#      70                                                               #L065CA {0}
SYM    70 "HEDF_STATUS"             :B2                                 #L0662A CRAI8 5-256 (0)
SYM    70 "IMRC_FAULT"              :B3                                 #L06646 CRAI8 5-256 (0)
SYM    71 "TCC_FAULT"               :B5                                 #L06676 CRAI8 5-257 (0)
SYM    72 "CANP_FAULT"              :B4                                 #L0663A  CRAI8 5-256 (0)
SYM    75 "EVR_SHORT"               :B4                                 #CRAI8 5-255 {0}
SYM    75 "EVR_OPEN"                :B5                                 #CRAI8 5-255 {0}
SYM    80 "HEGO_FDBACK"             :B1                                 #closed loop CRAI8 5-253 {0}
SYM    80 "OL_DRIVE"                :B2                                 #open loop due to driving conditions  CRAI8 5-253 {0}
SYM    80 "HEGO_FAULT"              :B4                                 #closed loop with HEGO fault CRAI8 5-253 {0}
SYM    96 "ACSW"                    :B3                                 #A/C clutch Demand Switch {0}
SYM    A6 "SCP_UP"                  :B5                                 # {0}
SYM    C6 "FP_2SPD_ERROR?"          :B1                                 # L06613 CRAI8 5-255 {0}
SYM  101F "bitmap_mon_1"            #[UY]                               #Bitmap flage CRAI8 5-255 {0}
SYM  1021 "scpbitmap_1"             #[UY]                               #Bitmap flags CRAI8 5-252 {0}
SYM  1022 "scpbitmap_2"             #[UY]                               #Bitmap flags CRAI8 5-252 {0}
SYM  1023 "scpbitmap_3"             #[UY]                               #Bitmap flags CRAI8 5-252 {0}
SYM  1024 "scpbitmap_4"             #[UY]                               #Bitmap flags CRAI8 5-252 {0}
#    1114                                                               # L065AC {0}
SYM  1146 "J1979_01_1E"             #[UY]                               #Flags Bitmap CRAI8 5-250 {0}
SYM  14FE "pid_316dd_d"             #[UY]                               #Bitmap flags CRAI8 5-254 {0}
SYM  17B8 "scpbitmap_5"             #[UY]                               #Bitmap Flags CRAI8 5-253 {0}
SYM  17B9 "scpbitmap_6"             #[UY]                               #Bitmap Flags CRAI8 5-253 {0}
SYM  17BA "scpbitmap_7"             #[UY]                               #Bitmap Flags CRAI8 5-253 {0}
SYM  17BB "scpbitmap_10"            #[UY]                               #Bitmap Flags CRAI8 5-254 {0}
#    17BC                                                               # L06568 {0}
#    17BD                                                               # L065B0 {0}
SYM  17BE "bitmap_ofd_2"            #[UY]                               #Bitmap flags CRAI8 5-255 {0}
SYM  17BF "bitmap_ofd_3"            #[UY]                               #Bitmap flags CRAI8 5-256 {0}
#    17C0                                                               # L06663 {0}
SYM  17C1 "bitmap_ofd_5"            #[UY]                               #Bitmap flags CRAI8 5-257 {0}
SYM  17C2 "bitmap_fmem3"            #[UY]                               #Bitmap Flags CRAI8 5-251 {0}
SYM 17764 "PGM_SELECT"              #[UY]                #Sw            # L06630 Canister Purge hardware present CRAI8 5-256 {0}
SYM 9FF00 "IDBLOCK"                 #                    #              #256Byte EEPROM ID block CRAI8 5-238 {0}
SYM 9FF13 "IDBLOCK_FMT"             #[UY]                #              #CRAI8 5-238 {0}
BYT 9FF13 9FF13                                                          # {0}
by jsa
2024 Dec 10, 15:17
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 691
Views: 393450

Re: EEC V file conversion

BOOSTEDEVERYTHING wrote: 2024 Dec 10, 09:10 Here is scpbitmap_10

Code: Select all

     # JNB   from L06514 HEGO_FAULT = 0                                            Sxx0629C_RZAxxxxx_5.3.1.1_SCP_PID_PID_DEFS_
0651a: c7,01,ba,17,46     stb   R46,[R0+17ba]    SCPBITMAP_10 = TMP0L;
0651f: 11,46              clrb  R46              TMP0L = 0;
06521: 32,69,03           jnb   B2,R69,06527     if (CHTIL_CMD = 1)  {
06524: 91,01,46           orb   R46,1            B0_TMP0L = 1; }

     # JNB   from L06521 CHTIL_CMD = 0                                             Sxx0629C_RZAxxxxx_5.3.1.1_SCP_PID_PID_DEFS_
06527: 33,6c,03           jnb   B3,R6c,0652d     if (SWC = 1)  {
0652a: 91,04,46           orb   R46,4            B2_TMP0L = 1; }

     # JNB   from L06527 SWC = 0                                                   Sxx0629C_RZAxxxxx_5.3.1.1_SCP_PID_PID_DEFS_
0652d: 33,72,03           jnb   B3,R72,06533     if (SWC_FAULT = 1)  {
06530: 91,08,46           orb   R46,8            B3_TMP0L = 1; }

     # JNB   from L0652D SWC_FAULT = 0                                             Sxx0629C_RZAxxxxx_5.3.1.1_SCP_PID_PID_DEFS_
06533: 34,9f,03           jnb   B4,R9f,06539     if (FPUMP_SPEED = 1)  {
06536: 91,10,46           orb   R46,10           B4_TMP0L = 1; }

     # JNB   from L06533 FPUMP_SPEED = 0                                           Sxx0629C_RZAxxxxx_5.3.1.1_SCP_PID_PID_DEFS_
That is 'cart before the horse'.

I see you have revised ACL to be CHTIL_CMD, which now matches the flag list from CRAI8 for scpbitmap10, does it match up elsewhere in code?

On L0651A the contents of R46 are stored to 0x17BA.
On L0651F the contents of R46 are cleared to zero.
On L06524 onward various flags are tested and if set 1 then a bit in R46 is set 1.
The segment of code is transferring flag states from source locations to destination locations.
The destination can't be before the source. Assuming your source bit names are correct, then the destination must be 0x17BB.

Code: Select all


###### Do scpbitmap_10
0651f: 11,46              clrb  R46              TMP0L = 0;
06521: 32,69,03           jnb   B2,R69,06527     if (CHITL_CMD = 1)  {
06524: 91,01,46           orb   R46,1            B0_TMP0L = 1; }

     # JNB   from L06521 CHITL_CMD = 0                                             Sxx0629C_RZAxxxxx_5.3.1.1_SCP_PID_PID_DEFS_
06527: 33,6c,03           jnb   B3,R6c,0652d     if (SWC = 1)  {
0652a: 91,04,46           orb   R46,4            B2_TMP0L = 1; }

     # JNB   from L06527 SWC = 0                                                   Sxx0629C_RZAxxxxx_5.3.1.1_SCP_PID_PID_DEFS_
0652d: 33,72,03           jnb   B3,R72,06533     if (VSOUT_FAULT = 1)  {
06530: 91,08,46           orb   R46,8            B3_TMP0L = 1; }

     # JNB   from L0652D VSOUT_FAULT = 0                                           Sxx0629C_RZAxxxxx_5.3.1.1_SCP_PID_PID_DEFS_
06533: 34,9f,03           jnb   B4,R9f,06539     if (FPUMP_SPEED = 1)  {
06536: 91,10,46           orb   R46,10           B4_TMP0L = 1; }

     # JNB   from L06533 FPUMP_SPEED = 0                                           Sxx0629C_RZAxxxxx_5.3.1.1_SCP_PID_PID_DEFS_
06539: c7,01,bb,17,46     stb   R46,[R0+17bb]    scpbitmap_10 = TMP0L;             # [ 17BB]
by jsa
2024 Dec 10, 13:45
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 691
Views: 393450

Re: EEC V file conversion

BOOSTEDEVERYTHING wrote: 2024 Dec 10, 12:53 Is there a way to make the font on certain items stick out more, bold, underline, larger font, anything like that?
Some Programming language file editors can be configured to show certain things in different colours. They would need some sort of config file built to suit the LST pseudo code.
by jsa
2024 Dec 09, 15:29
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 691
Views: 393450

Re: EEC V file conversion

BOOSTEDEVERYTHING wrote: 2024 Dec 09, 10:37 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???
Paste up the code where the SCP bits are loaded into RAM.
by jsa
2024 Dec 09, 14:57
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 691
Views: 393450

Re: EEC V file conversion

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.
by jsa
2024 Dec 06, 16:00
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 691
Views: 393450

Re: EEC V file conversion

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?
by jsa
2024 Dec 06, 02:34
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 691
Views: 393450

Re: EEC V file conversion

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}
by jsa
2024 Dec 05, 18:14
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 691
Views: 393450

Re: EEC V file conversion

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.
by jsa
2024 Dec 03, 18:13
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 691
Views: 393450

Re: EEC V file conversion

In general it depends on if they are part of a subroutine or there is a whole subroutine for each .#

If part of a sub make it a comment. If a whole sub is doing each .# then rename the sub.
by jsa
2024 Dec 03, 17:00
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 691
Views: 393450

Re: EEC V file conversion

BOOSTEDEVERYTHING wrote: 2024 Dec 03, 08:20 To clarify subroutine naming, Is the below the actual subroutine?

Code: Select all

37.1.6  HIGH DATA RATE MISFIRE DETECTION (CRAI0)
Or is it this?

Code: Select all

 37.1.6.1  Hdr_misfire_foreground_main
If it is the first one, The second is the code segment that should be called out in the cmt file, correct?
To clarify, the above, I would suspect, Go to Sxx98DA2 in CRAI8.
37.1.6 speaks to calculations done by AICE, which is a peripheral chip external to the 8065 so you wont see the code for AICE calculations in LST.

AICE may/not have code, it could be hard wired silicon, anyone know?

This part of Sub98DA2 looks like 37.1.6.1

Code: Select all

98dac: b0,cd,48           ldb   R48,Rcd          FGTMP0L = SYNC_CTR_0;
98daf: 7b,01,78,0e,48     sb2b  R48,[R0+e78]     FGTMP0L -= HDR_AICE_DLY;
These two 37.1.6.1 lines are possibly segments as I don't see calls.

Code: Select all

                                           hdr_accels_from_aice();
                                           hdr_normalize_accels();
A lot of parameters used in 98DA2 need to be identified to confirm it is 37.1.6.1.