The Museum of HP Calculators

HP Forum Archive 15

[ Return to Index | Top of Index ]

Swap Disks Exploded
Message #1 Posted by Howard Owen on 13 Aug 2005, 4:41 p.m.

I like pyrotechnics, so it was great fun to blow up the swap file LIF images into individual files. They are on the web at http://retrocalculator.com/SWAP/exploded. I named the files with their LIF name as root, and their type (as reported by TD's lifdir) as the file extension. They live in a directory under the above mentioned path named after the disk they came from. They will also be available vi anonymous ftp to ftp.retrocalculator.com as soon as the new static IP propagates out. I can't tell for sure, but you may have to use a special username to get anonymous access. I'll see once ftp is up.

The purpose of doing this work is to facilitate the "Swapdex" project to index these files. You can access the swapdex Wiki here.

I've also thrown together a quick and dirty Mysql database of the files. It isn't accessible from the web yet, but it could and should be once the schema is better defined. If you would like to help do that, see the Wiki link above.

Regards,
Howard

      
Re: Swap Disks Exploded
Message #2 Posted by Vassilis Prevelakis on 14 Aug 2005, 2:05 a.m.,
in response to message #1 by Howard Owen

Howard Owen wrote:
> I like pyrotechnics, so it was great fun to blow up the swap file LIF images
> into individual files. 

I am not sure what you had in mind but the swap archives are split into individual files. At least the ones at ftp://ftp.hpmuseum.org/lif/swap

All files are encoded in swap file format documented in http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=24, which simply involves prepending 32 bytes of header to the file. The header is the LIF directory header for that file ONLY.

The swap file format is not LIF. It only contains some elements from the LIF directory. So you do not need to "expand" the files, you simply need to skip these 32 bytes.

E.g. if I want to see the contents of file chhu01/curlex.l71, I will simply do:

arrakis% dd if=chhu01/curlex.l71 ibs=32 skip=1 | xd
 000000000000    5e000000  00f00e00    00000800  10ff131b    *^...............*
 000000000010    694100d0  1bb013f7    f84c3641  0911db07    *iA.......L6A....*
 000000000020    10b17d11  88bf411b    ad139f69  d230019a    *..}...A....i.0..*
 000000000030    260c0013  44760013    43faa0ae  fa324181    *&...Dv..C....2A.*
 000000000040    bf431bda  1a3070f8    35b40187  5f431b70    *.C...0p.5..._C.p*
 000000000050    0118b1f8  c12310b1    5a4e0801  5be91108    *.....#..ZN..[...*
 000000000060    86bf411b  60f81bb4    01860428  0131051e    *..A.`......(.1..*
 000000000070    00000007  00011404    19528001  7b0d0000    *.........R..{...*
 000000000080    494e4b4a  45542020    2020e214  00000525    *INKJET    .....%*
 000000000090    00000004  00011404    19578001  19060000    *.........W......*
 0000000000a0    54454c44  49523731    5044e214  00000529    *TELDIR71PD.....)*
 0000000000b0    0000000b  00011404    24348001  4e140000    *........$4..N...*
 0000000000c0    4355524c  45582020    2020e208  00000534    *CURLEX    .....4*
 0000000000d0    00000001  00011512    06238001  db000000    *.........#......*
 0000000000e0    ffffffff  ffffffff    ffffffff  ffffffff    *................*
          *** SAME ***
 000000000100    ........  ........    ........  ........    *................*

Moreover, your "exploded" files appear to be corrupted as well. E.g. your version of CURLEX.LEX71 is:

arrakis% xd CURLEX.LEX71 
 000000000000    5e000000  00f00e00    00000800  10ff131b    *^...............*
 000000000010    694100d0  1bb013f7    f84c3641  0911db07    *iA.......L6A....*
 000000000020    10b17d11  88bf411b    ad139f69  d230019a    *..}...A....i.0..*
 000000000030    260c0013  44760013    43faa0ae  fa324181    *&...Dv..C....2A.*
 000000000040    bf431bda  1a3070f8    35b40187  5f431b70    *.C...0p.5..._C.p*
 000000000050    0118b1f8  c12310b1    5a4e0801  5be91108    *.....#..ZN..[...*
 000000000060    86bf411b  60f81bb4    01860428  0131....    *..A.`......(.1..*

The length (0x6D) is also wrong. If we look at the curlex.l71 header we see:

arrakis% dd if=curlex.l71 ibs=32 count=1 | xd
 000000000000    4355524c  45582020    2020e208  00000000    *CURLEX    ......*
 000000000010    00000001  00010120    33568001  db000000    *....... 3V......*
that the file length should be 0xDB bytes, 219 in decimal (file length in bytes starts at offset 0x0C, and it is 3 bytes long (LSB first).

Note also that even files that are not encoded in any way (e.g. chhu01/acopy.text) are damaged. So you should check your program to make sure it decodes the files correctly.

Finally, simply looking at the filename inside the header and using this to name the extracted file is not sufficient as file names may have characters that are not acceptable to the local file system (e.g. \), you need some kind of mapping for the unacceptable characters.

Best Regards

**vp

Edited: 14 Aug 2005, 2:17 a.m.

            
Re: Swap Disks Exploded
Message #3 Posted by Howard Owen on 14 Aug 2005, 4:59 a.m.,
in response to message #2 by Vassilis Prevelakis

Thanks for the feedback, Vassilis!

I'll check on the corruption you noted. I'm pulling the files out of the LIF images (also on the museum site, but under the 'hpswap' directory) with lifget from a perl script. The script is in the "exploded" directory too, called "getem.pl". Perhaps lifget does not preserve the LIF header, and what you are looking at are the "raw" bits. I'll figure it out, either way. In the meantime, I've restricted access to the files. It won't do to distribute bogus date. I'm trying to reduce confusion, not add to it. 8)

My purpose in exploding the LIF images is to have bits I can work with in my indexing project. I plan to create descriptions and listings of all the program files, with Unix line endings rather than the interesting LIF TEXT format. I plan to drop these in beside the raw bits and refer to them in my database by URL. I may well be able to get by using the museum's copies, but I have to resolve the corruption issue before I can decide one way or the other.

Thanks again!

            
Corruption
Message #4 Posted by Howard Owen on 14 Aug 2005, 12:02 p.m.,
in response to message #2 by Vassilis Prevelakis

The files merely lack the LIF headers:

hbo@sol|1137> hexdump -C CHHU01/AST41N1.BASIC75 >AST41INI.hex
hbo@sol|1138> dd if=ast41n1.b75 ibs=32 skip=1 | hexdump -C >ast41n1.hex
48+0 records in
3+0 records out
hbo@sol|1140> md5sum *.hex
d919845771e9165ca64ac5177e508a20  AST41INI.hex
d919845771e9165ca64ac5177e508a20  ast41n1.hex

The file in caps is the one I produced with Tony Duell's lifget utility. The small case one is from the museum site.

The files here at the museum lack at least one disk that appears in the /hpswap directory. For that reason, and because I still think they could be useful for my Swapdex project, I'm going to leave the files up. I'm composing a plain text README now that explains how they differ from the museum's copies, and points here. Later I'll add a web page with links to all the other sources and better explanations of hat I'm trying to do.

For now, anon ftp is still hosed, but http://retrocalculator.com/SWAP/exploded works.

Thanks again for taking the time to look the files over!

Edited: 14 Aug 2005, 12:43 p.m.

                  
Re: Corruption
Message #5 Posted by Vassilis Prevelakis on 14 Aug 2005, 6:32 p.m.,
in response to message #4 by Howard Owen

OK got them. I was in error. The 0xDB in the CURLEX directory entry is the length in NIBBLES! So its 219 nibbles or 109.5 bytes. So the length of 110 is correct.

I have been dealing mainly with HP-85 files which have the length in bytes and was unlucky to pick a very small file (CURLEX). This meant that my wrong file length would still be less than a block (256 bytes) and thus would not ring any bells. If I had chosen a file like BEEPLEX which is 411 nibbles long (clearly greater than the 1 block it occupies) I would have investigated further.

**vp


[ Return to Index | Top of Index ]

Go back to the main exhibit hall