so, i'd like to think that i am somewhat of an authority on the subject, but i've come across a lot of errors on both the GM and tuner/hacker side of 8F...

for instance, there are a lot of options in the available XDFs that do literally nothing. there are tables that are incorrectly described and labeled. there are scalars and tables that aren't in any way utilized in the code. there is some interesting code to control the fan due to being at a high manifold pressure for long periods of time that i haven't seen available in any tuning package. there is a table that does absolutely nothing, yet i've seen some of the high dollar tunes have purposely changed values in it. the factory calibrations have absolute crap fueling, running into overflow when the VE adder and main or idle VE is combined as they are in the code, which then get cut down to d255 anyways. the fact that the barometric update function is entirely disabled in the code. the shift light values being populated but not used. the intake runner temp calculation that appears to function, but at the end of its subroutine, all of the values are scrapped making it a waste of time.

things like this cause problems if they're not made aware. so, i'd like to extend an offer: anybody that has any questions specific to 8F, be they assumed to be true or outright myths, ask. if anybody else has solid info or cares to refute what i have to say, feel free as well.

i already have an 8F BIN disassembled and commented apparently further than anyone else ever has that has released their work publicly, so now it is down to putting it all into an XDF that doesn't have so many errors to fix. and as much as i may regret doing it, i may even patch 8F to use a 3BAR properly, though i'll just state that there are probably better options out there if you're pushing that much pressure.



takers?

Very interesting post, I honestly wish I knew more about this to comment intelligently.  I've been wanting to go to the EFI university class, but none have been offered locally since I returned stateside ( I'm Active duty Army). 

Please continue sharing your knowledge as I for one am interested. 

Cheers,
Thomas

i'm sure i'll have plenty to post soon enough.... there are enough bugs i've caught already that i'm sure there are more hidden in there.

Yes it has been documented that 8F has a ton of error's/flaw's but considering the time frame and having more than one engineer the project turned out fairly well (hack not so well). I am glad to see someone with interest in the definition/.bin but in all honesty by the time you are done there will be no need to call it 8F as you will have changed so much it will be your's. Many years ago I went through the same process with making 8F better. I found it to be extremely time consuming/frustrating and with the potential to completely ruin my engine I decided to go a different route(never try experimental tune's on a customers vehicle). I have made some changes to my own definition and with 300 TGP tunes under my belt I have a very good understanding of 8F and it's routines. For my customers that make good power and would like 3 bar support I recommend dynamic efi for their needs. Simply re-pin the harness and have 3 bar support at your fingertips that is completely safe.  Just out of curiosity who's high dollar tunes are you referring to? lol  Also how do you confirm your results? Back in the day we had to build test benches and what not.

i'm really only completing the XDF for others use really.... my purposes are limited to grabbing stock values for importing into nAst1, after which i don't plan on ever using it again.

as for who's calibrations, no idea. i don't ask when someone says "i have this chip, can you copy it for me so i can have a spare", i just do a quick compare to a stock BIN to make sure nothing looks corrupted(i've had a few of those pop up) and send them on their way. have noticed a few patterns over my time of doing it, a lot of unique but similar changes and some that you can actually track the lineage of back to what i'm told is a TG160 calibration. whether or not that is accurate, i'll never know.

and i've had my testbench for nAst1 built for quite some time... before that, i tested code out on the wife's 90GP. pretty simple to drop 8F into it, just have to disable a few codes and it's ready to go. more on that in the next post, which may or may not hit the character limit for a single post.

8026: coolant temp threshold to add power steering cramp spark advance. populated, but not used.

8028: barometric update RPM threshold. populated, but not used.

8029: barometric update D-TPS threshold. populated, but not used.

802A: barometric update rate. populated, but not used.

8050: MPH threshold to allow ESC. populated, but not used.

8052-8053: empty values.

8056-8070: pseudo baro update table. populated, but not used.

8071: max map offset for baro adjust. populated, but not used.

809B-809D: empty values.

809E-809F: populated, but not used. no obvious use of what they could be.

80B2-8108: shift light values. all disabled except for 80C7 and 80D9, which are used to determine gear for gear specific EGR multiplication.

848F-8493: DTC flags.... most are permanantly enabled in the code, meaning switching them off won't disable the DTC checking process. to disable them, would need to branch past individual codes via patches. codes that aren't perma-on: 22, possibly 42, 32, possibly 43. the other way to bypass them would be to change the values they're compared against to into a range that can't really happen.

84E4-84E5: populated, but not used. no obvious use of what they could be.

84E6: options byte. bit 2 controls if a power steering cramp will disable a/c. the rest of the bits are onvolved with forcing certain outputs on. b6 will force EGR to be always on or off(looks like set forces always on). b7 looks to force the SES on. from the looks of it, it is used to form byte 49.

84E7: more forced outputs.

84EC-84F5: populated, but not used. no obvious use of what they could be.

8515: FACTOR FOR DECREASING C/L INT DELAY DURING DEFAULT MAP OPERATION MALF 35 PARAMETERS. doesn't appear to be used.

855B-8561: populated, but not used. no obvious use of what they could be.

856F: launch mode EGR gain. doesn't appear to be used.

864E: options byte. if bit 0 is changed, the code can attempt to jump to HUD algorithm, which will cause problems. same with bit 1. bit 2 controls the alhpa-n fuel calc at idle. doesn't control when in other situations though, those have to be dealt with using the scalars. bit 4 controls the 7th injector function. don't mess with this, you don't have the goofy cold-start injector that was used or planned on being used on the early MPFI 60V6s. bit 5 does nothing... it's supposed to select between MAT and calculated intake runner temp. but it loads MAT no matter what is selected. but intake runner temp isn't calculated either, so that's why. bit 7 won't matter since it only controls shift light vs TCC operation and shift light is non-functional anyways.

864F: options byte. bit 0 controls a lot of EGR functions, changing it will break a lot of functions.

8650: options byte. bit 2, more fun EGR stuff that shouldn't be changed. bit 5, more injector 7 stuff, don't change. bit 6 is W-body A/C, this is for an additional low pressure check, if you disable it, it will take out one of the checks used to disable the compressor.

8651: options byte. bit 6 is indicating whether or not an A/C pressure sensor is present. it's not 100% functional(doesn't ever read the pressure sensor a/d channel), so don't turn it on.

8652: options byte. bit 0 is more HUD stuff, don't change. bit 6 changes knock sensing and some ALDL operation, don't change it.

8653: options byte. bit 7 controls whether or not to calculate intake runner temp. it doesn't work, so don't bother.

8672: COLD MAN. PRESS FILT COEF (DECEL ENLEAN). populated, not used.

8674: HOT MAN. PRESS FILT COEF (DECEL ENLEAN). populated, not used.

86AF-86B1: GM's dirty little emissions trick that didn't quite function as intended. the first two values form a window in which the maximum AFR will never be limited. the temps used are a small window around where the EPA would have started it's city MPG/emissions testing at. the max AFR that is used is 17:1 though, so it looks like it was never effective.

86C0-86C1: populated, but not used.

86C8-86CA and 86D7-86DA: 7th injector items, don't bother.

86D6: coolant offset constant. disabled due to no intake runner temp calc.

86E1: table, unknown function. its result can replace the calculated airflow value.

8895: base pulse constant for inlet temp. normally, if you had a mask that would calculate intake runner temp, it would use that value here, instead, raw MAT is used. because of this, i don't recommend using an air temp sensor that isn't mounted in the manifold itself when using 8F.

8A06: manifold runner temp target coefficient. because of the disabled intake runner temp calculation, this table is useless.

8A17: lag filter coefficients to filter inlettemp. same situation as above.

8A28: coolant offset multiplier. same as above.

8AFF-8B03: not bugs per-se, but highly misunderstood. here are a couple of values that can richen up the target AFR when in PE. here is how it works: normal target PE lookup is done. then these values are tested to see if AFR should be richened further. 8AFF is compared to current MPH, if above this MPH, continue checking, otherwise disable additive PE fuel. now a timer is checked to see how long you've been in PE and above that MPH threshold. if not enough time has passed, then no mod to AFR, and then MAP threshold is checked to see if timer should increment. if above the threshold, it runs up to the timer, if not, the timer stays where it is at. so if you're in PE, but not above the MAP threshold, it freezes, just something to keep in mind. anyways, if all of those requirements are met, then the value at 8B03 is subtracted from the target AFR to richen it. factory values are to richen the AFR by .2 if above 70MPH for 2.56 seconds with at least 84kPa MAP.

8BB6: additive correction to INT delay at idle. populated, not used.

8BC1: prop counts gain when idling. populated, not used.

8C49: idle gain table. PITA to explain, so i'll copy/paste my notes from A1:
table actually uses a coded value for lookup.

b0 set when there is high rate of RPM change
b1 set when idle speed error is higher than 8C47
b2 set when RPM is rising(b2 and 3 may be reversed)
b3 set when RPM is falling
b4 set when idle speed is lower than desired
b5 set when idle speed is higher than desired
b6 set when 80Hz logic has determined O2 says "lean"

it's not easy to deal with due to it being a coded value.

8D98: manual trans byte. serves exactly one purpose, which is to skip comparing idle speed error to the 8D37 byte while moving. when at 0MPH, it will always be checked.

8D99: throttle follower offset for manual when moving. not quite. it's used regardless of transmission selected and is always used above the MPH found at 8D36. 12MPH in a stock cal, so if you have an issue suddenly start/stop there, that's why.

8E81: populated, not used.

8E83: table.... that does nothing. never called in code. may have been used during early code testing for some purpose, but nothing that made it to production.

8EDA: initial wastegate DC. for a long time, this has been "vs TPS".... well, it's actually vs RPM. not sure how that happened, but i bet that was an interesting result when people changed it.

8EEF: interesting table here, used to turn the fan off after a long period of MAP being very high(indicating being in boost).

8EF5: and the compliment to the above table, this is what turns it on. seems to control fan 1. the thresholds for when to enable are at 8F13-8F18.

8EFB: bit 7 controls whether or not an optical or magnetic VSS is in use.

8EFC: populated, not used. value it holds would imply some type of spark advance bias.

since i'm at the boost section, here is an interesting thing to realize: when it comes to boost, the ECM considers anything above the baro read to be boost. so if you're at a high enough elevation to only be at 50kPa baro(that's pretty high, BTW) and have 50kPa setup in your boost table, you'll only get around sea level atmospheric pressure in the intake(100kPa), not at the 150 kPa you might expect to see. so, the ECM uses the MAP sensor as a relative sensor when it comes to boost target and control... something to remember.

oh, more fun stuff: 8F will run differently when used in a 16149396 instead of a 1227727 or 1227730. there are quite a few values stored to and read from the SRAM that the 9396 got and the 7727 and 7730 didn't get. EGR populates a lot of that area.



and that is everything i have found so far. i'm pretty sure that is everything, other than the typical "the stock tune is crap", which i won't say is wrong. there is also the issue of the XDFs floating around using incorrect conversions, which also needs dealt with.

I can see you are much better reading code than I ever was. Thankfully I had help from people as talented as you back in 2005 when I was really into that kind of stuff. I would half to go back and look at my results to see if we got everything like you did. None the less good luck with your project seems as if your are very able to finish it correctly. All my tunes have an atmel 29C256 eeprom so they are not hard to identify.  :icon_mrgreen:

hmm.... not too many of those have come across my burner regardless of application, lots of reprogrammed 27C256 and an occasionaly 27SF512 soldered in it's place, something i do a lot of when necessary.

 :twitch: woah... last i talked to jeremy (previous owner of car) he was planning to take it to mc racing in ks which i guess was the only place willing to tune the car and switch it to a 3 bar map but he told me that would cost around $500, cool project GL with it!

done properly, using a 3BAR in place of a 1 or 2BAR MAP is all done through code changes alone, no calibration changes necessary. i already have all of the code necessary to do so from doing it in nAst1, so there isn't much new that needs done.

done improperly, as in just plugging it in and attempting to adjust the entire calibration to make the ECM happy, it will never be right.

I know a few of the chips I sent you were (to best of my knowledge) OG TG160 chips. I think those were unique in that they were UV erased stock eproms updated with his tune.

and the one I most recently sent you is that Kenny Hottune chip(i think???). (have to reply back to your pm on w-body yet) But, and perhaps Adam can verify, that he was a lot of the brains behind those chips.

Edit: searched the guy I bought the car off of's posts, the chip I sent you lately, Rob is indeed a Hottune chip

in any case, i do have a neat little archive of them building.

Yes I helped Kenny tune his 5 speed TGP back in 2005 shortly before he opened KAZ Motorsports. I named his tune the "hottune" that he ended up selling for 400+ dollars. I also know for a fact he was not using TGP or even w-body memcals to burn his tune onto because I donated about 10 of the chips I had laying around. Not really sure how you came about this information as I rarely spoke of it. It did piss me off a tad but at the end of the day I tune for the challenge not money!!  ;)   Also I'm still tuning not sure what happened to him...

I don't even recall where I heard it to be honest. I wish I knew more of what you and Rob are talking about, but at some point soon I'll be moving to the HotTune chip again.

If it makes you feel any better mine came in a $700 TGP  :laugh: I do remember thinking it insane that he had a $400 price tag on that chip. Which IIRC has a SST memcal soldered on it.

I remember he (Kenny) had a bit of falling out with the community at large and ended up getting completely out of it.

I was never upset with Kenny, if I was he and this forum would have known it. I'm pretty sure Kenny used the SST soldered in as I was and still use Atmel. Literally got thousands of them back in the mid 90's from a missile silo out west being decommissioned.