[File] [PATCH] Magdir/filesystems for IBM SaveDskF floppy image *.DSK
Jörg Jenderek
joerg.jen.der.ek at gmx.net
Sat May 14 21:00:42 UTC 2022
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
some days ago handled files that start with value 0xAA. So i looked
for other starting with this value. So i looked at some floppy disk
images with DSK file name extension.
When running file command version 5.41 on hundreds such examples i
get an output like:
06200B13.DSK: floppy image data (IBM SaveDskF, old)
06200D19.DSK: floppy image data (IBM SaveDskF, old)
06200D9.DSK: floppy image data (IBM SaveDskF, old)
2-NK.DSK: floppy image data (IBM SaveDskF)
2M256R-K.DSK: floppy image data (IBM SaveDskF, compressed)
DISK1-2.DSK: floppy image data (IBM SaveDskF, compressed)
DISPLAY3.DSK: floppy image data (IBM SaveDskF)
H1-NK.DSK: floppy image data (IBM SaveDskF)
With option -i only generic application/octet-stream is shown. With
option --extension only 3 byte sequence ??? is shown.
For comparison reason i run the file format identification utility
TrID ( See https://mark0.net/soft-trid-e.html). Some examples ( like
06200D19.DSK 06200D9.DSK 2M256R-K.DS H1-NK.DSK) are not recognized
and are described as Unknown!. The recognised examples are described
as "IBM SKF disk image". The examples described by file command with
an additional "old" are described by TrID with additional "(old)"
phrase by dsk-skf-old.trid.xml. The examples described by file
command with an additional "compressed" are described by TrID with
additional "(comp)" phrase by dsk-skf-comp.trid.xml. The third varian
t
examples described by file command without an additional "compressed"
or "old" are described by TrID with additional "(uncomp)" phrase by
dsk-skf.trid.xml (See appended trid-v-dsk.txt.gz).
Luckily TrID tool with option -v shows used file name extension and a
reference URL. There also links for samples and suitable software are
listed.
The detection happens inside Magdir/filesystems by lines like:
0 beshort 0xAA58 floppy image data (IBM SaveDskF, old)
0 beshort 0xAA59 floppy image data (IBM SaveDskF)
0 beshort 0xAA5A floppy image data (IBM SaveDskF, compressed)
This now starts like
# URL: http://fileformats.archiveteam.org/wiki/LoadDskF/SaveDskF
# Reference: http://mark0.net/download/triddefs_xml.7z/
# defs/d/dsk-skf-old.trid.xml
0 beshort 0xAA58
>0 use SaveDskF
# defs/d/dsk-skf.trid.xml
0 beshort 0xAA59
>0 use SaveDskF
# defs/d/dsk-skf-comp.trid.xml
0 beshort 0xAA5A
>0 use SaveDskF
0 name SaveDskF
>0 beshort x floppy image data (IBM SaveDskF
!:mime application/x-ibm-dsk
!:ext dsk
>1 ubyte =0x58 \b, old)
>1 ubyte =0x59 \b)
>1 ubyte =0x5A \b, compressed)
I put displaying part now inside sub routine SaveDskF. Otherwise i
must add for all 3 variants part for information giving lines like fo
r
file name extension and so on. So i avoid redundance. Furthermore is
is possible to add more test lines (like check for number of heads)
when used 2 byte magic reveals as too weak. Instead of generic mime
type application/octet-stream i choose an user defined one. I myself
found only example with DSK suffix, but according to documentation
there should exist samples with digit inside suffix like 1dk, 2dk and
so on.
To check for difference between file command and TrID output i
checked more fields in the header. For debugging and didactic purpose
you may add some lines like:
>38 uleshort !0 \b, 1st sector at %#x
>>1 ubyte !0x5A
>>>(38.s) indirect x \b; contains
>38 uleshort =0 \b, 1st sector at 0x200
>>0x200 indirect x \b; contains
The last field of header at offset 38 contains the offset to first
sector, which of course is the DOS/MBR boot sector which can it self
inspected again by Magdir/filesystems via indirect call. This of
course only works if no compression is used. If this offset is 0,
then this means real offset value is 0x200, but i do not find such
examples. Interesting is that many samples although described with
OEM-ID "IBM 20.0" are described with "dos < 4.0 BootSector (0)". This
means that the extended boot signature value is not 0x29 as found on
"new" boot sectors and also not 0x28 as expected for "older" OS/2
disk. That is not described in the page about the design of the FAT
file system on Wikipedia. What a surprise!
On mentioned site download links for examples and tools are
listed. I verified information partly by 7z package tool (See
appended 7z-l-dsk.txt) and decoding tool deark (See appended
deark-l-dsk.txt) by command lines like:
7z l -tFAT *.DSK
deark -l -m loaddskf 06200D19.DSK
With the help of this outputs i start to interpret the fields in the
SaveDskF header. So i should get here the same values as for the
inspected boot sector and to not confuse the user the same phases
should be used. But there is one exception. If full capacity of disc
is not used, the SaveDskF utility does not store unused sectors. It
stores only used sectors and reports this "lower" counted number
inside it header part. This i done by additional line like:
>34 uleshort x \b, sectors %u
So for standard 1440 KB samples i get "sectors 2880 (volumes <=32
MB)" by information of DOS boot sector. For example DISPLAY3.DSK
i get according to header also this ", sectors 2880," but for smaller
06200B13.DSK is get here ", sectors 1017,".
After the magic bytes the media type is stored as 2 byte integer.
That is the first byte of the FAT. This value is also stored as byte
value inside boot sector. That means the upper byte of media type is
never used. So this seems to be nil in all examples. So now show this
information by lines like:
>2 ubyte !0xF0 \b, Media descriptor %#x
>3 ubyte !0 \b, upper byte of media type %#x
For most floppy examples this value is 0xF0, but i also found
examples with value 0xF9 and 0xFE. The current TrID definition assume
that this value is always 0xF0. So samples with unusual Media
descriptors like H1-NK.DSK and 06200D19.DSK are not recognized by
TrID. If upper byte is always nil then this could also be used as
additional test which maybe look like:
0 beshort 0xAA5A
>3 ubyte =0
>>0 use SaveDskF
The typical sector size is 512. That value is shown by line like:
>4 uleshort !512 \b, Bytes/sector %u
There exist discs with other sector sizes, but when i use the
mentioned SAVEDSKF.EXE tool to create DSK images i got garbage.
For most floppy examples the number of heads is 2. But i create an
image H1-NK.DSK with just one head. So show this information for
unusual case as in the BIOS parameter block by line like:
>26 uleshort !2 \b, heads %u
As far as i know for floppies or at least standard IBM PC floppies
here only value 1 or 2 can occur. So this information maybe can be
used as additional test, which may look like:
>>26 uleshort <3
>>>0 use SaveDskF
For all inspected floppy examples at offset 30 4 bytes are stored
with nils. These are described as unused. So show here unexpected
values by line like:
>30 ulelong !0 \b, at 0x1E %#x
If this value is always zero then this could also be used as
additional test which maybe look like:
>>>30 long =0
>>>>0 use SaveDskF
For most inspected floppy examples the number of heads is 2. But i
create an image H1-NK.DSK with just one head. So show this
information for unusual cases as in the BIOS parameter block by line
like:
>26 uleshort !2 \b, heads %u
After the header, an ASCII comment may follow, which seems to be
terminated by \r\n\0. In all my inspected comment examples the
comment directly starts after header. That means at offset 40 (or
hexadecimal 28). In theory the comment could appear later. So the
offset of the comment string itself is stored at position 36 as 2
byte value. When following mister Spock logic you would expect that
for non comment examples this value is something like zero or
negative. Unfortunately here the value is also 40. So to check for
the existence of a comment you must check if the first sector (
That is the DOS boot sector) if far away from the beginning. If
this not the case (like offset 0x29=41) then there is no space for
comment.
Unfortunately there exist samples like 06200B13.DSK, 06200D19.DSK and
06200D9.DSK (Seems to concerning "old" variant") where first sector
is far away (1st sector at 0x200) but the possible comment part is
just filled with nil bytes. So i must check if possible comment part
contains printable ASCII or not nil bytes. So now show existing
comment field by lines like:
>(36.s) ubyte !0x00
>>38 uleshort >41
>>>36 uleshort x \b, at %#x
>>>(36.s) string x "%s"
After applying the above mentioned modifications by patch
file-5.41-filesystems-dsk.diff then all my inspected DSK examples are
still described but with more details. This now looks like:
06200B13.DSK: floppy image data (IBM SaveDskF, old)
, 2848 clusters
, checksum 0xbfa322f2
, sectors 1017
, 1st sector at 0x200
06200D19.DSK: floppy image data (IBM SaveDskF, old)
, Media descriptor 0xf9
, 1st cluster at sector 29, 2372 clusters
, sectors/FAT 7
, root directory at sector 15
, checksum 0xe49f9d51
, sectors/track 15
, sectors 1050
, 1st sector at 0x200
06200D9.DSK: floppy image data (IBM SaveDskF, old)
, Media descriptor 0xf9
, 1st cluster at sector 29, 2372 clusters
, sectors/FAT 7
, root directory at sector 15
, checksum 0x70b1daea
, sectors/track 15
, sectors 2398
, 1st sector at 0x200
2-NK.DSK: floppy image data (IBM SaveDskF)
, Media descriptor 0xf9
, sectors/cluster 258, cluster shift 1
, FAT 1, root entries 4096
, 1st cluster at sector 10, 2876 clusters
, root directory at sector 10
, checksum 0x0013ebdd
, sectors/track 36
, sectors 12
, at 0x28 "2880 kb floppy /n /k switch"
, 1st sector at 0x46
2M256R-K.DSK: floppy image data (IBM SaveDskF, compressed)
, sectors/cluster 258, cluster shift 1
, reserved sectors 256
, 1st cluster at sector 288, 2737 clusters
, root directory at sector 274
, checksum 0x002614ff
, sectors/track 36, sectors 290
, at 0x28 "2880 Kb 256 reeserved sectors"
, 1st sector at 0x48
DISK1-2.DSK: floppy image data (IBM SaveDskF, compressed)
, 2848 clusters
, checksum 0x258afca9
, sectors 287
, 1st sector at 0x29
DISPLAY3.DSK: floppy image data (IBM SaveDskF)
, 2848 clusters
, checksum 0x18b39069
, sectors 2880
, 1st sector at 0x29
H1-NK.DSK: floppy image data (IBM SaveDskF)
, Media descriptor 0xfe
, root entries 64
, 1st cluster at sector 7, 314 clusters
, sectors/FAT 1
, root directory at sector 3
, checksum 0x65eac9ab
, 40 cylinders, heads 1
, sectors/track 8
, sectors 304
, at 0x28 "head 1"
, 1st sector at 0x31
I hope my diff file can be applied in future version of file
utility. So i know that output of file command was and is here
correct and TrID is wrong in some cases.
The SAVEDSKF.EXE can create "normal" FAT floppy images (if i remember
right by /D switch). These are described by file command with
starting phrase like "DOS/MBR boot sector". Normally such images have
file name extension like IMG or IMA. The images created by SAVEDSKF
still use here also the DSK suffix.
With best wishes,
Jörg Jenderek
- --
Jörg Jenderek
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYoAYegAKCRCv8rHJQhrU
1u3mAKCy6ytM7dEvVHsk0+Y5rTseSoiFIgCgvgkrzhUDGUw/UGLD51QsftA9dGw=
=CqW/
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trid-v-dsk.txt.gz
Type: application/x-gzip
Size: 441 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220514/8de26552/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: deark-l-dsk.txt.gz
Type: application/x-gzip
Size: 1626 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220514/8de26552/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7z-l-dsk.txt.gz
Type: application/x-gzip
Size: 3787 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220514/8de26552/attachment-0005.bin>
-------------- next part --------------
--- file-5.41/magic/Magdir/filesystems.old 2021-09-20 16:07:28.000000000 +0200
+++ file-5.41/magic/Magdir/filesystems 2022-05-14 22:20:11.484527600 +0200
@@ -2400,7 +2400,102 @@
0 string ACT\020Apricot\020disk\020image\032\004 floppy image data (ApriDisk)
-0 beshort 0xAA58 floppy image data (IBM SaveDskF, old)
-0 beshort 0xAA59 floppy image data (IBM SaveDskF)
-0 beshort 0xAA5A floppy image data (IBM SaveDskF, compressed)
+# URL: http://fileformats.archiveteam.org/wiki/LoadDskF/SaveDskF
+# Update: Joerg Jenderek
+# Note: called "IBM SKF disk image" by TrID
+# verfied by 7-Zip `7z l -tFAT -slt *.dsk` and
+# `deark -l -m loaddskf 06200D19.DSK`
+# Reference: http://mark0.net/download/triddefs_xml.7z/defs/d/dsk-skf-old.trid.xml
+0 beshort 0xAA58
+>0 use SaveDskF
+# Reference: http://mark0.net/download/triddefs_xml.7z/defs/d/dsk-skf.trid.xml
+0 beshort 0xAA59
+>0 use SaveDskF
+# Reference: http://mark0.net/download/triddefs_xml.7z/defs/d/dsk-skf-comp.trid.xml
+0 beshort 0xAA5A
+# skip foo by additional check for unused upper byte of media type in SaveDskF header
+#>3 ubyte =0
+# skip bar by additional check for valid "low" number of heads in SaveDskF header
+#>>26 uleshort <3
+# skip foo by additional check for unused double word field in SaveDskF header
+#>>>30 long =0
+#>>>>0 use SaveDskF
+>0 use SaveDskF
+# display information about IBM SaveDskF floppy disk images
+0 name SaveDskF
+# SaveDskF magic
+>0 beshort x floppy image data (IBM SaveDskF
+#!:mime application/octet-stream
+!:mime application/x-ibm-dsk
+!:ext dsk
+# also suffix with digit (1dk .2dk ...); NO example FOUND!
+#!:ext dsk/1dk/2dk
+>1 ubyte =0x58 \b, old)
+>1 ubyte =0x59 \b)
+>1 ubyte =0x5A \b, compressed)
+# media type; the first byte of the FAT like: 0xF0 (usual floppy) 0xF9 0xFE
+# https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system
+>2 ubyte !0xF0 \b, Media descriptor %#x
+# upper byte of media type is not used; so this seems to be nil
+>3 ubyte !0 \b, upper byte of media type %#x
+# sector size in bytes as in the BIOS parameter block like: 512 ; SAVEDSKF.EXE with other sizes produce garbage images
+>4 uleshort !512 \b, Bytes/sector %u
+# cluster mask; number of sectors per cluster, minus 1
+>6 uleshort+1 >1 \b, sectors/cluster %u
+#>6 uleshort+1 x \b, sectors/cluster %u
+# cluster shift; log2(cluster size / sector size) like: 0~1=ClusterSize/SectorSize
+>7 ubyte >0 \b, cluster shift %u
+#>7 ubyte x \b, cluster shift %u
+# reserved sectors; as in the BIOS parameter block like: 1 256 (2M256R-K.DSK)
+>8 uleshort >1 \b, reserved sectors %u
+#>8 uleshort x \b, reserved sectors %u
+# FAT copies; as in the BIOS parameter block like: 2 (usual) 1 (2-NK.DSK)
+>10 ubyte !2 \b, FAT
+# plural s
+>>10 ubyte >1 \bs
+>>10 ubyte x %u
+# root directory entries; as in the BIOS parameter block like: 224 (usual) 64 (H1-NK.DSK) 4096 (2-NK.DSK)
+>11 uleshort !224 \b, root entries %u
+# sector number of first cluster (count sectors used by boot sector, FATs and root directory) like: 7 10 29 33 288
+>13 uleshort !33 \b, 1st cluster at sector %u
+# number of clusters in image; empty clusters at the end are not saved and counted like: 2372 2848
+>15 uleshort x \b, %u clusters
+# sectors/FAT; as in the BIOS parameter block like: 1 (H1-NK.DSK) 7 9
+>17 ubyte !9 \b, sectors/FAT %u
+# sector number of root directory (ie, count of sectors used by boot sector and FATs) like: 3 (H1-NK.DSK) 9 10 15 19 274 (2M256R-K.DSK)
+>18 uleshort !19 \b, root directory at sector %u
+# checksum; sum of all bytes in the file
+>20 ulelong x \b, checksum %#8.8x
+# cylinders; number of cylinders like: 40 80
+>24 uleshort !80 \b, %u cylinders
+#>24 uleshort x \b, %u cylinders
+# heads; number of heads as in the BIOS parameter block like: 1 (H1-NK.DSK) 2
+>26 uleshort !2 \b, heads %u
+#>26 uleshort x \b, heads %u
+# sectors/track; number of sectors per track as in the BIOS parameter block like: 8 15 18 36
+>28 uleshort !18 \b, sectors/track %u
+#>28 uleshort x \b, sectors/track %u
+# unused double word field seems to be always like: 0
+>30 ulelong !0 \b, at 0x1E %#x
+# number of sectors in images like: 1017 2786 2880
+>34 uleshort x \b, sectors %u
+# if string is "printable" it can be a real comment
+>(36.s) ubyte !0x00
+# if 1st sector is far enough away (> 0x29) then there is space for comment part
+>>38 uleshort >41
+# offset to comment string like: 28h=40
+>>>36 uleshort x \b, at %#x
+# comment string terminated with \r\n\0
+>>>(36.s) string x "%s"
+# offset to the first sector like: 0 (If this is 0, assume it is 0x200) 29h=41 (DISPLAY3.DSK) 31h 43h 45h 46h 48h 50h 200h=512
+>38 uleshort !0 \b, 1st sector at %#x
+# FOR DEBUGGING!
+#>(38.s) ubelong x SECTOR CONTENT %x
+# not compressed floppy image implies readable DOS boot sector inside image
+>>1 ubyte !0x5A
+# when not compressed it is readable as DOS boot sector via ./filesystems
+#>>>(38.s) indirect x \b; contains
+>38 uleshort =0 \b, 1st sector at 0x200 (0)
+# maybe standard DOS boot sector; NO example FOUND HERE!
+#>>0x200 indirect x \b; contains
0 string \074CPM_Disk\076 disk image data (YAZE)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.41-filesystems-dsk.diff.sig
Type: application/octet-stream
Size: 2200 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220514/8de26552/attachment-0001.obj>
More information about the File
mailing list