Hello trid users,
some days ago i handled COFF objects. For Itanium CPUs this looks like DEGAS
hi-res bitmaps described by bitmap-pi3-degas.trid.xml. Inside the definition
a web site about DEGAS image is mentioned. That is expressed by line like:
<RefURL>
http://fileformats.archiveteam.org/wiki/DEGAS_image </RefURL>
On that web site samples and format specification are found. DEGAS low-res
compressed bitmaps with PC1 file name extension are described by
bitmap-pc1-degas.trid.xml. This contains only one recognition pattern. That
is expressed by XML construct like:
<Bytes>8000</Bytes>
<Pos>0</Pos>
Unfortunately exact the same is found inside img-lif.trid.xml. That
definition describes "HP Logical Interchange Format disk image".
So all such DEGAS bitmaps and HP floppy disk images are described as the
same with 50% recognition rate (see appended output/trid-v.txt).
So i replaced img-lif.trid.xml with a new one. The used reference contains
no relevant information any more (Dead URL). So i replaced it with a new one
about the HPDir Project. This is expressed by line:
<RefURL>
https://www.hp9845.net/9845/projects/hpdir/</RefURL>
There some basic unofficial information about the structure of the LIF file
system is described. Also a document about LIF implementation with name
LIF_excerpt_64941-90906_flpRef_Jan84.pdf is mentioned.
Unfortunately i myself found only 1 HP floppy image at the beginning. So i
can not create trid definition by help of tridscan. So i create definition
file manual according to documentation. Later i found more examples on FTP
server of HP museum with starting URL:
ftp://ftp.hpmuseum.org/hpswap/At offset 8 the directory start address in units (probably 256 bytes) is
stored as 4 byte big endian integer. Typical value is 2. That means
directory start at 0x200. In theory higher values are possible, but then
there is a gap between header and directory. And on floppies with only some
hundreds of KiB you would not waste hundreds of bytes. So i assume that this
value is always below 256. That means the 3 upper bytes are nil. That is
expressed by XML construct like:
<Bytes>000000</Bytes>
<Pos>8</Pos>
At offset 12 the LIF identifier is stored as 2 byte integer. In
documentation is only written that this value is octal 010000 for system
3000. That is the only version find in my examples, but i do not know if
this is always true. So i delete such pattern like:
<Bytes>1000</Bytes>
<Pos>12</Pos>
At offset 14 2 unused dummy bytes are stored. This are set to nil. That is
expressed by XML construct like:
<Bytes>0000</Bytes>
<Pos>14</Pos>
At offset 16 the length of directory in units is stored as 4 byte
integer. According to documentation for model 64000 this is 14. For example
DSKA0000_hfe.img this value is 18 and for hex dump based test-lif.img this
value was 24. Highest value i found was 80. This can also be verified by
running lifstat utility. This value is set when initializing the file
system. In theory higher values are possible, but then space for files
content become smaller. And on floppies with some hundreds of KiB you would
not waste hundreds of bytes. So i assume that this value is always below
256. That means the 3 upper bytes are nil. That is expressed by XML
construct like:
<Bytes>000000</Bytes>
<Pos>16</Pos>
At offset version is stored at 2 byte integer. According to documentation
this value is 0 for systems without extensions or 1 for model 64000. So i
assume that version is always smaller than 256. That means the upper byte is
nil. That is expressed by XML construct like:
<Bytes>00</Bytes>
<Pos>20</Pos>
The words 21 til 126 are used for extensions. For my first example this are
nils. But this not always true. So i delete all patterns at such
higher offsets.
The maximum size of the entire record (unless otherwise noted for specific
record types) is 1024 bytes.
At offset 2 the volume label is stored. This consist of 6 characters. Allowed
are up cased letter, digits, underline and space character. So HP disk images
are not misidentified by obj_omf.trid.xml as "OMF - Relocatable Object Module
Format", because there a nil byte is expected expressed by XML construct like:
<Bytes>00</Bytes>
<Pos>2</Pos>
But i believe this must not be always be true, because 2 byte record length
is stored at offset 1 there. The maximum size of the entire record (unless otherwise noted for specific
record types) is 1024 bytes. That gives in hexadecimal 0x03FD. So maybe
instead a nil byte also value 1, 2 or 3 is possible. Luckily i myself
does not find such case in my object examples.
Instead of generic mime type application/octet-stream i use a user defined
one. That is expressed by liken like:
<Mime>application/x-lif-disk</Mime>
In the old definition only LIF file name extension is mentioned. I also
found 1 example with img extension. In the documentation of hpdir is written
that for easier handling, it is a good idea to use image files with the
extension ".hpi" (hp image). So this is now expressed by line:
<Ext>LIF/HPI</Ext>
With the new definition now HP disk images are now recognized first with
50.1% recognition rate and the DEGAS low-res compressed bitmaps (*.pc1) are
not misidentified any more as HP disk image (See appended
output/trid-v-new.txt).
TrID definition, some examples and output are stored in archive lif.zip. I
hope that my XML file can be used in future version of triddefs.
With best wishes
Jörg Jenderek
