[File] [PATCH] Magdir/c64 Comodore tape image; : details+extension
Christos Zoulas
christos at zoulas.com
Thu Feb 29 03:52:11 UTC 2024
Committed, thanks!
christos
> On Feb 27, 2024, at 8:43 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
>
> Hello,
>
> some days ago i send patches for Commodore floppy disc images. So i also
> look for Commodore tape images.
>
> When running file command version 5.45 on such examples and "related"
> files i get at first glance not bad looking output like:
>
> 3501_quizmaster_program_s1.t64: T64 tape Image
> Version:0x101 Entries:2
> Name:QUIZMASTER
> 3505_demonstration_data_s2.tap: C64 Raw Tape File (.tap),
> Version:1, Length:212445 cycles
> Blues_Brothers_Chain.t64: T64 tape Image
> Version:0x100 Entries:5 Name:
> C64S_tape_file.txt: T64 tape Image
> Version:0x3121 Entries:13620
> Name:890abcdefghijklmnopqrstu
> C64_TOP_FIVE_II.T64: T64 tape Image
> Version:0x100 Entries:1 N
> Name:C64 TOP FIVE II.T64
> Caitan_the_Demo.t64: T64 tape Image
> Version:0x100 Entries:1
> Name:->ZYRON'S PD<-
> Drillinstructor-Hotline.t64: T64 tape Image
> Version:0x100 Entries:1
> Name:IMAGETAPE
> Exploding_Fist_TSI.t64: T64 tape Image
> Version:0x100 Entries:1
> Name:IMAGETAPE
> For Kicks.t64: T64 tape Image
> Version:0x100 Entries:1
> Name:->ZYRON'S PD<-
> Little Nipppers 4K [Craptastic].tap: C64 Raw Tape File (.tap),
> Version:1, Length:87426 cycles
> MyTapeT64.t64: T64 tape Image
> Version:0x100
> Name:MY-T64-TEST\240\240\240\
> OperationWolf+3-711.T64: T64 tape Image
> Version:0x100 Entries:2
> Name:OPERATIONWOLF+3-711.T64
> Spy vs Spy (X&Y).t64: T64 tape Image
> Version:0x100
> Name:DEMO TAPE
> Toxic [Freeload].tap: C64 Raw Tape File (.tap),
> Version:1, Length:580510 cycles
> Wizball+.t64: T64 tape Image
> Version:0x100 Entries:2
> Name:->ZYRON'S PD<-
> ironmanoffroad.t64: T64 tape Image
> Version:0x100 Entries:1
> Name:\311RONMAN'S \317FFROAD
> tap-text.txt: C64 Raw Tape File (.tap),
> Version:116,
> Length:1750343713 cycles
> vtxxxx_pharoahs_tomb.tap: C64 Raw Tape File (.tap),
> Version:1, Length:1216051 cycles
>
>
> Furthermore for samples only generic mime type application/octet-stream
> is shown with -i option. With --extension option only 3 byte sequence
> ??? is shown for such samples.
>
> For comparison reason i also run the file format identification
> utility DROID ( See https://sourceforge.net/projects/droid/). My
> inspected TAP samples are here described as "TAP (Commodore 64)" by PUID
> fmt/802. The TAP suffix is considered as valid and TXT is considered as
> "bad" in misidentified text sample tap-text.txt. Some T64 samples
> (starting with 9 byte phrase "C64S tape") are recognized and described
> as "T64 Tape Image Format" by PUID fmt/820. The T64 suffix is considered
> as valid (See appended droid-tape.csv.gz).
>
> On Linux according to shared MIME-info database the samples are not
> recognized.
>
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). This identifies the
> the T64 samples as "Commodore 64 Tape container" by emu-t64.trid.xml.
> My real inspected TAP samples are described as "C64 Tape image format
> (v1-updated)" by tap-1.trid.xml. Here 2 suffix are listed (.TAP/RAW).
> The text sample tap-text.txt (starting with C64-TAPE-RAW is here
> described as Unknown! (See appended trid-v-tape.txt.gz)
>
> With the help of the other tools i found page about TAP format on file
> formats archive team site and on vice emulator web server. That
> informations are expressed by comment lines inside Magdir/c64 like:
>
> # URL: http://fileformats.archiveteam.org/wiki/Tap_file
> # https://vice-emu.sourceforge.io/vice_16.html#SEC392
> # Reference: http://ist.uwaterloo.ca/~schepers/formats/TAP.TXT
> # http://mark0.net/download/triddefs_xml.7z
> # defs/t/tap.trid.xml
> # defs/t/tap-1.trid.xml
>
> The handling of TAP samples is done inside Magdir/c64 by lines like:
> 0 string C64-TAPE-RAW C64 Raw Tape File (.tap),
> >0x0c byte x Version:%u,
> >0x10 lelong x Length:%u cycles
>
> According to vice emulator documentation some of the remaining bytes in
> header before data bytes have a meaning (like platform, video standard).
> One byte is still reserved for future expansion. So this seems to be
> nil. So show this informations by additional lines like:
> >0xE ubyte x \b, video
> >0xE ubyte 0 PAL
> >0xE ubyte 1 NTSC
> >0xE ubyte 2 old
> >0xE ubyte 3 PALN
> >0xE ubyte >3 %#2.2x
> >0xF ubyte !0 \b, at 0xF %#2.2x
> # file data
> #>014 ubequad x \b, data %16.16llx
>
> Instead of generic application/octet-stream i show an user defined mime
> type one. At the moment such samples are called "C64 Raw Tape File
> (.tap)". But when you not grow up in area of playing games on Commodore
> C64 computer like me than this description sounds like Egypt hieroglyphs
> for normal users. The phrase tap means that this 3 byte string is used
> as file name suffix. This becomes more clearly when putting this
> information inside !:ext magic, so that this information is shown with
> option --extension and not as description text. By DROID such samples
> "TAP (Commodore 64)". So i choose additional company name Commodore to
> occur in description. Some samples like vtxxxx_pharoahs_tomb.tap are for
> platform VIC-20 and not for C64. So the phrase C64 is not always true or
> constant and may vary depending on platform byte. At least because of
> nil byte for further expansion the TAP samples are binary files and are
> not text like sample tap-text.txt starting with 12 byte ASCII phrase
> C64-TAPE-RAW. So the magic check must be done as binary. The TrID tool
> do not misidentifies this text samples because it also check the version
> byte for value 0 or 1. This means Original Layout or updated. In my
> inspected samples i only found value 1. According to documentation there
> should exist samples which start with phrase C16-TAPE-RAW, but i do not
> found such samples. According to TrID beside TAP the 3 byte suffix RAW
> should occur, but i do not found such samples. So i show best suited
> description and correct associated suffix by next lines. These look like:
> 0 string/b C64-TAPE-RAW Commodore Raw Tape File (platform
> !:mime application/x-commodore-tape
> !:ext tap
> >0xD ubyte 0 C64
> >0xD ubyte 1 VIC-20
> >0xD ubyte 2 C16 Plus/4
> >0xD ubyte 3 PET
> >0xD ubyte 4 C5x0
> >0xD ubyte 5 C6x0 C7x0
> >0xD ubyte >5 %#2.2x
> >0xD ubyte x \b),
>
> With the help of the other tools i found page about T64 format on file
> formats archive team site and on vice emulator web server. That
> informations are expressed by comment lines inside Magdir/c64 like:
>
> # URL: http://fileformats.archiveteam.org/wiki/T64
> # Reference: http://ist.uwaterloo.ca/~schepers/formats/T64.TXT
> # https://vice-emu.sourceforge.io/vice_16.html#SEC394
> # https://www.infinite-loop.at/Power64/Documentation/
> # Power64-ReadMe/AE-File_Formats.html
> # http://mark0.net/download/triddefs_xml.7z
> # defs/e/emu-t64.trid.xml
> There you find download links for samples like the above inspected ones.
> There i also found links to software like DirMaster, cbmconvert and
> Deark. With the help of these tools i could handle my inspected samples.
> I also could read, convert and extract samples with command lines like:
> verified by command like:
> deark -m t64 -l -d2 Caitan_the_Demo.t64
> cbmconvert -v2 -t -D4 ironmanoffroad.d64 ironmanoffroad.t64`
>
> First variant for T64 samples is done inside Magdir/c64 by lines like:
>
> 0 string C64S\x20tape\x20file T64 tape Image
> >32 leshort x Version:%#x
> >36 leshort !0 Entries:%i
> >40 string x Name:%.24s
>
> When inspecting some dozen of examples many are not distinguishable,
> because some samples have the same tape name like ->ZYRON'S PD<- or
> IMAGETAPE. Some samples have unique name (like OPERATIONWOLF+3-711.T64
> or MY-T64-TEST\240\240\240. According to documentation the tape
> container name can contain 24 characters and is padded with 20h (space
> character, but samples created with DirMaster tool are right padded A0h
> (240 octal see MyTapeT64.t64 sample). So now show name if not empty (like in
> Blues_Brothers_Chain.t64) by line like:
> >>40 string/24/Tb >\040 Name:%.24s
> In most of my inspected samples i only get version 0x100. I found only
> one example like 3501_quizmaster_program_s1.t64 with version 0x101 and
> no example with version 0x200. So maybe it is more useful to show this
> information by line like:
> >>32 leshort !0x0100 Version:%#x
>
> For number of used directory Entries is get values like 0 1 2 5.
> In that context the maximal directory entries (MaxFiles or just called m
> in further text) are interesting. So show this information by new
> additional line like:
> >>34 uleshort x MaxFiles:%u
> Here i get values like 0 1 2 5 30 31 32. In documentation is written
> that some emulators expect exactly the value 30 (that is hexadecimal
> 1E). Furthermore after header (size 64=40h) the directory part is stored
> with size m*20h. That information becomes useful in later considerations.
>
> Now lets consider first tape directory entry at offset 40h. It starts
> with C64 file type. There in most case i get here value 1. That means
> normal tape file. In few few samples like MyTapeT64.t64 i get here value
> 0. That means free. The other possible values are like:
> 2~tape file with header 3~memory snapshot 4~tape block 5~digitized
> stream 6-255~reserved
> So show unusual values by line like:
> >>0x40 ubyte !1 \b, C64 file type %#x
>
> The start and end address for first tape entry is shown by lines like:
> >>0x42 uleshort !0x0801 \b, load address %#4.4x
> >>0x44 uleshort x \b, end address %#4.4x
> In most cases i get value 0801h for load address. When extracting such
> entries by deark for example the resulting tape member is identified by
> Magdir/c64 as something like Commodore C64 program. For few samples like
> 3501_quizmaster_program_s1.t64 i get value 1201h. So the extracted tape
> member is described as Commodore VIC-20 +8K BASIC program. For sample
> like ironmanoffroad.t64 i get value 04a0h. This program with such an
> exotic load address is not identified by current Magdir/c64. For empty
> MyTapeT64.t64 i got value 0 here. The end address depends on program
> size. In most cases this and so the end address is different even if
> tape name is same. So now i got distinguishable descriptions here.
>
> Some areas are described as unused. In my inspected samples and
> according to TrID the value is nil. So for control reason i show
> unexpected values of unused areas by lines like:
> >>0x46 ubeshort !0 \b, at 0x46 %#4.4x
> >>0x4c ubelong !0 \b, at 0x4C %#8.8x
> I will use that information later for identification.
>
> The offset of first entry and the content can be shown by lines like:
> >>0x48 ulelong >0 \b, at %#x
> #>>>(0x48.l) ubequad x \b, 1st data %16.16llx...
> So for offset i get values like 0 (empty) 60h 80h E0h 400h 440h.
> Apparently there is no gap and entries appear in directory order so the
> offset is done by formula like:
> =64+32*m=40h+20h*m
> When maximum for m is ffFFh then the maximal offset is 200020h and this
> is decreased in 20h steps. I will use this information later.
> Unfortunately the data can not be identified by indirect procedure
> because when extracting the Commodore program this is constructed by
> load address and these data content bytes.
>
>
> The first existing filename on tape is now shown by line like:
> >>>0x50 string/16/bT x "%0.16s"
> This name is stored encoded with PET-ASCII and is padded with 20h (space
> character, not A0h). Here i get strings like "DRILLINSTR. /HTL"
> "WIZBALL+ " and so on. Now the whole file description is unique
> enough even if internal tape name is same as in ->ZYRON'S PD<-.
> Furthermore this file name often correlates with stored tape name on
> file system (like Drillinstructor-Hotline.t64 Wizball+.t64 etc.)
>
> Last the type of first file is shown by lines like:
> >>>0x41 ubyte x
> >>>>0x41 ubyte =0x00 Scratched type
> >>>>0x41 ubyte =0x01 SEQ unclosed type
> #>>>>0x41 ubyte =0x44 foo type
> >>>>0x41 ubyte =0x80 DEL type
> >>>>0x41 ubyte =0x81 SEQ type
> >>>>0x41 ubyte =0x82 PRG type
> >>>>0x41 ubyte =0x83 USR type
> >>>>0x41 ubyte =0x84 REL type
> >>>>0x41 ubyte =0xC2 PRG locked type
> >>>>0x41 default x
> >>>>>0x41 ubyte x %#2.2x type
>
> In many examples the type value is 82h. That means PRG type (program).
> But i often also found value C2h (like in Caitan_the_Demo.t64). That
> means locked PRG. Value 1h means SEQ unclosed type (like in sample
> 3501_quizmaster_program_s1.t64). For samples where i found no human
> readable type description i show hexadecimal value (like 0x44 in
> Spy vs Spy (X&Y).t64).
>
> The first 32 bytes of the file contain an ASCII signature that begins
> with "C64". Unfortunately, there are several variants of it, such as
> "C64S tape file", "C64S tape image file", and "C64 tape image file".
> The file command recognize these 3 variants, but DROID only recognizes
> the first one. The file command does not check all 32 bytes. Even worse
> it describes text samples like C64S_tape_file.txt starting with "C64S
> tape file" wrong as tape samples by first variant. The last two variant
> are padded with \0-characters as described but the first in my inspected
> samples contain no \0-character in signature. I could try to look
> general for keyword tape inside signature but then i must exclude TAP
> samples with keyword RAW. So this would become more complicated. To
> match all possible variants in the end i choose recognition way as done
> by TrID tool. This checks only for 3 byte string C64 at the beginning
> and nil bytes in unused area. I also check for "low valid" offset
> (matching by formula 40h+20h*m; m=0-FFffh). So the unified tests now
> starts with lines like:
> 0 string/b C64
> >0x46 ubequad&0xFFff1F00C0ffFFff 0 Commodore Tape image
> !:mime application/x-commodore-tape
> !:ext t64
>
> Instead of generic mime type application/octet-stream i display an user
> defined one. At the moment such samples are called "T64 tape Image". But
> when you not grow up in area of playing games on Commodore C64 computer
> like me than this description sounds like Egypt hieroglyphs for normal
> users. The phrase T64 means that this 3 byte string is used as file name
> suffix. By TrID such samples are called "Commodore 64 Tape container".
> So i also choose additional company name Commodore to occur in
> description. Here in Europe T64 sound like brutal Russian war aggressors
> trying to divide Ukraine country with ribbon by tanks. So this becomes
> more clearly when putting this information inside !:ext magic, so that
> this information is shown with option --extension and not as description
> text any more.
>
> After applying the above mentioned modifications by patch
> file-5.45-c64-tape.diff all inspected Commodore tape examples are still
> recognized. But now some more details to distinguish samples are shown.
> Furthermore the few misidentifications also vanished. This now looks like:
>
> 3501_quizmaster_program_s1.t64: Commodore Tape image
> Version:0x101 Entries:2
> Name:QUIZMASTER
> MaxFiles:2,
> load address 0x1201,
> end address 0x2def,
> at 0x80 "QUIZMASTER"
> SEQ unclosed type
> 3505_demonstration_data_s2.tap: Commodore raw Tape image
> (platform VIC-20),
> Version:1, Length:212445 cycles
> , video NTSC
> Blues_Brothers_Chain.t64: Commodore Tape image
> Version:0x100 Entries:5
> MaxFiles:5,
> end address 0xb0ad,
> at 0xe0 "BLUES BROTHERS 1"
> PRG type
> C64S_tape_file.txt: ASCII text
> , with CRLF line terminators
> C64_TOP_FIVE_II.T64: Commodore Tape image
> Version:0x100 Entries:1
> Name:C64 TOP FIVE II.T64
> MaxFiles:31,
> end address 0x547f,
> at 0x420 "C64 TOP FIVE II"
> PRG type
> Caitan_the_Demo.t64: Commodore Tape image
> Version:0x100 Entries:1
> Name:->ZYRON'S PD<-
> MaxFiles:1,
> end address 0x442e,
> at 0x60 "CAITAN DEMO /TMT"
> PRG locked type
> Drillinstructor-Hotline.t64: Commodore Tape image
> Version:0x100 Entries:1
> Name:IMAGETAPE
> MaxFiles:30,
> end address 0x3433,
> at 0x400 "DRILLINSTR. /HTL"
> PRG type
> Exploding_Fist_TSI.t64: Commodore Tape image
> Version:0x100 Entries:1
> Name:IMAGETAPE
> MaxFiles:30,
> end address 0xcfd0,
> at 0x400 "EXPLODING FIST"
> PRG type
> For Kicks.t64: Commodore Tape image
> Version:0x100 Entries:1
> Name:->ZYRON'S PD<-
> MaxFiles:1,
> end address 0x2baf,
> at 0x60 "TRIAD/ FOR KICKS"
> PRG type
> Little Nipppers 4K [Craptastic].tap: Commodore raw Tape image
> (platform C64),
> Version:1, Length:87426 cycles
> , video PAL
> MyTapeT64.t64: Commodore Tape image
> Version:0x100
> Name:MY-T64-TEST\240\240\240\
> MaxFiles:0, C64 file type 0,
> load address 0000,
> end address 0000
> OperationWolf+3-711.T64: Commodore Tape image
> Version:0x100 Entries:2
> Name:OPERATIONWOLF+3-711.T64
> MaxFiles:32,
> end address 0xc4e8,
> at 0x440 "711-OP.W.+++100%"
> PRG type
> Spy vs Spy (X&Y).t64: Commodore Tape image
> Version:0x100
> Name:DEMO TAPE
> MaxFiles:30,
> end address 0xac88,
> at 0x400 "FILE"
> 0x44 type
> Toxic [Freeload].tap: Commodore raw Tape image
> (platform C64),
> Version:1, Length:580510 cycles
> , video PAL
> Wizball+.t64: Commodore Tape image
> Version:0x100 Entries:2
> Name:->ZYRON'S PD<-
> MaxFiles:2,
> end address 0xabe1,
> at 0x80 "WIZBALL+"
> PRG type
> ironmanoffroad.t64: Commodore Tape image
> Version:0x100 Entries:1
> Name:\311RONMAN'S \317FFROAD
> MaxFiles:30,
> load address 0x04a0,
> end address 0xbcbd,
> at 0x400 "IRONMANS OFFROAD"
> PRG type
> tap-text.txt: ASCII text
> , with CRLF line terminators
> vtxxxx_pharoahs_tomb.tap: Commodore raw Tape image
> (platform VIC-20),
> Version:1, Length:1216051 cycles
> , video PAL
>
>
>
> I hope my diff file can be applied in future version of file utility.
>
> With best wishes
> Jörg Jenderek
> --
> Jörg Jenderek
> <Nachrichtenteil als Anhang.DEFANGED-6794><trid-v-tape.txt.gz><droid-tape.csv.gz><file-5_45-c64-tape_diff.DEFANGED-6795><file-5_45-c64-tape_diff_sig.DEFANGED-6796>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>
More information about the File
mailing list