http://john824.fotopic.net/p37077620.html

I punched it in 3rd gear at 4000-7000 RPM and logged the conventional MUT airflow and my new 2 byte airflow.

The airflow would go higher on the stock turbo if I revved higher and removed the bung from my exhaust which I have in temporarily so I don't upset my neighbours whilst I defrost the windscreen in the mornings whilst the engine is running. Also forgive my slight overboost

It took a few goes and some disassembly work, but the key is to find the variable that is just about to be divided by 64 before it becomes the usual airflow value we all know that clips after about 1600 Hz.

I have kept my 2 byte load on request ID 00 and 01, and put this on request ID 02 and 03. So the addresses to change will be 8 bytes on from the ones we discussed before for load. Scaling is then 6.29/64*((256*requestID02)+requestID03).

 

For Eric, this variable appears to be the one closely associated with the tables he has been working with, so logging it may be useful.

Do people want me to find the locations for the Evo 8 and 9 US models?

 

Nice...

The big issue is when we can get real 2 byte responses and custom requests, this way its always a custom request to a memory area, and a response of the word associated with it.

Hopefully Bez gets his stuff back in order and that stuff starts panning out.

 

Yeah, definitely for the 94170008 as its the most prevelent Rom, and as many others as you think are useful.

 

The MUT table flash block is a big one too, takes a while. It would be far more elegant to have a realtime RAM snooper that can read and write bytes, words or longs on a custom protocol that doesn't interfere with the standard diagnostics. Whilst the holy grail, it is a massive amount of work. I've spent 5 hours today just doing this because of those little niggles! I was also looking for wastegate duty. I managed to log the presently used wastegate max, but when I log what I think is the actual duty I get strange results.

 

The funny thing is I think there actually is something along those lines built-into the Roms thats used for debugging purposes that nobody has documented.. It makes sense as it would be far easier for Mitsubishi to have a diagnostic mode designed for tuning by making live changes, this is what it would typically be used for.

I wish I had the time (and understanding) to really get through everything without feeling like I'm translating pheonecian to aramaic in my head in real time..

 

FFFF89BA is the RAM location of the airflow word on 94170008.

As before, we change the lower word of each request ID location to 89BA and 89BB (the upper word at FFFF doesn't change):

Request ID 02 &H3806A Uint16 change to decimal 35258
Request ID 03 &H3806E Uint16 change to decimal 35259

 

May i say on behalf of the US evo community...A very big Thank you !! Mr. Banks.

Its people like you and Jack and Bez that really help drive the community tuning base.

Be sure and have a safe and very happy Holiday season !!!!!!!

milburn

 

Excellent!

d

 

Really appreciate your efforts John. I have been using the 2 byte load with great success. If you can post the addresses and tables for 88590015 that would be awesome!

 

John,

Awesome work as usual. I will definitely use this as needed to determine the scaling for the MAF table. However, I think that the 1600 limit currently imposed should give me enough resolution to figure things out.

I'll have to check those addresses for my ROM. I think it may be easier to paste a few lines of the hex code along with the address so people with IDA Pro can search their own ROM for the same code to verify if the address and code are the same or located in a different place.


Thanks again,
Eric

EDIT: When you say RAM address and not ROM address for the airflow word, you are referring to the RAM address that you have seen by disassembling the ROM correct? (I know we actually change the ROM at the address for the request IDs). I think this was in one of the AktiveMatrix threads, but is there an offset that we can specify for the RAM location when opening the ROM in IDA Pro or am I just totally missing something here? Don't shoot me for being new with disassembly. It's just that I noticed when opening a ROM, there is a 'Diassembly menory orginization' window that asks for RAM offsets, ROM offsets, etc, but I didn't know if we had to put anything in there. I was just assuming that when downloading the ROM we didn't have any access to the RAM portion, unless that is downloaded, too.

 

Good work JBanks.

 

I'll see what I can post up re code and the other ROMs.

Eric, in the ROM MUT table, there are values that point to RAM to log the realtime variables. So load, airflow, RPM are held in RAM and we just point the MUT table to them so we can log them. I've not done anything special with RAM segments etc, just look at the code and the addresses in there for variables I want to log and then change the MUT table to point to them.

 

John,

Thanks for the clarification. That's what I thought, but sometimes I like to know for sure to make sure that I am on the same page and grasp what is being done and going on.

And as far as posting code for other ROMs, don't worry about that at all....that would just take too much time and I don't want to waste your time on that. I was just suggesting since the locations for certain code is at different addresses between different ROMs, it may be useful to post a snipit of what the actual hex code, perhaps a few bytes, looks like so that someone else can easily find the address by searching for the same code.

Eric

 

In this case, its just a pointer reference in memory, and not actual code.

In the future, mods will consist of new or modified routines, and it will be necessary to find the old code to replace/modify... so you will see that stuff more often in the near future.