Catweasel opinions, sources of info etc.
Eric J. Rothfus
eric at rothfus.com
Wed Mar 9 16:36:10 CST 2005
>>I'm looking into using an eZ80 and a Flash card. By using track buffering
>>it is possible to emulate almost anything with very little RAM.
> Hi Randy
> I'm familiar with Eric's work. I was stating that without
>specific hardware, writing these unusual formats is not possible
>with a PC. Eric's stuff is a good way to handle things.
> Does anyone know the specifics of what is different
>between the SVD format and the FDI's?. The SVD is an
>ASCII octal format. Is the FDI a binary or something?
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
- 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)
More information about the cctech