I am trying to make the fuel and timing tables go higher one of them goes to 6000rpm the other goes to 6400rpm wich on a decent smallblock is kinda on the low side Here is what I am doing.......

I am using tunerpro and a usb autoprom to modify and emulate,

I am changing the locations of the tables by using the hex editor to find a blank spot large enough for the larger table ( in its current location If I enlarge the tables It overlappes the next item) So then I modify the hex address ( move it to the blank spot that I found using the hex editor) by using the xdf Item editor in tunerpro. I have no Idea if this is the correct way to do this or not. Obviously I am doing something wrong because when you try to start it using the modified version it starts just fine and idles until you hit the gas and then it dies. It obviously cannot find the table that I modified What am I missing????? am I even on the right track????

 

Have you disassembled it?.
If you're just trying to cut and paste things, you might run into issues.

You really should invest in an ecm bench, rather then trying patches on a running engine. Believe me, it's money and time well spent.

 

ok I am game for just about anything..... Could you explain what / how to go about doing this?? I know little about all of the technical stuff. I really want to learn how to do this but I am clueless. I try to search for this stuff but everything I find is either extremely basic or waaaaaaaaaaay over my head... any help is much appreciated

 

What you are doing and the way you are doing it is a recipe for disaster. If you are intent on modifying your .bins source code and you wish to keep your engine together then start here https://www.thirdgen.org/techbb2/sho...de+for+dummies . An ECM bench for testing your changes would also be a good idea. Don't expect to make magic happen right away. If you feel you are not up to the task, you might look at an aftermarket setup. HTH

 

Read all the stickies on source code till they make sense.
Get a hac and start going through it while referencing the pink book.

The stock code also won't support >6400 rpm.
It doesn't calculate an rpm value higher than that.
It simply stops at 6375 actually.
The motor will keep reving, but the code will only use the last table value. You can modify the code to calc higher than that though as I've done for learning purposes. This shows how the stock code calcs rpm. https://www.thirdgen.org/techbb2/sho...light=rpm%2F25
There are stock GM non 3rd gen bins that support > 6400 too. One of those things I found while looking for something else.

 

that would bee too easy. I kind of like beating up on carbureted cars and imports with most of gm setup, and they really don't like getting beat by a 4X4 truck. I am not afraid to learn this, I just am new to the injected world...

How do I get an ecm bench????? what do I need to make one??? I probably have a lot of the stuff to do it.

There is one more thing that I was wondering.... I have found somewhere that my combonation can support a MAT sensor. Does anyone know how to do this????? or do you have a link to an article that explains this. I found that it is possible just can't find how.....

Thanks

 

6375 RPM is the most you can expect out of the stock pcm without radical changes to the code to allow for a 16 bit rpm term with 24 and/or 32 bit routines to handle the math. Its doable, but beyond the scope of most DIY'ers.

 

My first suggestion would be to pick up the motorola reference manual for the HC11 at moto's site. Read teh central cpu section and look over the instruction set to get a flavor for what youll be working with. Its certainly not impossible to do this. I didnt know, and still really dont know much about computer hardware or any of that and I managed to pick it up. Having former knowlege would be a great help but you can manage without it if you take your time and work things out. Youll make mistakes (I do all the time) and get lost sometimes (yep, happens alot to me as well) but in the end youll be able to work it out.

 

Yep, you will run into a lot of apparent dead ends.
Just work on something else that's easier and read more and that wall you hit will suddenly disappear.

P4's do it with only one 16bit calc I believe. Never counted.
After that it is all 8bit. See my link above. As long as the DRP comes in on a 16 bit register. It should just be a cut and paste deal.

I thought a 6395 was one of the fast tbi ecm's.

 

You will have to build an ECM bench yourself. Search the stickies at the top and read them as many times as it takes to soak it all in. As for MAT support, the '6395 has provisions and code for it but is not enabled and the tables are blank in the TBI applications. Basically you just need to connect the sensor then enable it in the code and populate the tables. Sounds a lot easier than it really is though to a newbie but is far easier than extending the RPM range in the code. Learn to walk, then run before attempting to fly. No flame intended, just trying to keep you from becoming discouraged. If you try to get in too deep too fast, you will become overwhelmed and give up. HTH
The '6395 is a P6 PCM but is no faster than a P4. It runs at the same clock speed. It just has a bigger PROM and more I/O hardware for tranny control.

 

Thats RPM/25 x 256 as you probably know. This is /256 and stored as an 8 bit term, as you also probably know. You could have a seperate calc. that calcs RPM/25 x 128 or some other increment that expands the RPM range that the accumulator can handle. Only problem is if you want filtering, table lookups, etc, then 16 and 24 bit routines are needed to handle the expanded rpm term. Not too terribly hard to write, if youve had assembly experience. I had 16 and 24 bit table look up and filtering routines in the '8063 tbi ecm, so if that can handle them, then the later ecms/pcms certainly can.

The P6 also has an improved MPU with more RAM as well as non-multiplexed address lines and other improvements. If Im not mistaken, the speed they run at is ~2 MHz. This is exactly 2x the speed of the older tbi ecms, so they definatly are faster and better then what came before them in the tbi cars/trucks.

 

By your comments, I can't tell if you've actually looked at how 8D calcs the rpm term. Could just be me. The ecm is good to 9k+ theoretically. https://www.thirdgen.org/techbb2/sho...light=rpm%2F25
Instead of RPM/25. You do an RPM/xxxx term and stick it in the code right next to where the /25 term is done. Or else where. But that's where GM put it.
I've done a bin to 9k for giggles. Can't test it since my bench only goes to 64xx.
The hard part is understanding how the code works.
The code patch was easy. Well Rbob helped.... I went way off on a tangent. It took longer to figure out how to add the jsr in than anything else.
The stock 8D has a bunch of extra code in the middle of the calc for other things. Had to figure all that out first.

 

I won't get discouraged...... I am in this for the challenge....... I love a good challenge, if its not a challenge it gets boring to me.

 

Im working with the $0D, which has the same calcs. in it. I think We're both saying the same thing, but in a different way. My idea is just to change the numerator in the FDIV so that its RPM x 25 x 128 rather then x 256 so the accumulator isnt overrun in the rpm calc from the DRPs. Then divide by 128 and store the new RPM/25 term as a double byte value, or just use the calculated value x 128. Provide filtering and then its good to go. Theres a slight resolution loss with this but considering some of the inaccuracies with a SBC dist., I dont think it would matter much.

 

Well, if your in for a good challage, you picked the right thing. This is probably one of the hardest car related things you can do. Read all you can and take it slow and you shouldnt get overwhelmed.