on my aging PC, the motherboard had a built in FDC so I can plug a floppy drive and read some msdos disk under Linux for example. This is quite handy when you just want to see the directory of a floppy or copy some files or write a non protected .ST disk image with 9 or 10 sectors for example.
Soon I will need to replace my PC, but recent motherboards don't have FDC anymore (and cheap USB floppy drive are not an option since they're limited to fixed 720 or 1440 capability).
So I wondered, is there a way to use the kryoflux as an FDC to issue some simple low level command (steps, read/write sectors, ...) ? Either through DTC or through another API ?
With low level commands, it would be possible to change the 'mtools' set of programs for example and replace kernel systems calls by calls to the kryoflux board.
Other alternative would be to dump the whole floppy first, then mount/read it with the appropriate command, but that's often much slower when you just want to see the content of a directory.
Same to write files, I could write them to a local .ST disk image and dump the whole .ST file to the board, but that's also not very handy.
Seeing that there's less and less solution to access floppies nowadays, I think it could be an interesting addition to the KF is some tools or API were available to access the disk structure at the file/directory level.
Or maybe such tools already exist ?
The firmware is capable of very (nanoseconds level) precise positioning from the index signal, but you should consider the index signal jitter which - in extreme cases -, in theory could cause a delay long enough to overwrite the next sector header. Although it's pretty unlikely to happen, it's not entirely impossible; really depends on the drive hardware.
Discounting index signal jitter, first, you'd have to sample the entire track to know where to position the writing - you need to read each track to be written at least once.
For the positioning itself to work you'd have to sync to index first each time, then the hardware and firmware takes care of the rest, including very fast switching of the write gate (read/write mode).
However, if you do sync to index, you might as well re-write the whole track: it will be guaranteed to be correct (unlike a partial rewrite) and would cost less time if you consider what happens if you want to write multiple-sectors partially with a re-sync each time... not to mention you don't have to read the track first in order to know the correct write position.
With a track write at once you can also combine the writes to a track which on the other hand will be significantly faster than re-writing sectors, no matter how that is performed, since the KF hardware is capable of writing continuously at the disk rotation speed.
If there is any real world interest in this, it should be possible to release e.g. a hardware access library.
You can do this indirectly via DTC by dumping and converting track contents, but unless you dump a whole disk at once it can get pretty slow for each track due to drive spin-up time.
You should consider what the KF hardware is: it's a signal sampler capable of measuring flux reversals (reading) and generating flux reversals (writing). So it has no concept of formats and such whatsoever; that should be taken care of the OS level driver in your use case.
You should also consider that apart from the sampling everything is software driven, which makes it incredibly flexible - unlike an FDC -, but also resource intensive, again unlike an FDC
Cheap USB drives make features like these quite redundant - for most users it's just reading the PC formats already supported by those... and you can do that a lot better with DTC.
The cheapest route is translating an OS request to a DTC command and just let DTC work in the background.
Anything else would involve writing a "real" driver for your OS, which may not be much fun
Which would be just as fast, or maybe faster than what you get normally via OS drivers, since they have to deal with the drive via the FDC interface, which can be a lot more ineffective (via standard controller commands, interrupts etc) than simply telling DTC to read a single track.
So it may be possible to see what the OS wants to achieve and issue partial and track reads, not just full disk ones.
You could also further improve this by only reading unread tracks from a disk and using the stream files (or a simple pre-translated sector buffer) for tracks already available.
When I said a command to "read/write sector", it was more like a higher access API call that would internally read the track, decode it to MFM, find sector header and return sector data as bytes. For writing, replace sector data by new bytes in the track, reencode track as mfm/flux transition and rewrite the whole track to disk.
So, such HW API could be something like the commands available for WD1772 for example (step, read sector, read track, ...), that would return either MFM data (for people wanting to access Amiga disk for example) or data bytes directly (for MSDOS/Atari ST like formats where MFM data are not needed to do some basic dir/copy/... commands and track structure is often the same with 9 or 10 sectors).
I think an API allowing to write basics tools to access the floppy at the file level would be really useful (even if disk accesses are not realtime due to the flux coding/decoding done on the host PC)
The advantage is that how the actual reading is performed and any of the details are don't care for such an approach.
Anything more complicated would involve someone writing the necessary drivers including the interpretation of flux data. How that is done in DTC is pretty complex process involving several stages (think OSI model) that is simply way too complex to interface to from the outside world, unless you are only interested in the results - in which case you can simply invoke DTC in the first place...
Yes please!If there is any real world interest in this, it should be possible to release e.g. a hardware access library.