Alternative Hardware Design for Floppy Interface

Some additional thoughts: - There is just too much the 765 won't do. Even 179x series can't read some formats. That why I think a system with a fast processor with direct access to the read (and write) data stream is the best universal solution. It also must be easily programmable, so that an oddball format can be handled by "just adding software". - I agree with Chuck - reading is far more important than writing, however hand in hand with that, is that ultimately the data read has to be recoverable somehow. - Although you could take an old PC and wrap on a custom FDC for certain formats, I don't think this is a good idea, because of what I consider is the most important point: The system has to become an accepted "standard" - even if only by members of this list. If everyone "does their own thing", there is no consistancy, and little chance of someone else being able to recover data. Did we learn nothing from the Don Maslin situation. You just can't keep valuable backups in the hands of only one person. The key thing is that if someone needs a particular disk, they need to be able to obtain not only the backup data, but enough information to recreate the disk. This would include: - A open & well documented hardware design. We must assume that at some point any boards we make will become unavailable. The information needs to be presented to allow someone with enough of a requirement to recreate a compatible system. - Open and well documented software. If the hardware/software system allows for custom code to handle oddball formats, then that code needs to be made available as well. Ideally there would be some forum to collect and organize this information. - Documented image file formats. Supporting libraries and tools available to persons developing for the system, so that consistance can be maintained. In many ways, such a development would be a logical extension to my ImageDisk project - I developed that tool with the explicit goal of making sure that the data from archived floppies could be extracted by other means. To that end, I documented and released the Image File format into the public domain, developed additional tools to manipulate the images, and have make the source code to those tools and the IMD program itself freely available. A good example of the use of this documented format is my recent efforts to recover files from CDOS disks - after some screwing around, I found the only way I could reliably recover data from the disks was to extract it from ImageDisk images - Although I happen to have authored those tools, I have published enough information that most any of you could have done it as well if you had the need. Equally important is the fact that if I should subsqeuently have to recover files from a different CP/M system - I could most likely do it with the same or a very similar program. What I would like to see is a hardware version of ImageDisk - basically something that can read/write *anything* - and documented well enough that I can figure out other ways to manipulate the data if I need, and standardized enough within our communitity that the archived data will be equally useful to others. The Catweasel may fill this void - I'm not sure how standardized the various images files that can be created from it are, or what other tools are available. As far as I can tell it has suffered from a somewhat inconsistant and erratic software development. I also don't really like that it's tied to a PC PCI card, as that locks it into certain environments unless you want to do a bunch of development not relating to the actual task at hand. And how open and recreatable it is I do not know. I personally like the idea of a "mostly software" system based around a simple/fast fairly modern engine - I'm currently working on projects using Blackfin BF536 and BF537, and also a Curris EP9307 (ARM9), either of which has plenty of muscle for the task - I'm sure other ARM7/ARM9 devices, MIPS etc. would also be contenders. The actual processor used isn't to my mind all that important, since specific modern processors usually become unobtanium in short order anyway - more important is that the code base be portable and well documented. I don't think an 8-bit control processor interfaced with an off-the- shelf FDC will have the flexibility, nor the design longevity required for this type of project. Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.classiccmp.org/dunfield/index.html