Bin Hacking Via Tunerpro
 

There's a variety of ways to get started with your own code hack. You can go the traditional route with DOS-based programs and assemblers, or you can hack directly in TunerPro. I prefer the latter personally, it makes me feel like I'm in control of what I'm writing and it’s more accessible to the novice hacker. Once you're done there's no need for an assembler, just save and run it. You need a copy of the Motorola machine code included below, a hack of the program you're working with and patience of course.


I begin by writing the basic code out in notepad just to get a feel for how everything will work. It's not really important how it works at first because you will rewrite it several times figuring out what works, what addresses you need to reference, how to eliminate unnecessary segments, etc.


First draft
Attachment 343472


Then I look through the hack for the area I want to put it, figure out what needs to be moved or erased and what I need to reference (things like rpm, tables, constants and so on) then tidy up the first draft of the hack in notepad.

Useless Power Steering code looks like a good place to put the hack
Attachment 343473

Second draft with added info
Attachment 343474


Once I'm convinced it will run (and it often won't first time out) I open up TunerPro, create a table spanning the area I'm working with and start writing the string out. It helps to have the tables displayed bottom down instead of the standard view- go to Tools, Preferences, then uncheck Reverse Rows.

Right click, insert new XDF parameter
Attachment 343475

Select table
Attachment 343476

Add the table Adress
Attachment 343477

Add the number of lines of code at Number of Rows
Attachment 343478

Make sure it’s in Hex Digits
Attachment 343479

Begin writing the code string out
Attachment 343480


Save, program, test and diagnose the hack if you run into a problem. An ECM bench really helps you move from beta testing to on the road quickly, but you don't necessarily need one.

Incorrect command found
Attachment 343481

Corrected command
Attachment 343482


After a while you will memorize the machine code nomenclature and programming rules and it basically becomes another language, albeit a strange one. Carefully study how the program was originally written for clues on how to properly write a routine and you will graduate from simple modifications like changing which sensor a routine uses to more complex things like adding your own tables and writing your own multi-stage rev-cut routines. As always the community is here to answer your questions.

A few tips- consider rewriting the bin as a relocateable file using names for routines, that way you can move routines wherever you need by referring to names instead of addresses. This is on my to-do list with my current program, however it’s not necessary and an effective hack can be written with addresses, it just takes more time to calculate the space between points in the bin (especially using hex numerals). If you’re working with a tight bin that doesn’t have much empty space you can remove some unnecessary or inoperable routines (the factory test and power steering routine in $6E are good examples) and shuffle some things around for extra space but if you have enough empty space in the bin create a subroutine (JSR command) that piggybacks of the existing work to an unused area of the bin to free up clock cycles.

Re: Bin Hacking Via Tunerpro
 

Most of the files here...

Re: Bin Hacking Via Tunerpro
 

We can't upload Docx files???

Re: Bin Hacking Via Tunerpro
 

Thank you for this. Bin hacking is one of those things I have on my to do list. I don't have any coding experience but I have created or modified parameters using TPRT.

Re: Bin Hacking Via Tunerpro
 

No prob, I'd like to see more people hacking. I know there's some good ideas out there waiting to be put to use.

Re: Bin Hacking Via Tunerpro
 

THANK YOU! I cant believe I missed this, but saved to favs. Ive been wanting to patch in the anti-lag to see if I could get it to work. Once I have more time I will post any questions I have. Two questions up front.... How will I know if there is enough space in the calibration to input the patch? I know I can replace a routine but will I need to replace it with something of equal size for checksum?

Re: Bin Hacking Via Tunerpro
 

Depends on the ecm. '730s have tons of empty space, the '165 is a little tighter. It's good practice to fill all unused space but not necessary.

Re: Bin Hacking Via Tunerpro
 

That's where I left off, not sure what or where to look for empty space. If you gave me a starting address I may be able to figure it out.

Thanks!

Re: Bin Hacking Via Tunerpro
 

What's the ECM and mask?

Re: Bin Hacking Via Tunerpro
 

'730 S_AUJP V4

Re: Bin Hacking Via Tunerpro
 

I am not terribly familiar with the '730, but look into the SRAM mod (S_AUJP may have it already) and open up the hex editor and start looking for large sections of 'FF' or '00', usually at the end of the bin as those will be unused space. The '730 can address larger chips (SRAM) than the 128K originally used.

Re: Bin Hacking Via Tunerpro
 

Adding to the end is best.
Looking in the XDF (or the actual bin) for the end of the calibration section or the code section.
Finding the unused RAM storage spots are the most troublesome because they can appear to be unused but are actually used by a 16 bit value (only calls out the address of the starting byte)
The checksum end of things ended up being the easy part.

to reiterate what was stated above, Adding code or a static values work pretty easy once you get the hang of it, be careful adding into the center of an existing bin as there are "indexed" jumps to positions within the program.
They are jumped to by position not by "Lable" or address so to speak.
Adding to the middle can cause the locations to shift and not operate correctly.

When we made the S_AUJP V4 "re-locatable", All of these indexed jumps were changed to "lables" so the jumps would always find the correct place.
Then adding or moving things around got much easier to do.
The main routines are configured that way in $8D, others may/may not be as bad.

There is a thread in the stickys called "Source Code for Dummies" that goes through the process of getting bin files to the edit-able state and then how to compile it back to a runable bin file.
It is time consuming and very confusing at first, but ask Q's and others will help keep you going.
Jp