+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: Question about LIF file Volume Flag/Number (/thread-21222.html)
Question about LIF file Volume Flag/Number - Christoph Giesselink - 01-31-2024 06:26 PM
I recently used Sylvain's description
https://www.hpmuseum.org/forum/thread-20985-post-181642.html#pid181642
how to build a LIF volume over Lifutils with a ROM image inside. So I build a LIF volume with one HP41 ROM image file inside.
When I want to show the LIF volume content with my
Lifls V0.07
tool, no entries are shown.
The problem is the
// Volume Flag/Number (value = 32769 only HP-75)
at position 0x1A in the LIF Dir entry of the ROM file
starting length
offset in bytes what
0 10 file name (lower case mapped to upper,
padded with trailing spaces)
10 2 file type
12 4 start block
16 4 allocated length in blocks[*]
20 6 date and time that the file was created
26 6 miscellaneous data[*]
========== -75* File Types ==========
- The miscellaneous data field contains these values:
0 0x80
1 0x01
2 password char 1
3 password char 2
4 password char 3
5 password char 4
All historic LIF volume files in the
http://holyjoe.net/HP71/Online-LIF-Disk-Project.zip
contain at position 0x1A of the LIF directory header a 0x8001 content, independent if this is a HP-75 file type or not.
Only the LIF entry data created with
rom41er MATH1D <math.rom >math.lif
in my example has a 0x0000 at position 0x1A. My Lifls V0.07 expected here the 0x8001 content on all file types unequal to 0x0000, and ignored this dir entry on all other contents.
Why have all LIF volume files at the Online-LIF-Disk-Project have directory entries with a 0x8001 Volume Flag/Number, where a LIF file document tells us, the two bytes are
0 unused
1 unused
for all file types except 75 files?
I haven't checked all other file types created with the lifutils, I meanwhile ignore the Volume Flag/Number content except for the HP75 file types in my Lifls V0.08 tool.
RE: Question about LIF file Volume Flag/Number - Martin Hepperle - 02-02-2024 08:05 AM
The documentation for the LIF format is clear w.r.t. this word.
It contains a flag in the high bit #15 and a file volume number in the lower 14 bits. Therefore a filler bit of 0 is placed at bit position 14.
As the typical files used by calculators and small computers are small and fit onto a single medium, the volume number is usually == 1.
A word of 0x0000 would be invalid. The minimum value should be 0x0001, the first file of a multi-volume file.
My documentation:
// (L flag) and (volume number) typically == 0x8001
// L - Last Volume Flag (1 bit)
// If the last volume flag (L) = 0, it is not the last volume of the
// file.
// If the last volume flag (L) = 1, it is the last volume of the file.
volinfo = (1 << 15) | 1;
Official Documentation e.g.:
HP64000 Logic Development System
Flexible Disk Drive Reference Manual
64941-90906, January 1983
[...]
16-bit word at offset 13d:
[L (1 bit) - volume number (15 bits)]
L - Last Volume Flag (1 bit)
If the last volume flag (L) = 0, it is not the last volume of the file.
If the last volume flag (L) = 1, it is the last volume of the file.
Volume Number (1 filler bit + 14 bits)
This is a 14-bit unsigned integer containing the volume number of this file on this medium.
Volume number = 0 is not a valid condition. All files must be contained on at least one
volume. Volumes start with number 1 and are incremented by one for each subsequent volume.
Implementation
Words 14 and 15 are available for implementation dependent uses by file types -2000 to
-77777. These fields must be set to 0 for all interchange file types and for file types -2 to -177.
[...]
Martin
RE: Question about LIF file Volume Flag/Number - jsi - 02-02-2024 12:11 PM
(01-31-2024 06:26 PM)Christoph Giesselink Wrote: Only the LIF entry data created with
rom41er MATH1D <math.rom >math.lif
in my example has a 0x0000 at position 0x1A. My Lifls V0.07 expected here the 0x8001 content on all file types unequal to 0x0000, and ignored this dir entry on all other contents.
This is indeed a bug in rom41er.c, rom41hx.c and rom41lif.c which set the bytes 26D and 27D to zero. A first review of the sources revealed that this only applies to these programs. All other programs initialize directory entries with volume number = 1 and last volume flag set (0x8001).
RE: Question about LIF file Volume Flag/Number - Christoph Giesselink - 02-02-2024 08:33 PM
Martin, Joachim,
TNX for the info.
So my conclusion is, the "Volume Flag/Number" number is not used by the HP41.
On mixed LIF disks with file types of other calculator/computer on other systems, reading such a disk volume with such an directory entry may run into trouble with an invalid "Volume Flag/Number" content.
RE: Question about LIF file Volume Flag/Number - jsi - 02-04-2024 11:08 AM
Fixed in LIFUTILS 1.7.11