Discferret broken?

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/