Have these Amiga games been dumped?

[mr.vince]

Would you mind using PM for this, or using a separate thread?

[BarryB]

Well, i've bit the bullet and ordered the Kryoflux Personal Edition Premium (I actually kept calling it kYRoflux for some daft dyslexic reason!!)

So now I can write IPF's of most of my originals, except those not IPF'd already!!

And I've submitted 2 test dumps to the SPS FTP and notified them so they can see which of my 2 drives is best for dumping!!

[mr.vince]

Thanks, will be checked.

[BarryB]

I have a 2nd external Amiga drive for dumping, an Amitek, if needed!! But, I may as well wait until I have my Kryoflux and dump with that.

Also, I have the following PC floppies for use with the Kryoflux:

ALPS DF354N113F
SONY MPF920-E
PANASONIC JU-257A607P

Which of the above 3 will be suitable?

[Keir]

The majority of PC drives work fine for dumping Amiga DSDD disks. Just try them out on a known-good AmigaDOS disk when you get the Kryoflux. Probably you will find all three drives work!

[Keir]

It's an interesting track format. It's not MFM, but instead a variable-length encoding which provides the same guarantees on flux density as MFM. That is, that there will be between 1 and 3 quiescent bitcells (0 bits) between every flux-reversing bitcell (1 bit). The encoding efficiency is at least as good as MFM: its encoded size is always between 1.5x and 2x larger than the original data.

To discount a few myths about this format:

There is a checksum per track, however you must decode the track to get the checksum. Possibly this was beyond the Trace machines used to do duplication back in the day, but for WHDLoad installers, mfmparse, and the like, it is quite possible. So it will be possible to verify disk dumps without having to run the entire disk through the game's track loader.

I also read that this format achieves the theoretical best encoding efficiency. Well, that's a bold statement as reasoning about encoding efficiencies gets into some exciting information theory. Certainly it is data-dependent how much better this scheme is than MFM -- for certain data it will perform no better (but also no worse!). It is also the case that for most data, packing it and then using normal MFM will be more efficient -- that's how the original cracks of these games can easily fit on the same number of disks (also, the disks generally aren't full in the first place!).

[dlfrsilver]

Thanks for clarifying these Good to know that finally there is checksums used on tracks !

[BarryB]

Ok, have now got my Kryoflux

Have set it up according to the instructions, wrote an IPF and checked it works on my Amiga (which it did) so the drive I'm using (Sony MFP920-E) seems OK.

If I want to start contributing Kryoflux dumps do I need to do a test dump or use specific commands?

Have also used the Linux tools by kaffer (great bloke ) to create and write some IPF's of my own so it appears the Kryoflux is working.

[mr.vince]

Originally Posted by kaffer

There is a checksum per track, however you must decode the track to get the checksum. Possibly this was beyond the Trace machines used to do duplication back in the day, but for WHDLoad installers, mfmparse, and the like, it is quite possible. So it will be possible to verify disk dumps without having to run the entire disk through the game's track loader.

Ok, so you don't run it through the game's loader, but your own loader, which on top also needs to understand this special transport layer, which is not MFM compatible. Don't see where this is less work, because you basically implement a completely "insane" format with no real advantages, that needs to decode a stream from the beginning to the end to get the data.

Trace would expect the checksum to be added to the end of the raw data for verification purposes, which does not work, because there is none and I am pretty sure that if there was, Trace would have had a problem with the way the data was written anyway. At least it can not decode it from the stream.

This means that to add these four games to any toolchain, you put in a lot of work, to just support these four games. It's therefore been shelved for the time being, at least on our end, to be implemented with the next big overhaul of the Analyser.

Originally Posted by dlfrsilver

Thanks for clarifying these Good to know that finally there is checksums used on tracks !

Well, it's not available for any tools, as written above, unless you code your own decoder, which is not standard MFM (see above again), so much work. And not trivial for anyone not coding, hence all you can do is actually play it.

Originally Posted by BarryB

Ok, have now got my Kryoflux

Have set it up according to the instructions, wrote an IPF and checked it works on my Amiga (which it did) so the drive I'm using (Sony MFP920-E) seems OK.

Sweet. The Sony is a good choice (only 82 tracks, but has all the bells and whistles needed otherwise), ALPS is really worse.

[Keir]

Got Nitro, KGS, Obitus supported in mfmparse now, and generating good IPFs. Just a bit more work to do for Armour-Geddon -- a few more track formats in that one...

[dlfrsilver]

Now since you've made working IPF, i don't understand the story SPS told us.

They said it was not possible since the SPS library lacked the "transportation" layer.

And now Kaffer has made IPF XD !

Any explanations would be good.....

[Abaddon]

Originally Posted by kaffer

Got Nitro, KGS, Obitus supported in mfmparse now, and generating good IPFs. Just a bit more work to do for Armour-Geddon -- a few more track formats in that one...

Ill test out your mfmparse update with Nitro NTSC version and let you know if it works. Are you looking for raw streams of games to add to your parser? I have several Synergy releases that all have the same disk format and many other raw steam dumps as well.

[Keir]

Originally Posted by dlfrsilver

Now since you've made working IPF, i don't understand the story SPS told us.

They said it was not possible since the SPS library lacked the "transportation" layer.

And now Kaffer has made IPF XD !

Any explanations would be good.....

The tool that SPS use to make their IPFs needs extending in order to handle these Psygnosis games. However, SPS recently released source code for their IPF decode library, and that has allowed others to reverse-engineer and support the format. So, in short, I do not use SPS's analyser tool.

[Keir]

Originally Posted by Abaddon

Ill test out your mfmparse update with Nitro NTSC version and let you know if it works. Are you looking for raw streams of games to add to your parser? I have several Synergy releases that all have the same disk format and many other raw steam dumps as well.

Yeah, always looking for more raw streams! Cheers!

I have a small queue of stuff to do (Armour-Geddon, double check of some apparently unused Obitus tracks, and an old Rob Northen hidden-sector protection on Time). But not a great deal.

[kipper2k]

@Kaffer

I'm kinda confused with your statements about the Psynosis games. Are you saying that you have created an ipf of KGS and able to write it ?

[Keir]

Originally Posted by kipper2k

@Kaffer

I'm kinda confused with your statements about the Psynosis games. Are you saying that you have created an ipf of KGS and able to write it ?

Yes.

[Interceptor]

Originally Posted by dlfrsilver

Now since you've made working IPF, i don't understand the story SPS told us.

They said it was not possible since the SPS library lacked the "transportation" layer.

And now Kaffer has made IPF XD !

Any explanations would be good.....

well firstly, lets get Kaffer's definition of a "Good IPF"

[Keir]

Originally Posted by Interceptor

well firstly, lets get Kaffer's definition of a "Good IPF"

Fully working to the extent of the original game disks on real Amiga or emulator.

[Interceptor]

Originally Posted by kaffer

Fully working to the extent of the original game disks on real Amiga or emulator.

That seems to be most people idea of a good IPF.

Thing is though, the official releases are checked as authentic, so we know we aren't releasing tarnished/modified images out in the wild.

hence the preservation aspecdt of it, without this, IPF just becomes yet another disk image container.

[Keir]

Originally Posted by Interceptor

That seems to be most people idea of a good IPF.

Thing is though, the official releases are checked as authentic, so we know we aren't releasing tarnished/modified images out in the wild.

hence the preservation aspecdt of it, without this, IPF just becomes yet another disk image container.

I had a discussion with SPS about this. It is not my intention to have my generated IPFs be confused with SPS-generated and -blessed archival quality images. I stamp my IPF headers with some magic values to make them particularly easy to spot. Further more, of course, SPS keeps CRC32 values for all their blessed images, so this is another way to distinguish between them. This could be beefed up to sha1sum or similar if collisions (accidental or forged) were a concern.

IPF can be a general-purpose container *and* the preservation format of choice.