Further development of writing functionality

All news about KryoFlux go here.

Which method would you prefer for disk duplication in DTC / KryoFlux?

completely independent duplication based on "best guess", creating more or less analogue copies
8
19%
image format dependent, like G64 dumping / writing works today
16
37%
user defined scripting
14
33%
don't care, I am interested in dumping / image creation only
5
12%
 
Total votes: 43

User avatar
mr.vince
Posts: 1873
Joined: Tue Oct 05, 2010 5:48 pm

Further development of writing functionality

Post by mr.vince » Fri Oct 04, 2013 9:41 pm

We know that many people are happy with their units, but we also know that some / many / those that yell loudly want some automated duplication solution. We come from a preservation based approach, but we understand people also like to tinker / experiment, although this is the far opposite of the formal and scientific approach where nothing should happen by accident.

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?

drdanj
Posts: 37
Joined: Sat Dec 29, 2012 9:47 pm

Re: Further development of writing functionality

Post by drdanj » Sun Oct 13, 2013 10:32 am

I'm torn, I'd love to be able to create MFM/FM images of sector dumps of arbitrary geometry, but I would like the flexibility of being able to script elements too - for example deliberately mixing FM/MFM sectors, dictating the CRCs to write, messing with sector numbers and the like. The former is ultimately the most useful, but the latter would allow the creation, easily, of backups of some protected software and also give people a tool with which to learn and understand how floppy formats and lots of these old protection mechanisms actually worked! :)

d.

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

Re: Further development of writing functionality

Post by IFW » Sun Oct 13, 2013 11:49 am

I am so glad you mentioned that... you are probably the first to guess what it is for ;)
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.

drdanj
Posts: 37
Joined: Sat Dec 29, 2012 9:47 pm

Re: Further development of writing functionality

Post by drdanj » Sun Oct 13, 2013 4:41 pm

Having thought a bit more then, yes, the scripting is absolutely the most useful thing that could be implemented - it would be easy enough to write "format x image -> script" converters for simple sector images, or well described formats, which would give the result desired in option 2 as well as affording the extra flexibility where it's needed. Option 1 is just grubby :D sort of like sticking a Picasso through one of those spirit duplicator machines they used to have at primary school!

d.

User avatar
NF6X
Posts: 15
Joined: Sat Aug 17, 2013 2:17 am
Location: Riverside, California, USA
Contact:

Re: Further development of writing functionality

Post by NF6X » Sun Oct 13, 2013 6:39 pm

At the moment, I am most interested in being able to write floppies from MFM sector image files of non-copy-protected disks. My motivation is to be able to take image files of things like operating system disks that are downloadable for use in emulators, and write them to real floppies in order to boot up real vintage systems. Platforms that I need this capability for include 5.25" floppies for TRS-80 models I, III and 4, 5.25" floppies for the Color Computer, and 8" floppies for TRS-80/Tandy models II, 12, 16 and 6000. Most of those are single-sided by default, but the models 12 and 6000 came with double-sided 8" drives and all of them were often upgraded with double-sided drives by end users. Many of those systems used floppy controllers such as the WD1793 or similar ones.

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?

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

Re: Further development of writing functionality

Post by IFW » Sun Oct 13, 2013 7:05 pm

Yes, one of the main motivation is specifically the millions of possible variants of FM and MFM disks - and a few requests we got both from hobbyists as well as professional users.
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 :)

User avatar
NF6X
Posts: 15
Joined: Sat Aug 17, 2013 2:17 am
Location: Riverside, California, USA
Contact:

Re: Further development of writing functionality

Post by NF6X » Sun Oct 13, 2013 8:32 pm

Thanks! My vote is cast for user scripting now.

User avatar
Malvineous
Posts: 156
Joined: Sun Oct 31, 2010 10:57 pm
Location: Brisbane, Australia
Contact:

Re: Further development of writing functionality

Post by Malvineous » Tue Oct 15, 2013 12:45 pm

I hate to raise this topic again knowing your opinions of the matter, but to be fair, if some more of the code was open source you may not have to employ developers, you might be able to get community developers to collaborate on adding this type of functionality. I know you are very proud of the capabilities of your software, but perhaps there is room for a very basic open source utility that can handle just the basics of reading and writing (maybe "analogue" only.)

User avatar
NF6X
Posts: 15
Joined: Sat Aug 17, 2013 2:17 am
Location: Riverside, California, USA
Contact:

Re: Further development of writing functionality

Post by NF6X » Tue Oct 15, 2013 3:41 pm

I agree strongly with Malvineous. I failed to research the KryoFlux carefully enough before I purchased mine. If I had realized that it could not generate the IPF files that it is capable of writing to floppies, and that the IPF format was not open, then I would not have purchased it. For my purposes, it's essentially a read-only device, and thus not very useful to me at all. I've used the power supply that came with my KryoFlux more than I've used the KryoFlux itself.

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.

drdanj
Posts: 37
Joined: Sat Dec 29, 2012 9:47 pm

Re: Further development of writing functionality

Post by drdanj » Tue Oct 15, 2013 3:57 pm

(Speaking as an independent individual with no vested interests) - truth told, there have been competing things but they've never gotten off the ground. DiscFerret springs to mind? Despite what you might think, this is pretty niche, and in x number of years no one else has come up with something that does the job as well as a kryoflux. The IPF format is fairly well deconstructed and Kier has put up a utility that can create IPF files and is open - it's not to the specification of SPS, but it will create files that the kryoflux is happy to write, and it's quite hackable. The IPF read-library source is also downloadable, and that basically shows the inner workings of the format.

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 :D)? 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.

d.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest