1. Forum
  2. USENET
  3. comp.sys.cbm

  • F64 Support in StarCommander or some other Util ?

    From Tomaz Kac@tomcat@sgn.net to comp.sys.cbm on Tuesday, July 01, 2003 08:10:15
    From Newsgroup: comp.sys.cbm

    Hi!

    I have an 1541-II drive for some time now and thanx to people like Steppe I also have some 5.25" floppies to play with. :) Recently I have got a CD called "C64 Unicorn CD '96" or similar. It is packed with .D64 images which have all been checked, etc. and most are not to be found on the net. What is most interesting is that all images also come with .F64 companion file, which basically contains 3 additional bytes per sector.
    Most (I would say over 90%) of images work fine without this .F64 file, but some need it because it contains error and checksum information, which is checked. I know only of one other format that does that - .G64, but that is a completely different way of storing this data.
    There are some tools that can be used to transfer these images back to the real 1541 drive, BUT for this the drive needs to be modified (Dolphin DOS modification) and two new cables must be built (connecting the PC to the Drive AND both Joystick ports), which I really don't want to do - it is not really worth it.
    So I have a question - does anyone know of a program that could use this .F64 file and write back the .D64 images with this additional info using normal XE1541 cable ? The .F64 file is really straight-forward, I have found ONE site on the net with the format description and I include it at the end of this message.
    What would be perfect is support in StarCommander :) But I guess that could be
    out of the question, since the format is not well spread ?
    If anyone could help out with this then I can supply the .F64 files and images, even the CD image if they would want.

    Best regards,
    Tomaz

    Here is the format description from
    http://members.tripod.com/~petlibrary/F64.HTM

    *** F64 (a companion file to certain D64's)
    ** Document revision 1.1
    Created by a program called FCOPY, written by M. Edzes in the early 1990's, these files contain some extra information about the associated D64 files like the low-level disk ID, sector checksum, valid sector flag and header ID. Some of what you are about to read is pure conjecture on the part of the author to explain what these files are. These files appear to
    be very rare, but are available from a CD called "C64 CD 96", also known as
    the "Unicorn" CD.

    They all appear to be the same size, 2051 bytes, and seem to start with
    the DISK ID from the D64 image.

    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
    ----------------------------------------------- ----------------
    0000: 30 34 .. .. .. .. .. .. .. .. .. .. .. .. .. .. 04..............

    Here the DISK ID is "04", and is likely obtained from the sector header
    ID for track 18/0 (not the one visible on the BAM sector).
    Once we take into account the first two bytes, this leaves the remaining 2049 bytes. Dividing this number by 683 (the number of sectors in a standard 35 track D64 image) leaves us a grouping of 3 bytes per sector. Below is a dump of the first few bytes of the F64 files, and we will examine a few of the 3-byte descriptions.

    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
    ----------------------------------------------- ----------------
    0000: .. .. 2D 07 01 2B 07 8D 2B 07 47 2B 07 AE 2B 07 ..-úú+ú?+úG+ú®+ú 0010: 80 2B 07 C3 2B 07 1C 2B 07 4E 2B 07 EC 2B 07 47 €+úĂ+úú+úN+úě+úG
    0020: 2B 07 FE 2B 07 5F 2B 07 69 2B 07 F3 2B 07 90 2B +úţ+ú_+úi+úó+ú?+ 0030: 07 22 2B 07 4D 2D 07 01 2D 07 01 2D 07 01 2D 07 ú"+úM-úú-úú-úú-ú

    The first sector has a description of "2D 07 01".
    Byte: 00 - "2D". This byte likely represents whether the sector data
    was read or not. This value can be either "2D" (a "-"
    character, meaning data not valid) or "2B" (a "+" character,
    meaning data valid).
    01 - "07". This is the "data descriptor byte" meaning the sector
    is OK, and exists. If it was a value other than 07, we have
    an error 22 ("data block not found").
    02 - "01". This is the checksum for the sector. It is arrived at
    by XOR'ing all the bytes contained in the sector, from
    position 00 to position FF.
    The second sector has a description of "2B 07 8D". From the above layout, this means the sector data is ok, the data header is ok ("07"), and has a checksum of "8D" (calculated and verified from the D64).


    Tomaz Kac |\ _,,,---,,_
    --------- Deus Ex-Machina /,`.-'`' -. ;-;;,
    E-Mail: tomcat@sgn.net |,4- ) )-,_. ,\ ( `'::. worldofspectrum.org/tomcat '----''(_/--' `-'\_) TC
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Tomaz Kac@tomcat@sgn.net to comp.sys.cbm on Wednesday, July 02, 2003 07:07:26
    From Newsgroup: comp.sys.cbm

    have a look at http://sta.c64.org/scbetahistory.html
    The Star Commonader supports the F64 companion file since
    version 0.83.08 beta. Only read access is implemented and
    enabled you can't create F64 files with it.

    Oh man, how could I miss this ? I went through the doc thoroughly - or so I tought :) Thanx for this info...

    If you transfer a decent D64 file to a disk, SixPack
    ZipCode or D64 with error info attached and SC detects a
    F64 file with the same name (of the source D64) in the
    same directory, it will ask you, if the data of the F64
    file should be take into account.

    It didn't ask me when I tried - i.e. something must of gotten wrong or I used an
    older version - but I am 99.9% sure it was the latest release from the site.

    You can hopefully restore the error info on real disks
    this way. Since the F64 cannot handle _all_ possible
    errors and because some info can be interpreted ambiguous
    it may be possible, that you cannot reproduce all error
    info.

    Well, I will 100% try it again with the latest release of SC !!!

    If you should detect such problematic D64/F64 pairs, you
    should contact Joe directly and describe him the problems.

    Will do, I have around 6000 .D64 files with .F64 companions which I will test over the course of next month(s) so I will prolly stumble on some...

    PS: Please don't create any further F64 file with the
    FCopy-PC transfer system. You should use Markus Brenners
    mnib instead. It produces GCR files, which are able to
    handle nearly all possible error schemes.

    Well, I don't have the cables needed for FCopy-PC transfer system so I will definetly not be making these.

    Again, thanx for this info, I am sorry I missed it in the documentation and bothered you guys here :(

    Best regards,
    Tomaz

    Tomaz Kac |\ _,,,---,,_
    --------- Deus Ex-Machina /,`.-'`' -. ;-;;,
    E-Mail: tomcat@sgn.net |,4- ) )-,_. ,\ ( `'::. worldofspectrum.org/tomcat '----''(_/--' `-'\_) TC
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Tomaz Kac@tomcat@sgn.net to comp.sys.cbm on Wednesday, July 02, 2003 11:12:54
    From Newsgroup: comp.sys.cbm


    Will do, thanx for pointing this out ! :)

    Tomaz

    On 2 Jul 2003 02:05:13 -0700, in comp.sys.cbm you wrote:

    Hi Tomaz,

    Make sure to grab F64Check from http://sta.c64.org/scextprg.html ,
    too. It analyzes F64 files. If the Commander is doing something weird,
    first, you should check the F64 (and the D64) with F64Check, as,
    perhaps, the _files_ are damaged, not the Commander is buggy... ;-)

    Joe Forster/STA
    sta@c64.org


    Tomaz Kac |\ _,,,---,,_
    --------- Deus Ex-Machina /,`.-'`' -. ;-;;,
    E-Mail: tomcat@sgn.net |,4- ) )-,_. ,\ ( `'::. worldofspectrum.org/tomcat '----''(_/--' `-'\_) TC
    --- Synchronet 3.18b-Win32 NewsLink 1.113