Grumpy

While not for the weak of heart, or the novice, here's a code patch, for when using source code.
While not perfect this patch will get you close on converting the 58 code from 2 bar to 3 bar.

The changes are
1)
Change:
LDAB #135 ; load accum A
To,
LDAB #211 ; load accum A

2)
Change:
LDAB #200 ; load accum B
MUL ; Multiply 8 by 8
ADCA #8 ; Add with carry to A
To,
;LDAB #200 ; load accum B
;MUL ; Multiply 8 by 8
;ADCA #8 ; Add with carry to A

So when your done, the Source Code would look like:

LF56D: STAA L00BC ; Turbo Boost Pressure
; Kpa=n/1.28 Store Accum A
LDAA L003F ; filtered map adc term load accum A
LDAB #211 ;135 ; load accum A
MUL ; Multiply 8 by 8
SUBD #400 ; Subtract Memory from A
BCC LF57B ; Branch if Carry Clear
CLRA ; Clear A
CLRB ; Clear B
LF57B: LSLD ; Logical Shift Left Double
BCS LF581 ; Branch if carry set
LSLD ; Logical Shift Left Double
BCC LF583 ; Branch if Carry Clear
LF581: LDAA #255 ; load accum A
LF583: STAA L003D ; MAP Store Accum A
LDAA L003F ; filtered map adc term load accum A
;LDAB #200 ; load accum B
;MUL ; Multiply 8 by 8
;ADCA #8 ; Add with carry to A
STAA L003A ; map term for BPW Store Accum A
RTS ; Return from Subroutine

For educational purposes only, ie for understanding automotive engine management systems.
No warranty expressed or implied.
Use at your own risk.
If your not totally confident on your code ability do not attempt to try this.
Not legal for highway use.

Again, this is for the folks that are trying to get serious about understanding Source Code, and engine management systems.

89 Iroc Z

You just took all the fun away, now i can't sue.

Dave_Jones

Actually, I'd say the fun level just went from 15 psi to 30.

Why am I imagining the sound of turbos spooling?

Thanks Bruce!!!!!!!!

JPrevost

cool stuff

jnjspdshop

Where is a good place to start to learn about source code??

Grumpy

Do a search here. And then just start asking questions, as you begin bumping your head against the wall.
Grab a copy of the 60 code, and you can use that as a model.
And there's some partically commented stuff for the common masks on line. So initially it's hunt, hunt, hunt...
Just no easy way, to get into it that I know of.

11sORbust

jnjspdshop

Maybe I didn't put that right. First where can I grab a copy of the 60 code? I already have a copy of a 58 code from Craig Moates. I have taken some computer science courses in college, so I am vaughly familiar with source code. What program do I use to edit an compile the source. Also does this source code once compiled generate a .bin file??

Grumpy

You have an email.

stevver84Z

i am also a bit curious about that too... i've been on here looking around for a while now i i have never really understood how to modify the code. i think i understand that a "hac" is the code behind the definition file? right?? i just dont know how to modify it
im kinda a newbie so pleaz dont kill me

Grumpy

There are several ways to work with computer code. One is the *normal* way of using an editor and just getting in to change the calibration data.

Compling, or assembling it is another. In this case, you can change the code, and the way the code actually runs. Add routines, remove routines, change table sizes, you have the power to so about anything you want when you have the actual source code.

*Hacs* around here means having a disassembly of the code. It might be just the calibration area. It might be the whole code, and it may or may not be commented.

Commented Source Code, is having an Human version of what the ecm is doing, in full detail. When you look at the .bin file all your seeing is the machine code.

HTH

JP84Z430HP

I started a thread to hopefully get something going on source code, but nobody replied to the first question. Maybe I'll throw a couple more out there and see what happens????

Here's the thread:
Source Code For Dummies

stevver84Z

ok so just so i get this straight, the 'normal' way of changing the data is using a program such as tunercat or winbin, right?
I guess my next question is how do you view the data other than through winbin or tunercat??
i have a "hac" labled "anht_hac.pdf" and it basically shows a line of letters numbers and symbols (which i believe is hexadecimal?? right??) and after that a line which explains what the hex means. not that i am going to cause i'm still very new to this, but if i were to modify that how would i go about doing so??

ps... thanks for your patience

11sORbust

Mark Mansur has a great web page that helped.... http://www.supportfitness.com/mark/t...eatingECUs.htm

stevver84Z

Thanks for the reply. ill read over that a little later. thanks!

RBob

iTrader: (1)

Yes to the normal way. This is the easiest and most straight forward method of altering the bin calibration. 99% of the folks out there use this method.

The other method is to alter the source code and reassemble the code each time. The only time this method should be used is when code changes are also being made to that MASK/bin. Otherwise there is no benefit.

Once source code is present and this actual code is being changed, it is almost a necessity to update the source code and reassemble even for calibration changes.

The reason for this is that the calibration addresses get changed with a lot of the code changes. This would require the definition file (ECU, TDF) to be updated every time a code change was made (not always, but a lot).

When working with source code it becomes less error prone to also make all calibration changes directly to the source code and reassemble.

RBob.

JP84Z430HP

Some people make changes with a hex editor, after they have a good commented HAC to go by. The BIG down-side to this is that a bin editor will calculate things into a real-world value for you. But, if you have a heavily modified source code, it may be the best way....

EDIT: The down-side would be a down-side of using a hex editor, the real world values is a nice thing of the bin editor....

junkcltr

iTrader: (1)

I tried it. It doesn't work with the 3-bar MAP sensor I have. I need use a cal. table to convert the MAP A/D value before storing it to 0x0039. That is, I have to linearize it before letting the BBZB code see the A/D value.

Could you post what 3-bar MAP sensor that this was intented for?
You wouldn't happen to have the MAP A/D count value for the MAP around sea level (engine off)? That would help a bunch.

Anyone have a GM 3-bar with a MAP A/D count value with the MAP at around 100KPA that they could post?

Grumpy

It was for the GM 3 bar.
Why not save yourself the trouble, and just use the sensor spec'd?.
Dunno how to *see* the A/D count.

junkcltr

iTrader: (1)

I am having fun messing with this stuff. I never tested/calibrated a MAP sensor before so it is something new for me. I picked up two sensors brand new for $12 a piece. I want to use them for measuring exhaust pressure before the turbos. I figured that if they get messed up from the gas/heat, no big loss. I would like to ECM correlate the intake boost to the exhaust backpressure.

[/QUOTE]
The ALDL byte 30 is the raw MAP A/D count if the ALDL scanner does not mess with it. Usually they convert it to KPA or PSI or something. I am using TunerPro and recording just the straight MAP A/D count value (multiply by 1, no offset). The $58 code reports the raw MAP A/D value that was read (mem location 0x0039).

junkcltr

iTrader: (1)

There is a problem with this patch even with a linear 3-bar MAP sensor. I highlighted the problem and the split the screen to show why the problem happens. Take a look and let me know what you think. It is due to the 0x0017 value still being loaded for a 2-bar MAP sensor and not a 3-bar MAP sensor.
With the sensor I am using I have to do a lookup table first. I posted this for the guys using the GM 3-bar MAP sensor. I could be in error here, but I think one piece of code was over looked.

Grumpy

In an oem type set-up you might be looking at as much as a 3:1 ratio, of back pressure to boost. Unless, you're running an extremely large turbo, it's unlikely that you get anywhere's near 1:1. The imports with the 700 RPM power band, can acheive cross-over (less then 1:1), but it can kill the drivibility, for a daily driver.

junkcltr

iTrader: (1)

With the headers/manifolds & turbines I have I think I am in the 3:1 range. That is why I want to use the 3-bar MAP to measure the exhaust pressure. I would like to know the exhaust pressure because it may change what cam I will put in the engine.

Grumpy

Your the first person, I've seen even mention that. There are so many bigger fish to fry, that the EBP to Boost ratio is about trivial in comparison. But, whatever floats your bubble.

junkcltr

iTrader: (1)

Am I the first to pick a part your 3-bar patch also? Did anyone even help out/look at this for you when you wrote it?
I have been thinking of trying a different cam with a smaller exhaust lobe and therefore less overlap with a constant LSA. For some reason I got this thing about needing huge downpipes for less turbine pressure differential, and a thing about cam overlap due to EBP vs. intake pressure. I think I gain a fair amount of HP by getting it right/better.

OK, back to understanding the 3-bar patch you wrote. Thank you for putting it out there. It is a great starting point for me and gives motivation to do this stuff.

All of this is correct as far as I can see. Theoretically the multiply of 211d that was used should have been 204d (but it is close enough).
This piece of code needs to be fixed. It was forgotten.
The "cmpa #0x7D" is for a 2-bar map and should be changed for the 3-bar map. This will cause ALDL byte 45 (Boost pressure) to read off a bit for some boost values.
---------------------------------------------------------------
Now the BIG thing. This part of the patch has a problem ONLY IF it is not accounted for with the VE tables.

The original equation for the 2-bar map was: MAP_FOR_BPW = (MAP_A2D_COUNT * 200d) + 8d. The MSByte of the result is used for the injector BPW calculation.

The 3-bar bin uses the equation: MAP_FOR_BPW = MAP_A2D_COUNT. That is it, no real equation due to it being commented out.

Ok, let's see how bad the 3-bar equation "under estimates fuel".
Let's use a 2-bar GM linear MAP KPA of 141KPA (MAP A/D count of 170d or 0xAA). So, MAP_FOR_BPW = (170d * 200d) + 8 = 0x84D8. The 0x84 is sent to the BPW fuel calculation for turning on the injector.
Let's now use a 3-bar GM linear MAP of 141KPA (MAP A/D count of 115d or 0x73). MAP_FOR_BPW = 0x73. The 0x73 is sent to the BPW fuel calculation for turning on the injector.

Ok, so what went wrong? The 2-bar MAP at 141KPA sent a value of 0x84 to the BPW calc. and the 3-bar MAP at 141KPA sent a value of 0x73 to the BPW calc..........the 3-bar is falsely telling the fuel injector to be leaner than it theoritically should be by a value of 0x84 - 0x73 = 0x11 (17d). Therefore, the VE tables need to be increased to over come the MAP making it too lean. It gets worse as the boost increases (errors up to 42d).

What needs to be done. Leave the equation and do not comment out the code. Increase the value of the 200d constant to 200d *1.5 = 300d. This will cause an overflow in the MAP_FOR_BPW value when the 3-bar MAP sensor exceeds approx. 271KPA (MAP A/D of 219d or 0xDB). Another MAP_FOR_BPW (call it MAP_FOR_BPW_3BAR) needs to be created for the fueling equation. It is used when the MAP exceeds 267KPA to keep the BPW calc. theoretically correct.

All of the values used here are rounded/approximated using course values from a spreadsheet. More accurate values should be used when the actual code it patched. This was presented to give you an idea of what the patch does.
Please post if you see something in error or something just doesn't make sense.

RBob

iTrader: (1)

The PW is left alone for a 1 bar MAP sensor, it is doubled when a 2 bar MAP sensor is in place, it needs to be tripled with the 3 bar MAP sensor. Now the engine won't be going lean.

RBob.

junkcltr

iTrader: (1)

That is correct. It needs to be tripled for the 3-bar. The 2-bar does not max. out the MAP_FOR_BPW value so there is room left for the 3-bar fueling up to a point. At 271KPA the MAP_FOR_BPW value overflows. This means an extra MAP term is needed for the fueling eqn for above 271 KPA.

The interesting thing is that it would have been better to not comment out the code and use it. Add two lines of code "bcc" and "ldaa #0xFF" to clamp the MAP_FOR_BPW (MEM[0x003A]) to 0xFF when it overflows. This would give the correct fuel up to 271KPA. Above that it would get increasing leaner by 1 bit up to 315KPA. This is gives a much better MAP fuel term than commenting out the code, but is not entirely the correct way to do it. At least with this change, only the Boost vs. RPM fuel multiplier could compensate for the leaning out at 271 KPA.

RBob

iTrader: (1)

The 3 bar MAP_FOR _BPW value won't overflow if the code if left as Grumpy posted it:

Then triple the PW after the MAP_FOR_BPW has been factored in.

RBob.

junkcltr

iTrader: (1)

That is true that it won't over flow with the Grumpy patch, but it will not triple the PW either. Tripling it would require a constant change from 200d to 300d, but his patch only uses a constant change of 256d......so it does not triple it and under estimates fuel.

No matter how it is done, the MAP_FOR_BPW overflows when correctly tripled. Therefore, another MAP_FOR_BPW is needed for the fueling equation. The MAP term will range from 0x00 to 0x2A when the 3-bar MAP goes from 271KPA to 3-Bar. The term isn't that big and could just be "fixed up" using the boost vs. RPM table (F77 table).

EDIT: another way to look at it: The Grumpy bin uses a multiplier of 256d, my patch uses a multiply of 300d. The Grumpy patch underestimates fuel by (256/300) = .85. Notice that the example I gave early on at a MAP of 141KPA showed that Grumpy's patch under estimated fuel by 0x84 - 0x73 = 0x11. That is, 0x73/0x84 = .87 (remember my example was rounded numbers) or approx. 85%.

RBob

iTrader: (1)

You are not understanding where the PW gets tripled. It isn't the MAP_FOR_BPW term.

RBob.

junkcltr

iTrader: (1)

That is true. I am missing something, but I don't see any other code mods that Grumpy posted that would change the MAP value from being doubled to tripled. Please post the code he changed to do this.

I am going to compile the patch I did and try it on the bench this evening. Maybe my thoughts are totally messed up. The spreadsheet seems correct though.

Grumpy

Gee, now that's an idea, then maybe run it in the car for a while to make sure that it does, what's expected.
Oh, and then you can start looking for the other problems.
Then once you find, and cure those, you'll have something to begin working with.

junkcltr

iTrader: (1)

I try to get things theoretically correct. Then I move on to the bench and then on to the car. There is 16K of available space with another 4K of SRAM available. That should be enough space to do pretty much anything.