|
elRey
|
 |
« Reply #15 on: May 15, 2012, 01:49:06 PM »
|
|
|
the bottom 14 bits of 0x199BA is 0x199BA & 0x0x3fff = 0x19ba
the upper bits of 0x199BA is 0x18000>>14 = 6 ^I don't get this at all. Wait. Oh I see. 11001100110111010 --001100110111010 = 19ba 11000000000000000 = 18000 |
|
|
|
« Last Edit: May 15, 2012, 01:53:23 PM by elRey »
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #16 on: May 15, 2012, 02:00:55 PM »
|
|
|
mov r12, #0A17h
mov r13, #206h
movbz r14, byte_F89C
calls 82h, LookupI_825c24 ; References a lookupI table
movb byte_381E4A, rl4
mov r12, #848h
mov r13, #207h
mov r14, word_F89E
calls 82h, LookupJ_825c98 ; References a lookupJ table
mov r12, #0A17h mov r13, #206h #0A17h = 18A17 Looks right. It lands me at the map I expect. mov r12, #848h mov r13, #207h #848h = 18848 Looks wrong. It lands me in the middle of a map (wrong map). ?? |
|
|
|
|
Logged
|
|
|
|
|
matchew
|
|
« Reply #17 on: May 15, 2012, 02:49:48 PM »
|
|
|
mov r12, #848h
mov r13, #207h
#848h = 18848 Looks wrong. It lands me in the middle of a map (wrong map).
??
Try 0x1C848.... The difference is 206 vs 207 |
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #18 on: May 15, 2012, 03:03:42 PM »
|
|
|
right on the dot. Thanks. I can't say I understand it, but I believe I'm seeing the pattern.
Thanks guys.
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #19 on: May 15, 2012, 04:05:13 PM »
|
|
|
Try 0x1C848....
The difference is 206 vs 207
I'm curious as to why... is r13 used to modify dpp in the subroutine? |
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
ArgDub
Full Member
Karma: +60/-1
 Offline
Posts: 202
|
|
« Reply #20 on: May 15, 2012, 04:28:22 PM »
|
|
|
I'm curious as to why... is r13 used to modify dpp in the subroutine?
What Andy's plugin names as LookupJ is a 1d map lookup function that returns a 16bit unsigned value, X axis is also 16bit unsigned. The parameters passed are: r12 = map address, r13 = Map DPP, r14: X variable. |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #21 on: May 15, 2012, 04:33:33 PM »
|
|
|
right on the dot. Thanks. I can't say I understand it, but I believe I'm seeing the pattern.
If R13 is used to pass DPP 0x207<<14 | 0x848 = 0x81c848 I'm assuming the rom is mapped to 0x80000, which means the offset into the ROM is 0x1c848 or, to make things easier 0x7<<14 | 0x848 = 0x1c848 |
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
ArgDub
Full Member
Karma: +60/-1
Offline
Posts: 202
|
|
« Reply #22 on: May 15, 2012, 04:46:12 PM »
|
|
|
Correct, function LookupJ expects a pointer (r13 << 14 | r12) to map's X_AxisLength, following X_AxisLength is the X_Axis itself and the map is next to the axis
|
|
|
|
« Last Edit: May 15, 2012, 07:19:28 PM by ArgDub »
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #23 on: October 20, 2012, 04:39:29 PM »
|
|
|
mov r12, #2B94h ; KFZW2 Map
mov r13, #3BC4h ; KFZW2 Load axis
mov r14, word_380CDE
mov r15, word_380CEE
calls 0, sub_2B24 ; KFZW2 Lookup
How does the sub_2B24 WLookup2D_Spark function know where the RPM axis is? (which is @ 13B64) code right before lookup: ZWGRU:
mov [-r0], r9
mov [-r0], r7
mov [-r0], r6
sub r0, #2
mov r4, word_382C14
extp #20Ah, #1
cmp r4, word_829FE4
jmpr cc_NC, loc_8B8E4C
Thanks, Rey |
|
|
|
« Last Edit: October 20, 2012, 04:50:36 PM by elRey »
|
Logged
|
|
|
|
rajivc666
Full Member
Karma: +23/-2
Offline
Posts: 127
|
|
« Reply #24 on: October 21, 2012, 06:39:18 AM »
|
|
|
The memory locations 380cde and 380cee contains a factor for load and rpm, since the dimensions of the tables are known, starting point and factors of the axes are sufficient to look up the table.
|
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #25 on: October 21, 2012, 11:03:14 AM »
|
|
|
Map and axis are in different locations. i.e. the axis are not next to map. Nor are they next to each other. The code only references the map location and one of the axis location. How does it know where the other axis is located?
380cde and 380cee I assumed were the inputs for the lookup. Am I wrong?
|
|
|
|
|
Logged
|
|
|
|
|
matchew
|
|
« Reply #26 on: October 21, 2012, 11:35:51 AM »
|
|
|
0x380CDE and 0x380CEE I assumed were the inputs for the lookup. Am I wrong?
No you are correct. These are the variables that each axis uses. One of which is tied to a specific axis, the other can be applied to various different axis. |
|
|
|
|
Logged
|
|
|
|
rajivc666
Full Member
Karma: +23/-2
Offline
Posts: 127
|
|
« Reply #27 on: October 21, 2012, 11:42:04 AM »
|
|
|
One thing you should understand is that these axes in definitions are made for humans, the ecu may not be using it as projected in definitions. If you decode the part were the memory locations 0x380CDE and 0x380CEE get their values you will understand.
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #28 on: October 21, 2012, 01:18:16 PM »
|
|
|
If you decode the part were the memory locations 0x380CDE and 0x380CEE get their values you will understand.
This. The axis is referenced in the assignment of the Stutzstellen variables. mov r12, #0C1h ; '-' ; Move Word movbz r13, nmot ; Move Byte Zero Extend mov r14, SNM16ZUUB_w ; Move Word calls 0, sub_75D2 ; Call Inter-Segment Subroutine mov SNM16ZUUB_w, r4 ; Move Word |
|
|
|
« Last Edit: November 23, 2012, 11:31:54 AM by phila_dot »
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #29 on: November 23, 2012, 10:13:19 AM »
|
|
|
Ah I get it. That last line keeps the axis location in memory. Cool.
|
|
|
|
|
Logged
|
|
|
|
|
