LS1 Boost OS V1

[aaronc7]

Really cool stuff!

Does this disable the "baro update" logic, which I think you talked about removing in a post from a few years ago?

[bubba2533]

Really cool stuff!

Does this disable the "baro update" logic, which I think you talked about removing in a post from a few years ago?

Yes and thanks!

[160plus]

Yes and No. All EGR related code and parameters are no longer functional. I used that address space for my code and parameters. Beyond that I have included tables (Stock VE & Open loop EQ) that have been modified so that tuning with the correct Axis values be seen.

Are the area's you used for the custom code taking the place of specific tables/scalers....where it would be simple to remove things from existing XDF's simply by the items ID number?

I did not change the OS with the assumption that it could still be read and wrote with commercial tools.

My personal thoughts on this are that you would want to use a custom OS number, not to prevent certain tools from reading or writing the OS but to prevent the issues that will arise by now having 2 OS's that use the same number where things should not be interchanged. The average DIY guy isn't going to read about 90% of the instruction's for something until after they brick a pcm.....and even then they may brick several before they try and determine what they are doing wrong or ask for help.

I am not signing up for creating an entire XDF when 99% of parameters are unchanged

That's totally understandable, the way XDF's are created and then coveted I feel are a large part of why more has never been done for GM stuff in comparison to the way other ECU's have had things made avaible.

If you or anyone for that matter has a better solution I'm open to changing pretty much anything

I'm typically not someone that likes to conform to what others have done but in this case I do think there is an easier and likely better(for your average Joe) way to go about this. The idea of integrating this kind of OS upgrade into an XDF is very unique I'll give you mad props for that.........but I think in the long run its going to end up creating more issues for people when there are simpler(and safer) ways to go about doing this.

My suggestion is a 2 part idea that involves separating the OS patch from the tuning aspect of the XDF.
Part 1:
I see two ways you could distribute the altered OS where its impossible for the user to screw something up.
A) distribute an OS only where the user needs to write the OS to their PCM and then flash calibration data into the new OS. This is how both EFI Live and Hp Tuners both do it and honestly it works quite well when all the vehicle/tune related code can be contained in the calibration section. However this does bring up some questions that I don't think anyone has ever really bothered to look into and that's if there is anything in the OS it self that changes based on the vehicles platform it was being used in. I would assume there is not, but with out comparing a few dozen variations of the same OS it would be impossible to say for sure.

B)Create a simple application that asks the user to select the desired file, validate the OS number and checksums in the file they select and them perform the patch and save it as a new file. It may not be as simple as applying a patch with Tuner Pro, but tuner pro does not validate the OS number of checksums so there is a massive amount of ways a person can create a corrupted file.

Part 2:
The tuning parameters you have in the XDF are great, but they are only part of what people are going to want to be able to use. I think keeping the boost only side as a simplified version for fine tuning would make sense, but also having a complete XDF that was fully compatible with your custom OS would go a long ways. In this case, rather then trying to make a new XDF, just take one of the existing XDF's and alter it. Remove what's no longer compatible and then add in the boost tables you've created following the XDF's original layout format.

Wrapping this up, I think the most ideal way to distribute a custom OS that is usable by your average Joe is going to be a zip folder with 4 files. You would either have a stand alone app that applies the patch or a bin file that has already had the patch applied, a complete XDF that is compatible with the OS and then a boost parameter only XDF that could be used for fine tuning. The last file would be a text document with a basic set of instructions on how to use the bin file(or app) and then how to build a base line tune and what tables should be populated.

[Gampy]

My thoughts and opinions ...

The OsID should be changed.

The bin mapping has changed, therefore any application that maps out the bin is now incompatible!
Sorry, but that is the facts ...

Personally I would do an XDF for the patch only (or a binary patch and a standalone patching application), and a complete compatible XDF for Tuning.
Having to open two XDF's to modify the tune would be a royal pain.

Just my 2 cents.

[NSFW]

I like the idea of new OS IDs as well. That will prevent mishaps from people accidentally mixing and matching stock-OS XDFs and boost-OS XDFs.

The existing XDFs just need the OS IDs changed to match... There's an unlocked version of a 7603 XDF sitting in a pull request in BoredTruckOwner's repo right now, and hopefully others will follow if they're needed. Then it'll be trivial to make new XDFs with the new OSIDs and the right table definitions.

[antus]

I third that. The other patched OSs out there have their own OSIDs which are great for identification. I think we should do the same. We can easily add a new OSID to pcmhammer so it'll be able to identify it. And it can be written with the same patch in the XDF so everyone who applies the code changes gets the new OSID.

[Tre-Cool]

You will probably find the EFILIVE guys might even add support for your custom OS too if we ask them. They have stated they will not be doing any custom os stuff for the earlier controllers, but they could easily remove the egt parameter code references in their existing calz files & add your new options into it or some1 could port the new tables into a cax file.

Someone for instance wrote a cax file to support a diesel ecu that efilive didnt map out but could read/flash. I know i'd probably have a play with it in something.

[bubba2533]

Are the area's you used for the custom code taking the place of specific tables/scalers....where it would be simple to remove things from existing XDF's simply by the items ID number?

Yes, My parameters are overlapping some EGR specific parameters/tables. I have the parameter range determined, so anything within that range should just be removed from an existing XDF along with the few tables that I have modified. I don't know what you mean by ID number, but I imagine the address of the parameters would be enough.

My personal thoughts on this are that you would want to use a custom OS number, not to prevent certain tools from reading or writing the OS but to prevent the issues that will arise by now having 2 OS's that use the same number where things should not be interchanged. The average DIY guy isn't going to read about 90% of the instruction's for something until after they brick a pcm.....and even then they may brick several before they try and determine what they are doing wrong or ask for help.

Based on everyone else saying the same thing I think a new OS number is in need. The next question is what should it be?

That's totally understandable, the way XDF's are created and then coveted I feel are a large part of why more has never been done for GM stuff in comparison to the way other ECU's have had things made avaible.

I'm typically not someone that likes to conform to what others have done but in this case I do think there is an easier and likely better(for your average Joe) way to go about this. The idea of integrating this kind of OS upgrade into an XDF is very unique I'll give you mad props for that.........but I think in the long run its going to end up creating more issues for people when there are simpler(and safer) ways to go about doing this.

It's the only way I knew how to do it. TunerPro seems like the only software that had the ability to patch like this. I feel like this is what it was made for, but I just took it a little further than most people.

My suggestion is a 2 part idea that involves separating the OS patch from the tuning aspect of the XDF.
Part 1:
I see two ways you could distribute the altered OS where its impossible for the user to screw something up.
A) distribute an OS only where the user needs to write the OS to their PCM and then flash calibration data into the new OS. This is how both EFI Live and Hp Tuners both do it and honestly it works quite well when all the vehicle/tune related code can be contained in the calibration section. However this does bring up some questions that I don't think anyone has ever really bothered to look into and that's if there is anything in the OS it self that changes based on the vehicles platform it was being used in. I would assume there is not, but with out comparing a few dozen variations of the same OS it would be impossible to say for sure.

B)Create a simple application that asks the user to select the desired file, validate the OS number and checksums in the file they select and them perform the patch and save it as a new file. It may not be as simple as applying a patch with Tuner Pro, but tuner pro does not validate the OS number of checksums so there is a massive amount of ways a person can create a corrupted file.

That all sounds great, but out of my realm of knowledge.

Part 2:
The tuning parameters you have in the XDF are great, but they are only part of what people are going to want to be able to use. I think keeping the boost only side as a simplified version for fine tuning would make sense, but also having a complete XDF that was fully compatible with your custom OS would go a long ways. In this case, rather then trying to make a new XDF, just take one of the existing XDF's and alter it. Remove what's no longer compatible and then add in the boost tables you've created following the XDF's original layout format.

Wrapping this up, I think the most ideal way to distribute a custom OS that is usable by your average Joe is going to be a zip folder with 4 files. You would either have a stand alone app that applies the patch or a bin file that has already had the patch applied, a complete XDF that is compatible with the OS and then a boost parameter only XDF that could be used for fine tuning. The last file would be a text document with a basic set of instructions on how to use the bin file(or app) and then how to build a base line tune and what tables should be populated.

Again, I think having better software to patch would be awesome. It would allow someone to have a much better base file since the current VE and Open Loop EQ table could be condensed into the new MAP axis and extrapolated. As awesome as that would be sadly I'm surprised I got as far as I did. I mean I wrote this patch in google sheets lol, so I don't think I'll be able to create an application like that. If someone wanted to get started on something like that I would be more than happy to help, but I may slow them down more than I would help.

[bubba2533]

Quick thought....what if the patch was a part of PCM Hammer?

[kur4o]

Again, I think having better software to patch would be awesome. It would allow someone to have a much better base file since the current VE and Open Loop EQ table could be condensed into the new MAP axis and extrapolated. As awesome as that would be sadly I'm surprised I got as far as I did. I mean I wrote this patch in google sheets lol, so I don't think I'll be able to create an application like that. If someone wanted to get started on something like that I would be more than happy to help, but I may slow them down more than I would help.

Universal patcher have very advanced patching system. As the name of the program implies it. You can compare 2 bins and create a patch for the difference by a click of a button. You can add OS numbers as filters. Use condition for the applications of the patch and so on.

Also you can make prefilled tables as a patch. For example make main OS patch separate and add different prefiiled starting tables patches that are applied later.

The best approach will be to add some numbering system of the patch version. Some free byte can be used, that way you can easily identify if the file is patched and add specific data for 1,2,3 bar options.

Top of the line is to add some search string that will find the newly added tables and if the bin is not patched there will be no tables found. [Bringing user made mistakes down to zero]