I dont know if this will help but I could not get mine to work until I ran notepad as administrator and then saved the files into the ecuflash directory and not into the rom metadata file itself. That worked for me. Flashing will take a long time so do not attempt to log out. I did then cancelled the action and now can not read from my ecu. I can write to it(changes show after flashing) and open port works with my logworks though. I am still trying to figure that out though. Good luck getting it to work its worth it.

 

mrfred is right. I will add though that I don't have a problem with just changing the name but i HAVE to change it to something like 8859-BAK-0015.xml ... not 88590015.bak or 88590015bak.xml ... the trick seems to be breaking up the digits. OF course moving the file out of the directory is the best sure fire way to avoid any conflicts.

 

I'm not even trying to add MUT manually, anymore.

I have wiped out 1.34 entirely, all the shadow copies Vista keeps, all restore points, all the asociated files, emptied the recylce bin, done a disk cleanup, removed any trace of EcuFlash, all xml files, all php files, all temp files, full shutdown and reboot and installed 1.40 and yet it still won't inherit Evo9base_2xxx. It only inherits Evo9base. Man, what gives? I don't know where else to look. I'm gonna wipe out my entire ROM ID database, I guess.

Works perfect on my XP desktop, inherits only Evo9base_2xxx. Obviously, I need it on my laptop. ARRGGG!

 

Anyone got a fresh and completely untouched 88590015 hex they care to share?

 

Thank you guys.

This is how I finally resolved it. I created a custom metadata directory away from where EcuFlash stored it as recommended and EcuFlash FINALLY quit referencing the Evo9base file, (even though the coding instructed it NOT to in the first place.) I put the 2 xml definitions that I wanted and the parent xml that I wanted (Evo9base_2xxxx) and it is working like it's supposed to. So far.

I even deleted the base file before I created a new directory and it still referenced the base parent xml (even though it wasn't there) and greyed out all the mods in the evo9base_2xx. Wierd. It had to be Vista. Nowhere in the updated xmls that come with 1.40 did it instruct it to the base file, only the modded base. Somehow, as mrfred suggested, EcuFlash was referencing a duplicate set of <include> commands that weren't there, or that I couldn't find or both.

Anywho, thanks for the suggestions. I have all my orginal hex's, I'm happy. Seems to be working. I'll be entering MUT addresses and doing the jdm map mod, so hopefully it works with the way I have it set up.

 

I'm actually starting to wonder if (as was suggessted) I saved a duplicate 88590015 originally, since it was the first one I was working with, and it had the original instructions and that was what was being referenced, since it would have been saved in the same directory. Sounds like you guys hit the nail on the head. Again, many thanks. I'm just baffled as to why I couldn't fix it by deleteing it. I even delted the so called "shadow copy" that Vista is known to store.

I hope I don't have problems every time I try to add code.

Any suggestions as to how to approach it?

No matter what, do I save any updates to the code in different locations and then move them as needed, like I did here, essentially - that being the moral of the story?

Anywho, off to enter MUT addy's.

Thanks again guys.

 

I have been running into this problem everytime I do it with vista. I have not tried it with a different opperating system. Good news is now that you have a good directry to put them into you can put new ones in the same and it should work. Let me know if you figure out how to get the changes to express with out playing with the dir.

 

MUT3D2byte up and running!

Thanks to everyone who has contributed to make these mods a reality!

Changing the directory seems to be as simple as putting it in a different folder. Future mods will confirm this, hopefully. I'll save anything new into that new folder and change the directory.

Out of necessity, I actually had to roll back to 1.34 because of the 2.0 cable driver causing issues - I use a 1.3 and simply cut the 2 updated xmls I desired and added them to the folder, using care not to include any of the 1.34 version Evo9base, nor the 1.34 88590015 non-MUT3d 2byte xml.

It's referencing only the 1.40 Evo9base with the updated xml as well as the 1.40 88590015, again with xml updated.

Thanks again to all!

 

Hello guys,

I gotta say I'm kinda lost with all that 2 byte stuff... I'm tuning an EVO 8 with a 96530006 ROM...modified with Tephra's latest V5 pack. And my main problem is to know which load value I should log to have the most accurate map tracing tables (to match ignition and fuel tables).

Beside that, it seems that the 2 byte load is needed in order to go above 255 in load value...as far as I have understood. Right?

So, using the Tephra pack, I've chosen a 2 byte to 1byte load factor of 1.2 which seems quite fine for what I need.

When I log with Evoscan, my "load MUT 2 byte mod" values are slightly lower than the "calculated load"...Nevertheless, is it the one I should rely on?
But anyway, both of those load values seem kinda low in regard to the boost I'm running... Is there a value/factor which needs to be changed in Evoscan to match the 2 byte load factor of the Tephra mods?

Thx for making things a little bit clearer...

 

you can either use LoadMUT2Byte or 1byte load.

if you are using 1byte load you need to get the xml for evoscan from my thread...

 

Ok so I just need to paste the modifier 96530006 xml file in the evoscan directory (C:\Program Files\EvoScan\EvoScan v2.5\ROMS)? That's it?

And it will be ok to read the proper load value? Great...

Thx Tephra.

 

This load thing is driving me crazy...

Evo 8 fitted with several mods including an Evo 9 tubby, pushing 1.5bar up to 5,500rpm and then gently decreasing until 1.35 are reached at 7500rpm...and the max load reading I have on evoscan is 240 something!! It seems kinda low IMO...

Nevermind I rely on "load MUT 2 byte mod" or "load 11bit4", the reading are exactly the same...

Running with the AVC-R on "off", I have approx 1bar to 1.1bar boost and a max load of 200-210... which is ok when compared to the load value I have running more boost...but which still looks low.

What do you guys think about that? Am I expecting too big load values (hence my surprise) or is there really a problem in the readings I have?

EDIT: changed the values in the 3D MUT table in order to have 2 byte load... Helped a little as the max load value I now have with my AVC-R off is 225... But I still can't go above 240-250 on B mode...
Should I change the load factor in the Tephra's options?

note: with std xml and non tephra modded bin, I was easily hitting 255 on load 11bit4...

 

96420011 MUT 3D address = 3a0bc.

 

anyone know the evo IX 88590013 mut address and 2 byte load? thanks in advance.

 

Honestly I think the newer 1 byte load from Tephra's version 5.10 patch makes life so much easier. It just combines the 2 MUT load bytes together into one loggable byte, then just add the extra definition into EvoScan and voila!