12-29-2013, 02:50 PM
(12-28-2013, 04:15 PM)admin Wrote: The IPF file format is known (before it was officially posted), and it lacks thing needed to duplicate ALL copy protections.
I've seen this comment a couple of times, but have never seen an actual list of protections methods that can't be represented. Can you give some examples, and why the format falls short? If you (or someone else) have already done this in another forum, please just provide a link, and accept my apologies.
(12-28-2013, 04:15 PM)admin Wrote: IPF files could be generated by any program and we could write IPF images back to disk, but there would be no guarantee that the copy would work. So, this is a format that will never be supported.
Can you elaborate on any guarantees of successful writing? I'm specifically interested in how you're doing that, and how .scp files offer capabilities that .ipf, or KF .raw files don't.
The only way I can think of to make any guarantee is to take a flux-level dump of the destination disk after writing, and compare it flux-for-flux with the source dump. If it's the same, it's as guaranteed as you can be; if not, then there's no guarantee. That method should be possible regardless of the flux storage format (.scp, .ipf, .raw, etc.).
I do see that using the .ipf format introduces a data conversion step (raw flux to .ipf description), but other than that, I don't see how there's any difference otherwise with regards to rewriting verification. Also acknowledging that at this point there is no end-user available raw-to-IPF converter, and that KF doesn't write raw streams to disk, but still curious about these questions from a technical standpoint.
I'm still on the fence about whether I think yet another disk format is really needed. WinUAE already supports the IPF format, and WinVICE supports (ok, mostly supports) the .g64 format. WinVICE needs to be updated to fully support the variable density functionality of .g64, and there might be some other protection that can't be represented but not sure what that would be.
I guess my concern is that if another emulator format is introduced, it will take more time and effort to get it supported by emulators than it would to update the existing formats/support to make them even more compatible.
Thanks!
Robert