Hello trid users,
some days ago i handled some Intel serial flash ROM for I/O Controller Hub
(ICH) by rom-intel-ICH.trid.xml.
When when i run TrID on such examples these are misidentified as "TransCopy
disk image" by tc-transcopy.trid.xml. When i run TrID on such disk images
these are described correctly. (see appended output/trid-v-old.txt).
For comparison reason i also run the file utility (newest version
>5.41). This identifies the ROM examples as "Intel serial flash" and "for
ICH/PCH ROM <= 5 or 3400 series A-step" by starting 4 byte pattern
5AA5F00F. And the disk examples are now described as "TransCopy disk image"
and are not misidentified (see appended output/file-new.txt). According to
documentation i also run a patched file command that displays more
information (see appended output/file.tmp).
Trid identifies disc examples as "TransCopy disk image" by definition
tc-transcopy.trid.xml via 2 byte start pattern 5AA5. That was expressed by
XML construct like: <Bytes>5AA5</Bytes> <ASCII> Z</ASCII> <Pos>0</Pos>
2 Bytes are not so unique enough. So by that definition all mentioned ROM
examples are also identified as TransCopy disk image. Luckily it also
displays an URL on Wikipedia about Central Point Software (CPS) and its ISA
floppy controller card "Option Board". This information was expressed by
reference URL line like:
<RefURL>
https://en.wikipedia.org/wiki/Central_Point_Software</RefURL>
With this information i found documents (image_format.txt and
TranscopyFormat.txt) about the TransCopy image format on web site
www.robcraig.com.
So i generate trid definition by running tridscan. In global strings
section i get lines like:
<String>UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
<String>%I%I%I%I%I%I%I%I%I%I%I%I%I%I%I%I%I%I%I%I
<String>UI*I*I*I*I*I*I*I*I*I*I*I*I*I*I*I*I*I*I*I*I*I*</String>
<String>UUUUUUUUUUUUUUUUUUUUUUUR$J$J$J</String> <String>%UUUUUU</String>
<String>)UUUUUU</String> <String>UUI*</String> <String>UUJJ</String> This
pattern are found in track data. So i assume that these pattern are
triggered by empty data blocks padded with some fill bytes. No
characteristic ASCII text is found. So i delete the whole global string
section.
After 2 byte signature 2 description lines are stored, which are optional
zero-terminated and have a maximal length of 32 characters.
In first description i found ASCII text like "Project Workbench 2.20", "Visi
On Calc" or "Wizardry V Disk 1 of 3". In second description in found text
like "(1988).", "Advanced - Utility" or 'Program Disk 2". Unfortunately that
information can not be used to skip Intel serial flash ROM with unlikely
description starting with hexadecimal F0F0. So i mention information about
description fields in remark line.
If the maximal length (32) of first description field is not used then some
padding pattern with nil occur in definition. Thar was expressed by XML
construct like:
<Bytes>0000</Bytes>
<Pos>32</Pos>
When first description is filled with maximal (32) character text, this
pattern vanish.
Third XML construct looks like:
<Bytes>0000200720072007200720072007200720072007200720072007200720072
<Pos>64</Pos>
Again first appear padding with nil bytes from second description
text. According to documentation from offset 66 ( hexadecimal 42) come 190
unknown bytes til offset 256, which Look like ASCII formatted with attribute
bytes (MESSAGES). So it is unclear if this ASCII part always appear is
always the same. So i delete that construct.
At offset 256 ( hexadecimal 100) the disk type is stored as byte value. In
many examples this value was 0xff. That means unknown. in one example
WIZ2_720.IMG the value was 7. That means MFM Double Density.
At offset 257 (hexadecimal 0x101) the starting cylinder number is stored as
byte value. In my inspected examples this value was 0 as typical
expected. That information was expressed by XML construct like:
<Bytes>00</Bytes>
<Pos>257</Pos>
That information is shown by patched file command by phrase like: "cylinder
start=0". but theoretically you can save only part of disc, then this value
would be non zero. So the above construct then disappears.
At offset 258 (hexadecimal 0x102) the ending cylinder number is stored as
byte value. In my inspected examples this value often was 40, but i also
found value 41 and 79.
Next construct looks like:
<Bytes>0201</Bytes>
<Pos>259</Pos>
At offset 259 (hexadecimal 0x103) the number of sides is stored as byte
value. In my examples i only found value 2.
At offset 260 (hexadecimal 0x104) the Track Increment is stored as byte
value. In my examples i only found value 1. Assuming that also other Track
Increment are possible this construct now becomes like:
<Bytes>02</Bytes>
<Pos>259</Pos>
So i name this replacement variant tc-transcopy-2side.trid.xml and the
description text is expressed by line like:
<FileType>TransCopy disk image (2 sides)</FileType>
Because we consider floppy disc images i only expect also value 1 here. So i
create a second variant tc-transcopy-1side.trid.xml for one side disc images
by just replacing the above XML construct by:
<Bytes>01</Bytes>
<Pos>259</Pos>
By that constructs which test for value 2 or 1 the Intel serial flash ROM
are skipped because there the invalid disk side value zero occur.
At offset 261 (hexadecimal 105) Track-Pos Table with 512 bytes til offset
773 (hexadecimal 305). So i assume that patterns especially short nil are
just triggered by lucky circumstances like
<Bytes>00</Bytes>
<Pos>264</Pos>
So i delete such pattern.
At offset 773 (hexadecimal 305) Track-offs Table with 512 bytes til offset
1285 (hexadecimal 505). So i assume that patterns nil are just triggered by
lucky circumstances like:
<Bytes>010001</Bytes>
<Pos>779</Pos>
So i delete such pattern.
At offset 1285 (hexadecimal 505) the Track-length Table with 512 bytes til
offset 1797 (hexadecimal 705). So i assume that patterns nil are just
triggered by lucky circumstances like:
<Bytes>30</Bytes>
<ASCII> 0</ASCII>
<Pos>1338</Pos>
So i delete such pattern.
At offset 1797 (hexadecimal 705) the Track-type table with 512 bytes til
offset 2309 (hexadecimal 905) is stored. So i assume that patterns are just
triggered by lucky circumstances like:
<Bytes>07</Bytes>
<Pos>1798</Pos>
So i delete such pattern.
Instead of generic mime type application/octet-stream i use the user defined
one, that is used by file command ( See output/file-i-new.txt). So that is
now expressed by line like:
<Mime>application/x-floppy-image-tc</Mime>
The current definition only mention one file name extension. That was
expressed by line like:
<Ext>TC</Ext>
The original file name extension was 3 byte "IMG", but that extension is
often used by others. So also 2 byte extension "TC" is found, but maybe
never used official by CPS. So this is now expressed by line like:
<Ext>TC/IMG</Ext>
With my 2 trid definitions all of my inspected TransCopy disk image are now
described correctly and satisfactions of Intel serial flash ROM disappear
(see appended output/trid-v-new.txt). TrID definition and output are stored
in archive tc_img.zip. I hope that the 2 XML file can be used in future
version of triddefs.
With best wishes
Jörg Jenderek
