Z69

Some back ground:]Old threads

Note: all initial testing done with the stock aujp tables.

L006F is the mass of air per cylinder.
The calc is basically: cyl vol/Temp * Map * VE. Or PV/T *VE
Go to the previous page of the anht hac to see the calc.
The temp term is calc'd using the MAT A/D inverted and referenced to the limited airflow calc at L006b. Along with the CTS. This temp term is stored at L006D and improperly labeled Inv MAT in the hac. Do a search on L006B to see where else the limited air flow is used.
MAT calc explained

So basically it's L006D * Map-EGR * VE = L006F.

Then it's (cyl air mass) L006F * Final AFR * Injector constant *2 as seen in the code above.
This is where the PW gets limited in calc LE424. Or L006F * FAFR.
It's easy to see on the bench. Just put L006f in the data stream and monitor it and PW. You'll see PW stop increasing even though L006F is.
If you do some calcs, you'll find that The injector constant is smaller than the Final AFR in a lot of instances. The Injector constant is an inverse term or 1/lb/hr. So a bigger injector has a smaller constant. That means if you swapped the multiply order of these two terms, FAFR & Inj Const. It would raise the limit at which PW is capped.
In fact, on the bench I was never able to get the PW to CAP again after I switched the two LDX addresses in the code above.
Even with a 502 and a 22lb injector.
I made L006f as large as reasonable by testing at 32f for MAT and CTS with WOT and 98.4kpa. The PW always followed the VE table and never maxed out while L006F continued to increase.
I also changed the VE to verify a change in PW.
This may cause some loss of resolution at low rpm, but I was never able to get L006f to go to zero. I tested at 227f cts and 164f mat and 500rpm with stock tables.
And since the limited airflow is used in determining L006D, it may require some low rpm VE adjustments or changes to the MAT tables.
But I don't think anyone needing the bigger injectors will notice the added tuning required.

Note the stock aujp bin will cap the PW at 3200 rpm when MAT and CTS are 32f. This is also the max ve in the stock table. But I didn't see a normal temp of 195 cts and 100 mat causing a cap with the stock bin until above 383 cid.
I only tested at 408 though.

ok, where's that flame suit


oh yeah, the new code at 4C81 to 4C88 no offset:
FE 84 1C BD E4 2C DE F1

JP86SS

iTrader: (1)

What did he say?
I've translated to Dinglish

SWAPPED THESE TWO LINES and it works.

Thanks Scott for not giving up.

Craig Moates

Well done!

92Z-666

iTrader: (2)

Indeed, nice going. I've been just barely bumping that cap for a while (406ci/32's/LT4HOT/SR:5400 redline), and I was planning some dry N20 this year.

I'm sorta bummed that I didn't get to finally nail that one myself. I put 3 hours into it last year. I just ordered an Ostrich too... to help with that and the N20 tuning.

Now, I don't mean to hihack the thread.. but one thought stands out here. GM missed this for.. how many years? It stands to reason that it never came up on any 350CI or smaller engine w/ factory stuff.. but you'd figure SOMEONE knew this by now.. the aftermarket maybe?? How about the GM partners like ASC Mclaren? They did ALOT of p4 stuff some with Turbos. I'm curious wether any factory GM or aftermarket chip has the execution order the way you do now. Lets PETITION..someone send the code to GM for verification and ask for a memcal revision! LOL.

Your outcome..is explained very well and makes enough sense that I'll burn one in the spring. This will get me into the quick-8 at NFME Memphis 05 I PROMISE you. (I missed it by ONE PLACE last year - street-tire)

Again.. Great effort... despite some of the constructive-ish feedback you and the others endured. Be assured at least one person will have great fun testing it out! I'll try to do some cruise-VE tuning runs with the motor AS-IS to see the effects on VE as a pure SINGLE point of change.

It'll be a while.. someone will beat me... I have not caught up to things I needed to do LAST year yet...

gta324

Something to implement in S_AUJP ver3?

/N.

ED89

Would the fix apply to the ANHT bin as well?

Ed89

Grumpy

It just wasn't a concern. The code did what it was supposed to do, there was no reason to *waste* the money to *perfect* it.

How many years has MS milked the computing world for new and improved versions of Win, when in fact it was just as much about eye candy as anything else.

drive it

iTrader: (1)

Would 4C81 to 4C88 be the same address for all 8d? Y and F?
Thanks!

JP86SS

iTrader: (1)

It would be close to there but look for the pattern of codes to locate it exactly.
That's the best way to be sure.

ED89

I reviewed the hex file/code for ANHT and AUJP and found 2 differences between the two. One is location (thanks for the advise JP86ss) and the other being $24 vs $2C.

ANHT LOCATION
4C79-4C80
DE F1 BD E4 24 FE 84 1C(original code)

aujp
4C81 to 4C88 no offsetoriginal code)
DE F1 BD E4 2C FE 84 1C

Since I am just getting going with my first patch. How big a difference are the two values? What does that difference mean?Will the patch still work?

Thanks in advance

ED89

92Z-666

iTrader: (2)

Its a big enough difference that the car won't work well, if at all (might go into backup hopefully), if you change that byte to MATCH any of the other chips patches, or if you insert the originally posted patch ditectly in place. The original patch is for ONLY the chip listed... and for chips that have the original code and subroutine in exactly the same memory(prom) location.

The 2 programs have this routine, and that subroutine in different locations is all. You can alter the original patch to work.

I'll give someone else time to give you the answer in bytes.. (or/and to flame me).. Its dinertime

I'll be back...

{edit} ok, I'm back.

If you find that code section and reverse the positions of the "DE F1" and the "FE 84 1C" you'll get the same results for your chip as the original patch listed. Leave the other bytes that are specific to your chip ALONE.

One problem (in a pure coding sense) is easily seen here.. there are 2 bytes in one instruction and 3 in the other. We don't just *****-nilly go and do this without making darn sure that NOTHING in the rest of the programming points to, or jumps to, a location that includes most of these 5 locations. Example if 20 bytes earlier there was a JMP to the FE841C instruction in the FACTORY chip, it will now land on an opcode that means logical garbage, and possibly instructional opcode garbage to it (4CDE) and crash may ensue. (sorry 4C opcode escapes me)

Respecting the abilities of the folks involved here I'm not going to even check to see if that is a problem. honestly... but to those reading this as a guide 'how to patch' .. don't simply follow the technique blindly. 'swapping bytes' and 'shifting position' of bytes in programming without a compiler is for the pros and the stupid :P For this reason I say again.. what he's researched and posted is generous.

Z69

LDX- LoaD address or index register X. It's a 16 bit register.

DE F1
DE is the op code for LDX w/ direct addressing
Basically means put 00 in front of the next byte listed. Which is used to load the ram address/location 00F1 to be used in the following JSR(BD). The actual location of the subroutine will vary with the bin.

FE 84 1C
FE is the op code for LDX w/indirect addressing mode.
Means use the # stored at the location listed in the following 2 bytes or 84 1C.

I'm not very far along in asm, but as posted above I wouldn't go changing things "***** nilly". I wouldn't do this as your very first edit. That said...
Check your code out above and below and compare it to anht or aujp. There are other posts with references to op code listings to help you "decode" what your seeing. Do what ever makes you comfortable. As I take no responsibility for any changes someone else makes using a hex editor.
And this is a really easy edit so I don't see the need for a patch.
One of these days I'll get around to one of the manual bins to see what if any difference they have since I actually need t o use this mod for a 6spd 468.

11sORbust

Do you think there is a reason they inversed the injector constant?

Is this the right changes?

Thanks!

dimented24x7

iTrader: (2)

The injector constant must be inversed in order for the equation to make physical sense.

With MAF, the injector duty cycle is (airflow rate/total max fuel flow rate of all injectors) x inverse AFR.

With SD I think its (mass of air per cylinder/max fuel flow rate of the injector feeding that cylinder) x inverse AFR = injector pulse width.

As you can see, with both systems the injector flow rate must be an inverse since your dividing by it.

As for the pulsewidth limit, basically the mass of air/cylinder x the afr can result in a result that is greater then $FFFF? Am I reading that right? Nice work finding that, BTW. It looks like a subtle but very important interaction in the code.

ED89

92Z-666 and z69

Thanks for the responses. It has been very informative.

I will compare the codes and decide.

Thanks


ED89

92Z-666

iTrader: (2)

I started with my factory 305 5-spd cal originally AXXC. (I'm running a mild 406/T56.. I make the metal 6-speed plates BTW :-) ). The fueling code in that area is identical.. for purposes of the mod.

AXXC 4C80:

96 65 13 64 FF 03 CC FF FF DD 6B DC 6F DE F1 BD
E4 4C FE 84 1C BD E4 16 59 49 DD E2 CE 00 E2 96

Z69

Do you think there is a reason they inversed the injector
constant?

Division eats up a lot of clock cycles. The most of any single instruction I think. Read something to the affect of "DIV is bad in asm" So if you can do the math prior to the cpu...

They go so far as to use tables to invert the MAT. Not sure if this is the only reason though.

And it's A / F. Or look at the units of each factor. Need to end up with seconds at the end.....

I wasn't too worried about the manual bin fuel stuff.
Just the throttle follower and any other differences they have.
Thinking along the lines of a S_8D.bin.

92Z-666

iTrader: (2)

Hey just wanted to chime back in, I tested the fix on my real live working big-cube car and it worked exactly as advertized. Like I said in an earlier post: I had been brushing against "the cap" ever since gaining some exhaust efficiency and I was able to see in a WOT (and WB) scan that I have a touch more commanded fueling and the flat-cap on my commanded-PW graph is now replaced with up to 0.6ms worth of smoothly transitioning humpage.

Cool. I'll be re-tuning VE and Idle and will report any worthy feedback.

Moates "ecm852" (csv file) data of the 2 WOT runs is available to interested parties associated with this particular thread.

Thx again Z69.

dimented24x7

iTrader: (2)

I was thinking about this, and I suspect there was a reason for it. As stated, the inj constant can be smaller then the final AFR so GM may have done the calculations in that order to reduce any error (rounding, resolution, etc.) that may accumulate when the pulsewidth is calculated. I dont know what the values normally are so I cant say how much but I suspect its probably nothing to worry about.

I have something similar with the code Im using. I have to do the calcs in a certain order or large ammounts of error can accumulate from having small results initially. Even though doing things in the order that I do them in could possibly result in an overflow early on, the cost of that is small compared to all the error Id accumulate by having the pulsewitdth dwindle down to nothing right after the first multiplication. The likelyhood of this happening though is next to nill. Would require lots of airflow at a very low RPM.

The way I chose to do it has the pulsewidth very large at first but with each calculation it gets smaller and smaller. The other way around would have it start off with a value of maybe decimal 10 or 15, rather then decimal 15,000, and getting larger. There are no .3's or .7s in binary. Its either 1 or 0, so all those little bits and pieces add up.

junkcltr

iTrader: (1)

Was it really missed by GM?? What happens when you through some bad sensors into the equation??

Also, as pointed out in the initial findings.....if you get range, then you lose resolution..

BTW, excellent work Z69.

92Z-666

iTrader: (2)

From memory.. failed sensors are generally picked up as err-flags and some middle default values are substituted, or the max may be used (thats what you may be saying but i never seen one of those specifically but I'm not into the code like I used to be)

I really wonder about lnigenf*lter and the others who did big cube swaps in the 90's.... now wheres that chip I used to have....

Yep I see your point. The factory stuff could be considered exactly appropriate given the target C.I.D. range and other variables. This would bring us to consider an alternate cure... one more in line with your statement. Perhaps either:

1. The use of a 16 (or 9) bit memory space for the 6b value, or

2. detection of overflow of 6b and the subsequent storage of the remainder, to be used just after the reading of 6b.

I like Z69's method.. the one thats DONE and "good nuff"(tm)

TRAXION

Way to go Dayv Also, for the record Z69's fix is in the S_AUJP VERSION 3 file that will be posted later today (3/22/05).

Tim

Z69

Don't know for sure, but if the SD calc was used in a 4 cyl. BCC, then underflow would be assured I'd think.
Did this calc originate in a V8 bin or a smaller engine bin?

junkcltr

iTrader: (1)

Same thoughts I had about the smaller engine stuff. My earlier comment was made with that in mind. I think the change that you made is great for the V8 stuff.

If someone was interested and had the time, then the result could be checked for under/overflow and shifted accordingly before it is returned to the caller.

89 Iroc Z

Just for clarity the original AUJP values that need to be changed are “DE F1 BD E4 2C FE 84 1C” correct? I just want to make sure I don’t change the wrong thing.

Z69

As quoted above, these are the original op codes as they would be seen in a hex editor at the listed locations.
You can see an actual picture in the post above by 11sOrBust.

Change it to read FE 84 1C BD E4 2C DE F1 instead for aujp.
Change it to read FE 84 1C BD E4 24 DE F1 instead for anht.

The difference is due to the location of the 16x16 routine being different in the two bins and the actual code is in a different location too.

92Z-666

iTrader: (2)

Just got through 2 passes worth of cruise VE tuning and my cruise area needed about 5-9% of VE reduction. Take that as a data point, not as a guide for what to do blindly. No other changes to the vehicle other than some WOT tuning prior to this test.

Attached(hopefully) is a table showing the amount of change (1.0=no change.. or no data collected during the logging so ignore those.)

Anyone else tesing? I'm curious if its not just the really cold air messing with me.. don't think I've ever tuned VE in the cold.. might have some coolant based corrections to make :\

{edit: I dunno why the image below has so much whitespace don't flame me the image, as saved, does NOT have all that whitespace below it }

Z69

From the bench testing I did.
The colder the mat the the more likely to hit the PW cap.
This was at WOT though.
The calc'd air flow, sorry name won't come to me, reaches 255 faster with a bigger cid.
This calc air flow is also used for the mat comp counts table.
Which is what adjusts the Grams air/cylinder based on CTS and MAT.
And if you've moved the mat sensor.....

Maybe Traxion will post some of his results....

TRAXION

Bench isn't built yet and I have no f-bod.

92Z-666, FWIW, it VERY well could be the colder air. Do you have a relocated MAT?

Tim

92Z-666

iTrader: (2)

Absolutely not. I'm of the opinion, in general, that the engineering done on the ECM's sensor locations need to NOT be jacked with.. especially the MAT. Its close to the valve for a reason. Folks have made alterations to be able to move it, and thats fine for them.. its just not fine for me.

I know part of the changes seen in my VE are caused by the environment..(I should say, by my inattentiveness to the coolant and IAT modifiers for anything other than warmed-up summer air).. just wanted others to consider ALL things and think about it more. I'll re-check as it gets warm.

PS Trax.. I've got a spare F-shell u can borrow just gotta have it back in 4 years

TRAXION

92Z,

I'm one of those who relocated it. The obvious reason was because of the MiniRam. However, I actually relocated BEFORE I had the MiniRam. I relocated it in order to see the ACTUAL incoming air temp instead of the heatsoaked temp due to the sensor location. It's a pretty straightforward fix with regard to the MAT tables to run a relocated MAT .... of course, IMHO

Another F-Shell? What about the one in the 'other' garage? Did you get a third? I'll have my garage in 6 months or so. My next F-Body will be a street legal but fully stripped road racing car Can you say no interior except for 2 seats? I can. I feel the need to turn my wheel instead of driving straight for 1/4 mile

Tim

92Z-666

iTrader: (2)

Trax, yea like I said others might go ahead and do it and modify table(s) but IMO its more correct to HAVE the IAT follow a curve related to the actual cyllinder entering air temp rather than being a flatline that has little to do with the actual air temperature at the valve. I want a sensor inside the cyllinders lol. This point is a little more moot when you're dealing with a fully warmed engine and a correctly recalibrated set of calcs. I don't do it because I don't understand how to get it close as a pure math calc... (and I've already done enough things I don't fully understand to want to add to it lol)

the vette code had an oil-temp input on another channel maybe use that for the airbox? the MR had no provision? thats one intake I never tried.

On the "shell" yea I'm talkiing the red one.. although if you can strtaighten a unibody (RBFH!) and don't care if it has no title, the teal one will be here tonite..

92Z-666

iTrader: (2)

Bump for another thanks to Z69. One full season of flatline WOT WB o2 readings and drastically more accurate dyno sessions in the 406. Nice to be able to turn up the dry 50 shot a little too

appreciate it man..

Z69

HTH