pcmhacking.net

antus wrote:The initial screen shot shows an "Intel 28F800B" detected, and then it says that the PCM size is 0.

The error comes from here, specifically pcmInfo.ImageSize

https://github.com/LegacyNsfw/PcmHacks/ ... er.cs#L221

Then we see "PCM and file are both the same hardware P01_P59" BUT it is using that because it has used the default clause, which dates back to the earliest days of PCMHammer, even ls1flash-free before that. That default clause, when an OSID is not recognised, contains:

https://github.com/LegacyNsfw/PcmHacks/ ... fo.cs#L843

Code: Select all

                default:
                    this.IsSupported = false;
                    this.KeyAlgorithm = 40;
                    this.Description = "Unknown";
                    this.ImageBaseAddress = 0x0;




Love your work, that makes sense. I haven't tried v21 again with the calibration modified slightly, and v20 works with every write option.
                    this.ImageSize = 0;  <---------------------
                    break;

So, the simple fix is to get a description of what OSID naming conventions BoostOS does and will be using. Maybe section of some namespace for that purposes, like EFILive and HPTuners COS have done. Then we can add some logic that will detect BoostOS OSIDs and set ImageSize to 1024*1024 (1Mb). 76xxyyyy where 76 is P59 BoostOS, xx is major version, yyyy is minor version?

Then the better and additional part of the fix is to get rid of the default clause and error more clearly that an OSID is unknown. Also update that size comparison to compare against the size of the detected flash chip, not the image size looked up from OSID.

Edit: Having said that, clone write works for me also. I have also tested a calibration write, with the same file, and the results are as originally reported. So I guess this check is not triggered in the clone code path, but is in the cal code path. That in itself might also be a bug.

Edit2: Of course! Its related to the OS that is on the PCM. So if you are writing a BoostOS over a known OSID, such as your initial clone, then the check passes because the size was looked up from the PCMs original OSID. Then once it has BoostOS on it, you loose the ability to write because next time it'll not be able to find the BoostOS id. Fortunately, it looks trivial to improve this situation, as the flash chip type is retrieved only a couple of lines before hand and is in scope, so it's simple to refer to the flash size, rather than the size recorded against the OSID. It'll just take some time to clean this up properly and remove the size from the OSID. I can't see any reason hard coding this is necessary when we can always pull the flash chip type.

I still want to add BoostOS officially. Information about OSID naming convention is welcome, that can go in at the same time.

antus wrote: Then we see "PCM and file are both the same hardware P01_P59" BUT it is using that because it has used the default clause, which dates back to the earliest days of PCMHammer, even ls1flash-free before that. That default clause, when an OSID is not recognised, contains:

https://github.com/LegacyNsfw/PcmHacks/ ... fo.cs#L843

Code: Select all

                default:
                    this.IsSupported = false;
                    this.KeyAlgorithm = 40;
                    this.Description = "Unknown";
                    this.ImageBaseAddress = 0x0;
                    this.ImageSize = 0;  <---------------------
                    break;

                // usa 12586243
                case 12587603:
                case 12587604:
                case 76030003:
                case 76030004:
                case 76030005:
                case 76030006:
                case 76030007:
                case 76030008:
                case 76030009:
                    this.KeyAlgorithm = 40;
                    this.Description = "12586243";
                    this.ImageSize = 1024 * 1024;
                    break;

Knackersjewels wrote:And Bubba, It'd be awesome if I could get a few tips on how the launch control is implemented, I had an issue where I enabled it at >70% tps, and it would spark cut while driving. Especially bad if downshifting, and giving a boot full, where rpm was higher than the launch rpm, the ecu would cut spark, but because rpm was 2000 above the launch limit, it would keep cutting spark even once the rpm was below launch rpm, I had to shut the car off to get it to reset to normal. Hope that makes sense.

I've since set the launch tps to 98%, but I feel it's either something I set incorrectly, or a glitch that may need addressing.

The OSID's were added quite some time ago I believe, but there hasn't been an official release since that time.