PHF to HEX?

[pman92]

mycanic is newer hardware from the same company (eepod) as the MCS1 I'm using. They use the same drivers.

So does mycanic work with PTdiag as well?

What about mycanic-FD and mycanic-IOT? I see they use different USB drivers but do they uae the same J2534 DLL?

Or does only the MCS1 work with PTdiag?

[oldtinfords]

mycanic is newer hardware from the same company (eepod) as the MCS1 I'm using. They use the same drivers.

So does mycanic work with PTdiag as well?

What about mycanic-FD and mycanic-IOT? I see they use different USB drivers but do they uae the same J2534 DLL?

Or does only the MCS1 work with PTdiag?

There are different versions of PT for the MCS1, the mycanic & the FD, so I'm going to guess there will be another version for the IOT too. I'm not aware of there being separate J2534 DLL's for each device

[TripleFJeff]

To fill in a few things since DWS and I have been discussing this over PM as well.

I tried with the files DWS's tool made and it failed with an error indicating the "Last data address" had a format error. I added 2 leading spaces to it to make it match a working hex I had, and it worked with no issues. He's updated the converter to account for it.

[TripleFJeff]

mycanic is newer hardware from the same company (eepod) as the MCS1 I'm using. They use the same drivers.

So does mycanic work with PTdiag as well?

What about mycanic-FD and mycanic-IOT? I see they use different USB drivers but do they uae the same J2534 DLL?

Or does only the MCS1 work with PTdiag?

There are different versions of PT for the MCS1, the mycanic & the FD, so I'm going to guess there will be another version for the IOT too. I'm not aware of there being separate J2534 DLL's for each device

My version of PT is ancient, but it says it works with MCS1 or CarDAQ. Iirc, when I switch between the 2 versions of PT I have it has to rewrite some firmware in the MCS1 each time, so there must be some device specific stuff in PT.

[oldtinfords]

To fill in a few things since DWS and I have been discussing this over PM as well.

I tried with the files DWS's tool made and it failed with an error indicating the "Last data address" had a format error. I added 2 leading spaces to it to make it match a working hex I had, and it worked with no issues. He's updated the converter to account for it.

I had the same error with a file I created last night. I have created a new file today & result is PROGRAMMING SUCCESSFUL

[DWS]

To fill in a few things since DWS and I have been discussing this over PM as well.

I tried with the files DWS's tool made and it failed with an error indicating the "Last data address" had a format error. I added 2 leading spaces to it to make it match a working hex I had, and it worked with no issues. He's updated the converter to account for it.

I had the same error with a file I created last night. I have created a new file today & result is PROGRAMMING SUCCESSFUL

Nice! Glad it's working out well.

Now the question is, how many more of these weird file formats exist lol. There's like 6 variations of just the EEC-V 216kb bin files, seemed like no one could hold a standard back then, or it was intentional so files wouldn't work across programs. I think hex and phf are closer to real standards.

I could create a bin into a phf/hex format, but the header info would need to be populated somehow and I'd have to work out how the checksums were calculated in the header/footer so my tool could calculate it the same way. Maybe that intel standard would describe that stuff some though, I didn't look too deep into it, but I'm assuming the header/footer items were just meta data, so not strictly part of the standard.

[oldtinfords]

Now the question is, how many more of these weird file formats exist lol. There's like 6 variations of just the EEC-V 216kb bin files, seemed like no one could hold a standard back then, or it was intentional so files wouldn't work across programs. I think hex and phf are closer to real standards.

I could create a bin into a phf/hex format, but the header info would need to be populated somehow and I'd have to work out how the checksums were calculated in the header/footer so my tool could calculate it the same way. Maybe that intel standard would describe that stuff some though, I didn't look too deep into it, but I'm assuming the header/footer items were just meta data, so not strictly part of the standard.

The only other format that comes to mind is VBF

[DWS]

Now the question is, how many more of these weird file formats exist lol. There's like 6 variations of just the EEC-V 216kb bin files, seemed like no one could hold a standard back then, or it was intentional so files wouldn't work across programs. I think hex and phf are closer to real standards.

I could create a bin into a phf/hex format, but the header info would need to be populated somehow and I'd have to work out how the checksums were calculated in the header/footer so my tool could calculate it the same way. Maybe that intel standard would describe that stuff some though, I didn't look too deep into it, but I'm assuming the header/footer items were just meta data, so not strictly part of the standard.

The only other format that comes to mind is VBF

Ironically, that was already on my radar, but that's for even newer files and of my understanding there's a lot better support around those file formats except when they are encrypted of my understanding. I saw somewhere that showed the actual file format spelled out in good detail. I suspect there's probably not a need to convert phf to vbf, or vbf to hex? I'd assume the main ones are bin to vbf and vbf to bin.

[oldtinfords]

Now the question is, how many more of these weird file formats exist lol. There's like 6 variations of just the EEC-V 216kb bin files, seemed like no one could hold a standard back then, or it was intentional so files wouldn't work across programs. I think hex and phf are closer to real standards.

I could create a bin into a phf/hex format, but the header info would need to be populated somehow and I'd have to work out how the checksums were calculated in the header/footer so my tool could calculate it the same way. Maybe that intel standard would describe that stuff some though, I didn't look too deep into it, but I'm assuming the header/footer items were just meta data, so not strictly part of the standard.

The only other format that comes to mind is VBF

Ironically, that was already on my radar, but that's for even newer files and of my understanding there's a lot better support around those file formats except when they are encrypted of my understanding. I saw somewhere that showed the actual file format spelled out in good detail. I suspect there's probably not a need to convert phf to vbf, or vbf to hex? I'd assume the main ones are bin to vbf and vbf to bin.

If vbf to bin & bin to vbf were added, that would be great. An all in one tool

[DWS]

Yea that's effectively my ultimate plan long term, open up all of the main file formats so you can convert between them freely and be able to use whatever software you want that doesn't encrypt their files. Read using PCM flash, convert and edit with say an XDF, then convert to a hex file and write with another program. Seems kind of silly it's not standardized but I guess that's just how things are.

On my site, when a file is being modified, it's converted to a standard format, then converted to whatever the user chooses (defaults to the same format it was sent as). Supporting all of the different layouts/formats isn't really that hard, but a lot of software devs I guess don't want to put in the time and effort on that side of thing.

Anyway, I'd have to read up more on VBF files again and see what all is involved. Going to the formats with headers might need a bit of extra work to really make them supported well. Like the computer type probably should be a drop down and as I add detections of each type it could be more automatic. That side of things can get complicated fairly fast to really make it a smooth and automatic experience.

Also knowing what software requires what format is a big help too. Like we more or less have learnt that PTdiag requires the 2 space prefix format, but other software might require a different number of spaces for hex files, or maybe more spaces is fine but too little causes issues. That's kind of the problem with file formats that aren't super strict on their standard some programs expect some broken version of the standard while another program might be a different version of the broken standard. I did notice older PHF files seem to have 2 spaces, newer got 1, then the newest ones seem to have no spaces, so maybe it's just PTdiag being updated through the years or something, don't really know the history that well, just what I can see in the files.

Bin files on the other hand seem to be fairly rock solid on their formats, one of the banks sometimes grows or shrinks a bit for different padding standards, then the fully padded 256kb format is the most universal which is probably why tuner pro uses that format for the EEC-V and IV computers. I guess same issue, different way it's presented, instead of spaces in a header, it's padding in the file.

On the space thing in PHF and HEX files, it would be awesome to investigate that deeper and maybe we can work out it's version x to y for this format, y to z for another, etc. The more detailed that stuff can be, the better the end user can be sure they have the right format selected.

Either case, working with file formats is kind of neat, gives me a bit of a break from working out assembly code, hardware, documenting, etc (going fairly hard on the EEC-V computers). Talking about that, I probably should make a post about my little project to see if anyone wants to help by submitting photos and such.