Dev time is always limited, hence we need to focus. To help us better understand what people expect of enhanced writing support, we have a little poll for you. We know the answers are very broad and leave room for further interpretation. This is just to give us a feel for what is important to you.
One thing you can help us with by writing a reply: The first option would mean taking the raw data, applying some magic and then slamming it back onto the disk. This will for sure not work for certain types of data, disks would not come out "perfect", but might work. This would also mean you would be creating copies which are inferior, and might not work when copied again. This means imperfections of generations add up. We so far have a pretty good track record of only delivering scientifically correct solutions, e.g. data written is fully known and can therefore e.g. verified (like when writing a G64 file created by KryoFlux in the first place). Such functionality would get lost, or at least only work for some edge cases. This would for sure be a "consumer" feature and not be intended for any preservation / archival work.
Whatever may come to mind, let us know. This is really a huge construction site and will bind resources for a long time. Another option would be to hire another programmer or to take a longer unpaid leave from the regular day job. Would you be willing to spend a few bucks for it in regard to actually buying a software add-on?
So yes, user-scripting will allow to read (and check for modification)/write/verify any kind of disk, regardless of its format, as long as the basic elements used to encode a track and its sectors are already supported by the language.
This would be effectively what duplicators used for duplicating and verifying a disk (like FreeForm used by Trace, but with emphasis on preservation aspects), with the added bonus of being able to fully read and verify any kind of custom format as well.
As I understand it, the most common sector image files for these just include the data from all sectors in sector number order. That is, not in the physical sector order as written on floppy tracks with sector interleaving for performance improvement. The physical sector ordering (i.e., the interleave count) isn't included in the image files, so a user would need to specify that in some manner.
I'm not sure which poll option is most applicable to what I want. Would it be the user defined scripting option?
There is simply no way of supporting all of those formats for *writing* - there will be always one slight "variant" that would make the disk unreadable or unreliable on a real system when read.
Unless a disk is copy-protected generic reading can be supported (as it is now), but getting content off such a disk is a completely different problem (which requires a reliable analyser, like the one in DTC) to actually writing the data, since sector formats (or in fact any other format apart from IPF) lack the *exact* details required to replicate such a disk in a way the target system expects.
With user-scripting anything could be easily changed - provided the user has a basic understand of what he is doing - either by users like you or ourselves
I am interested in archival of old media in order to preserve its content, but I am also interested in preserving the hardware that the media was meant for. In many cases, that means that I need to independently generate new floppies for use on that hardware in order to be able to boot up the machine. An effectively read-only device doesn't help there at all. Sure, it can write from IPF files, but I cannot create an IPF file. It can write Amiga sector images, but most of my vintage computers aren't Amigas.
I've read that you have not yet released IPF creation libraries and/or documentation because you are agonizing over how to license them without letting anybody else make money off of them. Maybe you should instead worry that somebody will be inspired to develop a competing product that is more useful and/or more open, and take the whole game away from you.
Personally, I'd love to see the scripting (I can't change my vote )) - it'll give the writing flexibility everyone wants and, I'm guessing, would allow people to write open utilities to create scripts for their own favourite formats (just so long as FM is supported )? Surely that's a win for all concerned? Stable, well tested software that allows individuals to write anything they want with the hardware.
Just my tuppence.