Prepping a bin that runs mostly stock (AXXD) code and adding functionality for boost.

I've got a car running on a 2 bar MAP sensor.
The rom has VE and timing tables up to 200 kpa and 6400 rpm.
It also flashes the CEL when KR hits a specified threshold after hitting a MAP threshold.

It will also be able to read a wideband sensor and utilize the info however you'd wish.
What other tables would you like to see altered or created?
What functionality would you like to have or see?

 

Welcome to 2008 lol and even further beyond this i'm sure but i was hoping for this back then.

If it just does 200 kpa fueling and spark thats more than enough. Dont need much else, althought enrichment vs iat and spark retard vs iat are important features that be nice to have

 

Sorry I was driving a fourth gen then!

Definitely thought of those IAT tables. I'll be sure they come up in one of the next rounds. That will require some tweaking that I need for future flex fuel and mode switching too. So it's all intermingled.

 

This is kinda funny considering the conversation we had yesterday.

-- Joe

 

Did you put a 2bar map on a spare ADC and reference that for your VE and advance table, or are you using the 2bar as your only MAP and halving all the values?

I tried it the 2nd way but didn't catch every single thing that referenced the MAP. A forum member who's quite better at assembler than I did it the first way but it was only a BPW adder after 100kpa, no spark.

-- Joe

 

I had the idea of making the PE mode spark adder into a boost spark retarder. Doing it that was is simple. Just change the "add" to a "subtract" instuction when in boost. PE MODE is not really needed with boost. For N/A it is only active from 93 KPA and higher.

 

That makes sense. Most people don't use PE spark adder anyway, so it could be a useful BTM.

I used to just lock my timing in anyway at the low (usually around 25 degrees) advance, rather than retard under boost. but I've always run non intercooled. On my current build I'm wondering if I can use full timing under boost with the a/w intercooler.

-- Joe

 

Only the one map sensor. I followed the map through the the rom. I can't say I found everything, but I think I did. The car feels stock and drives perfectly.

 

Years ago some of the resident experts said that doing it that was was "wrong", but in reality it's just a voltage kpa translation. Everyone recommended using the $58 stuff which had bugs and was a pita to tune with it's closed vs open tps tables, etc.

-- Joe

 

Right I was suggested to use a second MAP but resolution lost (.35kpa per step vs .8kpa) is minimal and I'm driving a car with oem drivability.
Perhaps it will be more obvious in a bigger cube motor or a supercharged engine, but I don't see it and my butt is finely tuned.

 

... you just love stirring that pot, you know I am going to respond lol.

I'm not sure I agree about bugs in the $58, as GM code was always very well written as it was. Members were having a hard time changing it, as well as adapting it to different setups, but the problem always seemed to be the collective thought process, not the code. I know you don't want to hear this but Rauscher figured it out a long time ago, he always stood on the sidelines correcting people when they were far off, but nobody capitalized on what he was saying because of their ego's, they wanted to do it themselves, so in the archives everything stood. Code $58, $8F and $8D were all developed during the same time by GM, nobody ever thought during that time they would all be hacked and rewritten to accommodate different engines, so they were only really intended for the engines they were written for. Could they be written for different engines, of course they could, but the problem always lies in who was doing it, not the code itself. Publicly, $8F is hardly commented on, but don't ever think there aren't tuners out there who don't use it to perfection and just dropped it into the '7730's with V8's after making a few changes, they just keep it to themselves. Hell if RBob would have created an XDF for $8F a decade ago we wouldn't be having this discussion, but he gave us something better. No bugs in the $58 though, Eric Marshall took it, ignored the $59 rewrite, and within an extremely short period of time gave it 3 Bar capability and a host of other features the way he wanted and it came out incredible, how long did it take the $59 guys, and even today bugs seem to make themselves prevalent in that code...

I think what Vanilla Ice is doing is good for the community.

 

My only concern when I started this was if I could make it feel stock and it definitely does.
I have a bin ready to rock, but would benefit from the tweaks wementioned in this thread.
Things in my head;
Wastegate control via AIR delete or CCP delete.
Per gear timing control.
Per gear wastegate control.
Drivemodes switchable on the fly with Killswitch, economy, Antilag (partial or actual), normal and wastegate 0'd valet mode.
Virtual Flex fuel sensor via NVRAM or actual sensor.
Wideband input with logic programmed to fuel cut in lean conditions.
Cel readout without paperclip.
Maybe wire in a momentary switch instead of vats to operate other functions.
Probably a bunch more if I can get it without all the inputs lacking in this.

 

Doing it this way is fine as long as you found all the MAP values, or at least the ones that mean something in the real world. I *think* doing the spark adder to subtractor is as simple as making one hex value change in a hex editor.

In terms of the resolution lost, it is not the code or remapping the resolution causing the problem. It is the simple fact that now you are using 0 to 5v to represent 0 to 207 kpa instead of 104 kpa. A 3 bar has worse resolution. The only way around this is to use one ECM input for the 1bar map and another ECM input for the the boost MAP. Using a diesel 3 bar map is nice in this config because they do less vacuum so the 0 to 5v spans more of a boost only map range.

A voltage MAF or MAP is just a flow or pressure to voltage translator.

And yes, GM has bugs in the code. The $8D has a bug where if the A2D converter doesn't come back it will hang. Very small chance of this but it is a bug.

If you read through different versions of code, you will find the GM "C" team wrote the TBI stuff, the "B" team wrote the $8F based stuff, and the "A" team wrote the camaro/vette stuff. Later on the "A" team code was used for a basis of the years of code that followed.

 

Check out the $12P code. It is designed for the 165 ECM but has the features you desire and real time tuning. Not the "bump"/fart" engine stall stuff that the "emulators" around here provide. His design was done right and is synchronous.

 

From memory, the AXXD is like the $BUA disassemble that floats around, and not like the $8D BAUJP code dissamble. The code itself is slightly different. Enough to move some of the tables/constants around. Something to keep in mind when you did/do your PROM read.

 

This was before you joined the forum.

$58 is hard coded for V6. Some things simply don't work because the math is wrong when you set the cylinder select to v8. Also, the injector constant exists but was not used, nor was the cylinder size if I recall. (which makes the VE calc kinda not a VE calc)

You don't have to take my word for it. Ask RBob, or anyone else who used it over a decade ago. In fact, ask all the code 59 people who fixed most of the bugs haha.


I know you are having a hard time believing this but I really do like RBob and consider him a very good hardware guy.

However, with that said, Bruce Plecan was the $58 expert. I've got dozens of emails back and forth with Bruce as I was one of the first adopters of $60, which was a 32k version of $58, fully commented, some things fixed, etc. I'm aware of the fact that RBob contributed.

This isn't a stock vs aftermarket debate. I really like $8d. But $58 was problematic.

So just so we are clear for everyone viewing, NOBODY has the source code for any of these things. What guys have done was disassembled bins, and carefully tracked the dumps to understand how they work. People commented them (called 'hacks', but oddly enough when we did it in the 80s to software we called it 'cracks', but that's another story).

When you disassemble something you can't really see how it was developed in it's native language. Disassembling, commenting, and getting this stuff to re-assemble is a daunting task. The guys who did this deserve a lot of respect. Assembly programming is a lost art. I don't even have anyone on staff that knows assembly, they all retired. I have not done it since school.

I suspect the GM/Delco software engineers had a development environment and wrote this stuff in C. I bet the native code was a lot more adaptable, but when compiled, optimized, etc a lot of the switches are gone. I suspect they probably had a tone of #ifdef statements throughout.

Now I'm not trying to pay myself on the back, but this is what I actually do for a living (software engineer, not car guy). In fact, next week will be my 19th year with the same company. I don't just write or design software, I'm in charge of the whole show. So to put it plainly, I completely understand how this works

I'm torn. I felt the same way about $60 before Bruce died, but after he died nobody was around to support it. I sure as hell am not going to bust out the 68HC11 manual from 20 years ago and re-learn this crap if something needs to be fixed or added.

-- Joe

 

The bump/fart is mainly due to the tuning software or crappy emulation hardware. The software should be able to keep track of the memory addresses that have changed, and only overwrite those without replacing the whole bin.

This is why "flash" ECM's suck big time. You are not just overwriting your arrays, you are overwriting your logical operations. The later LT1 PCM was a huge step backwards.

This is one of the reasons I think GM developed it using a special build environment and in C. All of these disassemblies are drastically different in some ways. It seems consistent with an environment where things were #ifdef'd in or out, libraries were included, etc.


Edit: apparently researched this a few years ago.. https://www.thirdgen.org/forums/dfi-...165-773-a.html

Forgot all about it..


-- Joe

 

I never understood why people want on the fly real time bin uploads. When you do a log you need time to analyze the results and change the settings in the tune, save and then burn/flash/whatever

Having the car running whole time seems pointless.

I dont think ebl flash, lt1 flashing or ls1 hp tuner flash uploads are difficult to do or are undesirable features. They work really well

 

What you are saying is how I did it for years, using custom spreadsheets to do my BLM conversions to VE numbers.

Then I got my first pocket romulator or whatever it was. I could dial idle in within a few minutes. By having a person drive, I could sit in the passenger seat and get most of the VE map dialed in. For AE it's an absolute must. I can fix even the worst AE problems quickly.

But it also depends on what you are using for software. One of the things I really like about tunerstudio is that it highlights the cells you are currently in, so you know you are altering the right thing. It's a lot easier than switching between applications or windows for log vs tune. I don't know if tunerpro has that functionality now, I have not looked at it in many years.

-- Joe

 

The code base for $58 is old, it originated in a C3 ECM. It was then updated to run on the '7749 P4 ECM. Hence the oddities in the code such as the quasi-async injector firing mode.

Not entirely true, take code 59 for example. When you see things such as this:

The F29 and F29C are directly from the source code. The above examples are from the $59 XDF file. So someone managed to get their hands on the original $58 source.

It was done in assembly, no #ifdef or such were used. The libraries of certain sections of code was dropped into the source to be assembled (not linked in).

RBob.

 

I have no plan to support anything real time.
Mode selection on the fly is far more elegant. But will require tuning the old way.

The purpose of this is to give turbo functionality to Tpi cars for dirt cheap. Any features I add will only be what I want in my own car for use or fun.

When I release anything I will have it available to all to continue in their own way just like I always do. So the morbid comments are moot.

 

Forgive me but, how did you come to that conclusion?


Do we know this because we've interviewed the developers or ?

From a development perspective, I guess in the 1980s this would make sense as a lot of stuff was written in assembler to run on slow hardware, use less memory, etc. But I've never seen anything other than commented disassemblies. Surely if someone had original GM source it would have found it's way to the internet by now.

-- Joe

 

I think most people who use $8d or $58/59 use an emulator. I wasn't suggesting adding NVSRAM support, although from what I understand that's a pretty cool addition.

Giving people an alternative is good. For people who have '165's they can use $12p, for people who have '730s they can use your modified $8d.

It's like peace on earth


I actually bought an ostrich yesterday. I wanna play with $12p on my test bench.

-- Joe

 

Note: please see post #22 above for the entire context of this post.

Not a conclusion. There are actual people that write this stuff. Meeting and talking with them gets interesting.

RBob.

 

You are being cryptic

What you are saying is you've actually met and conversed with people who did the original GM software development? (Who maybe left the building with the source ?)

Why haven't these people made the source public? It's been 30 years since some of this stuff was new..

-- Joe

 

Why go through the trouble though? The '7165 can be tuned for boost as is with the stock MAF, and run and drive flawlessly. No need to switch to MAP or an entirely new code. Bailey was here years ago, explained how to do it tuning the LV8 and a few other areas, and that was that. Boosted $8D? $8F is a drop in and works with a few small changes. It was always here, but nobody wanted to learn how to do it, they were waiting for the comments from others. In just about every single $8F thread in the archive, RBob hinted on what to do, but nobody listened.

 

Not directly. The code can only read up to 255 grams per second, which is roughly 450 cfm. That's not even near the numbers you would see on a hot n/a motor, let alone with boost.

By adjusting the load multiplier on the 255 cell? That's silly. You have absolutely no idea what the true airflow is, not do you have any enrichment control as boost increases.

I'd feel more comfortable using PE fuel adder. Both both methods are very wrong.


One could argue that even if the MAF could read the airflow required you would still want boost switches. (like boost retard).

I thought Funstick got that working ? (This was before RBob joined thirdgen.org). $8F was DIS right? Don't you just inverse the settings?

-- Joe

 

I'm not being cryptic at all. Yes. Never stated that folks left the building with it. Maybe a confidentiality agreement?

RBob.

 

Maybe. If you have direct first person knowledge of someone who actually had the source, then I guess someone has seen the source.

But I'd bet a nice prime rib dinner that nobody on this forum has the original source


-- Joe

 

Now you are being nonsense-able. Of course people have seen the source, [B]people, or persons[B] wrote it.

And you would know this how? Do you know every person that is registered here?

RBob.

 

I tell ya what, introduce me to a forum member who has seen the factory code, and I'll buy you dinner the next time you are in Boston.

-- Joe

 

Whatever...

RBob.

 

Trouble? Child's play.

Haha I'm kidding, but it's a cakewalk. I do it as a fun exercise plus what I'm adding is NOT oem stuff.

 

Hey I'll take you up on that offer...

Vanilla whatever I'm saying is in no way directed towards you in a negative way, I think what you are doing is excellent for the community and I mean that. It is refreshing to have an STI perspective into the mix, it opens us up to new ideas...

 

Boost thru maf has been done by tequilaboy i believe. Blowerworks.net. Upgraded maf. Without a higher reading system, 255 is hit on mild 300 whp cars let alone a serious boost deal. Hell a stock 305 with 10-12 psi is 300 whp

Boost using pe adder vs rpm enrichment is ideal for centri blown cars but worthless for turbo car which can see various boost levels per rpm depending on throttle input/load

8D is nice since the whole thing is setup already for our cars Tpi sbc's. Be nice to just drop in a boost capable code so little tune work as to be done. Base files that are close make life that much better

 

Yes, and he learned from Bob Bailey who visited my old thread and showed him how. This was exactly my point, only few members took what was being said and ran with it. RBob has been saying this for years, Bailey came because I invited him and he shared how to do it and then left because he was treated wrongly by someone who wanted to argue code with him and he didn't want to waste his time...

 

Anyways, getting back on topic. It's going to be very interesting to see how this turns out. I only know of one member that gave $8D a boost feature in chip form, and that was Funstick, but again, he dropped off the website. I'm very interested to see what Vanilla Ice does with it, and hopefully there are members willing to test, video and comment on it for us. Sort of put the final nail in this coffin that was left open for over a decade so to speak...

 

Patrick did it by using a different MAF sensor (I think Ford?), and he modified the code quite extensively. This was back when the two of us put Powerdynes on our Corvettes. He wanted to stick with MAf code so he didn't lose his dash functionality. (I didn't care, and ran $60). I spoke to him quite often on the phone and on Corvette forum at the time. He's a smart cookie.

But as you are well aware, this is quite a stretch from playing with the LV8 load multiplier to get enrichment. And I agree with you 100%, that's nearly impossible on a car that will build boost at varying throttle positions (turbo!). Blowers typically only build boost WOT. (usually).


-- Joe

 

Come on down, I'll buy dinner anyway. You can check out my disaster of a shop, we can hit the range do some shooting, etc. Warning though, you'll leave as a registered Republican.

-- Joe

 

It seems nobody has anything to add to the "project..."



Don't forget to chop down a tree and curse Obama for being solely responsible for destroying America.

 

How much work do you want to do?

Off the top of my head, Wastegate control, Alky injection control, Boost fan control (for people running a/w intercoolers), Overboost protection (not wastegate, but rather spark cut).

Having wideband (EGO) based closed loop would be fantastic if you could shoehorn an AFR lookup table rather than BLM and narrowband.

-- Joe

 

Not sure about features, maybe something to rival Turbo Tweak would be a nice start...

 

Maybe you can list some details since all I have seen is pretty typical mail order tune stuff.

 

Vanilla, to not be compensated for all of this work would be ludicrous, but I digress;

 

I saw all that. I'm no hardware guy. I leave that to RBob and the others.

And I will ask for donations but I don't expect anything.

Also, I am looking for ideas and features to add, but I won't add anything I won't personally want (or think would be fun to do) without direct compensation.

 

You're kinda answering your own question though, not to mention nobody here has given it much thought because they were still stuck on just getting it to read boost. I would just focus on the basics, people want wastegate control, alky control, they want to be able to run e85, etc. Those are of course a given with any boost code.

 

Right, but that's the reason for this thread. What are the options people have always wanted but never had implemented?
I may or may not do the coding for it just due to limited time and desire but if you never speak up about it, I may never think of it in the first place.

 

Don't do the goofy switch thing on a memcal PCB. The 730 has a lot of unused digital inputs that can be used for things like "race mode", or things like that.

Put an NVSRAM in place of the PROM and add the write signal wire(s) to the ECM PCB. With some simple code the sky is the limit for features. You will find the limitation of the older ECMs is that they don't do Electronic Transmission control and has limited RAM. If you don't care about that then the 730 is the best ECM to use because it has the most unused analog/digital inputs and PWM/digital outputs. I have posted years ago how to get more RAM without adding hardware. You can also add RAM hardware with the 730.

Creating on-the-fly tuning is best done through the ALDL link. You can steal bus cycles via hardware but it must be reasonably fast. The emulators I have seen around here are slow and bump into the MCU read cycles often causing engine stumbles due to ECM reset and/or improper read data.

Most aftermarket ECMs that allow boost have a "feature" list. The lists are all pretty much the same.

 

It has been a long time since I have seen a GAL used in a design. Looks like a possible address scrambler to make the code harder to disassemble.

 

TThere's nothing Goofy about it. It's actually very simple, easy and useful. There will be no bump (guaranteed), IF I set it to work while the engine is running. Which I haven't decided.

I still have no interest in programming on the fly tuning when it's already available. I can buy an Ostrich for that for much cheaper than my time.

Off the shelf feature lists are all bland and boring. I'm looking for something that hasn't been done or ideas I can't get from google.