Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

KryoFlux device writing is not supported #22

Open
simonowen opened this issue Feb 17, 2020 · 9 comments
Open

KryoFlux device writing is not supported #22

simonowen opened this issue Feb 17, 2020 · 9 comments

Comments

@simonowen
Copy link
Owner

It's possible to read directly from KryoFlux devices but not write to them, as only the read commands are understood.

The KryoFlux device creators do not provide a library or any documentation on how to drive the device from 3rd party software. The only officially supported method is to use the dtc application, either directly, or spawned from 3rd party applications to do the work. This gives little control over the process and is not an attractive solution for SAMdisk.

The only alternative is to reverse-engineer the USB protocol used by the dtc application and use the same requests directly. This has been completed for reading support only, with further work required to identify the commands and surrounding behaviour. The limited on-board buffering also requires USB streaming mode to be used to keep sufficient buffers queued up to avoid underflow during the process.

The current lack of write support is mostly due to the effort required to reverse-engineer the remaining device commands, and the availability of a fully documented competiting product (SuperCard Pro), which already supports writing.
@claunia
Copy link

claunia commented Feb 21, 2020

Personally I would never add support for writing.

@SM7I
Copy link

SM7I commented May 18, 2020

I would love the write support. It really does not make any sense not to include write support. If making image from physical disk is possible, then the other way around ought to work as well. I would even make a donation to see this being done.

@simonowen
Copy link
Owner Author

I'd like add write support, but the benefit to effort ratio is still too low for it to be on my radar. I feel the time needed to reverse-engineer the application and protocol would be better spent on other projects.

The situation would be different if the KryoFlux team document the USB API or provide a library to talk directly to the device. Their current stance of spawning the CTA application to do any work is a non-starter.

I'm open to pull requests if anyone else wants to do it in the meantime.

@tomas-nestorovic
Copy link

Hi Simon,

I've implemented the write support in my Real and Imaginary Disk Editor, more particularly under its Issue 57. The problem consisted of two major parts - input correction, and writing.

You can find the input correction in CCapsBase::TCorrections structure which holds user's settings - correction of revolution timing, correction of number of cells per revolution, jitter correction, and correction of first sector appearance. The last one is the least important but the previous three corrections should always be applied in order make a track as much predictable and well timed as possible.

Having such well formed track, the user is free to modify its sectors (e.g. import new files to the disk, etc.).

The writing itself was more tricky to crack. The best way to adopt it in SamDisk is to simply follow the path of code in CKryoFluxDevice::SaveTrack method where you will find

  • conversion of modifications made by user into correctly timed flux transitions,
  • pre-compensation of the fluxes (see also CCapsBase::CPrecompensation class),
  • conversion of pre-compensated fluxes into KryoFlux proprietary "KFW\1" format (I did the major breakthrough in this thread on OldComp, sorry only in Czech),
  • sending of the "KFW\1" binary to the device,
  • verification of writing.

However, please note that the implementation as of today is the first functional version with many drawbacks and speed concerns. Also, I haven't yet much tested it with HD floppies (much = I only know that the "KFW\1" format is the same also for them). The method is proved to work well only with 2DD 3.5"/5.25" floppies.

RIDE has adopted most of the reading support from SamDisk (plus here and there added some of its own), so I'd be very pleased to at least indirectly requite SamDisk 👍

Tomas

@SM7I
Copy link

SM7I commented Apr 3, 2021 via email

@tomas-nestorovic
Copy link

Hi Johan,

I regretably never had a computer with 3" floppy drive, so these are not yet supported. But internal PC floppy drives are, and their support sits on the same driver as SamDisk, that is Simon's fdrawcmd.

Standard and Extended DSK images are supported - I needed them many years ago :-) But +3DOS isn't supported, so you won't see the files stored in the DSK image, unless the DSK contains one of the implemented filesystems, e.g. MS-DOS :-( Otherwise, you'll be able just to dump the DSK image to an internal PC floppy drive (3.5"/5.25") and browse its sectors in hexa-mode.

Also please note that current release is 1.5.5 (now finishing 1.5.6, to be released next week). KryoFlux R/W support is planned for 1.6 which shall be released either at the end of April or beginning of May after I've done some more tests 💾🙂

Tomas

@tomas-nestorovic
Copy link

tomas-nestorovic commented Apr 27, 2021 •
edited

A community preview version of RIDE with KryoFlux write support (2DD floppies only) has been released (a poor machine translation of Czech original, link to download at the end of forum comment). Hopefully Simon will have time to adopt (and further improve) it :-)

@SM7I
Copy link

SM7I commented Apr 27, 2021 via email

@tomas-nestorovic
Copy link

I just bought myself the starter pack for dummies, https://www.ebay.co.uk/itm/133458588651 Now yet the drive itself :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@simonowen @claunia @SM7I @tomas-nestorovic