[File] [PATCH] Magdir/c64 Comodore tape image;: details+extension
Jörg Jenderek
joerg.jen.der.ek at gmx.net
Wed Feb 28 01:43:29 UTC 2024
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
-------------- next part --------------
--
File mailing list
File at astron.com
https://mailman.astron.com/mailman/listinfo/file
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trid-v-tape.txt.gz
Type: application/x-gzip
Size: 748 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240228/16a7d33d/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: droid-tape.csv.gz
Type: application/x-gzip
Size: 968 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240228/16a7d33d/attachment-0003.bin>
-------------- next part --------------
--- file-5.45/magic/Magdir/c64.old 2023-06-19 15:43:13.000000000 +0200
+++ file-5.45/magic/Magdir/c64 2024-02-28 02:23:46.113067300 +0100
@@ -166,16 +166,63 @@
-0 string C64S\x20tape\x20file T64 tape Image
->32 leshort x Version:%#x
->36 leshort !0 Entries:%i
->40 string x Name:%.24s
-
-0 string C64\x20tape\x20image\x20file\x0\x0\x0\x0\x0\x0\x0\x0\x0\x0\x0\x0 T64 tape Image
->32 leshort x Version:%#x
->36 leshort !0 Entries:%i
->40 string x Name:%.24s
-
-0 string C64S\x20tape\x20image\x20file\x0\x0\x0\x0\x0\x0\x0\x0\x0\x0\x0 T64 tape Image
->32 leshort x Version:%#x
->36 leshort !0 Entries:%i
->40 string x Name:%.24s
+# 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
+# Note: called "Commodore 64 Tape container" by TrID, "T64 Tape Image Format" by DROID via PUID fmt/820 and
+# "T64 tape Image" by ./c64,v 1.14
+# verified by command like `deark -m t64 -l -d2 Caitan_the_Demo.t64` and
+# `cbmconvert -v2 -t -D4 ironmanoffroad.d64 ironmanoffroad.t64`
+# 32 byte signature starting like C64S\x20tape\x20file
+# C64\x20tape\x20image\x20file\x0\x0\x0\x0\x0\x0\x0\x0\x0\x0\x0\x0
+# C64S\x20tape\x20image\x20file\x0\x0\x0\x0\x0\x0\x0\x0\x0\x0\x0
+0 string/b C64
+# skip raw Commodore TAPe by check for unsed areas (\0 filled) and valid low (40h+m*20h; m=0-FFffh) offset
+>0x46 ubequad&0xFFff1F00C0ffFFff 0 Commodore Tape image
+#!:mime application/octet-stream
+#!:mime application/x-commodore-tape
+!:ext t64
+# version like: 0100h (examples found) 0101h 0200h (no examples)
+>>32 leshort x Version:%#x
+#>>32 leshort !0x0100 Version:%#x
+# number of used directory entries like: 0 1 2 5
+>>36 leshort !0 Entries:%i
+# tape container name, 24 characters (padded with 20h but with A0h for DirMaster created samples) like:
+# ->ZYRON'S PD<- IMAGETAPE MY-T64-TEST\240\240\240 OPERATIONWOLF+3-711.T64
+>>40 string/24/Tb >\040 Name:%.24s
+# MaxFiles; maximal directory entries like: 0 1 2 5 30 (=1Eh some emulators expect exactly this value) 31 32
+>>34 uleshort x MaxFiles:%u
+# 1st C64 filetype: 0~free 1~normal tape file 2~tape file with header 3~memory snapshot 4~tape block 5~digitized stream 6-255~reserved
+>>0x40 ubyte !1 \b, C64 file type %#x
+# 1st start address or load address of first entry like: 0000 (empty|snapshot) 04a0h (ironmanoffroad.t64) 0801h (typically) 1201h (3501_quizmaster_program_s1.t64)
+>>0x42 uleshort !0x0801 \b, load address %#4.4x
+# 1st actual end address in memory
+>>0x44 uleshort x \b, end address %#4.4x
+# reserved; must be 0
+>>0x26 ubeshort !0 \b, at +0x26 %#x
+# not used like: 0 (examples found and according to TrID)
+>>0x46 ubeshort !0 \b, at 0x46 %#4.4x
+# not used like: 0 (examples found and according to TrID)
+>>0x4c ubelong !0 \b, at 0x4C %#8.8x
+# offset (=64+32*m) into 1st container file like: 0 (empty) 60h 80h E0h 400h 440h ...
+>>0x48 ulelong >0 \b, at %#x
+# 1st filename (in PETASCII, padded with 20h, not A0h) like: "DRILLINSTR. /HTL" "WIZBALL+ " ...
+>>>0x50 string/16/bT x "%0.16s"
+# https://www.lyonlabs.org/commodore/onrequest/Inside_Commodore_Dos.pdf
+# file type like: 0~Scratched 1~SEQunclosed 81h~SEQ 82h~PRG C2h~PRGlocked ...
+>>>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
+# other unusual file type
+>>>>0x41 default x
+>>>>>0x41 ubyte x %#2.2x type
+# inspect 1st entry content (often Commodore C64 BASIC program *.PRG) without load adress
+#>>(0x48.l) ubequad x \b, 1st data %16.16llx...
@@ -183,5 +230,44 @@
# Esa Hyyti <esa at netlab.tkk.fi>
-0 string C64-TAPE-RAW C64 Raw Tape File (.tap),
+# Update: Joerg Jenderek
+# 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
+# Note: called "TAP (Commodore 64)" by DROID via PUID fmt/802
+# a variant starting with C16-TAPE-RAW should exist, but no examples found
+0 string/b C64-TAPE-RAW Commodore raw Tape image (platform
+#0 string C64-TAPE-RAW C64 Raw Tape File (.tap),
+#!:mime application/octet-stream
+!:mime application/x-commodore-tape
+!:ext tap
+# According to TrID als raw suffix, but no such samples found
+#!:ext tap/raw
+# computer platform like: 0~C64 1~VIC-20 2~C16 Plus/4 3~PET 4~C5x0 5~C6x0 C7x0
+>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
+# this should not happen!
+>0xD ubyte >5 %#2.2x
+>0xD ubyte x \b),
+# Reference: http://mark0.net/download/triddefs_xml.7z/defs/t/tap.trid.xml
+# http://mark0.net/download/triddefs_xml.7z/defs/t/tap-1.trid.xml
+# Note: called "C64 Tape image format" (v0-original) (v1-updated)" by TrID
+# TAP version like: 0~OriginalLayout 1~Updated (often)
>0x0c byte x Version:%u,
+# file data size (not including header)
>0x10 lelong x Length:%u cycles
+# video standard like: 0~PAL 1~NTSC 2~OLD NTSC 3~PALN
+>0xE ubyte x \b, video
+>0xE ubyte 0 PAL
+>0xE ubyte 1 NTSC
+>0xE ubyte 2 old NTSC
+>0xE ubyte 3 PALN
+# this should not happen!
+>0xE ubyte >3 %#2.2x
+# reserved for future expansion like: 0
+>0xF ubyte !0 \b, at 0xF %#2.2x
+# file data
+#>014 ubequad x \b, data %16.16llx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.45-c64-tape.diff.sig
Type: application/octet-stream
Size: 2550 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240228/16a7d33d/attachment-0001.obj>
More information about the File
mailing list