status of 2 byte load?
Evolving Member
Joined: Dec 2006
Posts: 276
Likes: 0
Think of it this way. The MUT command is an ID. The ID is an offset into a table of addresses in memory, each address in the table points to a byte to be returned.
The MUT 'handler' for this is very simple:
Receive ID, multiply ID times 4, add result to base address of MUT lookup table. Fetch address from the table, fetch byte from fetched address, transmit it...
They are not talking about recoding the ECU, just changing what addresses are examined by a couple of seemingly not very useful MUT IDs. The hard part would seem to be finding the two bytes to repoint the MUT table at.
-jjf
The MUT 'handler' for this is very simple:
Receive ID, multiply ID times 4, add result to base address of MUT lookup table. Fetch address from the table, fetch byte from fetched address, transmit it...
They are not talking about recoding the ECU, just changing what addresses are examined by a couple of seemingly not very useful MUT IDs. The hard part would seem to be finding the two bytes to repoint the MUT table at.
-jjf
correct.
what is happening is we are assigning MUT table entries 0 and 1 to point to the memory addresses identified by the address parameter
the MUT table entries are identified by the "name" parameter, the memory address for the load is idenified by the "address" parameters.
Code:
<table name="00" address="38062" type="1D" level="1" scaling="uint16" /> <table name="01" address="38066" type="1D" level="1" scaling="uint16" />
this post
https://www.evolutionm.net/forums/sh...2&postcount=45
contains the formula for using the 2 byte load in evoscan, it's similar to the formula you will need if you want to use Mitsulogger.
2 byte load =((256*[00])+[01])*0.3125
ahh ok gotcha.
so we are telling the MUT table where to look in memory via the entry number (requestID) in the table..
seems simple enough.. :P
so for the average user to get this to work we need to update the ECU's MUT table with new memory pointers (to the real load bytes) and then we need to get our logging software to request those updated RequestID's... and log it
so we are telling the MUT table where to look in memory via the entry number (requestID) in the table..
seems simple enough.. :P
so for the average user to get this to work we need to update the ECU's MUT table with new memory pointers (to the real load bytes) and then we need to get our logging software to request those updated RequestID's... and log it
I think I'm still missing some thing here, I put those 2 tables into EcuFlash, and opened and saved my ROM, but when I compared my new ROM to my old they are exactly the same...??
Are the 38062 and 38066 memory positions universal amongst different ECU's? Ie will that work for my AUDM??
Are the 38062 and 38066 memory positions universal amongst different ECU's? Ie will that work for my AUDM??
I think I'm still missing some thing here, I put those 2 tables into EcuFlash, and opened and saved my ROM, but when I compared my new ROM to my old they are exactly the same...??
Are the 38062 and 38066 memory positions universal amongst different ECU's? Ie will that work for my AUDM??
Are the 38062 and 38066 memory positions universal amongst different ECU's? Ie will that work for my AUDM??
You are not changing anything on the ROM image itself, only pointing to an existing memory address that contains the actual load value.
so for a 13/14 RequestID 00 is @ 0x3EE66, and 01 is @ 0x3EE6A....
So it shouldn't be too hard for me to find the memory address of RequestID 00 on my AUDM?
is 27458 and 27459 universal memory positions for Evo9's for Load??
Last edited by tephra; Mar 2, 2007 at 07:27 PM.
no they are not. That is the problem. Finding the correct memory addresses is like looking for a needle in a haystack.
yeah, welcome to the wonderful world of hacking your car... 
I think there are some efforts going on to find these addresses, and basically decode the EVO 9 roms, but I don't know the status of these projects.
Evolving Member
Joined: Sep 2006
Posts: 152
Likes: 0
From: Germany
2 Byte Adresses for EVO7, ID: 99860002
2 Byte Load:
Load high byte: FFFF885C
Load low byte: FFFF885D
2 Byte Airflow:
Airflow high byte: FFFF88B4
Airflow low byte: FFFF88B5
Mut Table IDs begins at: 0x302d8
So, if you want to patch MUT ID0 and ID1 to log load, then you must change:
Address 0x302da to 0x885C (load high byte)
Address 0x302de to 0x885D (load low byte)
Calculation of load: 5/16*(LoadHigh*256+LoadLow) (orig. load is 5/8*..)
If you want to patch MUT ID2 and ID3 to log airflow, then you must change:
Address 0x302e2 to 0x88B4 (airflow high byte)
Address 0x302e6 to 0x88B5 (airflow low byte)
Calculation: 6.29/64*(256*AirHigh+AirLow)
2 Byte Load:
Load high byte: FFFF885C
Load low byte: FFFF885D
2 Byte Airflow:
Airflow high byte: FFFF88B4
Airflow low byte: FFFF88B5
Mut Table IDs begins at: 0x302d8
So, if you want to patch MUT ID0 and ID1 to log load, then you must change:
Address 0x302da to 0x885C (load high byte)
Address 0x302de to 0x885D (load low byte)
Calculation of load: 5/16*(LoadHigh*256+LoadLow) (orig. load is 5/8*..)
If you want to patch MUT ID2 and ID3 to log airflow, then you must change:
Address 0x302e2 to 0x88B4 (airflow high byte)
Address 0x302e6 to 0x88B5 (airflow low byte)
Calculation: 6.29/64*(256*AirHigh+AirLow)
Nearly certain on these...someone can double check if they wish:
05 ROM, Internal ID 96940011
MUT table is defined at address 3F314 and it looks like this:
The 2 byte load address is FFFF899A and FFFF899B. So, change the first two values in your MUT table to these two values. If you don't have the whole MUT table defined in ECUFlash, you need address 3F316 and 3F31A.
If you want to add the MUT table to your ECUFlash definition, just add this to the 96940011.xml file in the rommetadata\mitsubishi\evo folder:
Eric
05 ROM, Internal ID 96940011
MUT table is defined at address 3F314 and it looks like this:
The 2 byte load address is FFFF899A and FFFF899B. So, change the first two values in your MUT table to these two values. If you don't have the whole MUT table defined in ECUFlash, you need address 3F316 and 3F31A.
If you want to add the MUT table to your ECUFlash definition, just add this to the 96940011.xml file in the rommetadata\mitsubishi\evo folder:
PHP Code:
<table name="MUT table" address="3f314" type="3D" level="1" scaling="Hex16">
<table name="X" type="Static X Axis" elements="16" scaling="Hex16">
<data>4</data>
<data>6</data>
<data>8</data>
<data>A</data>
<data>C</data>
<data>E</data>
<data>10</data>
<data>12</data>
<data>14</data>
<data>16</data>
<data>18</data>
<data>1A</data>
<data>1C</data>
<data>1E</data>
<data>0</data>
<data>2</data>
</table>
<table name="Y" type="Static Y Axis" elements="32">
<data>3f314</data>
<data>3f334</data>
<data>3f354</data>
<data>3f374</data>
<data>3f394</data>
<data>3f3B4</data>
<data>3f3D4</data>
<data>3f3F4</data>
<data>3f414</data>
<data>3f434</data>
<data>3f444</data>
<data>3f474</data>
<data>3f494</data>
<data>3f4B4</data>
<data>3f4D4</data>
<data>3f4F4</data>
<data>3f514</data>
<data>3f534</data>
<data>3f554</data>
<data>3f574</data>
<data>3f594</data>
<data>3f5B4</data>
<data>3f5D4</data>
<data>3f5F4</data>
<data>3f614</data>
<data>3f634</data>
<data>3f654</data>
<data>3f674</data>
<data>3f694</data>
<data>3f6B4</data>
<data>3f6D4</data>
<data>3f6F4</data>
<data>3f714</data>
</table>
</table>
Eric
Last edited by l2r99gst; Mar 4, 2007 at 06:03 AM.