Have an idea how to make KryoFlux even better? Let us know...
Post Reply
Posts: 27
Joined: Sun Aug 14, 2011 9:40 am


Post by hawui1 » Sun Oct 28, 2012 1:15 pm

Do you have or do you plan to release an SDK (in the form of a DLL or static lib) to allow to other applications to take advantage of your Card.. ?
A library with command about resetting the card, stepping drive's head, turning motor on/of and of course extracting the raw track data, decoding MFM etc..
That would be very nice..

User avatar
Posts: 2634
Joined: Mon Nov 08, 2010 2:42 pm

Re: SDK ?

Post by IFW » Wed Oct 31, 2012 12:12 pm

You can already use DTC as a backend application on several platforms, capture its output, messages and files generated then use them in a frontend like the GUI does. The other details are all taken care of by DTC and you are free to use as low level (stream files) or as high level (sector images) images as you want. You can adjust the sampling process as well through the various parameters. The whole process itself is very complex, and it's not a matter of controlling the motor, or telling the system to convert from MFM etc. - there are many layers of interaction that should all work in their specified order to get the desired results. Exposing them partially is meaningless.
Therefore, a few use cases and sound justification would be nice, that would highlight what would be the exact advantage of not using the existing system as a backend.

Jim Battle
Posts: 1
Joined: Sat Apr 27, 2013 9:11 am

Re: SDK ?

Post by Jim Battle » Mon May 06, 2013 7:39 am

IFW, I just got a kryoflux to replace the seemingly now unsupported catweasel card. Besides, I have a bunch of floppies in a format where the transitions are so slow that the 8b catweasel counter is not nearly enough to capture all the information.

Anyway, I'm now faced with the job of warming over my old code to get it working with the kryoflux. The core decoder will be largely unchanged, but this model of launching shell jobs in the background is kind of clunky. My current code does something like this pseudocode:

Code: Select all

foreach track 0 to 76
   step to this track
   sectordata = []
   foreach try 1 to 10
       capture 1.2 revolutions of stream data
       decode the sector data for any uncaptured sectors
       break try loop if all sectors are now captured
The nice thing about this approach is most tracks are decoded on the first try so I can very quickly step through maybe three tracks per second. With the kryoflux scheme, the most efficient way to run is to launch a command requesting the kryoflux to capture all the tracks to .raw files, then run my program to decode it all. It seems like -i0 causes the -r parameter to be ignored so every track captures 5 revolutions of data, taking one second per track. But ignoring that hiccup, if I really wanted to keep my current structure, I'd have to launch a command for each try of each track. Having 77 temp files or launching dtc 77+ times per disk just feels like a hack. I can understand that exposing all decoding logic via an API would be a lot of work, but, hey, that isn't my concern. I just want raw stream data access, since the formats I'm decoding are oddballs that kryoflux won't ever have support for.

User avatar
Posts: 2634
Joined: Mon Nov 08, 2010 2:42 pm

Re: SDK ?

Post by IFW » Mon May 06, 2013 2:05 pm

The -r parameter uses the minimum setting found while processing all of the image formats requested.
Since you set a preservation image with -i0, the minimum number of revolutions automatically becomes 5.
You can always increase the number of revolutions from the minimum, but you can't set it lower.
This is by design, to avoid bad or unusable dumps.

If you do not need the preservation settings, use -i0a instead.
Please read the manual about the difference between -i0 vs -i0a.

What you do could be simplified and made much faster easily.
Just dump the whole disk normally, then check the track content, and only after that should you invoke DTC to redump bad tracks.
The startup time of the drive, spin up, head settle and other delays are considerable, when you do your process 77 times, instead of just redumping a handful tracks.
You could even capture the DTC output, and once DTC finishes with a track just check the finished track, in your process - practically running in parallel, 1 track behind DTC, so at the end it would cost practically the exact same amount of time as you were dumping 78 tracks instead of 77 due to the one track delay of your processing.
The GUI captures DTC output and works with that in parallel, so it's definitely doable.

As for adding other formats, never say never - but obviously that needs images from known good disks.

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests