Swap Disks Exploded



#2

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


#3

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.


#4

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!

#5

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.


#6

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


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP PRIME: Hide return value from program and swap Edit with Run vrrr 2 195 11-09-2013, 04:04 PM
Last Post: vrrr
  BATTERIES' SWAP ON HP 48GX aurelio 7 351 10-06-2013, 07:50 PM
Last Post: aurelio
  x swap (I) hp 35s instruction Denis Doyon 4 210 12-25-2012, 11:22 AM
Last Post: Walter B
  OT: Old windows and ms/dos on 3.5 disks Ethan Conner 7 288 05-20-2012, 02:20 AM
Last Post: Marcus von Cube, Germany
  About HP71 swap disks Olivier De Smet 5 231 03-17-2012, 07:42 PM
Last Post: Olivier De Smet
  HP 41 / 71 SWAP Disks Richard Wagoner 4 220 03-17-2012, 01:53 PM
Last Post: Richard Wagoner
  Swap meets at HHCs? Peter Murphy (Livermore) 1 119 10-11-2011, 08:26 PM
Last Post: Allen
  HP-45 board swap kubla 2 138 07-28-2010, 10:34 PM
Last Post: kubla
  hp 41 register swap Sok-khieng Chum Hun 3 171 06-30-2010, 08:14 PM
Last Post: Thomas Klemm
  41 SWAP disk documentation? Ángel Martin 0 96 06-15-2010, 01:46 PM
Last Post: Ángel Martin

Forum Jump: