What is IPF?

[longbow75]

Can someone please explain me what this is? For all I know it's for amiga only, it holds protection info and we can't create one ourselves. Will supercard pro let us create ipf from flux file?

[admin]

IPF is file format created by KryoFlux/SPS. It is for all disk types, not Amiga. It's an attempt to make a universal disk format, but lacks the ability to support many types of copy protection. My .scp file format incorporates every possible protection because its flux level, not a decoded level.

I will not support IPF. Instead, I am working with the various emulation authors to support flux level images to achieve 100% compatibility.

[videofx]

IPF is file format created by KryoFlux/SPS. It is for all disk types, not Amiga. It's an attempt to make a universal disk format, but lacks the ability to support many types of copy protection. My .scp file format incorporates every possible protection because its flux level, not a decoded level.

This the is exact reason I did not buy the Kryoflux. I needed to be able to back up all my Atari, Apple, TRS-80, Amiga, etc and Super Copy Pro makes it easy. Kryoflux is too complicated.

[LordCrass]

IPF is meant to be used for mastering the original media, and it's not limited to Amiga. In the case of an IPF for a magnetic medium, think of it as a set of instructions for the floppy controller on how to write each track of the disk. The script language used specifically describes gaps, bit rate, checksums, data, etc.

As such, it's not easy to simply convert something to IPF. Someone has to look at the disk structure/data to determine what it all really is and then build an accurate description file from this. That is what the SPS team spent all these years doing. Some IPF files are standard AmigaDOS images with no protection, but the data has all been verified to be correct and original as far as disk structure goes (if there are bugs in a game's code that were present at manufacturing, that's a different issue).

If you were going to make a duplicate of a picture poster, you could think of IPF as an instruction list for how to draw the poster yourself, right down to coordinates to draw lines between, exact colours to use, pen type, etc. On the other hand, you can think of SCP files as a hi-res scan of the poster you fed in.

It might be nice if the SuperCard Pro software had the ability to write IPF files back to disk, but any sort of automatic creation of IPF files would be half-assed and unreliable without some serious AI behind it.

[admin]

The IPF file format is known (before it was officially posted), and it lacks thing needed to duplicate ALL copy protections. There is no AI at all. 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.

[longbow75]

I see.Thanks for all the replies. I guess now I'll look forward to .scp integration.

[RJMcInty]

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.

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

[admin]

Numerous Pysnosis titles don't convert to IPF.

IPF format is flat missing data...simple as that. It's a subset of the original flux data, converted from that data.

The *only* way to insure 100% compatibility is by using the lowest level data possible, which is what flux gives you. There is no exception to this.... period. So, if you want complete compatibility, there is only one way to go.

[RJMcInty]

Numerous Pysnosis titles don't convert to IPF.

IPF format is flat missing data...simple as that. It's a subset of the original flux data, converted from that data.

The *only* way to insure 100% compatibility is by using the lowest level data possible, which is what flux gives you. There is no exception to this.... period. So, if you want complete compatibility, there is only one way to go.

Thanks, Jim. What data is missing from IPF? I've gathered from other posts that IPF doesn't currently support GCR data, but is there anything beyond that?

What about the Psygnosis titles make it so that it can't be represented in IPF? I'm trying to assemble an actual technical list of shortcomings with details, rather than broad, sweeping statements.

Also, do you have any comment on my questions about guarantees, and verifying data, or disk formats? As one of the players in this space, it'd be great to get your detailed feedback.

I really think that the community is at an inflection point with regards to emulator disk formats, etc., and it would be great to have good, factual, detailed conversations about where it's going, and what the best course forward is. Is .scp good enough? Is .ipf good enough? Is .g64 good enough? If not, what does the ideal format look like, and is it better to evolve an existing format to meet those goals, or do we really just start all over with a new format?

I'm painfully aware of the limited time that tool/emulator authors have to devote to their hobbies, so focusing on the biggest bang for the buck is good. I don't pretend to know what the right tasks are, but I'd love to see some healthy discourse around the disk format issue before everyone goes off and starts investing in making disk images, updating emulators, etc..

Just my thoughts...

Thanks,
Robert

[admin]

Ask the KryoFlux/SPS about the short comings. That is my competition, so I am not going help point out their issues. They are documented in various forums. There is no question that flux data is the best way to go. Besides flux level images, there are no disk image formats that support 100% protection compatibility. .g64 is not bad, but it has several cases, like the density issue, that make it less than 100% compatible.

Maybe 10 years ago we were concerned with file sizes, but not now. So, flux level images are the way to go. Flux is also easier to implement than .stx/.g64/.dsk/etc. etc. The virtual disk "rotates" at the speed given during the capture and the data is fetched for each clocking period, just like the real hardware does. There is no conversion and checking for certain cases t try to make things work.