[File] [PATCH] Magdir/c64, mmdf, images, pdp collision: D64 Image, MMDF mailbox, Targa image, PDP-11 UNIX/RT ldp
Jörg Jenderek (GMX)
joerg.jen.der.ek at gmx.net
Mon Feb 19 01:26:33 UTC 2024
Hello,
some days ago i read an article about emulation of old commodore
computer. In that context disc image with D64 file name extension are
mentioned. When running file command version 5.45 with -k option on such
examples and "related" files i get an output like:
Cabal+2-MarioSoft(1).d64: Targa image data
- Map (257-257)
257 x 257 x 1 +257 +257
- 1-bit alpha "\001\001\001\00
D64 Image
DolphinDosErrorBytes.d64: D64 Image
DragonNinja+4DCS+ATC+Pearl.d64: D71 Image
Kokotoni Wilf (ANTI-ROM).d64: Targa image data
- Map (257-257)
257 x 257 x 1 +257 +257
- 1-bit alpha "\001\001\001\001
D64 Image
M1571-D71.d71: Targa image data
- Map (257-257)
257 x 257 x 1 +257 +257
- 1-bit alpha "\001\001\001\001
D71 Image
My-8250-D82.d82: data
The Great Gianna Sisters.d64: Targa image data
- Map (257-257)
257 x 257 x 1 +257 +257
- 1-bit alpha "\001\001\001\001
D64 Image
MMDF mailbox
PDP-11 UNIX/RT ldp
TheGreatGiannaSisters.d81: D81 Image
bmpsuite-216col1st-98h.tga: Targa image data
- Map (152-217)
- RLE
1024 x 768 x 8 +768 - top
brucelee.d64: D64 Image
VAX-order 68k Blit mpx/mux executable
TTComp archive data
, ASCII, 4K dictionary
cbmcmd23.d80: data
elektrix.d64: D64 Image
file-speeddos.d64: D64 Image
input.tga: Targa image data
- RGB
70 x 46 x 24
lastninja12.d81: D81 Image
ls209.d81: D81 Image
maillog.expected.2: MMDF mailbox
PDP-11 UNIX/RT ldp
sim&rct.d64: data
test-mbox.d80: data
test-mmdf.d71: D71 Image
test-pdp.bin: PDP-11 UNIX/RT ldp
ucm8.tga: Targa image data
- Map (256)
128 x 128 x 8
"Truevision(R) Sample Image"
- author "Ricky True"
- comment "Sample 8 bit uncompressed
color mapped image" 24-2-1990 10:00:00
- job "TGA Utilities"
- TGAEdit 1.40
uupc.input.1: Targa image data
- Map (257-257)
257 x 257 x 1 +257 +257
- 1-bit alpha "\001\001"
MMDF mailbox
PDP-11 UNIX/RT ldp
Furthermore for samples not described as Targa image 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/). The
TGA graphic images are described as "Truevision TGA Bitmap" with version
1.0 without mime type by PUID x-fmt/367 or with version 2.0 by PUID
fmt/402. The sample maillog.expected.2 is described as "MIME Email" with
version 1.0 and mime type message/rfc822 by PUID fmt/950. Most of the
Commodore disc images are described as "null bytes" by
null_bytes.trid.xml because often the images contains no content at the
beginning (See appended trid-v-d64.txt.gz).
The description as mailbox happens inside Magdir/mmdf by line like:
0 string \001\001\001\001 MMDF mailbox
Luckily i found a page about MMDF (Multi-channel Memorandum Distribution
Facility) on Wikipedia. The file format is also described in section
five of manual user pages {See mmdf(5)}. This manual is part of packages
from some user manuals or mutt mail user agent or tin news reader. That
informations are now expressed by additional comment lines inside
Magdir/mmdf like:
# URL: https://en.wikipedia.org/wiki/MMDF
# Reference: https://docs.oracle.com/cd/E88353_01/html/E37852/
# mmdf-5.html
According to documentation MMDF (Multi-channel Memorandum Distribution
Facility) mailbox format is a "legacy" variant of mbox format. Each
message is surrounded by lines containing 4 control-A. Unfortunately the
check for these four control characters (magic strength=70) is not
unique enough. These matches a few D64 Images like "The Great Gianna
Sisters.d64" (strength=70) initialized with ^A and handled by
Magdir/c64. At the beginning the 2 Control-A characters can be read as
hexadecimal 0101 or octal 0401. The last is interpreted as "PDP-11
UNIX/RT ldp" by Magdir/pdp (magic strength=50).
I first try to additional check for following valid line terminator
(10=0Ah~LineFeed 13=0Dh~CarriageReturn) according to documentation.
The MMDF format was rarely used. So i found only few examples. Some
samples are from software oldmailconvert found on github. This test
works for maillog.expected.2 but not for sample uupc.input.1. There more
Control-A are at the beginning. I do not know if this is a real valid
MMDF example or if this byte sequence is an artefact of transfer
process. So i decide not to use this test and use another relaxed method
by looking for MBOX mail characteristic afterwards. Apparently MMDF can
be used as file name suffix. But when i understand documentation right
on systems with MMDF format the default mailbox name is like
/usr/spool/mail/username. That means no file name suffix here. According
to Magdir/mail.news for embedded MBOX message/rfc822 is used as mime
type. Unfortunately i found no mime type for MMDF. So i decided to
choose a similar user defined one. So the magic lines now looks like:
0 string \001\001\001\001
>5 search/610/b From\ MMDF mailbox
!:mime message/x-mmdf
!:ext /mmdf
The description as PDP (with magic strength 50) happens inside
Magdir/pdp by lines like:
0 leshort 0401
>68 ulelong !0x00000058 PDP-11 UNIX/RT ldp
By second test line from me at March 2013 Windows precompiled setup
information (*.PNF) are already skipped by check for WinDirPathOffset
value 58h. These tests matches a few D64 Images like "The Great Gianna
Sisters.d64" (strength=70) initialized with ^A and handled by
Magdir/c64. These always matches MMDF (Multi-channel Memorandum
Distribution Facility) mailbox format handled by Magdir/mmdf because
each message is surrounded by lines containing 4 control-A characters.
Unfortunately i am too young to have knowledge about PDP machines and i
find no file format specification on the net. So i try to construct more
test lines by applying logic like Mister Spock would do. When looking at
other related PDP-11 samples these seems to be binary (because of
executable) and not text files. So the MMDF mailbox (magic strength=70
handled by Magdir/mmdf) with characteristic text fragments can be
excluded. At offset 15 version byte is stored for other PDP samples.
This value seems to be often zero. At offset 8 2 byte "debug"
information (implied by "not stripped" phrase) seems to be stored. So 8
Control-A character at this locations are very unlikely for real PDP
examples whereas these byte sequence can occur in few Commodore disc
image initialized with ^A at the beginning like "The Great Gianna
Sisters.d64". These disc images are handled by Magdir/c64. So with
additional tests these lines now become like:
0 leshort 0401
>68 ulelong !0x00000058
>>8 quad !0x0101010101010101
>>>5 search/610/b From\
>>>5 default x PDP-11 UNIX/RT ldp
#!:mime application/octet-stream
#!:ext foo
I do not find mime type and file name suffix for such samples. So i
would be pleased if a PDP veteran could supply this information or can
send me such a real example so i can countercheck my test lines.
The description as Targa image data (with magic strength=70=110-40)
happens inside Magdir/images. There exist no simple unique pattern for
such graphic bitmaps. Therefore the displaying part is already done by
sub routine tga-image. So before calling this sub routine some
different tests are done. Unfortunately "one" branch is at the moment
true for few Commodore disc image (strength=70=70+0 handled by
Magdir/c64 like "Cabal+2-MarioSoft(1).d64" "Kokotoni Wilf
(ANTI-ROM).d64" "The Great Gianna Sisters.d64"). These few disc images
are initialised with Control-A characters at the beginning instead of
nil bytes. It is also true for few MMDF mailbox (strength=70 like
uupc.input.1 handled by Magdir/mmdf) with some Control-A characters at
the beginning. Control-A is interpreted as value 1 for byte value. Two
such bytes are interpreted as hexadecimal 0101 (=257 decimal or 0401
octal). So the misidentified non graphic samples are described with
dimension 257x257 and origin point at coordinates (+257 +257) and color
depth 1 (that means black and white). For real TGA samples often the
dimension is a known monitor size (SVGA 1024 x 768 like in
bmpsuite-216col1st-98h.tga) or low even square size (128 x 128 for icons
like in ucm8.tga). Few TGA samples are black and white. Most samples
real coloured. That means "high"color depth (8 that means 256 colours
like in input.tga or 24 that means about 16 M colours and so on). In
most TGA samples the origin is zero point (+0 +0 which is not shown by
current displaying lines). Few samples have non zero origin. For such
examples often only one of the coordinates is like dimension size (x or
y value). So i skip few Commodore D64 disc image like "The Great Gianna
Sisters.d64" and few MMDF mailbox like uupc.input.1 with unlikely
dimension 0101h x 0101h (257x257) and +0101h origin (+257 +257) inside
black&white (color depth 1) color branch. So this branch now becomes like:
>>>>>16 ubyte 1
>>>>>>8 quad !0x0101010101010101
>>>>>>>0 use tga-image
Luckily i found a page about D64 and derivates with more links on file
formats archive team web site. That informations are now expressed by
additional comment lines inside Magdir/c64like:
# URL: http://fileformats.archiveteam.org/wiki/D64
# Reference: http://ist.uwaterloo.ca/~schepers/formats/D64.TXT
# Reference: http://ist.uwaterloo.ca/~schepers/formats/D71.TXT
# Reference: http://ist.uwaterloo.ca/~schepers/formats/D80-D82.TXT
# Reference: http://ist.uwaterloo.ca/~schepers/formats/D81.TXT
There you find download links for samples like the above inspected ones.
There i also found links to software like Deark, cbmconvert, DirMaster,
Total Commander. With the help of these tools i could create my own
samples. I also could read, convert and extract "unrecognized samples
with command lines like:
deark -m d64 -l -d2 'sim&rct.d64
cbmconvert -v2 -P -d "The Great Gianna Sisters.d64"
The description at the moment happens by lines inside Magdir/c64 like:
0x16500 belong 0x12014100 D64 Image
0x16500 belong 0x12014180 D71 Image
0x61800 belong 0x28034400 D81 Image
So what is wrong? For some variants there exist no entry. For D80 images
a similar entry would be done by line like:
0x44e00 belong 0x26004300 D80 Image
The first step is to determine the offset of the directory which also
contain some useful information like disk name and ID. Commodore drives,
as most floppy drives, have a relatively slow head movement. To speed up
data access the directory is on the central track. These is different
for the variants. So for D80 image we have before 38 tracks with 29
sectors with 256 bytes size. So directory offset here is hexadecimal
44e00 (=282112=38*29*256). By first magic test line the first 4 bytes of
directory part are checked for validity. It starts with
track value of first BAM (Block Availability Map), followed by sector of
BAM. This is followed by DOS-version byte and a "reserved" byte. The BAM
is also located near the "middle". So in most cases we get same values
here. For D80 samples often BAM Track/Sector value is 38/0 (2600
hexadecimal) but in few samples (like test-mbox.d80 i got here value
39/1 (2701 hexadecimal). The DOS format version byte for D80 is 43h "C"
and version bytes are 3243h "2C". So show unusual values for D80 by
additional lines like:
>>>&0 ubeshort !0x2600 \b, first BAM
>>>>&-2 ubyte x track %u
>>>>&-1 ubyte x sector %u
>>>&2 ubyte !0x43 \b, version %#2.2x
>>>&0x1B ubeshort !0x3243 \b, type %#4.4x
>>>>&-2 string x "%0.5s"
So the first test lines must be changed. So for D80 the test for
track/sectors must be more relaxed. So the first test line becomes like:
0x44e00 belong&0xFEfeFFff 0x26004300
For D64 the DOS format version is usually 41h "A". But in some samples
(like sim&rct.d64) i got here 42h. According to documentation here
value not 42h or 0 is misused as "copy protection". Or in other words
the disc becomes read only. So for D64 images the first test line now
becomes like:
0x16500 belong&0xFFff00ff =0x12010000 D64 Image
But then less than 32 bits are used for detection, which can lead to
more collision with other file formats. In directory part are some short
areas described as unused or filled with 0xA0 according to unofficial
documentation. These seems to be true for most cases, but in some cases
instead i often found nil bytes. So show unusual cases (non 0xA0 filled)
by additional lines like:
>>>&0x04 ubeshort !0xa0a0 \b, at +0x4 %#x
>>>&0x17 ubyte !0xA0 \b, at +0x17 %#2.2x
>>>&0x1a ubyte !0xA0 \b, at +0x1A %#2.2x
>>>&0x1D ubelong !0xA0A0A0A0h \b, at +0x1D %#8.8x
So i choose the 4-byte area (at relative offset +0x1D from directory
start and filled with 0xa0 and 0x00) as additional second test. So this
start with lines like:
>&0x19 ubelong&0x5f5F5F5F =0 Commodore
!:mime application/x-commodore-floppy-image
Instead of generic application/octet-stream i show an user defined one.
When applying current used terminology then i would call such samples
"D80 Image". But when you not grow up in area of playing games on
Commodore C64 computer like me than this description sounds like egyt
hieroglyphs for normal users. The phrase D80 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. According to documentation "D80 image"
are "Commodore 8050 floppy disc image" and "D82 image" are "Commodore
8250 floppy disc image". The first floppy variant is single sided with
file size of 533248 bytes and the second is double-sided with doubled
file size 1066496. So i show best suited description and correct
associated suffix by next lines. These look like:
>>-0 offset =533248 8050 floppy disc image
!:ext d80
>>-0 offset =1066496 8250 floppy disc image
!:ext d82
Afterwards i jump backward at the beginning with track sector byte so
that relative offset can be used as in documentation and maybe the whole
part of all commodore variants can be unified. So this is done by next
line which looks like:
>>&-0x25 belong x
Now comes the more informative part especially for normal user and many
floppy images like collections. At relative offset 6 until 16h a disk
name padded with A0h (240 octal) is stored. When i use string directive
i get not 100% correct and also ugly looking output like like 'DIRCBM
DISK\240\'. I tried also a regular expression with excluding A0h but
that does not work and i get error messages like:
c64, 167: Warning: non-ascii characters in regex \0240 `[^\240]{1,16}'
Maybe another person has more brain than me or more experience with
regex and can change my lines. So when looking in all my Commodore
images often the name is alphanumeric with spaces. But i also found
names with plus, minus, equal signs. Few samples use parentheses for
copyright phrase like (c). So at the moment the disk name (like "DIRCBM
DISK" "CBMCOMMAND" for D80) is shown by lines like:
>>>&06 regex =[A-Z0-9.+-=!()*#\ ]{1,16} "%s"
#>>&06 regex =[^\240]{1,16} \b, "%s"
#>>>&06 string x \b, DISK_NAME '%0.16s'
After applying the above mentioned modifications by four patches
file-5.45-mmdf-d64.diff file-5.45-images-tga.diff file-5.45-pdp-d64.diff
and file-5.45-c64-d64.diff then all of my inspected samples are now
recognized. Most of the misidentifications are vanished and some more
details are shown. This now looks with -k option like:
Cabal+2-MarioSoft(1).d64: Commodore 1541 floppy disc image
with errors bytes
" CABAL 100%", ID 0x4d41
, type 0x494f, at +0xA4 0x52
DolphinDosErrorBytes.d64: Commodore 1541 floppy disc image
(40 tracks) with errors bytes
"MyDolphinDOS+er", ID 0x4444
DragonNinja+4DCS+ATC+Pearl.d64: Commodore 1541 floppy disc image
"SPELLETJES", ID 0x363
, at +0xA0 0x2ca0
Kokotoni Wilf (ANTI-ROM).d64: Commodore 1541 floppy disc image
"2A", ID 0xa0a0
M1571-D71.d71: Commodore 1571 floppy disc image
"MY-DIRMASTER-MY", ID 0xa0a0
My-8250-D82.d82: Commodore 8250 floppy disc image
"MY D82 NUMBER 1!", ID 0xa0a
, at +0x1D 00000000
The Great Gianna Sisters.d64: Commodore 1541 floppy disc image
"GIANA-GAME", ID 0x4747
TheGreatGiannaSisters.d81: Commodore 1581 floppy disc image
"CBMCONVERT 2.0", ID 0x3938
, at +0x1D 0xa0a0000000000000
bmpsuite-216col1st-98h.tga: Targa image data
- Map (152-217) - RLE
1024 x 768 x 8 +768 - top
brucelee.d64: Commodore 1541 floppy disc image
(175104 bytes)
"BRUCE LEE", ID 0x2331
VAX-order 68k Blit mpx/mux executable
TTComp archive data
, ASCII, 4K dictionary
cbmcmd23.d80: Commodore 8050 floppy disc image
"CBMCOMMAND", ID 0x4944
, at +0x4 0
elektrix.d64: Commodore 1541 floppy disc image
"ELEKTRIX", ID 0x3030
, at +0xA7 0xa0000000
file-speeddos.d64: Commodore 1541 floppy disc image
(40 tracks)
"My_SpeedDOS-456", ID 0x5350
input.tga: Targa image data
- RGB
70 x 46 x 24
lastninja12.d81: Commodore 1581 floppy disc image
"* FINNISH GOLD *", ID 0x323
, at +0x18 0x31, type 0x3120
ls209.d81: Commodore 1581 floppy disc image
"LOADSTAR 209", ID 0x2020
maillog.expected.2: MMDF mailbox
sim&rct.d64: Commodore 1541 floppy disc image
"SIM&RCT.D64", ID 0x3230
, type 0x3120, version 0x42
, at +0xA4 0x31
test-mbox.d80: Commodore 8050 floppy disc image
"TOTALCOMMANDER"
, ID 0x51a0, first BAM track 39 sector 1
, type 0x43a0 "C\240"
, at +0x4 0, at +0x17 0x4a
, at +0x1A 0x32
, at +0x1D 0xa0a0a000
test-mmdf.d71: Commodore 1571 floppy disc image
with errors bytes
"DIRCBM DISK-my", ID 0x3030
test-pdp.bin: PDP-11 UNIX/RT ldp
ucm8.tga: Targa image data
- Map (256)
128 x 128 x 8
"Truevision(R) Sample Image"
- author "Ricky True"
- comment "Sample 8 bit uncompressed
color mapped image" 24-2-1990 10:00:00
- job "TGA Utilities"
- TGAEdit 1.40
uupc.input.1: MMDF mailbox
I hope my diff files 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 --------------
--- file-5.45/magic/Magdir/pdp.old 2021-02-23 01:49:24.000000000 +0100
+++ file-5.45/magic/Magdir/pdp 2024-02-11 14:40:13.200776700 +0100
@@ -2,6 +2,7 @@
#------------------------------------------------------------------------------
# $File: pdp,v 1.11 2017/03/17 21:35:28 christos Exp $
# pdp: file(1) magic for PDP-11 executable/object and APL workspace
+# URL: https://en.wikipedia.org/wiki/PDP-11
#
0 lelong 0101555 PDP-11 single precision APL workspace
0 lelong 0101554 PDP-11 double precision APL workspace
@@ -12,13 +13,22 @@
>8 leshort >0 not stripped
>15 byte >0 - version %d
-# updated by Joerg Jenderek at Mar 2013
+# updated by Joerg Jenderek at Mar 2013, Feb 2024
# GRR: line below too general as it catches also Windows precompiled setup information *.PNF
0 leshort 0401
+# PDP-11 UNIX/RT ldp (strength=50=50+0) after D64 Image (strength=70=70+0 ./c64) and MMDF mailbox (strength=70=70+0 ./mmdf)
+#!:strength +0
# skip *.PNF with WinDirPathOffset 58h
->68 ulelong !0x00000058 PDP-11 UNIX/RT ldp
+>68 ulelong !0x00000058
# skip *.PNF with high byte of InfVersionDatumCount zero
#>>15 byte !0 PDP-11 UNIX/RT ldp
+# skip few Commodore D64 disc image like "The Great Gianna Sisters.d64" initialized with ^A and handled by ./c64
+>>8 quad !0x0101010101010101
+# skip MMDF mailbox like maillog.expected.2 with MBOX characteristic near the beginning handled by ./mmdf
+>>>5 search/610/b From\
+>>>5 default x PDP-11 UNIX/RT ldp
+#!:mime application/octet-stream
+#!:ext foo
0 leshort 0405 PDP-11 old overlay
0 leshort 0410 PDP-11 pure executable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.45-pdp-d64.diff.sig
Type: application/octet-stream
Size: 1006 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240219/1edeba54/attachment-0004.obj>
-------------- next part --------------
--- file-5.45/magic/Magdir/mmdf.old 2021-02-23 01:49:24.000000000 +0100
+++ file-5.45/magic/Magdir/mmdf 2024-02-11 17:07:25.887964200 +0100
@@ -4,3 +4,22 @@
# mmdf: file(1) magic for MMDF mail files
+# Update: Joerg Jenderek Feb 2024
+# URL: https://en.wikipedia.org/wiki/MMDF
+# Reference: https://docs.oracle.com/cd/E88353_01/html/E37852/mmdf-5.html
+# Note: Multi-channel Memorandum Distribution Facility (MMDF) mailbox format is a legacy variant of mbox format
+# (handled by ./mail.news); each message is surrounded by lines containing 4 control-A
#
-0 string \001\001\001\001 MMDF mailbox
+0 string \001\001\001\001
+# GRR: MMDF mailbox (strength=70=70+0 ./mmdf) after D64 Image (strength=70=70+0 ./c64) Targa image data (strength=70=110-40 ./images)
+# and before "PDP-11 UNIX/RT ldp" (strength=50=50+0 ./pdp)
+#!:strength +0
+# skip few Commodore disc Image where first content are initialized with ^A like "The Great Gianna Sisters.d64"
+# by looking for following valid line terminator (10=0Ah~LineFeed or 13=0Dh~CarriageReturn)
+#>4 ubyte&0xF8 =0x08 MMDF mailbox
+# or by looking for MBOX Mailbox (/mail.news) characteristic like:
+# https://github.com/dfandrich/oldmailconvert/blob/master/testdata/uupc.input.1
+>5 search/610/b From\ MMDF mailbox
+#!:mime application/octet-stream
+!:mime message/x-mmdf
+# https://github.com/dfandrich/oldmailconvert/blob/master/testdata/maillog.expected.2
+# but default mailbox name is like /usr/spool/mail/username
+!:ext /mmdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.45-mmdf-d64.diff.sig
Type: application/octet-stream
Size: 1022 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240219/1edeba54/attachment-0005.obj>
-------------- next part --------------
--- file-5.45/magic/Magdir/images.old 2023-07-27 20:04:45.000000000 +0200
+++ file-5.45/magic/Magdir/images 2024-02-12 13:20:26.412701600 +0100
@@ -13,8 +13,10 @@
# Targa - matches `povray', `ppmtotga' and `xv' outputs
# by Philippe De Muyter <phdm at macqel.be>
# URL: http://justsolve.archiveteam.org/wiki/TGA
+# https://en.wikipedia.org/wiki/Truevision_TGA
# Reference: http://www.dca.fee.unicamp.br/~martino/disciplinas/ea978/tgaffs.pdf
-# Update: Joerg Jenderek
+# Update: Joerg Jenderek February 2024
+# Note: called by DROID "Truevision TGA Bitmap" version 1.0 via PUID x-fmt/367
# at 2, byte ImgType must be 1, 2, 3, 9, 10 or 11
# ,32 or 33 (both not observed)
# at 1, byte CoMapType must be 1 if ImgType is 1 or 9, 0 otherwise
@@ -27,6 +29,8 @@
# and Image Type 1 2 3 9 10 11 32 33
# and Color Map Entry Size 0 15 16 24 32
0 ubequad&0x00FeC400000000C0 0
+# Targa image data (strength=70=110-40) before some Commodore disc image (strength=70=70+0 ./c64) like Cabal+2-MarioSoft(1).d64
+# and some MMDF mailbox (strength=70=70+0 ./mmdf) like uupc.input.1
# Conflict with MPEG sequences.
!:strength -40
# Prevent conflicts with CRI ADX.
@@ -42,7 +46,10 @@
>>>>17 ubyte&0x0F !11
# skip arches.3200 , Finder.Root , Slp.1 by looking for low pixel depth 1 8 15 16 24 32
>>>>>16 ubyte 1
->>>>>>0 use tga-image
+# skip few Commodore D64 disc image like "The Great Gianna Sisters.d64" and
+# few MMDF mailbox like uupc.input.1 with unlikely black&white, dimension 0101h x 0101h (257x257) and +0101h origin (+257 +257)
+>>>>>>8 quad !0x0101010101010101
+>>>>>>>0 use tga-image
>>>>>16 ubyte 8
>>>>>>0 use tga-image
>>>>>16 ubyte 15
@@ -57,9 +64,11 @@
0 name tga-image
>2 ubyte <34 Targa image data
!:mime image/x-tga
+# Apple Uniform Type Identifier: com.truevision.tga-image
!:apple ????TPIC
# normal extension .tga but some Truevision products used others:
# tpic (Apple),icb (Image Capture Board),vda (Video Display Adapter),vst (NuVista),win (UNSURE about that)
+# afi bpx
!:ext tga/tpic/icb/vda/vst
# image type 1 2 3 9 10 11 32 33
>2 ubyte&0xF7 1 - Map
@@ -110,6 +119,7 @@
# positive length implies identification field
>0 ubyte >0
>>18 string x "%s"
+# Note: called by DROID "Truevision TGA Bitmap" version 2.0 via fmt/402
# last 18 bytes of newer tga file footer signature
>18 search/4261301/s TRUEVISION-XFILE.\0
# extension area offset if not 0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.45-images-tga.diff.sig
Type: application/octet-stream
Size: 1529 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240219/1edeba54/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trid-v-d64.txt.gz
Type: application/x-gzip
Size: 2039 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240219/1edeba54/attachment-0001.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-19 01:58:05.918390600 +0100
@@ -5,9 +5,165 @@
#
# From: Dirk Jagdmann <doj at cubic.org>
-0x16500 belong 0x12014100 D64 Image
-0x16500 belong 0x12014180 D71 Image
-0x61800 belong 0x28034400 D81 Image
+# Update: Joerg Jenderek
+# URL: http://fileformats.archiveteam.org/wiki/D64
+# Reference: http://ist.uwaterloo.ca/~schepers/formats/D64.TXT
+# http://ist.uwaterloo.ca/~schepers/formats/D71.TXT
+# Note: verified by command like `deark -m d64 -l -d2 'sim&rct.d64'` and
+# `cbmconvert -v2 -P -d "The Great Gianna Sisters.d64"`
+#0x16500 belong 0x12014100 D64 Image
+#0x16500 belong 0x12014180 D71 Image
+# check directory start at offset 38*29*256 for valid BAM-track (26h|27h), BAM-sector (0|1), a DOS-version and reserved (0|80h) byte
+0x16500 belong&0xFFff007f =0x12010000
+# D64 Image (strength=70=70+0) after Targa image data (strength=70=110-40 ./images)
+# and before MMDF mailbox (strength=70 ./mmdf)
+#!:strength +0
+# checked for area filled with some A0h/0 combinations
+>&0xA3 ubelong&0xff5F5F5F =0xa0000000 Commodore
+#!:mime application/octet-stream
+!:mime application/x-commodore-floppy-image
+# file size 174848 for 35 tracks without errors bytes (EB), 175531 for 35 tracks with EB (+683),
+# 196608 for 40 tracks without EB and 197376 for 40 tracks with EB (+768),
+# 349696 for 70 tracks without EB and 351062 for 70 tracks with EB (+1366)
+# called "D64 Image" by ./c64 v 1.14
+>>-0 offset =174848 1541 floppy disc image
+!:ext d64
+>>-0 offset =175531 1541 floppy disc image with errors bytes
+!:ext d64
+>>-0 offset =196608 1541 floppy disc image (40 tracks)
+!:ext d64
+>>-0 offset =197376 1541 floppy disc image (40 tracks) with errors bytes
+!:ext d64
+# called "D71 Image" by ./c64 v 1.14
+>>-0 offset =349696 1571 floppy disc image
+!:ext d71
+>>-0 offset =351062 1571 floppy disc image with errors bytes
+!:ext d71
+# GRR: unexpected disc size!
+>>-0 default x
+>>>-0 offset <197377 1541 floppy disc image (%lld bytes)
+# https://sembiance.com/fileFormatSamples/archive/commodoreDiskImage/brucelee.d64
+!:ext d64
+>>>-0 offset >197376 1571 floppy disc image (%lld bytes)
+!:ext d71
+# jump backward at the beginning with track sector byte so that relative offset can be used as in documentation
+>>&-0xAF belong x
+#>>>&0 belong x MAGIC=%8.8x
+# 04-8F: BAM entries for each track, in groups of four bytes per track, starting on track 1 (see below for more details)
+#>>>&4 ubequad x BAM=%16.16llx
+# 90-9F: Disk Name, padded with A0h like: "SIM&RCT.D64" " CABAL 100%" "RE-CRACKS!!! [M]"
+>>>&0x90 regex =[\]A-Za-z0-9.+;=_%!()&\[\ -]{1,16} "%s"
+# GRR: regex NOT WORKING! message like:
+# c64, 55: Warning: non-ascii characters in regex \0240 `[^\240]{1,16}'
+#>>>&0x90 regex =[^\240]{1,16} \b, "%s"
+#>>>&0x90 string x \b, DISK_NAME '%.20s'
+# A2-A3: disk ID
+>>>&0xA2 ubeshort x \b, ID %#4.4x
+# A5-A6: DOS type like 3241h~"2A" (usually) 3032h (PF_Disk0_and_2.d64) 3120h (sim&rct.d64) 332dh (PF_Boot.d64) ... a0a0h (V.d64)
+>>>&0xA5 ubeshort !0x3241 \b, type %#4.4x
+#>>>>&-2 string x "%0.6s"
+# 02: DOS version type like 41h~"A" 42h (sim&rct.d64); not 41h or 00h, then "soft write protection"
+>>>&2 ubyte !0x41 \b, version %#x
+# 03: Double-sided flag; 0~D62 80h~D71~double side (but wrong DragonNinja+4DCS+ATC+Pearl.d64)
+>>>&3 ubyte !0
+>>>>&-1 ubyte !0x80 \b, side flag %#x
+# For control and get more magic reasons check for "filled" or "unused areas
+# A0-A1: filled with A0A0h (usually) 0DA0h (GBSC1A.D64 GBSC1B.D64)
+>>>&0xA0 ubeshort !0xa0a0 \b, at +0xA0 %#4.4x
+# A4: A0h (usually) 20h (Anti-Rom Intro 2 (ANTI-ROM).D64) 30h (FRANK BRUNO'S BOXING 6DGH.D64) 32h (PF_Boot.d64) 44h (V.d64) ... 5Ah (GBSC1B.D64)
+>>>&0xA4 ubyte !0xA0 \b, at +0xA4 %#2.2x
+# A7-AA: A0A0A0A0h (usually) A0000000h (Stormlord.d64 elektrix.d64)
+>>>&0xA7 ubelong !0xa0a0a0a0 \b, at +0xA7 %#8.8x
+# AB-FF: Normally unused (00h), except for 40 track extended format
+# AC-BF: DOLPHIN DOS track 36-40 BAM entries C0-D3: SPEED DOS track 36-40 BAM entries
+#>>>&0xAB ubequad !0 \b, nil=%16.16llx
+# Summary: Commodore 8050 (single-sided) 8250 (double-sided) floppy disc image
+# From: Joerg Jenderek
+# Reference: http://ist.uwaterloo.ca/~schepers/formats/D80-D82.TXT
+# check directory start at offset 17*29*256 for valid BAM-track (26h), BAM-sector (0), a DOS-version and side flag (0|80h) byte
+0x44e00 belong&0xFEfeFFff =0x26004300
+# D80/D82 Image (strength=70=70+0) like cbmcmd23.d80
+#!:strength +0
+# checked for area filled some A0h/0 combinations
+>&0x19 ubelong&0x5f5F5F5F =0 Commodore
+#!:mime application/octet-stream
+!:mime application/x-commodore-floppy-image
+# file size for 8050 image is 533248 bytes and for 8250 image is 1066496 bytes
+>>-0 offset =533248 8050 floppy disc image
+!:ext d80
+>>-0 offset =1066496 8250 floppy disc image
+!:ext d82
+#>>-0 offset x (%llu bytes)
+# jump backward at the beginning with track sector byte so that relative offset can be used as in documentation
+>>&-0x25 belong x
+#>>>&0 belong x MAGIC=%8.8x
+# 06-16: disk name, padded with A0h like: "DIRCBM DISK" "CBMCOMMAND"
+>>>&06 regex =[A-Z0-9.+-=!()*#\ ]{1,16} "%s"
+# GRR: regex NOT WORKING! message like:
+# c64, 167: Warning: non-ascii characters in regex \0240 `[^\240]{1,16}'
+#>>&06 regex =[^\240]{1,16} "%s"
+#>>>&06 string x \b, DISK_NAME '%0.16s'
+# 18-19: disk id bytes like: a0a0h 30a0h 4944h
+>>>&0x18 ubeshort x \b, ID %#4.4x
+# Block Availability Map (BAM) is typically contained on track 26h=38/sector 0 but 27h/1 in DESCRIPT.D80
+>>>&0 ubeshort !0x2600 \b, first BAM
+>>>>&-2 ubyte x track %u
+>>>>&-1 ubyte x sector %u
+# 02: DOS format version like 43h~"C" other~write protect
+>>>&2 ubyte !0x43 \b, version %#2.2x
+# 1B-1C: DOS version bytes like: 3243h~"2C" 43a0h~"C\240" 324ah~"2J"
+>>>&0x1B ubeshort !0x3243 \b, type %#4.4x
+>>>>&-2 string x "%0.5s"
+# 04-05: unused like: a0a0h 0 (cbmcmd23.d80)
+>>>&0x04 ubeshort !0xa0a0 \b, at +0x4 %#x
+# 17: A0h (usually) 30h
+>>>&0x17 ubyte !0xA0 \b, at +0x17 %#2.2x
+# 1A: A0h (usually) 32h
+>>>&0x1a ubyte !0xA0 \b, at +0x1A %#2.2x
+# 1D-20: A0A0A0A0h (usually) A0A0A000h A0000000h 00000000
+>>>&0x1d ubelong !0xA0A0A0A0h \b, at +0x1D %#8.8x
+# 21-FF: Unused
+>>>&0x21 ubequad !0 \b, at +0x21 %16.16llx
+# Update: Joerg Jenderek
+# URL: http://fileformats.archiveteam.org/wiki/Commodore_1581_disk
+# Reference: http://ist.uwaterloo.ca/~schepers/formats/D81.TXT
+# Note: called "D81 Image" by ./c64 v 1.14
+#0x61800 belong 0x28034400 D81 Image
+# check directory start at offset 39*40*256 for valid DIR-track (28h), DIR-sector (3), a DOS-version and reserved (0) byte
+0x61800 belong&0xFFff00ff =0x28030000
+# D81 Image (strength=70=70+0) like "Sonic_the_Hedgehog_+4 [Excess].d81" before
+# a.out SunOS mc68010 pure executable (strength=70=70+0 ./sun)
+#!:strength +0
+# checked for area filled with some A0h/0 combinations
+>&0x17 ubelong&0xffFF5F5F =0xa0a00000 Commodore 1581 floppy disc image
+#!:mime application/octet-stream
+!:mime application/x-commodore-floppy-image
+!:ext d81
+# jump backward at the beginning with track sector byte so that relative offset can be used as in documentation
+>>&-0x23 belong x
+#>>>&0 belong x MAGIC=%8.8x
+# 04-13: 16 PET-ASCII character disk name (padded with A0h) like:
+# "LOADSTAR #125 S0" "DIRCBM DISK" " (C) 1992 FLAIR " "YETI MOUNTAIN +6" "CBMCONVERT 2.0" "DIRCBM DISK" "* FINNISH GOLD *"
+>>>&4 regex =[A-Z0-9.+-=()*#\ ]{1,16} "%s"
+# GRR: regex NOT WORKING! message like:
+# c64, 163: Warning: non-ascii characters in regex \0240 `[^\240]{1,16}'
+#>>>&04 regex =[^\240]{1,16} "%s"
+#>>>&04 string x \b, DISK_NAME '%0.16s'
+# 16-17: Disk ID
+>>>&0x16 ubeshort x \b, ID %#4.4x
+# 02: DOS format version like 44h~"D" other~write protect
+>>>&2 ubyte !0x44 \b, version %#2.2x
+# 14-15: filled with A0A0h
+>>>&0x14 ubeshort !0xa0a0 \b, at +0x14 %#4.4x
+# 18: A0h (usually) 31h (lastninja12.d81) 20h (Sonic_the_Hedgehog_+4 [Excess].d81) 2eh (Monkey_Island_DE.d81) ... 59h (4x4_Off-Road_Racing_1988_Epyx.d81)
+>>>&0x18 ubyte !0xA0 \b, at +0x18 %#2.2x
+# 19-1A: DOS/DISK version 3344h~"3D" (usually) 3120h (lastninja12.d81) 3231h (Attitude21-Triad+GP.d81) ... 58a0h (4x4_Off-Road_Racing_1988_Epyx.d81)
+>>>&0x19 ubeshort !0x3344 \b, type %#4.4x
+#>>>>&-2 string x "%0.6s"
+# 1B-1C: A0A0h
+>>>&0x1B ubeshort !0xa0a0 \b, at +0x1B %#4.4x
+# 1D-FF: Unused (usually 0) a0a0000000000000h ("CBMCONVERT 2.0")
+>>>&0x1D ubequad !0 \b, at +0x1D %#16.16llx
0 belong 0x43154164 X64 Image
# C64 (and other CBM) cartridges
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.45-c64-d64.diff.sig
Type: application/octet-stream
Size: 3399 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240219/1edeba54/attachment-0007.obj>
More information about the File
mailing list