Disassembly question
Disassembly question
I think I got these comments from jcsbanks, but if tephra or John or anyone that knows disassembly can comment the rest of this subroutine, that would be great. I'm particularly interested in that part of the code with the FFFF8AC4 variable.
I *think* this is the variable for MUT28 for my ROM, 96940011. The reason why I am interested in what is going on here is because I remember Bez stating that a clipped version of mass airflow can be logged via MUT28. I'm wondering if this subroutine (the part that isn't commented) shows a way to log an unclipped value for this??
Sorry for my lack of disassembly knowledge. I'm hoping one of you guys will have this commented already or could at least tell me what's going on with the rest.
Thanks,
Eric
I *think* this is the variable for MUT28 for my ROM, 96940011. The reason why I am interested in what is going on here is because I remember Bez stating that a clipped version of mass airflow can be logged via MUT28. I'm wondering if this subroutine (the part that isn't commented) shows a way to log an unclipped value for this??
Sorry for my lack of disassembly knowledge. I'm hoping one of you guys will have this commented already or could at least tell me what's going on with the rest.
Code:
ROM:00015014 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ROM:00015014 ROM:00015014 ROM:00015014 sub_15014: ; CODE XREF: sub_149EC+Cp ROM:00015014 sts.l pr, @-r15 ROM:00015016 mov.l r14, @-r15 ROM:00015018 mov r15, r14 ROM:0001501A mov.l r1, @-r15 ROM:0001501C mov.l @(h'C0,pc), r4 ; [000150E0] = unk_5B6E ; axis ROM:0001501E mov.l @(h'C4,pc), r10 ; [000150E4] = sub_CC6 ; read table ROM:00015020 jsr @r10 ; sub_CC6 ROM:00015022 nop ROM:00015024 mov.l @(h'C0,pc), r4 ; [000150E8] = unk_2A00 ; maf scaling ROM:00015026 mov.l @(h'1B0,pc), r10 ; [000151D8] = sub_C28 ROM:00015028 jsr @r10 ; sub_C28 ROM:0001502A nop ROM:0001502C mov.l @(h'BC,pc), r10 ; [000150EC] = loc_1112 ; offset ROM:0001502E mov.w @r10, r10 ROM:00015030 add r10, r0 ; add contents of offset to maf scaling ROM:00015032 mov.l @(h'BC,pc), r11 ; [000150F0] = h'FFFF8AC6 ROM:00015034 mov.w r0, @r11 ; store in ram ROM:00015036 mov.l @(h'BC,pc), r4 ; [000150F4] = unk_2A1C ; maf smoothing ROM:00015038 mov.l @(h'19C,pc), r10 ; [000151D8] = sub_C28 ROM:0001503A jsr @r10 ; sub_C28 ROM:0001503C nop ROM:0001503E extu.w r0, r4 ROM:00015040 mov.l @(h'B4,pc), r10 ; [000150F8] = sub_24674 ROM:00015042 jsr @r10 ; sub_24674 ; with standard values this does nothing except put the result back in r0... ROM:00015044 nop ROM:00015046 mov.l @(h'B4,pc), r11 ; [000150FC] = h'FFFF8ACA ROM:00015048 mov.w r0, @r11 ROM:0001504A mov.l @(h'B4,pc), r1 ; [00015100] = h'FFFF8918 ROM:0001504C mov.w @r1, r1 ROM:0001504E extu.w r1, r1 ROM:00015050 mov.l @(h'B0,pc), r4 ; [00015104] = unk_2A38 ; air temp comp ROM:00015052 mov.l @(h'184,pc), r10 ; [000151D8] = sub_C28 ROM:00015054 jsr @r10 ; sub_C28 ROM:00015056 nop ROM:00015058 mov.w @(h'7E,pc), r10 ; [000150DA] = h'CD ROM:0001505A mulu r0, r10 ; air temp multiply by h'CD ROM:0001505C sts macl, r4 ; store result in r4 ROM:0001505E mov r1, r5 ROM:00015060 mov.l @(h'A4,pc), r10 ; [00015108] = sub_9B0 ROM:00015062 jsr @r10 ; sub_9B0 ; division ROM:00015064 nop ROM:00015066 mov.l @(h'A4,pc), r11 ; [0001510C] = h'FFFF887A ROM:00015068 mov.w r0, @r11 ROM:0001506A mov.l @(h'A4,pc), r4 ; [00015110] = unk_5BA2 ; baro axis ROM:0001506C mov.l @(h'74,pc), r10 ; [000150E4] = sub_CC6 ROM:0001506E jsr @r10 ; sub_CC6 ROM:00015070 nop ROM:00015072 mov.l @(h'A0,pc), r4 ; [00015114] = unk_5B5C ; baro axis ROM:00015074 mov.l @(h'6C,pc), r10 ; [000150E4] = sub_CC6 ROM:00015076 jsr @r10 ; sub_CC6 ROM:00015078 nop ROM:0001507A mov.l @(h'9C,pc), r4 ; [00015118] = unk_2A46 ; baro table ROM:0001507C mov.l @(h'158,pc), r10 ; [000151D8] = sub_C28 ROM:0001507E jsr @r10 ; sub_C28 ROM:00015080 nop ROM:00015082 mov.l @(h'98,pc), r11 ; [0001511C] = h'FFFF8AC8 ROM:00015084 mov.w r0, @r11 ROM:00015086 mov.l @(h'94,pc), r10 ; [0001511C] = h'FFFF8AC8 ROM:00015088 mov.w @r10, r10 ROM:0001508A extu.w r10, r10 ROM:0001508C mov.l @(h'6C,pc), r11 ; [000150FC] = h'FFFF8ACA ROM:0001508E mov.w @r11, r11 ROM:00015090 extu.w r11, r11 ROM:00015092 mulu r10, r11 ROM:00015094 sts macl, r12 ROM:00015096 mov.l @(h'58,pc), r4 ; [000150F0] = h'FFFF8AC6 ROM:00015098 mov.w @r4, r4 ROM:0001509A extu.w r4, r4 ROM:0001509C mov r12, r5 ROM:0001509E mov.w @(h'3A,pc), r6 ; [000150DC] = h'4000 ROM:000150A0 mov.l @(h'7C,pc), r10 ; [00015120] = sub_68A ROM:000150A2 jsr @r10 ; sub_68A ROM:000150A4 nop ROM:000150A6 mov.l @(h'7C,pc), r11 ; [00015124] = h'FFFF8AC4 ROM:000150A8 mov.w r0, @r11 ROM:000150AA mov.l @(h'7C,pc), r4 ; [00015128] = loc_2AAA ROM:000150AC mov.l @(h'7C,pc), r10 ; [0001512C] = sub_DC6 ROM:000150AE jsr @r10 ; sub_DC6 ROM:000150B0 nop ROM:000150B2 mov.l @(h'7C,pc), r10 ; [00015130] = unk_1106 ROM:000150B4 mov.w @r10, r10 ROM:000150B6 extu.w r10, r10 ROM:000150B8 mulu r10, r0 ROM:000150BA sts macl, r11 ROM:000150BC mov.l @(h'64,pc), r4 ; [00015124] = h'FFFF8AC4 ROM:000150BE mov.w @r4, r4 ROM:000150C0 extu.w r4, r4 ROM:000150C2 mov r11, r5 ROM:000150C4 mov.w @(h'16,pc), r6 ; [000150DE] = h'400 ROM:000150C6 mov.l @(h'58,pc), r10 ; [00015120] = sub_68A ROM:000150C8 jsr @r10 ; sub_68A ROM:000150CA nop ROM:000150CC mov.l @(h'64,pc), r11 ; [00015134] = h'FFFF8AC2 ROM:000150CE mov.w r0, @r11 ROM:000150D0 mov.l @r15+, r1 ROM:000150D2 mov.l @r15+, r14 ROM:000150D4 lds.l @r15+, pr ROM:000150D6 rts ROM:000150D8 nop ROM:000150D8 ; End of function sub_15014
Thanks,
Eric
Last edited by l2r99gst; Apr 3, 2008 at 11:22 AM.
Does 2AAA appear anywhere in the MUT? I am not so good with disassembly yet but looking at it looks like it calls a locate (if I remember right) that variable. Sorry not much help here.
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
sub_68A is r4*r5/r6 -> r0. That should be in Bez' disassembly though.
I'd need to look at sub_DC6 before I could comment on its function. What does Bez say it does?
I'd need to look at sub_DC6 before I could comment on its function. What does Bez say it does?
Code:
; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ RAM:00014964 RAM:00014964 RAM:00014964 MAF_MAIN: ; CODE XREF: FUIEL_MAFMAIN+Cp RAM:00014964 sts.l pr, @-r15 RAM:00014966 mov.l r14, @-r15 RAM:00014968 mov r15, r14 RAM:0001496A mov.l r1, @-r15 RAM:0001496C mov.l @(h'C0,pc), r4 ; [00014A30] = MAF_SCALE_HZ1 RAM:0001496E mov.l @(h'C4,pc), r10 ; [00014A34] = PRepaTABLE RAM:00014970 jsr @r10 ; PRepaTABLE RAM:00014972 nop RAM:00014974 mov.l @(h'C0,pc), r4 ; [00014A38] = MAFSCALE RAM:00014976 mov.l @(h'C4,pc), r10 ; [00014A3C] = TABLEMABLE RAM:00014978 jsr @r10 ; TABLEMABLE RAM:0001497A nop RAM:0001497C mov.l @(h'C0,pc), r10 ; [00014A40] = maf_add RAM:0001497E mov.w @r10, r10 RAM:00014980 add r10, r0 RAM:00014982 mov.l @(h'C0,pc), r11 ; [00014A44] = MAF_RESCALED? RAM:00014984 mov.w r0, @r11 RAM:00014986 mov.l @(h'C0,pc), r4 ; [00014A48] = MAF_SMOOTHING RAM:00014988 mov.l @(h'B0,pc), r10 ; [00014A3C] = TABLEMABLE RAM:0001498A jsr @r10 ; TABLEMABLE RAM:0001498C nop RAM:0001498E extu.w r0, r4 RAM:00014990 mov.l @(h'B8,pc), r10 ; [00014A4C] = AFTER_MAF_SMOOTHED RAM:00014992 jsr @r10 ; AFTER_MAF_SMOOTHED RAM:00014994 nop RAM:00014996 mov.l @(h'B8,pc), r11 ; [00014A50] = MAF_SMOOTHED RAM:00014998 mov.w r0, @r11 RAM:0001499A mov.l @(h'B8,pc), r1 ; [00014A54] = Temperature RAM:0001499C mov.w @r1, r1 RAM:0001499E extu.w r1, r1 RAM:000149A0 mov.l @(h'B4,pc), r4 ; [00014A58] = TEMP_COMP RAM:000149A2 mov.l @(h'98,pc), r10 ; [00014A3C] = TABLEMABLE RAM:000149A4 jsr @r10 ; TABLEMABLE RAM:000149A6 nop RAM:000149A8 mov.w @(h'7E,pc), r10 ; [00014A2A] = h'CD RAM:000149AA mulu r0, r10 RAM:000149AC sts macl, r4 RAM:000149AE mov r1, r5 RAM:000149B0 mov.l @(h'A8,pc), r10 ; [00014A5C] = sub_9B0 RAM:000149B2 jsr @r10 ; sub_9B0 RAM:000149B4 nop RAM:000149B6 mov.l @(h'A8,pc), r11 ; [00014A60] = TABLE_ARG1 RAM:000149B8 mov.w r0, @r11 RAM:000149BA mov.l @(h'A8,pc), r4 ; [00014A64] = PRES_LOAD RAM:000149BC mov.l @(h'74,pc), r10 ; [00014A34] = PRepaTABLE RAM:000149BE jsr @r10 ; PRepaTABLE RAM:000149C0 nop RAM:000149C2 mov.l @(h'A4,pc), r4 ; [00014A68] = PRESSURE RAM:000149C4 mov.l @(h'6C,pc), r10 ; [00014A34] = PRepaTABLE RAM:000149C6 jsr @r10 ; PRepaTABLE RAM:000149C8 nop RAM:000149CA mov.l @(h'A0,pc), r4 ; [00014A6C] = BAROCOMP RAM:000149CC mov.l @(h'6C,pc), r10 ; [00014A3C] = TABLEMABLE RAM:000149CE jsr @r10 ; TABLEMABLE RAM:000149D0 nop RAM:000149D2 mov.l @(h'9C,pc), r11 ; [00014A70] = MAF_RES1 RAM:000149D4 mov.w r0, @r11 RAM:000149D6 mov.l @(h'98,pc), r10 ; [00014A70] = MAF_RES1 RAM:000149D8 mov.w @r10, r10 RAM:000149DA extu.w r10, r10 RAM:000149DC mov.l @(h'70,pc), r11 ; [00014A50] = MAF_SMOOTHED RAM:000149DE mov.w @r11, r11 RAM:000149E0 extu.w r11, r11 RAM:000149E2 mulu r10, r11 RAM:000149E4 sts macl, r12 RAM:000149E6 mov.l @(h'5C,pc), r4 ; [00014A44] = MAF_RESCALED? RAM:000149E8 mov.w @r4, r4 RAM:000149EA extu.w r4, r4 RAM:000149EC mov r12, r5 RAM:000149EE mov.w @(h'3A,pc), r6 ; [00014A2C] = h'4000 RAM:000149F0 mov.l @(h'80,pc), r10 ; [00014A74] = multr4r5divr6 RAM:000149F2 jsr @r10 ; multr4r5divr6 RAM:000149F4 nop RAM:000149F6 mov.l @(h'80,pc), r11 ; [00014A78] = MAFAIR RAM:000149F8 mov.w r0, @r11 RAM:000149FA mov.l @(h'80,pc), r4 ; [00014A7C] = massive_index1 RAM:000149FC mov.l @(h'80,pc), r10 ; [00014A80] = DIM_MASS_GET RAM:000149FE jsr @r10 ; DIM_MASS_GET RAM:00014A00 nop RAM:00014A02 mov.l @(h'80,pc), r10 ; [00014A84] = INJ_SCALE RAM:00014A04 mov.w @r10, r10 RAM:00014A06 extu.w r10, r10 RAM:00014A08 mulu r10, r0 RAM:00014A0A sts macl, r11 RAM:00014A0C mov.l @(h'68,pc), r4 ; [00014A78] = MAFAIR RAM:00014A0E mov.w @r4, r4 RAM:00014A10 extu.w r4, r4 RAM:00014A12 mov r11, r5 RAM:00014A14 mov.w @(h'16,pc), r6 ; [00014A2E] = h'400 RAM:00014A16 mov.l @(h'5C,pc), r10 ; [00014A74] = multr4r5divr6 RAM:00014A18 jsr @r10 ; multr4r5divr6 RAM:00014A1A nop RAM:00014A1C mov.l @(h'68,pc), r11 ; [00014A88] = FUELPULSEBASE RAM:00014A1E mov.w r0, @r11 RAM:00014A20 mov.l @r15+, r1 RAM:00014A22 mov.l @r15+, r14 RAM:00014A24 lds.l @r15+, pr RAM:00014A26 rts RAM:00014A28 nop RAM:00014A28 ; End of function MAF_MAIN
What I am really trying to find out is if there is another variable that holds unclipped data for what Bez calls MAFAIR. This is MUT 28. In his comments above, the subroutine he calls DIM_MASS_GET looks like it may be what I am looking for, but I'm not sure. This is that subroutine:
Code:
; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ RAM:00000DC6 RAM:00000DC6 RAM:00000DC6 DIM_MASS_GET: ; CODE XREF: MAF_MAIN+9Ap RAM:00000DC6 ; sub_17190+Ap RAM:00000DC6 ; DATA XREF: ... RAM:00000DC6 mov.l @(h'10C,pc), r0 ; [00000ED4] = DIM_MASSIVE RAM:00000DC8 mov.w @r0, r0 RAM:00000DCA and #7, r0 RAM:00000DCC mov.b @(r0,r4), r0 RAM:00000DCE rts RAM:00000DD0 extu.b r0, r0 RAM:00000DD0 ; End of function DIM_MASS_GET RAM:00000DD0 RAM:00000DD2
Looking at his code further there are a couple more subroutines right under this one that looks like it also puts something into DIM_MASSIVE, but I'm guessing they are called under different conditions.
Thanks,
Eric
Last edited by l2r99gst; Apr 3, 2008 at 02:23 PM.
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
Finally figured out sub_DC6:
byte [@{(lowest 3 bits of FFFF6BC0) + r4}] -> r0
Based on the value of FFFF6BC0, the subroutine selects between one of eight values at the ROM address range from r4 to r4+7. In the context of the subroutine you are studying, r4 = 0x2AAA. So, depending on the value of FFFF6BC0, the subroutine will look up the value stored at one of the addresses from 0x2AAA to 0x2AB1. If you look at this address range in your ROM code, they'll all read the same value of 0x80. So the result of the subroutine in this instance is 0x80 -> r0 (no matter what the value of FFFF6BC0).
byte [@{(lowest 3 bits of FFFF6BC0) + r4}] -> r0
Based on the value of FFFF6BC0, the subroutine selects between one of eight values at the ROM address range from r4 to r4+7. In the context of the subroutine you are studying, r4 = 0x2AAA. So, depending on the value of FFFF6BC0, the subroutine will look up the value stored at one of the addresses from 0x2AAA to 0x2AB1. If you look at this address range in your ROM code, they'll all read the same value of 0x80. So the result of the subroutine in this instance is 0x80 -> r0 (no matter what the value of FFFF6BC0).
Last edited by mrfred; Apr 3, 2008 at 10:02 PM.
Trending Topics
Thanks mrfred and jcsbanks.
I was hoping, based on what Bez named the subroutine, that it would tell us what addresses held the unclipped mass airflow.
If MUT28 is the clipped mass airflow from the ECU, which is MAFAIR is Bez's comments and FFFF8AC4 for my ROM, does this particular code shown tell us anything about how or where the unclipped value is? That's really my whole interest in this.
A while back I made the correlation of mass airflow based on our load values, since the final load already has baro+temp compensation. Since the final load appears to be mass airflow/rev, all I did was log mass airflow (g/s) from OBD data and compared it to MUTIII data, load, under similar conditions. So, in reality, using the load correlation should be fine, seeing that load is mass airflow/rev, but if the ECU is doing a mass airflow calculation per time as well and storing it somewhere, I would like to be able to log that as well to be able to compare to the load based method, etc.
Eric
I was hoping, based on what Bez named the subroutine, that it would tell us what addresses held the unclipped mass airflow.
If MUT28 is the clipped mass airflow from the ECU, which is MAFAIR is Bez's comments and FFFF8AC4 for my ROM, does this particular code shown tell us anything about how or where the unclipped value is? That's really my whole interest in this.
A while back I made the correlation of mass airflow based on our load values, since the final load already has baro+temp compensation. Since the final load appears to be mass airflow/rev, all I did was log mass airflow (g/s) from OBD data and compared it to MUTIII data, load, under similar conditions. So, in reality, using the load correlation should be fine, seeing that load is mass airflow/rev, but if the ECU is doing a mass airflow calculation per time as well and storing it somewhere, I would like to be able to log that as well to be able to compare to the load based method, etc.
Eric
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
I had been wanting to go through that subroutine myself, so I checked it out last night. Here is my interpretation of what's happening:
The RAM variable you are interested in does indeed appear to represent a temperature and baro pressure corrected air flow. It would be a good one to log.
IMHO, the descriptions of the tables in ECUFlash that are referenced in this subroutine are way off the mark too. I have created relabeled and rescaled tables that more correctly describe the table axes and table contents:
For my evo9base.xml file:
For my Evo 9 88590015.xml file:
Sorry about only having this for the Evo 9 88590015. No time to do it for other ROMs. Hoping other people can do this. Pics of the tables are below. Anyhow, redefining the "MAF scaling" table kinda opens up a can of worms. This table appears to produce raw airflow values as a function of MAF Hz. The part of this table that I think needs consideration when it comes to tuning is that the table only goes to 1610 Hz. That is exactly the max value that a stock Evo 9 reaches (Thanks razorlab for all the posts on MAF Hz logging). Any modified Evo is going to produce MAF Hz values out of this range. razorlab has shown many examples of MAF Hz values reaching 2000 Hz. It could be said that people are doing just fine with tuning with the table "as-is", but I suspect people are compensating by having to richen up the AFR as RPMs increase past the point where 1610 Hz is reached. So, it seems to me that the tuning process could be made a little more logical by rescaling both columns of this table so that appropriate raw airflow values could be generated at 2000+ Hz. I have no idea what would be appropriate values for the raw air flow numbers though. That would have to come with trial-and-error. A good starting point would be to start logging 2-byte MAF Hz and the corrected airflow value (FFFF6C74 for the 88590015 ROM) to see what's happening to the corrected airflow out past 1600 Hz.
Code:
ROM:00017E80 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
ROM:00017E80
ROM:00017E80 ; set base injector pulse width
ROM:00017E80
ROM:00017E80 sub_17E80: ; CODE XREF: sub_177E8+Cp
ROM:00017E80 sts.l pr, @-r15
ROM:00017E82 mov.l r14, @-r15
ROM:00017E84 mov r15, r14
ROM:00017E86 mov.l r1, @-r15
ROM:00017E88 mov.l @(h'160,pc), r4 ; [00017FEC] = off_6D9A ; x-axis FFFF6B9E (supposedly) 2-byte airflow
ROM:00017E8A mov.l @(h'298,pc), r10 ; [00018124] = sub_CC6
ROM:00017E8C jsr @r10 ; sub_CC6
ROM:00017E8E nop
ROM:00017E90 mov.l @(h'154,pc), r4 ; [00017FE8] = unk_2D00 ; raw airflow
ROM:00017E92 mov.l @(h'288,pc), r10 ; [0001811C] = sub_C28
ROM:00017E94 jsr @r10 ; sub_C28
ROM:00017E96 nop
ROM:00017E98 mov.l @(h'148,pc), r10 ; [00017FE4] = unk_1112 ; 0x8C, #140
ROM:00017E9A mov.w @r10, r10
ROM:00017E9C add r10, r0 ; 0x8C + MAF scaling value -> r0
ROM:00017E9C ; raw airflow -> r0
ROM:00017E9E mov.l @(h'140,pc), r11 ; [00017FE0] = unk_FFFF6C76 ; 0x8C + MAF scaling val -> FFFF6C76
ROM:00017E9E ; raw airflow -> FFFF6C76
ROM:00017EA0 mov.w r0, @r11
ROM:00017EA2 mov.l @(h'138,pc), r4 ; [00017FDC] = unk_2D1C ; MAF compensation vs MAF Hz (FFFF6B9E)
ROM:00017EA4 mov.l @(h'274,pc), r10 ; [0001811C] = sub_C28
ROM:00017EA6 jsr @r10 ; sub_C28
ROM:00017EA8 nop
ROM:00017EAA extu.w r0, r4
ROM:00017EAC mov.l @(h'128,pc), r10 ; [00017FD8] = sub_26760
ROM:00017EAE jsr @r10 ; sub_26760 ; r4 -> r0 (always)
ROM:00017EB0 nop
ROM:00017EB2 mov.l @(h'120,pc), r11 ; [00017FD4] = unk_FFFF6C7A ; MAF_compenation -> FFFF6C7A
ROM:00017EB4 mov.w r0, @r11
ROM:00017EB6 mov.l @(h'118,pc), r1 ; [00017FD0] = unk_FFFF6ABE ; baro
ROM:00017EB8 mov.w @r1, r1
ROM:00017EBA extu.w r1, r1
ROM:00017EBC mov.l @(h'10C,pc), r4 ; [00017FCC] = unk_2D38 ; rel_air_dens vs FFFF6A5C IAT
ROM:00017EBE mov.l @(h'25C,pc), r10 ; [0001811C] = sub_C28
ROM:00017EC0 jsr @r10 ; sub_C28
ROM:00017EC2 nop
ROM:00017EC4 mov.w @(h'C4,pc), r10 ; [00017F8C] = h'CD ; #205
ROM:00017EC6 mulu r0, r10 ; IAT comp lookup * #205 -> r10
ROM:00017EC8 sts macl, r4 ; low word -> r4
ROM:00017ECA mov r1, r5 ; baro -> r1
ROM:00017ECC mov.l @(h'F8,pc), r10 ; [00017FC8] = sub_9B0
ROM:00017ECE jsr @r10 ; sub_9B0 ; lesser of r4/r5 and 0xFFFF -> r0
ROM:00017ED0 nop ; rel_air_dens*#205/baro -> r0
ROM:00017ED0 ; note: baro/#205 = pressure in bar
ROM:00017ED0 ; rel_air_dens/baro_bar -> r0
ROM:00017ED2 mov.l @(h'F0,pc), r11 ; [00017FC4] = unk_FFFF69CA
ROM:00017ED4 mov.w r0, @r11 ; rel_air_dens/baro_bar -> FFFF69CA
ROM:00017ED6 mov.l @(h'E8,pc), r4 ; [00017FC0] = off_6DCE ; x-axis FFFF6B9E
ROM:00017ED6 ; (supposedly) 2-byte airflow
ROM:00017ED8 mov.l @(h'248,pc), r10 ; [00018124] = sub_CC6
ROM:00017EDA jsr @r10 ; sub_CC6
ROM:00017EDC nop
ROM:00017EDE mov.l @(h'DC,pc), r4 ; [00017FBC] = off_6D88 ; y-axis FFFF69CA rel_air_dens/baro_bar
ROM:00017EE0 mov.l @(h'240,pc), r10 ; [00018124] = sub_CC6
ROM:00017EE2 jsr @r10 ; sub_CC6
ROM:00017EE4 nop
ROM:00017EE6 mov.l @(h'D0,pc), r4 ; [00017FB8] = unk_2D46 ; air density correction
ROM:00017EE8 mov.l @(h'230,pc), r10 ; [0001811C] = sub_C28
ROM:00017EEA jsr @r10 ; sub_C28
ROM:00017EEC nop
ROM:00017EEE mov.l @(h'C4,pc), r11 ; [00017FB4] = unk_FFFF6C78 ; air density correction -> FFFF6C78
ROM:00017EF0 mov.w r0, @r11
ROM:00017EF2 mov.l @(h'C0,pc), r10 ; [00017FB4] = unk_FFFF6C78 ; air density correction
ROM:00017EF4 mov.w @r10, r10
ROM:00017EF6 extu.w r10, r10
ROM:00017EF8 mov.l @(h'D8,pc), r11 ; [00017FD4] = unk_FFFF6C7A ; MAF_compensation
ROM:00017EFA mov.w @r11, r11
ROM:00017EFC extu.w r11, r11
ROM:00017EFE mulu r10, r11
ROM:00017F00 sts macl, r12 ; MAF_compensation * air_dens_corr -> r12
ROM:00017F02 mov.l @(h'DC,pc), r4 ; [00017FE0] = unk_FFFF6C76 ; airflow_raw
ROM:00017F04 mov.w @r4, r4
ROM:00017F06 extu.w r4, r4
ROM:00017F08 mov r12, r5 ; MAF_compensation * air_dens_corr -> r5
ROM:00017F0A mov.w @(h'7C,pc), r6 ; [00017F8A] = h'4000 ; #16,384
ROM:00017F0C mov.l @(h'A0,pc), r10 ; [00017FB0] = sub_68A
ROM:00017F0E jsr @r10 ; sub_68A ; r4*r5/r6 -> r0
ROM:00017F10 nop ; (MAF_scale + 0x8C)*(MAF_comp*air_dens_corr)/0x4000 -> r0
ROM:00017F10 ; airflow_raw*MAF_comp*air_dens_corr/0x4000 -> r0
ROM:00017F10 ; corrected_airflow -> r0
ROM:00017F12 mov.l @(h'98,pc), r11 ; [00017FAC] = unk_FFFF6C74
ROM:00017F14 mov.w r0, @r11 ; corrected_airflow -> FFFF6C74
ROM:00017F16 mov.l @(h'90,pc), r4 ; [00017FA8] = unk_2DAA ; @0x2DAA = 0x80
ROM:00017F18 mov.l @(h'88,pc), r10 ; [00017FA4] = sub_DC6
ROM:00017F1A jsr @r10 ; sub_DC6 ; byte [@{(lowest 3 bits of FFFF6BC0) + r4}] -> r0
ROM:00017F1C nop ; result: 0x80 -> r0
ROM:00017F1E mov.l @(h'80,pc), r10 ; [00017FA0] = unk_1106 ; injector scaling
ROM:00017F20 mov.w @r10, r10
ROM:00017F22 extu.w r10, r10
ROM:00017F24 mulu r10, r0
ROM:00017F26 sts macl, r11 ; injscaling * #128 -> r11
ROM:00017F28 mov.l @(h'80,pc), r4 ; [00017FAC] = unk_FFFF6C74
ROM:00017F2A mov.w @r4, r4 ; corrected_airflow -> r4
ROM:00017F2C extu.w r4, r4
ROM:00017F2E mov r11, r5 ; inj_scale*0x80 -> r5
ROM:00017F30 mov.w @(h'54,pc), r6 ; [00017F88] = h'400
ROM:00017F32 mov.l @(h'7C,pc), r10 ; [00017FB0] = sub_68A
ROM:00017F34 jsr @r10 ; sub_68A ; r4*r5/r6 -> r0
ROM:00017F36 nop ; [injscale*0x80]*[airflow_raw]*[MAF_smooth]*[air_dens_corr]/0x4000/0x400 -> r0
ROM:00017F36 ; injscale*0x80*corrected_airflow/0x400 -> r0
ROM:00017F38 mov.l @(h'60,pc), r11 ; [00017F9C] = unk_FFFF6C72 ; base injector pulse width?
ROM:00017F3A mov.w r0, @r11
ROM:00017F3C mov.l @r15+, r1
ROM:00017F3E mov.l @r15+, r14
ROM:00017F40 lds.l @r15+, pr
ROM:00017F42 rts
ROM:00017F44 nop
ROM:00017F44 ; End of function sub_17E80
ROM:00017F44
IMHO, the descriptions of the tables in ECUFlash that are referenced in this subroutine are way off the mark too. I have created relabeled and rescaled tables that more correctly describe the table axes and table contents:
For my evo9base.xml file:
Code:
<scaling name="AirTempFactor" units="Fraction" toexpr="x/64" frexpr="64/x" format="%.2f" min="0" max="2" inc="0.02" storagetype="uint8" endian="big"/>
<scaling name="AirTempBaroFactor" units="Fraction" toexpr="x/64" frexpr="64/x" format="%.2f" min="0" max="2" inc="0.02" storagetype="uint16" endian="big"/>
<scaling name="MAFHz" units="Hz" toexpr="6.29*x/64" frexpr="64/(6.29*x)" format="%.0f" min="1000" max="5000" inc="1" storagetype="int16" endian="big"/>
<scaling name="AirTempBaroCorrection" units="Fraction" toexpr="x/128" frexpr="128/x" format="%.2f" min="0" max="2" inc="0.02" storagetype="uint8" endian="big"/>
<table name="Airflow Raw Scaling" category="Fuel" type="2D" level="3" scaling="uint8">
<table name="MAF Hz" type="Y Axis" elements="21" scaling="MAFHz"/>
</table>
<table name="MAF Compensation" category="Fuel" type="2D" level="3" scaling="uint8">
<table name="MAF Hz" type="Y Axis" elements="21" scaling="MAFHz"/>
</table>
<table name="Relative Air Density vs Temp" category="Fuel" type="2D" level="3" flipy="true" scaling="AirTempFactor">
<table name="Degrees" type="Y Axis" elements="8" scaling="Temp"/>
</table>
<table name="Baro and Air Temp Compensation" category="Fuel" type="3D" level="3" swapxy="true" scaling="AirTempBaroCorrection">
<table name="IAT_Comp/Baro_Bar" type="X Axis" elements="4" scaling="AirTempBaroFactor"/>
<table name="MAF Hz" type="Y Axis" elements="9" scaling="MAFHz"/>
</table>
Code:
<table name="Airflow Raw Scaling" address="2d06">
<table name="MAF Hz" address="6da4"/>
</table>
<table name="MAF Compensation" address="2d22">
<table name="MAF Hz" address="6da4"/>
</table>
<table name="Relative Air Density vs Temp" address="2d3e">
<table name="Degrees" address="7070"/>
</table>
<table name="Baro and Air Temp Compensation" address="2d51">
<table name="IAT_Comp/Baro_Bar" address="6d92"/>
<table name="MAF Hz" address="6dd8"/>
</table>
Last edited by mrfred; Apr 4, 2008 at 04:25 PM.
mrfred,
You rock, of course. Thanks for taking so much time to explain this disassembly better. I can find the tables for my ROM and post them, if need be, but it looks like the 96940011 ROM will be replaced by 96530006 anyway, so maybe I will find the tables for both.
I don't think this redefines the maf scaling table, though. In my original thread way back when I noted the maf scaling table as a L/Hz vs Hz table. So, this is a raw airflow (volumetric airflow) vs Hz, which is what your disassembly just proved. The mass airflow is then calculated after pressure and temp corrections.
Anyway, on to my original question about this mass airflow...that variable that holds this airflow is loggable via MUT28. But, according to Bez (not sure if you showed this here or not), this is a clipped value. I tried logging it the other day, and it did indeed max out right around the time 1 byte load maxed out. So, I was wondering if there was any variable that held this data that wasn't clipped? Is it as easy as just logging the high and low byte of this variable?
I'm still reading through your disassembly, so it may be there in black and white for me to read again, but I just wanted to ask and also thank you for the work.
Eric
You rock, of course. Thanks for taking so much time to explain this disassembly better. I can find the tables for my ROM and post them, if need be, but it looks like the 96940011 ROM will be replaced by 96530006 anyway, so maybe I will find the tables for both.
I don't think this redefines the maf scaling table, though. In my original thread way back when I noted the maf scaling table as a L/Hz vs Hz table. So, this is a raw airflow (volumetric airflow) vs Hz, which is what your disassembly just proved. The mass airflow is then calculated after pressure and temp corrections.
Anyway, on to my original question about this mass airflow...that variable that holds this airflow is loggable via MUT28. But, according to Bez (not sure if you showed this here or not), this is a clipped value. I tried logging it the other day, and it did indeed max out right around the time 1 byte load maxed out. So, I was wondering if there was any variable that held this data that wasn't clipped? Is it as easy as just logging the high and low byte of this variable?
I'm still reading through your disassembly, so it may be there in black and white for me to read again, but I just wanted to ask and also thank you for the work.
Eric
Last edited by l2r99gst; Apr 4, 2008 at 04:32 PM.
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
Yep, just log the high (FFFF8AC4) and low (FFFF8AC5) bytes like 2-byte load. I'm really curious to see what you get out past 1600 Hz. I think it will flat line, but not sure. I don't know how table lookups work when the input value exceeds the table input range. I may log it myself on my way home from work this evening.
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
mrfred,
...
I don't think this redefines the maf scaling table, though. In my original thread way back when I noted the maf scaling table as a L/Hz vs Hz table. So, this is a raw airflow (volumetric airflow) vs Hz, which is what your disassembly just proved. The mass airflow is then calculated after pressure and temp corrections.
...
Eric
...
I don't think this redefines the maf scaling table, though. In my original thread way back when I noted the maf scaling table as a L/Hz vs Hz table. So, this is a raw airflow (volumetric airflow) vs Hz, which is what your disassembly just proved. The mass airflow is then calculated after pressure and temp corrections.
...
Eric
Yep, just log the high (FFFF8AC4) and low (FFFF8AC5) bytes like 2-byte load. I'm really curious to see what you get out past 1600 Hz. I think it will flat line, but not sure. I don't know how table lookups work when the input value exceeds the table input range. I may log it myself on my way home from work this evening.
Anyways, I'm very interesting to see what we get. If it works out, then this will be a way to log true mass airflow, as calculated by the ECU. Right now, all we have are my approximations based on load (which shouldn't be too far off, since load is a mass airflow/rev value calcuated by the ECU as well).
Eric
Last edited by l2r99gst; Apr 4, 2008 at 04:53 PM.
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
I just checked it using the Trace32. The ECU uses the last value in the table lookup output when the input value exceeds the input range in the table. I'm 100% sure that the raw airflow value flatlines at 232 when the MAF Hz exceeds 1610 Hz. Only way to get more fuel out past this point is to richen the AFR values in the fuel table.
Anyhow, I'll double check with a WOT log tonight if I can. Need to convince the wifey to let me floor it on the way home from work. :-)
Anyhow, I'll double check with a WOT log tonight if I can. Need to convince the wifey to let me floor it on the way home from work. :-)