The idea of
preservation is to make the data easier
to read/interpret/archive, not to keep the problem at the same level.
This is a very important point - if you are archiving disks for
historical reasons, you have to realize that like the original systems,
the tools you are using now will eventually become difficult if not
impossible to use on future "modern" hardware. It then becomes
critical to be able to recover the data by other means.
Agreed.
Another big reason to use a documented format is that you may
want/need to do other things with the data besides write it back to
original format disks ... the original system may not be available
or working. It may not have the means to transfer data other than
by reading it's floppies. You may be trying to extract files from the
disk, or run it under emulation. To do these things, you need to be
able to access the data directly from the image file, and to fully
understand how that data is organized.
In other words you never know what a future enthusiast or historian may
wish (or need) to do with this data so you make it as easy as possible to
do anything with it.
This is why I specifically documented and placed the
ImageDisk
file format into the public domain. The ability to do this was one of
FWIW, I wronte a simple set of programs to read, image, restore, etc the
disks used by soem older HP calculators, HP41, HP71, etc). I defined a
trivial image file format, which I documetned in the following way :
liffile(5) LIF Utilities liffile(5)
NAME
liffile - HP9114 LIF disk image file
DESCRIPTION
The HP9114 LIF disk image file format was designed as a
simple way to store HP9114 disk images on a larger com-
puter, and to allow programs to be written to process
those images (including writing them back to a physical
disk).
IMAGE FILE & LIF LOGICAL BLOCKS
The file consists of a raw dump of the data blocks on the
disk, in increasing numerical order. There are no headers
or trailers added, either for the entire image or for each
block. That is to say :
Bytes 0 to 255 are LIF logical block 0
Bytes 256 to 511 are LIF logical block 1
Bytes 512 to 767 are LIF logical block 2
and so on
As an HP9114 disk contains 2464 user blocks (organised as
77 cylinders, 2 heads, and 16 sectors per track, with each
sector being 1 block), an image file is always 2464*256,
or 630784, bytes long.
LIF DISK PHYSICAL BLOCKS
The correspondence between the logical block numbers
described in the last section and the physical sector
addresses on the disk is also straightforward. The cylin-
ders on the disk are numbered from 0 to 76. the 2 heads
(sides) are called 0 and 1, and the sectors on each track
are numbered from 0 to 16. Then :
Block 0 is cylinder 0, head 0, sector 1
Block 1 is cylinder 0, head 0, sector 2
Continuing on cylinder 0, head 0, until...
Block 15 is cylinder 0, head 0, sector 16
Block 16 is cylinder 0, head 1, sector 1
Continuing on cylinder 0, head 1 until...
Block 31 is cylinder 0, head 1, sector 16
Block 32 is cylinder 1, head 0, sector 1
LIF Utilities 16-March-2002 1
liffile(5) LIF Utilities liffile(5)
And continuing in this manner for all 77 cylinders
PSEUDO-CODE TO WRITE AN IMAGE TO DISK
Assuming the necessary functions exist to seek the disk
head to a particular cylinder ( seek() ) and to write a
256 byte sector ( writesector () )
) then it is reasonably easy to write a program to trans-
fer a disk image to a physical disk. The following
pseudo-code gives the basic idea :
declare blockbuffer to be 256 bytes long
open(image file)
for cylinder=0 to 76
seek(cylinder)
for head = 0 to 1
for sector = 1 to 16
read next 256 bytes of image file into blockbuffer
writesector(cylinder,head,sector,blockbuffer)
next sector
next head
next cylinder
close(image file)
end
REFERENCES
The logical block structure of a LIF device is given in
Appendix D of the HPIL Module for the HP71 Owner's Manual
The relationship between LIF logical blocks and
physical disk sectors was determined experimentally.
RESTRICTIONS
Although the LIF Utilities for linux are released under
the GNU public license, the only restriction placed on the
use of this image file format is that no (other) restric-
tions may be placed on its use. Anybody is welcome to
write programs using this file format (for example to con-
vert the image files into other formats, or to transfer
between physical disks and the image format) for any com-
puter or operating system, and to distribute these pro-
grams under any license terms they choose.
LIF Utilities 16-March-2002 2
liffile(5) LIF Utilities liffile(5)
AUTHOR
The LIF image file format was designed by Tony Duell,
ard at p850ug1.demon.co.uk
LIF Utilities 16-March-2002 3
In case it's not clear, the term 'any license terms' includes
closed-source. comemrcial software. All you can't do is prevent others
writing simialr programs to handle such files.
my primary motivations in creating the program. Nobody
owns the
format, and nobody can ever restrict what you do with it. I strongly
urge anyone who is creating other disk/data imaging systems to
do the same.
As do I.
-tony