IPF image database

[mr.vince]

Because Kaffer just hacked it in as RAW data. For the sake of being able to understand and verify it, you don't store raw, but scripted data, e.g. with checksums for replication. Nearly all disks have checksums for replication, but those four don't, at least not on this level. Apparently the ingame loader has some checksums stored.

So yes, it's understood how to bang this data into an image, but it can't be verified on the transport level. All upcoming versions of DTC will spit out verify errors. The current one does not yet verify IPFs (hence we say DO NOT USE unless you know that it does not).

I already invited Kaffer and we emailed. We don't yet fit together is the best explanation I guess.

[TCD]

Originally Posted by mr.vince

So yes, it's understood how to bang this data into an image, but it can't be verified on the transport level.

I really just mean to understand this bit, so sorry if I'm 'nagging' This means that if it can't be verified on that level, there will never be an IPF of it?

[mr.vince]

Unless the transport layer is properly extended by a new format (read above its not MFM compliant) and the properly scripted.

And yes, can be done, just takes much longer than chucking in blobs of raw data.

If you wonder why we don't "cheat", look at any other floppy controller project and check how many besides KF write Amiga disks (and many more) in general, regardless of copy protection, properly.

[dlfrsilver]

i wonder which computer this protection was written on (read, since it's not MFM, on which computer did they wrote the master before going on duplication ?).

Would be good maybe to ask giulio zicchi or justin garvanovic hehe

[Keir]

Originally Posted by mr.vince

Because Kaffer just hacked it in as RAW data. For the sake of being able to understand and verify it, you don't store raw, but scripted data, e.g. with checksums for replication. Nearly all disks have checksums for replication, but those four don't, at least not on this level. Apparently the ingame loader has some checksums stored.

So yes, it's understood how to bang this data into an image, but it can't be verified on the transport level. All upcoming versions of DTC will spit out verify errors. The current one does not yet verify IPFs (hence we say DO NOT USE unless you know that it does not).

I already invited Kaffer and we emailed. We don't yet fit together is the best explanation I guess.

But the IPF format does not have structure to explicitly call out checksums in track formats. It does divide up sectors/blocks within a track, differentiate between data and gap, and explicitly encode sync words. That's about it. Kryoflux write verification can't be based on the checksums present in the track format being written therefore. And why would it, presumably you do a bit-by-bit comparison of the written data with the original, using sync/block/gap information to synchronise with the data as it is read back for verification.

Anyhow this is only technical nitpicking. It will be nice for IPF to explicitly support the Psygnosis non-MFM coding.

[Keir]

Originally Posted by dlfrsilver

i wonder which computer this protection was written on (read, since it's not MFM, on which computer did they wrote the master before going on duplication ?).

Would be good maybe to ask giulio zicchi or justin garvanovic hehe

It could be written by an Amiga (with standard bitcell timing of course). Amiga disk controller writes the given raw bitcell stream with standard MFM DD bitcell timing.

[IFW]

As far as I remember they were written on commercial duplicators, as they used longtracks and the graphs show no precompensation problems - a standard controller can't write that dense data without generating random peakshifts due to poor precomp.

Just to clarify: IPF writing is the only writing function without a verify in DTC now. Everything else is fully verified, even things that were originally not
IPF will have verification as well, but it will only work if the data and context information are fully separated. If they are not, verify will always fail, as no two disks written ever are the same - what you need to verify is genuine data content, but for that to work you need to know what exactly the data is, and what is something else - usually gap.
All "official" IPFs files have the context and content data separated.
This also makes it possible to compare two ipfs and tell if they are different versions of the same game or not - you can simply compare the pure content, ignoring context.

[IFW]

Another thing worth keeping in mind is that IPF stores data and context and using those the actual data is being generated on the fly, depending on the type of operation suitable for emulation or suitable for writing or suitable for verification.
This saves on space (don't care these days... but did matter 10 years ago), plus makes it possible to manipulate the context without changing the content, e.g. write the data properly and automatically without too much magic involved, but knowing in advance where it is actually required

Kaffer is right, checksums etc are don't care for verification during writing.
As far as a file is concerned they don't exist or matter at that stage - they only matter when you create the master image (in our case the IPF file) in the first place.
What does matter is knowing exactly which part of the data should match, and which part is don't care - within reason... e.g. weak bits, no flux reversal areas etc.
Data that should match must fully match, that simple in theory in practice it can get very complicated when said data is mixed with weak bits.
The usual solution for mastering such data was to completely turn off verification for that track in your Trace script, I'd hope DTC will do slightly better than that though

[IFW]

There were three main reason for not posting IPF files when they appeared:
1, Since the main CAPS forum was this, it would have made the entire forum look like a piracy-hub...
2, The first few dozen preserved titles had complete scans included, potentially killing the EAB bandwidth very quickly...
3, It wouldn't have looked right for the developers and companies who did contribute - and still wouldn't. Preservation and distribution are two very different things.