Software-based floppy disc data separator

Philip Pemberton wrote on 17/06/2010 11:47:18: Hi Phil, I'm from SPS. By our records I can see we have had a couple of long conversations with you, and I am sorry we couldn't answer your large mails to your satisfaction (though I think we did pretty well, we even sent you all sorts of non-public information), but... I'm sorry to say it, but we are very busy people. I think people probably don't realise how much work we do (which is fine), but it does mean we must very carefully choose our priorities. We also have family's, day jobs, etc., and it is difficult to get on with productive work, and try to respond to emails from the many people that contact us in a timely manner. It's the same reasons that usually prevents us from posting on mailing lists too. We had some very nice conversations with you from what I can see, so I am not sure why you now perceive us in a negative light? Maybe your comment above "we can't tell you" (I don't think we said that?) is because we have not yet given you the DRAFT image file specs yet. If that is the case, we're not being obstructive, the reason for it is simply because the format doesn't exist yet... What we currently have is raw stream from our hardware, which can be used to create various sector image formats or saved to a file for later conversion. The DRAFT disk image format work is yet to be started - if it had, it would be in the WIP's. You are of course absolutely right in this regard. We have known since the beginning that it was a pretty ridiculous state of affairs for a image format intended for preservation (we have publically said this in multiple places elsewhere). Fortunately the reasons behind it have disappeared over the years, the remaining thing to do was multi-system support (now done, as of last week). It now basically comes down to finding the time to sort it out. We wanted to do a few other things first (like being able to show that an image really comes from us), but we have been discussing the subject internally recently, and we will probably defer that. It's high time it was available. Feel free to keep complaining until we do it. :) I should state here (as we have confused people on this before), that IPF is a *mastering* format. It is similar to how Trace prepared disk data for writing, where they had the disk data but also scripts describing checksums, data formats, protection, etc. - since you need to know how to write the data (especially copy protection) for it to be reliable (or of course work at all, for some types of protection). It is designed for writing, and that is basically what happens when an IPF tracks are loaded in an emulator (just not to a physical disk of course). IPF is a very different thing to a dump format, and I would say that for most non-preservation purposes a dump format is fine (and also has the advantage of being simple). Actually, we had nothing to do with that. Jeff took our developer information and did the whole thing himself, we first found out about it when somebody told us (incorrectly) he had reverse-engineered the IPF format. He hadn't - he used the developer docs available from our website. I am not sure where you heard that, because we are doing that right now, and have been for some time (off and on for a few years in fact). We even went round and contacted a lot of emulator writers (both open source and not) to see if they were interested in supporting IPF. If we want a broad take up of IPF, it is certainly in our interests. Perhaps you think we are not working with them because we haven't explicitly posted about it? Our analyser constitutes several thousand hours of engineering effort over the last 10 years, and comes out of many years of research and development done before that, so to be completely honest with you, I can't see us making that available for free any time soon. I suspect that people wouldn't complain that we are keeping some things to ourselves if we were a company making money from such a huge investment, but we're not even that. We did consider producing a demo version, but again we hit that time/priorities issue, and I doubt it would be interesting to many people anyway. Having said that, you might like to know KryoFlux does have a stripped-down version of parts of the analyser inside it, and has some pretty clever stuff going on. Obviously, don't take my word for it. The proof is in the pudding - you can try it yourself if you have an ARM7 development board. We said from the start that source will be available when everything is finished and we move out of beta, feel free to complain then if it's not. Sounds neat. :) We're coming very much from the preservation of consumer software angle, and KryoFlux is primarily built to solve problems in that area (we need it ourselves in this regard). Given that we're aiming at common use-cases, I guess this is something that might well stay unique to you - diversity in our solutions is a good thing. I have to say that I'm a bit surprised to see the rather negative sentiment in your post Phil, it's very different from the conversations we have had with you. I don't really understand the reasons for it, but perhaps we can all just try to get along? We're all fighting on the same side after all. Kieron