Proper P01/P59 Hard spark cut LC and rev limter fix

[dubcrazy8392]

In another thread i was struggling with the normally unavoidable issue with custom coding anything spark cut like launch control using the common method of forcing the coil dwell to 0 to make it skip spark events. This angered the TPU inside most of the P59 ECU's. would make the engine shut down because it seen the normal dwell than 0 dwell bounce as a problem and shuts down to prevent engine damage. After many attempts with this i could only half fix it. I started researching the methods used in various standalone systems and discovered that some actually modify the signal coming from the crank sensor essentially masking teeth per every engine rotation. i thought this was a rather interesting solution and went to work disassembling the P59's code to figure out how the crank sensor works. i'll skip the super technical stuff but i figured out a code patch that does what high end standalone systems do by manipulating the crank sensor signal to achieve a spark cut. This actually works way better in the P59 than the previous forcing of 0 dwell which gave the engine more of a mechanical on/off sound and effect to it. This new method sounds and acts more like a high end standalone systems with more of a stumble type cut.

What i did was use claude AI to whip up a small windows program that will scan either P01 or P59 BIN file to see if its possible to patch it with the custom code and if it passes all the checks you can apply the code patch to the BIN right in the program. I have not tested this on P01's to see if it actually works as i do not have any direct interest in the P01 because it is inferior to the P59 in every way though the apple fell from the same tree its relatively easy to support the P01 if your doing P59 work anyway. This was built with operating system 12587603 originally so that one at least is confirmed 100% working. read the notes in the program as well please. Lastly, if you have boost OS patched to your BIN file you would have to disable all of the spark cut functions in boost OS and use the new patched ones since boost OS uses the old dwell time based cut that angers the TPU.

This is only a VSS based launch control so if you do not have vehicle speed wired to your ECU this is not for you. There is also the hard spark cut rev limiter in there for those of you who like to party extra hard. put your stock fuel cut limiter higher than the spark cut limiter if your a party animal that likes all the fire, flames and bald eagles, and american flags coming out of your exhaust lol.

I used AI to build this so it gave me some notes as well.
- What to report if scan fails: the exact fail message from the log, the file size, and ideally the OS ID it shows
- VSS RAM address caveat: remind them the default P01 address (A0C0) may need adjustment depending on their variant, and that the UI lets them override it before patching
- Checksum reminder: the bold warning is already in the notes but worth calling out in the post too — TunerPro + checksum plugin before flashing, no exceptions
- The patched file: it saves as <original name>-LC-patched.bin in the same folder as the source BIN

Well thats it. Have fun with this! If you break your shit using it not my problem. brick your ECU, not my problem. This is free stuff so what would you expect right? if you test on the P01 platform or other P59 OS's outside the 12587603 OS and you see negative results other than expected i'd like to hear about those. I dont spend much time on the internet anymore so if anyone comments here dont get pissed if im not sitting on my keyboard anticipating to reply back.




Version 1.02 does the checksums automatically now as antus suggested. i just did a quick dirty and made it use the the tunerproRT P01-P59 checksum DLL well because that works pretty good! make sure the checksum dll stays in the directory with the exe.

[dubcrazy8392]

Ok, do not use the V1.00 file. found a mistake claude made in making it. the V1.01 has it fixed in the first post. oh and i forgot to mention to flash entire with PCMhammer to make this code work in your ECU.

[antus]

Motorsport features patcher. Excellent idea! But is the UI meant to look like this? Could be related to hi-dpi screen or dark mode or similar. It looks like it hasn't scaled the text and the window in the same way.

Also if you are using claude it shouldn't be hard to add checksum correction, and MPH / KPH settings for different regions. I'd suggest also asking it to persist settings to an ini file (or similar) so that those of us in KPH countries can set and forget and leave it on a NAS and it'll always use that setting when run. Its also a nice tweak to get it to generate and apply a main window icon and file icon as well.

[Knackersjewels]

Motorsport features patcher. Excellent idea! But is the UI meant to look like this? Could be related to hi-dpi screen or dark mode or similar. It looks like it hasn't scaled the text and the window in the same way.

Also if you are using claude it shouldn't be hard to add checksum correction, and MPH / KPH settings for different regions. I'd suggest also asking it to persist settings to an ini file (or similar) so that those of us in KPH countries can set and forget and leave it on a NAS and it'll always use that setting when run. Its also a nice tweak to get it to generate and apply a main window icon and file icon as well.

I think thats on your end Antus, it looks fine for me

Capture.PNG

In going forward, can it possibly work as a shift cut too? Or not interested?

[dubcrazy8392]

Motorsport features patcher. Excellent idea! But is the UI meant to look like this? Could be related to hi-dpi screen or dark mode or similar. It looks like it hasn't scaled the text and the window in the same way.

Also if you are using claude it shouldn't be hard to add checksum correction, and MPH / KPH settings for different regions. I'd suggest also asking it to persist settings to an ini file (or similar) so that those of us in KPH countries can set and forget and leave it on a NAS and it'll always use that setting when run. Its also a nice tweak to get it to generate and apply a main window icon and file icon as well.

yeah i can add checksum calculation later. as for the units of measure its pretty good at between 2-5mph anyway. if your using it for actual serious drag racing you want the LC function to deactivate almost instantly. over all i know there is much more that could be added to it but i just wanted to get a solution out there after hearing about how many was plagued by the same problems i had with forced 0 dwell killing their engines. it was embarrassing first time i went to a street race and lost all because the truck shut off on the launch the first time and the second time it made through the launch but when it hit the spark cut rev limiter the TPU freaked out and shut the spark down again for another big loss. that was my motivation to make it work right. spark cut gets way more attention at a race than the stock fuel cut ones does.

[dubcrazy8392]

In going forward, can it possibly work as a shift cut too? Or not interested?

i thought about flat shift and i know how to build the routine to add it in there but i i need to write into the app how to seek out the RAM for several other variables like the clutch switch flag bit, TPS for DBC and DBW in the P59's and than do it all over again in the P01's. than its getting people to actually add clutch switches to swapped vehicles that complain because the flat shift does work on their vehicle. anyhow gotta have support for both DBW and DBC, one or the other would throw a fit if they couldnt use it or it didnt work for them lol. it could be added it later over all though when? i dunno, when i feel like adding it.

[antus]

I think thats on your end Antus, it looks fine for me

Nah, it doesn't handle hi-dpi scaling. It must have layout done differently to however most apps use. I have a 4K main display and pixels are microscopic so I run 150% desktop scaling. I put it back to 100% and it looks normal. But every other app scales fine, so it is something in how the form was built (using the wrong unit type?). It'll probably just take a statement to claude that it's not scaling properly on hi-dpi screens and ask it to check the units are using the right measurement type and update so that it does scale normally. You can probably set your scaling to 150% regardless of desktop res just for test and I reckon it'll go weird for you too.

[dubcrazy8392]

I think thats on your end Antus, it looks fine for me

Nah, it doesn't handle hi-dpi scaling. It must have layout done differently to however most apps use. I have a 4K main display and pixels are microscopic so I run 150% desktop scaling. I put it back to 100% and it looks normal. But every other app scales fine, so it is something in how the form was built (using the wrong unit type?). It'll probably just take a statement to claude that it's not scaling properly on hi-dpi screens and ask it to check the units are using the right measurement type and update so that it does scale normally. You can probably set your scaling to 150% regardless of desktop res just for test and I reckon it'll go weird for you too.

i put another V1.02. download and try that one. claude said this about the problem and fixing it.
- ApplicationHighDpiMode = PerMonitorV2 in the csproj — tells Windows the app is DPI-aware per monitor, so the OS doesn't bitmap-stretch it (which is what causes the blurry/wrong-scale look on HiDPI)
- AutoScaleDimensions = new SizeF(96F, 96F) + AutoScaleMode = AutoScaleMode.Dpi — WinForms baseline is 96 DPI (100%). At 150% scaling (144 DPI) everything gets multiplied by 1.5; at 200% (192 DPI) by 2.0. All control positions and sizes scale automatically.
- Fonts were already correct — 9f, 8.5f, 9f are all in points which are device-independent units and scale naturally with DPI. No change needed there.

hope this fixes the problem because i cant replicate it personally.

[antus]

Same result. Maybe it's because I've got 3 displays, and display 1 & 3 are at 100% and display 2 (center) is at 150%?
BTW I see the checksum dll, I dont think you need that, all it does is skip the segments in the middle of the OS sectors because tunerpro only sums contiguous ranges. Since you have your own code, you should be able to easily implement it from the app native. This is my code from the original version. The type and ranges are in the XDFs, the plugin just implements these two jumps since tunerpro cant have multiple ranges for a single sum.

Code: Select all

                for ( UINT ui = pCalcInfo->dwRegionStartAddress; ui <= pCalcInfo->dwRegionEndAddress; ui+=2 ) {
					// implement os hack jumps, real start and end are configured in xdf, this just jumps unchecked parts
					if (os_hack && ui==0x500) { ui=0x502; OutputDebugString("Skip 0x500->0x501");}
					if (os_hack && ui==0x4000) { ui=0x20000; OutputDebugString("Skip 0x4000->0x1FFFF");}
					temp=pCalcInfo->pBaseData[ui]<<8;
					temp+=pCalcInfo->pBaseData[ui+1];
					wChecksum -= temp;
				}

[AngelMarc]

Messing with input data sounds like a hacky piggy bag thing that could really throw of spark timing as it cuts in and out.
Maybe there's some way you did it that's perfect though. Obviously, I can't say for sure how sane it is without knowing exactly how the ECU is programmed, or exactly how your code interacts with the stock code.