I will answer in brief. A proprietary analyzer is not in the best interests of preservation. It instead keeps preservation limited to a small group of "elite" people. This is wrong. If you really were afraid that people would post bad dumps, then you'd be signing official releases. If you have to dongle-protect the analyzer, there has to be some reason for it ? and the only reason I can see is to make money, and keep it out of the hands of people. The bug in the DiscFerret lasted that long because it wasn't really used heavily enough to be detected. After we put it to some use, the bug was found rather quickly. If I had started my testing back in August rather than late December, I'm certain it would have been caught back then. My understanding is that the Catweasel has similar issues. As for software and Linux support: Please make an open, accessible repository containing the source code for DTC, so I can recompile it for various platforms. I often use Linux platforms other than x86 or x86_64. This would help the community greatly. The firmware source code would be useful to people too, I am very certain. "People that want it can contact us. Some did/do. And some use the software as part of a special arrangement. I really don't see why this is wrong." "How should we know you would want to audit it?" Why is this the case? If the project is geared towards preservation, I should not have to jump through hoops to contribute. With many popular open source projects today, people submit pull requests all the time. There's zero hoops to jump through ? clone the project, commit new code, send a request upstream. Works great for the community. Or if not, at least make the USB protocol available. But no, I don't expect any of that from you, since I've seen enough. Though I haven't had 14 years in the industry, I have had several years of working with various open source and preservation related projects to know what's better for the community. I will put all my effort into making the DiscFerret a viable solution for imaging floppy disks, hard drives, and other media. This includes making the software extremely easy to use, and stable. Thank you for your time. I cannot support a project that favors elitism over preservation. --Dave

On 29/02/12 17:34, Christian Bartsch | KryoFlux Ltd. wrote: What I find interesting is that several of my UK, European and Japanese contacts (at various computer museums in those countries) were scared off of working with the DiscFerret. Nearly every one of them cited the same reason: "conflicts of interest" between assisting with DiscFerret and using commercial versions of the Kryoflux analysis software (which I suspect would be CTA or a variant thereof). I'm making no accusations or insinuations here. I just find it interesting that six people backed out and cited the exact same reasons. There was one question I asked which I don't recall you answering... In the CTA analyser screenshots in the WIPs, the Speedgraph has two lines plotted on it; one is magenta, one is blue. The magenta line appears to be the relative width of the bit cells after decoding (or possibly the PLL's 'VCO control voltage'). What does the blue line represent and how is it calculated? At this point in time, the read side of the DiscFerret microcode has been proven correct with testbenches and physical testing with various floppies and MFM/RLL drives. It works. I'm not going to say it's perfect and bug free, because nothing made by humans can ever be "perfect". Heck, even natural evolution doesn't get it right all the time. (though no doubt Mother Nature doesn't like to admit it! *GRIN*) Yes, the DiscFerret hardware has existed for a year, but it's only been in the last six months or so that the hardware has really been "out in the field". I never said it was production ready: that's why the initial production run was limited to 15 units (of which 13 were saleable and two were kept by myself). You're forgetting: there are only 15 DiscFerrets in circulation. Most of the users who bought the early units haven't even contacted me or joined the mailing list. It's only fairly recently that the project has gained any sort of momentum. Rome wasn't built in a day, and acorns don't grow into massive oaks overnight either. And you've succeeded. I did comment on your Facebook page -- I think I said something to the effect of "Is that a 74LS244? Interesting choice for an input buffer, especially when the source driver is open-collector on the end of a long cable." This comment got me blocked from your Facebook page. Simply for pointing out that I found the design "interesting." Also, the 74LVC14 and 74LVC07 combination is no more expensive than the 74HC244, and the hysteresis on the input side (Schmitt trigger) is very useful for cleaning up 'slow' rising/falling edges on O/C signals. Especially when they've been transmitted across 60cm (or more) of cable. In this case "doing it right" would have cost almost the same. When I designed the input stage of the DiscFerret, I looked at what disc drive manufacturers recommended, and I asked myself: "What is the worst thing a user can do to this, and how do I prevent it from damaging or destroying the I/O buffers?" The parts used for the I/O stage took an insane amount of time to track down and source, and I'm confident that they are the best possible parts for their intended application. As a point of reference, the current ST506 adapter boards for the DiscFerret are mostly passive: the RD_DATA / WR_DATA signalling is fed through an RS422 line driver/receiver chip as necessitated by the drive interface, but the control signals are passed straight through. Even with over a metre of cable between the drive and the DiscFerret, the signals are still razor sharp at both the drive end and the DiscFerret FPGA. If that's not a good design, I don't know what is. You've been very lucky. Ideally you need a 33-ohm source resistor and clamping diodes to protect the inputs on a HC244... some of them are extremely sensitive to ESD due to the manufacturing process. Which is why I stated that the DiscFerret was intended to supplement rather than compete with Kryoflux. DiscFerret --> Generic solution. Buy the board, adapt it for anything. In theory, it can even handle ESDI (if the decoding is done on the FPGA). Built in support for hard-sector discs from the get-go. Reprogrammable SRAM-based microcode and flash-based firmware, with recovery bootloader for the latter. Kryoflux --> Floppy discs only. Some noted issues with 8-inch drives and/or hard-sector discs (unless I've misunderstood the messages on your forum?). The one thing that concerns me about Kryoflux is that you've sidestepped the requirement for a device-unique USB Vendor and Product ID pair by using Atmel's EVKIT VID/PID. This is going to cause big problems for anyone who has (and wants to use) the Atmel AVR USB Developer Kit. Read the USB-IF Standard License and Atmel's USB Stack Licenses *very* carefully. Build on Debian stable -- i686 or x86_64 MultiLib. Watch in awe and amazement as your binaries work on any Debian-derived distribution (Linux Mint, Ubuntu and its variants, and so on). Do the same on CentOS 5. Watch as the binaries run perfectly on CentOS, Red Hat Enterprise, Fedora and any of the derivatives. When the DiscFerret software is considered stable, binary releases will be made for Windows and OS X. For Linux, an Ubuntu Launchpad PPA will be available when the final release is done -- installing DiscFerret will be as simple as: sudo apt-add-repository ppa:discferret/main sudo apt-get update sudo apt-get install discferret-all I Libdiscferret's dependency list is short -- and that's by design. Magpie's is almost as short. And as I said, this is all beta quality code. We know that reading works, writing is mostly untested (it needs a testbench, and one is being written -- it's on my hard drive actually) and decoding needs to be finished. Christian, can you answer one question for me, on behalf of SPS? Do you have any problem with my adding STREAM format support to my analysis tools and libraries? Several people have requested it be added to Merlin, but I've been holding off because I didn't want to cause any issues with SPS. If you need to consult with other members of SPS, that's fine, but a public statement as to what we can and can't do with STREAM and IPF would be most appreciated. Thanks. -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/