I have a bin in the middle of a stack that I am trying to tune. Under TP4 I created an XDF for the offset I needed and built the stacked BIN and could tune away with my Ostrich with no issues.
Recently I upgraded to TP5 and I can load the XDF and the stacked BIN I created in TP4 without issue. I can also make changes in RT but when I save and re-open the changes are lost.
Also, it appears the checksum is not updated in RT mode so the PCM flashes the CEL rapidly and runs in limp home mode when I ignition cycle the PCM. I don't remember that happening in TP4 but that could be conveniently forgetting that bit.
Any suggestions on how to get changes to a BIN in a stack to save into the stacked BIN file? Also, is there any way to get the checksum to update after every commit when tuning in RT such that there is no need for a manual upload?
Thanks,
Jeff
RT changes work in TP5 but save doesn't
Moderators: Mangus, robertisaar, dex
Almost certainly not a bug.
Check that the bin size in the XDF header appropriately matches the bin. Also, make sure the delta of your edit is larger than the resolution of the item you're editing.
If it's not that, please email me your XDF, bin, and steps to reproduce and I'll get you squared away.
Check that the bin size in the XDF header appropriately matches the bin. Also, make sure the delta of your edit is larger than the resolution of the item you're editing.
If it's not that, please email me your XDF, bin, and steps to reproduce and I'll get you squared away.
***************************************
TunerPro Author
1989 Trans Am
TunerPro Author
1989 Trans Am
Thanks Mark. Glad to hear it's not likely a bug as that should mean an easy fix.
I double checked the math but that doesn't mean I didn't make the same mistake twice!
The PROM I am emulating is for the very first GM TPI which was 4 kB (the only year for that size as far as I can tell).
So I found an XDF which had the correct bin size of 1000 (hex) and I never messed with that part again.
For reasons I don't really remember I configured the Ostrich for a 64 kB PROM which gave me 16 4k "slots". I am using a bank switch on the MSB and because of how I tied the other pins I end up needing to use "slots" 7 and 15.
So the XDF I was using in this case was set for an offset of 7000 (hex) and the alternate tune XDF for the other bank (which I did not test) used an offset of F000 (hex).
The file size of the stacked bin file is exactly 65536 bytes which also looks OK.
The table I am modifying has big changes (30%) in the midrange of an 8 bit table so resolution shouldn't be an issue.
If that isn't enough info I can send the files in question.
Thanks,
Jeff
I double checked the math but that doesn't mean I didn't make the same mistake twice!
The PROM I am emulating is for the very first GM TPI which was 4 kB (the only year for that size as far as I can tell).
So I found an XDF which had the correct bin size of 1000 (hex) and I never messed with that part again.
For reasons I don't really remember I configured the Ostrich for a 64 kB PROM which gave me 16 4k "slots". I am using a bank switch on the MSB and because of how I tied the other pins I end up needing to use "slots" 7 and 15.
So the XDF I was using in this case was set for an offset of 7000 (hex) and the alternate tune XDF for the other bank (which I did not test) used an offset of F000 (hex).
The file size of the stacked bin file is exactly 65536 bytes which also looks OK.
The table I am modifying has big changes (30%) in the midrange of an 8 bit table so resolution shouldn't be an issue.
If that isn't enough info I can send the files in question.
Thanks,
Jeff