Do you want to use this for the WG activation/deactivation table:

 

WGDC Limit During Fault scaling should be WGDuty16 (not WGDuty) and it should be word aligned.

 

Pd1, I was kinda sticking with non-hack stuff because everyone does things differently. The MUT table is present in all the ROMs, so that makes it easy to do the 2-byte mods (provided that they follow the instructions).

Anyone: Do any Evo 9s have ICS hardware? If yes, then I'd like to keep the ICS defs in the evo9base file. If no, then I'm all for tossing the ICS stuff.

teph, definitely a good idea to use the right byte length for lean spool enable/disable. I hadn't noticed what I was using.

I suppose I'll be vetting them, but I don't really want to. That's time I could be using to do other more useful thing. I hope that the base files will largely determine the layout.

 

yes my EvoIX has ICS - I mean leave it in evo9base.xml, but remove it from 88590015/88840017 etc etc xml's

I think if everyone does a good job of going through their own XML and submitting it then it shouldn't need vetting!

Also we really need to the ICS names updated as its still confusing - latters thou I guess

 

Ah, yeah, I forgot that I left those in there. No problem to remove them.

I was kinda limited on time and wanted to get something out the door relatively quickly. If you have time though to make further changes to the base xml file (remove table #2, fix up WG activate/deactivate, lean spool enable disable, rename ICS tables, etc) that would be great.

Got business travel tomorrow, so probably can't do anything more tonight. Might be able to jump back in tomorrow while travelling. If you can post an updated base xml file, I'll modify the 8859's to fit. I may look at trying to make an evo7base.xml file from the evo9base.xml.

BTW, for the time being, let's call the new base files evo7/9base_new.xml.

 

I didn't mean to be rude or sharp... Just trying to get the info across as quickly and efficiently as possible

I will post up a revised evo9base_new.xml (I assume colby will rename to evo9base.xml??) soon!

 

What does everyone think about ditching the "knock sensor filter maps"?

reasons:
a) don't know if they are defined properly
b) confuses people
c) shouldn't be modified by 99.999% of people anyway's

 

ok here are my revised evo9base.xml and 88580013.xml as an example.

I have commented out the knock sensor filter maps, in preparation for their deletion

 

I'm ready with 88840016 and 17, but I thimk I will wait for a final evo9base...

 

yeah I know - its a bit annoying

 

Here is my EVO 7 99860002 definition file.
The MUT Table is included and some tables have corrected ROM Adresses. The ALS Tables are added.
Not every Address is checked, but it is better then the original xml File.

 

No prob. Didn't come across that way. Also trying to be quick. :-)

Attached is a revised version of the evo9base.xml file that tephra posted. A few more items are fixed up, and also I found that some of the tables in the ROM xml files had table data details that belong in the base file, so I moved that data over to the base file.

I'm in favor of leaving the Knock Filter tables in the definitions because I think the ultimate goal is to provide as much information as possible, and the knock tables could be useful for someone trying to tune a non-stock bottom end. Even if the tables might be wrong, its probably worth leaving them there as reminder/placemarker.

 

MrFred-

Are you posting these base9 files for us to put into our ecuflash or is this going to be implemented into a new down loadable ecuflash version? Some of this stuff in the base files are killer and I could definitely use...

-E

 

These will be included in the next release of ECUFlash. I don't recommend installing them now unless you are helping update the definitions.

 

I couldn't come up with a definition if my life counted on it... I just know the definition of definition illiterate...

I'll wait for the release... Thanks for all you do for us!!

-E