Ski89Z28

I was wondering if this can be done.
Like the advance spark table it only goes to 4800rpms can you rewrite it to go to 5000rpm or higher?
If so will the chip accept it?

Basically I'm talking about GMEPro and WinBin.

Grumpy

Just writting a bigger table isn't the answer. You have to make room for it, and change the code to see the change. In other words you first have to develope source code, and then you can manipulate things.

junkcltr

iTrader: (1)

What are the benefits of extending the spark table?

J

Grim Reaper

So you can have a different spark advance at higher rpms.

For engines that make peak HP at high rpms, this can be a benefit.

Of more interest, would be extending the PE Fuel Add table to > 6,400 rpm (MAF and SD). With a Miniram and a decent cam, it is quite easy to make an engine that is making peak HP > 6,400 rpm.

But, as Bruce said, this really needs to be done in the Source Code. You must find the particular "routines" that work with these tables and let the various "loop counters" know that they have higher "limit" and need to "loop longer". Plus, you will need to realize that if you add the 'extra data portion' at the end of the "existing table" that you will "offset" ALL of the tables/constants that follow the table by the amount of space taken by the "extension".

There are a TON of other concerns but I hope this gets people to realize that while this sounds like a "simple task", without Source Code that has "soft labeled" addresses to "relink" the proper locations, you won't be able to "simple patch" a "few extra rows in the table" and have "everything work perfect". ALL CONSTANTS/TABLES following the table would be "offset" by the amount of spaced used.

Needless to say, TunerCat, GMEPro and WinBin would no longer work properly for all those constants/tables "displaced" either. With TunerCat you would need to "redo" all the table addresses, but you could do it with TDF Editor.

Again, only Source Code would really be the viable way to do this. And then, the best way would be to find a "clear area" on the eprom and create a "brand new table" so you wouldn't "offset" the other tables/constants.

Ski89Z28

Ok, Thanks Grumpy and Glenn for answering me but I have a few more questions and things.

I don't have TunerCat so I'll deal with the questions about GMEPro and WinBin.
These 2 programs use the ".ecu" files as the frame work, right? Meaning these tell/makeup the tables so making the tables on them larger would result in the program (WinBin or GMEPro) showing a larger table. So isn't it fair to say that the ".ecu" is the code file?

But, as Bruce said, this really needs to be done in the Source Code. You must find the particular "routines" that work with these tables and let the various "loop counters" know that they have higher "limit" and need to "loop longer". Plus, you will need to realize that if you add the 'extra data portion' at the end of the "existing table" that you will "offset" ALL of the tables/constants that follow the table by the amount of space taken by the "extension".

Find the "routines" and "loop counters" isn't a problem in WinBin since these files ".ecu" are nothing but text files.
Now as for the "extra data portion" will it "Offset" the rest of the tables/constants? Well that is why I'm asking this, cause I don't know if the ECM is "HARDCODED" to look for a memory address in the eprom.
I would think like any other type programming it just looks for the starting address and lets it run through the program and taking out the data when the routines are accessed and not the memory address (this is way too hard to design into the electronics). If this is true then depending on the amount of memory left on the chip you could extend these routines.

Also how much memory does the chip, say for the 165ecm, does it "actually" use of the 16K. I'm sure it doesn't use all of it. I thinking if it doesn't use all of the memory then it could be done very simplely.

Comments?

Craig Moates

Like they said, the ECU or TDF file is ONLY a template which tells your editor program what the layout mapping of the EPROM values looks like on the EPROM in terms of memory locations and index/table values. While you can change the 'values' (ie. degrees advance), you can't change the 'indices' (ie. RPM etc) directly with the editor program via the ECU definition. The ECU definition file is primarily to tell the editor program how the data is laid out on the chip so it knows how to map it back and forth.

If you want to change the range of values which the indices of a table represent, you can probably do that in the source code. What I mean is that you'll have to have a disassembly of your code and rigorously go through and not only change the values of the table index, but also look for any similar reference tables and change them also. It's certainly possible though. And you shouldn't have to change the size of the tables requiring more memory (although you could but more difficult). You should be able to just change the size of the increments between the table index values, for instance instead of going 1000,2000,3000,4000 you can go 1000,2500,4000,5500. But you've got to do some digging into the disassembly to make sure everything matches up. I've done some of this with MAF tables, and it's tedious, but it works.

Good to see someone digging...

-Craig

davidjon_99

The program is accessing table information from certain memory locations. It doesn't just start at the beginning and go to the end. It is doing all kinds of loops and subroutine calls, and it (the software program) is expecting to see certain information at certain memory locations.

Ski89Z28

Craig, I was hoping you would reply cause I know your work and you got yourself knee deep into this stuff.
But like I said I was able to add another row for the rpms in the ".ecu" file and have WinBin read it. The norm is for like 17 rows in the spark advance table going to a high rpm of 4800rpms. I added another row (the 18th), 5000rpms, and was able to edit it as I wanted.
So the ".ecu" file allowed the WinBin program to show the new fields and edit them. Am I right?

The question is, and I haven't tried it, is to program the chip and then to read it.

davidjon_99, Yes I knew that and was kinda excited about this and didn't explain myself too clear, soory.

However guys I still think modding the ".ecu" can give you the larger tables to work with but with the chip have enough space to hold it??

GregWestphal

iTrader: (1)

OK, one more time: it won't work unless you dig into the source code and change that. GMEPro, WinBin, and TunerCat are only interface programs that allow you to change certain values that the computer uses. By making that change in the .ecu file, you haven't accomplished anything since that table is only set up for 17 rows, not 18 or 16. The computer won't be looking for the extra row since it's not in the source code. Also, there isn't a whole lot of extra space on the 16k chip unless you delete other stuff like the AIR or EGR parameters.

Grim Reaper

You are in a DATA area and overwriting space which is probably reserved for some other constants/data.

You will CORRUPT the BIN if you do that. Please don't take this badly, but you completely misunderstand the functioning of how the programming in the BIN works. WinBin, TunerCat and GMEPro as "masks" that take the data from a portion of the bin. To properly ADD another row, you MUST tell the programming within the BIN that the table has been expanded, to look for another row and WHAT to do with it. You CANNOT haphazardly add a new row to WinBin and EXPECT the eprom to know what to do with it.

The ONLY way to do this is by disassembling the eprom and creating Source Code. Then modifying the "counters/loops" to know about the "extra row" AND you must "SHIFT DOWN" all the data downward or you will OVERWRITE the "valid data" with a ROW you just added. When the eprom goes to look for the data that SHOULD be there, it will have bad data.

What you are missing is, WinBin (and all other Bin Editors) are JUST modifying "pre-defined" DATA PORTIONS of the eprom. Those Data Portions MUST remain in a specific spot and you CANNOT just add tables to new locations. And they DO NOT modify the instructions to ensure they can read the expanded area of the Table - plus relocate ALL the data portions below the table PLUS relink all the instructions to use these new locations.

I STRONGLY SUGGEST you take a programming course for more information. Right now, you are in the "dangerous phase" where you have a little knowledge but not enough to truly appreciate the dangerous/erroneous thing you are about to do.

If you are lucky, you will only get an SES light. But the "added row" will NEVER be acknowledged by the ECM and at worst, you will corrupt/overwrite existing valid data with you "added row" which MUST overwrite it somewhere.

You are using a "hammer" to saw a board.

Ski89Z28

I know I seem thick headed and being Polish I guess I am.
But where is the source code for the parameters??
It isn't the TunerCat or WinBin or the GMEPro cause like you said it is just an interface program so you can see what your doing in english like terms.
The bin file is what??? it has all the info you typed into the the interface prgram but that is just that, info.
The ecu file is the only other file you deal with (in WinBin and GmePro) so you just change the parameters in there for extended parameters to be shown on the interface program. It will be the bin that will store all the info you type in or chage for those parameters.

So like I ask which one of these files above have the "source code" that would need to be edited?? I say the ecu file and in WinBin it is a text file in easy to read format.???

I will try to burn a prom this weekend with the extended parameters and post the bin and ecu files it if it works. But all I know was I did it last night and the parameters (extended ones) were there on WinBin and GmePro.

As for the the 16K I stated Iwas wrong wasn't I? The 27C128 has 128K right?

Grim Reaper

NONE. You need to "disassemble" the binary file (the actual executable program that we program on to the eprom, affectionately called a "BIN"). Then with this "disassembly" you need to 'reverse engineer' the "disassmbly instructions" to develop "documented" Source Code for the 68HC11 Assembler (which is the processor these cars use).

There is no "Source Code" laying around for guys to grab. The best you may find is a "hack" which is a partial listing of some Source Code. Anyone who has Source Code has developed themselves spending 1,000s of hours.

I strongly recommend doing a search on "Source Code" and "Assembler" and "disassembly" as I have made a few replies to posts related to this subject with "links" to various sites to get information on it.

Once you develop fully working Source Code, you can accomplish virtually anything you want. But one last note, most guys at this point dump the MAF and work with SD. The primary reason is there is just so much more room available in the SD Bin since it uses a 32K chip instead of a 16K chip as used by MAF systems.

Also, the SD code has some neat stuff in it that isn't in the MAF code. There is a "hack" readily available for SD which greatly helps in developing Source Code, but the hack is based on the Corvette ANHT, not the F-body AUJP.

CustomX

So basically, you need to take the bin...disasemmble it down to the binary, find out what does what..and where data is...then you can modify things to add rows in the tables...but you need to tell the ecm to look in differnt area of the prom for other information that you have offset by adding more tables....then the ecm should recognize the new table/rows....but that would be a pita correct?

Grim Reaper

Yeah, but it's the only method that really works. It's like trying to rebuild an engine, it's pretty tough to rebore the cylinders and mains with the engine still in the car.

You can always write to GM and complain to them for making it so difficult to "reverse engineer their programming and do things that GM never intended"?

Craig Moates

Why make bigger tables? You'd have to shift everything around, it'd be a mess. Much easier I'd think to change the indexing values within the BIN. Of course, TunerCat and such will STILL not let you do that, but it's still in line with what you want. You'll have to go to the disassembly for this still. Do a search for the BUA hack and you'll see what we mean about the actual coding of the source BIN program and how it is intertwined with the 'data' on the BIN. You can only change the data on the BIN with TunerCat and the like, but to do what you're talking about you'll have to go in & change the actual program.

Still I think redefining a table's span rather than making it bigger will work fine, the ECM just interpolates between tabulated values anyways. But you'll need to get in deeper than an ECU file will allow (unless it's a right-custom ECU file ) to do more than change some data values.

Grim Reaper

Actually, if a person takes the time to read the hack and LEARN the assembly language (and machine code) there is a way to "bit patch" the instructions. I do this all the time for a "quick test" of a code change without going through the process of "altering source code, reassemble it, etc".

But, if you don't understand "68HC11 Assembler/machine code", or what "disassembling/assembling" etc then there is NO WAY you should attempt this. But yes, there are methods to "bit patch" the instructions.

Do a search on "Highway Mode Spark Advance". There is a post I made where I explain a "bit patch" to implement on the SD 7730 to make Highway Mode Spark Advance work properly without having to "disassemble/reassemble" the Source Code.