Ok, the topic sounds a bit spectacular, but in fact it's reserved for the most important stuff you might want to know about your KryoFlux device. We'll be adding posts from time to time. If you feel you have something that's worth posting here, please do, BUT don't be embarrassed if we move it to another topic.

Now there you have it... you have a disk you want to image before the data vanishes forever or you want to submit something to us for inspection, e.g. to find out why it does not resolve with a sector decoder (to generate e.g. .ADF, .IMG etc.).

Although DRAFT, our soon to come, fully open and documented format to store raw data (flux reversals) conveniently in a single file, you can already use STREAM files. These are larger than DRAFT (because they have no compression applied) and consist of one file per cylinder / side, but can lateron be converted to DRAFT if you wish to do so.

Command line:DTC -d0 -fstreamfilename -i0 -i2

This will dump the current disk in drive 0 to a STREAM file with five consecutive revolutions per track. This is important for certain protections, e.g. weak (or flakey) bits, that otherwise can not be detected. Please note that this will make a dump without error correction, which sometimes is the only option you have (e.g. own disk coding used by a game). But you can add a sector decoder (e.g. .ADF) without actually writing this data to a file. The good thing is that errors that happen during decoding will reread the track, thus also forcing the raw stream to be reread.

Command line:DTC -d0 -fstreamfilename -i0 -i2 -i5

This will dump the current disk in drive 0 to a STREAM file with five consecutive revolutions per track and will make sure that all tracks are readable. After five retries, the operation will continue and store the data anyway. This is useful because e.g. copy protection can intentionally make one track unreadable for a sector decoder. In this case, it is very likely that the STREAM file still contains all data present on the source disk and you know that the parts of the disk readable by DOS are in good shape.

You can also limit the number of cylinders dumped, e.g. to create a small archive for inspection only. Let's dump cylinders 0-2 only:DTC -d0 -fstreamfilename -i0 -i2 -i5 -s0 -e2

You might have wondered what you can do with a forensic dump stored as DRAFT or as STREAM. Well - why not keep it and then experiment with it, or convert it to something you can use in an emulator. This can be useful to inspect a partially bad dump.

Let's assume you made a forensic dump in the first place:DTC -d0 -fstreamfilename -i0 -i2

Now let's decode it, but without the hardware present. It is possible to do the following with the hardware attached, but if you make a mistake, you could overwrite your dump file. So it's safer to unplug the hardware, just in case.

As you see, DTC works like reading from a real disk. You can even omit the filename for the sector decoder (-i5) and just check the image if it decodes sucessfuly. Adding logging parameter "-l8" will reduce output to sector decoder only.

As of today, the IPF decoder library ("capslib"), which is supported by many emulators for many platforms, supports loading of our compact CT raw format. The name originates from the original Amiga Capture Tool, which has been in use since 2001. Support for direct loading of stream files via the IPF decoder library is being worked on and will be available soon.

From the very first release, KryoFlux has been able to generate CT raw files with the option -i2.

To directly create CT raw files while you are dumping an Amiga disk:

DTC -f<streamname> -i0 -f<ctrawname>.raw -i2 -f<adfname> -i5

If you already have stream files, why not convert them to CT raw?

DTC -f<streamname> -i0 -f<ctrawname>.raw -i2 -m1

So if your stream files are named like MyDump_00.0.raw the command line would be:

DTC -fMyDump_ -i0 -f<ctrawname>.raw -i2 -m1

-m1 tells DTC to not use the KryoFlux board for dumping. Instead, the reading process is kind of replayed like the data would be coming right off the disk.