Dam I love the ecuflash forum, everyone has one goal in mind and that is figuring out the stock ecu where as if you go to engine drivetrain every other post is a argument.

 

OK some basics

in these ROMS, memory addresses are something like 0xFFFF1234, 4 bytes long, so often when you see 0xFFFFXXYY in the ROM this is a pointer to a memory address. If you look through your ROM for 0xFFFF it should crop up quite a lot (ie 100's if not 1000's of times)

in order todo the mod you need 2 things:
1) location of the MUT table (so you can change what MUT00 and MUT01 point to)
2) location of the 2bytes of load.

IDAPro makes things a bit easy because you can semi-visualise subroutines, and what memory locations they link too.

I hope this helps a bit

 

I know but you said look for the address in the rom that has 2 sets of 0xffff before it. And I only found one address that had that which is what I posted. I know what you mean as far as memory addresses though. I did see over a 100
0xffff, but once again there was only 1 spot that had 2 in a row followed by a memory address just like you stated so I assumed that was it.

This is what you wrote(and the previous 2 bytes will be 0xFFFF), my question is does this only apply to the 94170008 rom and not any others.

by the way I appreciate all your help.

 

oh no sorry, I see what you mean.

No what I meant was if the data at the memory addresses in the 2 original ROM's was the same, then you could probably conclude that not much had changed between the 2 ROM's, thus you could try the mod and see if it worked.

since they are different you run the risk of over-writing real ECU code with rubbish, - which would be BAD

 

Affirmative, so how did you actually find it in your rom if it was diff from the one posted by jcsbanks

 

ok well you need to find the MUT table first, this is a bit easy, just look for sequences of memory locations in the ROM, ie

FF FF x1 y1 FF FF x2 y2 FF FF x3 y3 FF FF x4 y4... etc etc etc, you can see the pattern, 2 bytes separated by sets of FF FF's - once you find a block of these (say 30 plus big) then the first 4 bytes is probably REQ00 you can verify this by using IDAPro to tell you what references that memory location...

next you need to find when your ROM stores the 2 bytes of load - this is harder...

 

can you post a pic string line of an example to show the pattern.

 

This is from IDA Pro...

ROM:000373C4 .data.l unk_FFFF6A09
ROM:000373C8 .data.l unk_FFFF6A08
ROM:000373CC .data.l unk_FFFF6A11
ROM:000373D0 .data.l unk_FFFF6A10
ROM:000373D4 .data.l unk_FFFF6D65
ROM:000373D8 .data.l unk_FFFF6D87
ROM:000373DC .data.l h'FFFF6D85
ROM:000373E0 .data.l unk_FFFF6A27
ROM:000373E4 .data.l unk_FFFF6076
ROM:000373E8 .data.l unk_FFFF6E49
ROM:000373EC .data.l unk_FFFF6078
ROM:000373F0 .data.l unk_FFFF6E4B
ROM:000373F4 .data.l unk_FFFF6047
ROM:000373F8 .data.l unk_FFFF6049
ROM:000373FC .data.l unk_FFFF604B
ROM:00037400 .data.l unk_FFFF6C32
ROM:00037404 .data.l unk_FFFF6A2D
ROM:00037408 .data.l unk_FFFF6A3D
ROM:0003740C .data.l unk_FFFF6A2F
ROM:00037410 .data.l unk_FFFF6A45
ROM:00037414 .data.l unk_FFFF6AA9
ROM:00037418 .data.l unk_FFFF6A99
ROM:0003741C .data.l unk_FFFF6087
ROM:00037420 .data.l unk_FFFF6AAB
ROM:00037424 .data.l unk_FFFF6BCD
ROM:00037428 .data.l unk_FFFF6BC7
ROM:0003742C .data.l unk_FFFF6B7B
ROM:00037430 .data.l unk_FFFF6027

 

you did this with ida pro trial version? If so what do you use for load segment and load offset. You keep saying all these ffff's but the program I use which is freeware shows hardly any except for the undefined spots

 

Did anyone verify the differences between the two byte load, LoadAF and LoadCalc? How much off are LoadAF and LoadCalc from the two byte load? Anyone have a log they can post of all of them?

 

whats LoadAF?

https://www.evolutionm.net/forums/sh...&postcount=108

 

Using the airflow parameter and rpm to calculate load.

 

I've compared calcload (from IPW/AFRMAP) to 2 byte load. Two byte load runs lower. I think I posted a comparison somewhere. My recollection is that if calcload is around 275, then 2 byte load is around 240-250.

Edit: I found my plot:

 

Thanks. It seems to me that the numbers from the 2 byte load are closer to the numbers from the airflow/rpm*852 load formula than the loadcalc formula. I have noticed that the loadcalc formula has consistently read higher than the load airflow formula. Am I correct in this assumption?

 

The problem with any calculation is its only as good as the data your given..

2 byte load is the actual unclipped load value from the ECU, so it should be the most accurate.

ECULoad (1C) is a 1 byte value that tops at 160
Airflow only reads to about 1609hz
RPM is "Choppy" due to the steps in the scaling.

Loadcalc was innacurate because of something that was never addressed which I had recently addressed in then new version of Mitsulogger..

You have to take a variable amount of injector latency into account based on Battery voltage.. So you generally have to find the value of the latency between 11v and 14v. Since I added this new value, the load calculations are reading much more inline with the 1C value (until it clips at 160) which means its much closer to being accurate.

This isn't so much of a problem if your using the Evoscan calculation with stock injectors, but altering injector scale in the ECU had a pretty significant affect on the calculation, and the latency being innacurately represented could represent about a 8-10% error in itself.

again, your at the mercy of the accuracy of the data you have to base your calculations on. But if you cannot modify a rom for 2 byte load, for whatever reason, then you have to decide which of the calculations work best for you. So far it seems that the revised formula I added is much closer to the true load.