Discferret broken?

On 3/6/2012 9:33 AM, Dave Dunfield wrote: All interfaces will fade, but I don't think USB will fade faster than the older, less flexible interface standards. The flexibility of USB created a large product sales footprint. As well, more people buy peripherals in the USB age than purchased in the RS232/Centronics Parallel age. I think the general public will resist replacement of this standard. I think the current DVD/BluRay shares some similarities, as the public has only recently found enough "value" in BluRay to migrate. I can't speak to the DiscFerret technology, but as ZoomFloppy competes a bit in this space (DiscFerret, KryoFlux, insofar as all three image disk data), I think I can comment with confidence. RS232 would simply not work with the ZoomFloppy hardware without additional hardware resources. For nibbling disks, ZoomFloppy is receiving data as it passes under the read head. Without internal RAM of any appreciable amount, the ZF unit must send that data at a rate fast enough to eliminate the storage requirement. Yes, RS232 could be accommodated by adding RAM, but I don't see a point. * USB works today. It's also easier to support for end users. An Ethernet-based solution has to contend with switches, firewalls, etc. * It's not feasible to make a RS-232 only device. Few people want such an item. I understand few != none, but most want to plug into their current machine and go. Thus: * The interface is USD$35.00 ($42.00 for the IEEE version). Adding RAM, creating a potential second PCB and firmware version for the RS232 version (or the additional work to create a unified firmware image and PCB), the additional testing involved to ensure all features work with both USB and RS232, and adding the hardware to enable RS232 (ZoomFloppy uses a USB-capable part for the uC, and needs no additional IC for USB. RS232 would require a level translator) would increase the price of the product. This means everyone will pay more for a feature that will benefit a few people. (I don't want to cite specifics, but I am pretty confident in my ability to price products for sale and think I can speak confidently on this point) * If/when USB becomes hard to use, I am sure someone will create a new ZoomFloppy-type unit that uses the newer standard. As the design is open source, there's little hurdle. Thus, I think it's best to develop/market a solution that minimizes the "means" and concentrates on the "ends" at an attractive price point, one that satisfies the needs of 80% of the community. I don't mean any offense, but the remaining 20% will often be unhappy with any pragmatic design ("Jim, I won't buy it until it supports data transfer by carrier pigeon!") and it's very hard to please them at all. They provide the most negative critiques ("Well, I wanted to like it, I really did, but Jim ruined the design by not using MSI components, opting for those playground-of-the-devil FPGAs"), generate the minority of sales ("Well, I'll buy one, maybe, but I'll just reproduce the design using my home PCB skills and portable CNC mill"), and demand the most out of development efforts and testing ("Jim, when will we get CBM 1551 support? Your product is useless to me without it. Yes, I know the 1541 will read/write the same format and the 1551 is just a 1541 mech with new interface electronics, but I expect 1551 support!"). Arguably, the Commodore market is not representative of all vintage markets, as lots of people still use CBM machines in daily activities. If I developed solutions for PDPs and such, where the majority of owners are collectors, the above would likely change. As with others, I can see merit to both sides of this debate. I have, though, found that those who choose to offer commercial products walk a fine line. Deftly handling the competing viewpoints requires significant diplomacy: * Vintage enthusiasts will pay reasonable sums for specialized physical products. Many surmise the premium cost is due to low volumes (often true), specialized parts (also true), and a nod to the person who bothered to offer the product in the first place. This doesn't give the producer a license to rip off the community, but the customers seem to be pretty savvy on costs and value. * There's less flexibility for software. I'll let others debate the reasons. * There's very little flexibility for software that enables hardware operation. * Releasing the design and the SW under an open source license creates lots of goodwill in the community. It's not necessary, but keeping a design closed or keeping the SW closed creates a considerable burden on the owner: o You either have to support all realistic SW platforms or endure criticism for the lack of support or timely support. o You have to defend the lack of HW features and you risk lots of negative discussion activity if that support is not forthcoming or is delayed. * As a commercial provider, I have to pay special attention to commenting on competitive designs. For instance, I have some serious concerns about drive solutions like IDE64 (I think the DOS is too intimately tied to the ATAPI standard and IDE specifically). However, blurting that out in a forum will likely be seen as an attack on a competitive product and a desperate move to build up my product Some other observations: * I feel releasing designs to open source aligns with the spirit of vintage collecting and preservation. Thus, I find purely closed offerings in this community problematic. In those cases, the designer is preserving the continued use of an older platform but yet not allowing the same flexibility for the preservation aid. Concerning KryoFlux, I still worry about longevity. If time passes and the owners move on, is the design now open source? (No, it is not). Thus, even though the design is free for non-commercial private use, it can't live beyond its creator's interest. * I do cost reduce solutions. However, I feel designs should "do no harm". In other words, the cost reduction might create units that do not function, but they should never adversely affect the target vintage equipment. * As a fellow enthusiast, I share David's concern over the closed and guarded nature of the KryoFlux Analyzer. I don't buy the arguments in the FAQ. I see no issue with letting anyone creating IPFs, as I feel the community will self select the people who do it well. As well, it's been my experience that there are lots of very intelligent people in this community, and one delude themselves thinking a "complex" solution is not useful to others without extensive training/education. * I disagree with Christian's "audit" response. I don't think the OP was lamenting the fact that he/she could not audit the source, but that a closed source product can never be truly "audited", as the author can always doctor the version provided for audit. And, even if I am wrong and it can, it creates a perception problem. * The legal concerns about "conflict of interest" do concern me. There are precious few people in this area of expertise, I think it's the responsibility of hardware and software vendors to ensure such a product or offering does not fragment the group. Christian's response did not clear things up. I don't understand how " 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). " would get one "thrown out of the 'house'". While it's an unsavory topic, it's one that demands some type of response. If someone said that to me, I believe I would send a note to the individual and request he/she forward it on, assuring them that they can work on both projects without fear of litigation. * I agree that you're paying someone not to develop a solution, but to *NOT* do something else. I'm a good example. I give up weeknights and weekends to develop products because I get paid to do so. I could enjoy another hobby if I was so inclined. * I've seen lots of OSS projects "die". While one might not call them "discontinued", users will steer clear when they see no effort is being expended on the project. * I am glad that the folks have made the Kryoflux formats open and documented. * I agree with Tony position that having to work with the producer to add a new target is a huge hurdle. What if the producer and Tony are at odds on the significance of the addition. As an example, I know there are folks who want to add SDIO support to sd2iec firmware as used in uIEC. I am happy for them, but I have very little intention of supporting or testing that in uIEC. In Christian's example, I'd have to work with the user to incorporate patches to support something I either don't care about, or active discourage. In the case of uIEC/SD, the source is open, as is the HW design, so they can happily go their own way without my hindering them. * I don't put a lot of stock in vintage product forums as a metric to gauge customer satisfaction. Those who don't like the product rarely post on the forums, they just sell the unit and move on, potentially carping about it in other forums. That said, I do not dismiss the jovial tone of the Kryoflux forum. I am convinced those folks do enjoy the unit. Meaning no offense to Tony, he does illustrate my 20% rule above. While his concerns are worhty of consideration, he admits he owns no USB host hardware and is thus not a prospective user. So, Christian's responses are largely academic, in that they will not sway Tony to buy a unit, because Tony can't use one. While such responses are worthwhile, one cannot spend too much time on these discussions in lieu of responding to actual owners and prospective buyers. Jim -- Jim Brain brain at jbrain.com www.jbrain.com