KryoFlux^® Support Forums

You can just file off a bit from the rail housing (plastic, metal and all), that works just as well. If it doesn't move easily on the rail afterwards, just move it up and down and spin it around the dismounted rail until it is loose enough again. Might take a while but eventually it should work out....

Not yet. The hardware can do it but the software support for that hasn't been released yet.

For 360 KB disks, add -k2 to your command line.
For 1200 KB disks, add -v360 instead.

I think the main reason was to make a file that would work on whatever flavour of Windows without the need to install any .NET stuff. Although I appreciate what .NET has to offer, it really leads to bloated code. If there is another advantage here, I assume IFW will chime in. Yes, VC++ 6.0 has the ...

IFW is the author... :) The Code seems to build well with Visual C++ 6.0, the old late-1990s version before Microsoft went .NET all over the place; I 'm not sure there is any such thing as "Visual Studio 2006", AFAIK the version after 2005 was 2008. Of course 6.0 is an old compiler withou...

Sure, why not. I'll PM you my address. But no hurry, I don't think I'll get around to it until maybe the weekend after the next.

As for stepping it's a possibility, but would require a drive for testing Unfortunately the Mitsumi/Newtronics isn't my own :( , I've just sent it back to the owner for whom I modified it. Otherwise I'd of course lend it to you. But anyway I'd think it would be a good thing for all drives if you al...

May I propose a different seeking algorithm for "negative" tracks? I just modified a non-Panasonic drive, a Mitsumi/Newtronics. It steps to -8 very well, but then it doesn't step up again until "negative space" is exited. So it will read track 0 of a normal flippy disk backside f...

Thanks... it's just that I kinda feared you might have "given up" on IPF for platforms not yet fully supported by it, or lowered your standards. I'm a believer in a fully universal format so to speak, and not really happy with the current jungle of emulator formats.

Just a question... is this a temporary measure until the IPF libraries have been extended to fully cover GCR coding? Or are you saying, "For Commodore stuff, G64 is the way to go and IPF is not"?

Oh and thanks for the great work, much appreciated.