Catweasel opinions, sources of info etc.

Eric J. Rothfus eric at rothfus.com
Wed Mar 9 16:36:10 CST 2005


...snip...
>>
>>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.
>>
>>
>>Randy
>>
>
> 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?
>dwight

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



More information about the cctech mailing list