Another disk imaging project (long response)

Sorry to join this thread late, but I think it would be a fantastic idea/project to create this universal vintage computer floppy controller. Of course, I WOULD think so, since I've been working on part of the idea for the past couple of years - the Semi-Virtual Diskette (SVD) http://www.theSVD.com . Feel free to download the software like. There seems to be at least four catagories/layers of functionality that would be appropriate for this type of device as detailed below (in no particular order). There's enough overlap of these areas that a single device could be built to fulfill all of the features. --- Floppy Emulation The idea behind floppy emulation is to provide a solid-state mechanism that would allow vintage machines to boot/read/write directly from/to diskette images without the need for a physical floppy drive or physical floppies. Given, particularly, that floppy media has a degrading lifespan, this type of device makes it far easier to operate vintage gear. Further, this type of device makes it possible to backup/copy diskette images for archival and later use. For purposes of this discussion, it is assumed that the device is NOT a full-fledged PC. So a PC would be a necessary part of the whole solution, being used to archive and upload/download the images to the device. This device would probably not have an off-the-shelf floppy controller, since they are normally meant to operate with a particular encoding such as M/FM for the WD179x. Encodings such as H8/H89, Apple 2, N*, etc. are NOT stock M/FM. Instead, this device would probably have a micro-conroller or processor that would "bit-bang" the same type of floppy control. There is a downside to this type of device. The vintage machine is a necessary part of a "floppy copy" operation. That is, since the device looks just like a floppy drive & floppy to the vintage computer, the computer must run a "copy" operation to make a backup copy of a floppy. If the target diskette is copy- protected, it is quite likely that the vintage machine would not be able to copy it. The SVD that I've been working on for the last couple of years is exactly this type of device. Though the current downside to the SVD is that it must be specifically programmed to support a paricular floppy type. The SVD II will be generic, taking a soft description of the floppy type. This will allow SVD with even previously unsupported platforms. Further, it is locked into 300rpm with 4 micro- second bit cells. --- Stand-alone Floppy Reader/Writer Almost the opposite of the floppy emulator, this device would attach to a vintage floppy drive and extract/write images to and from the floppies inserted in the drive. It could be used to make duplicates of floppies either from physical to image or from image to physical. Through multiple simultaneous floppy drive connections, it could make dynamic copies of floppies whereby the copy would be BETTER than the original. The nice thing about this device is that it wouldn't need to be connected to the vintage computer to make the copy. Further, it need not necessarily know about the encoding mechanism for the floppy, being able to make copies based upon the bit transitions seen on the floppy interface lines. Like the floppy emulator, this device would not be a full-fledged PC, using a periphery PC to up/download images and for configuration. This device would be able to deal with issues such as rotational speed variation and bad sectors probably more effectively than a vintage computer trying to make a copy. However, it would also need to understand and adapt to different mechanisms such as hard-sectored, indexed, and non-indexed floppies (as in Heathkit, WD179x, and Apple 2 floppies respectively). It would need to be configurable to deal with different densities, rotational speeds, sides, tracks, and other floppy physical characteristics. It would also need to be able to generate an appropriate write-precompensated signal. Fortunately, it could be made smart enough to auto-configure itself for write-precomp. --- External Floppy Controller Both of the above devices represent relatively stand-alone functionality, using the PC only for control, configuration, and image storage. Another very interesting device would be one that would act as a dynamic external "vintage floppy controller" for a PC. A specialized PC-based floppy driver could be created that "speaks" to the external controller over a (pick your favorite) parallel/RS232/USB link using sector read/write commands...not unlike the way in which the Commodore 64 or Model 100 interface to floppy drives. Through driver and external device configuration software, the external device will present a vintage floppy drive and floppy to the PC as a simple storage device, allowing it to read/write to it. In addition to read/write commands, other commands would be available to format and download raw sectors and tracks. Although this would be a very _interesting_ device, I feel that it probably goes too far, and that the increased work necessary to create it provides very little extra value. The other two devices above allow you to work with "images" of floppies, which IMHO is enough. --- PC Software Control All of these wonderful features require some form of robust control, such as what can provided by your off-the-shelf PC. Though it wouldn't be a required part of the "function" of the device, it would be a necessary part of the control of the device. Through the PC's extensive user interface as well as its connectivity and storage, it would be able to help configure and control the device as well as provide periphery functions such as: - floppy image analysis, verification, and translation - file system manipulation, including insertion and extraction of individual files I've spent a lot of time on this area, as well, with the SVD. The SVD software runs on both Windoze and Linux PCs, allowing you to upload/download images to the SVD. Further, it understands the filesystems of many of the different vintage boxes include the H8/H89, TRS-80, and Apple, allowing you to download individual files. I'd be happy to collaborate on the creation of new devices in this area. It should be possible to reuse SVD code, or to at least steal some of the ideas. Eric