RT changes work in TP5 but save doesn't

[jsiddall]

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

[Mangus]

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.

[jsiddall]

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

[Mangus]

Crud. I missed the stacked bin piece of the puzzle in your original post. This is indeed a bug. I'll fix it for the next build. I won't be able to release a build until late next week.

Apologies.

[jsiddall]

Thanks Mark. I appreciate the quick response on this.

Jeff