Catweasel opinions, sources of info etc.

...snip... Just a few notes on this thread... - regarding the SVD "format" it isn't ASCII octal really. Dwight was refering to the input format to the SVD software that understands H8/H89. The SVD "format" is a modified sector-based format that is half-way in between binary data and floppy track bit image (like FDI). - I've seen two "bit-image" styles of images. In the first, the image contains a byte-by-byte image of the data on the floppy, which normally includes the sector sync bytes, sector header information, data, and checksums. In the second, you have a raw bit-stream, which is necessarily longer than the byte-style because it includes clock bits for FM or special encoding for MFM (for eg.). The byte-by-byte images hide the details of the encoding (FM, MFM, or even GCR), and the bit-by-bit images hide details such as write-pre-compensation. - Randy is talking about implementing a system by which the raw bit stream would be represented, therefore, allowing FM, MFM, GCR, RLL, etc. to be done easily...though write pre-comp is a bit tougher to deal with when allowing the vintage box to write back to the solid-state disk. - the big difference between what Randy is describing and what the SVD does is mainly memory. The SVD was designed around a low amount of memory, so the data fed to it must be custom-prepared based upon the type of floppy it is emulating. With more memory, as in Randy's design, you can have the floppy emulator be blissfully ignorant of the data format and just spew bits. All of the intelligence in this design is in the PC preparing the bit stream. Note that the SVD has to do a lot of that anyway. - Randy mentioned using a track buffering scheme to try to lower the amount of memory used in the bit-spewer approach. Should work well, though there will probably be a latency when seeking multiple tracks. (he and I have talked about this a bit already) Eric