View Full Version : Help UNCRunching a file

July 4th, 2017, 07:59 PM
Can anyone tell me what format the following file is in, please?

I'm able to extract the contents with lu.com but the individual files are all *.?z? files, which should be CRunch files, and I can't get UNCR.COM to UNCRunch them. I've tried version 2.0, 2.3 and 2.8. I can't find any other versions.

July 7th, 2017, 01:11 PM
Not sure if this is any help, but...

I've downloaded your file, and looked inside it. I note that there is a file list at the beginning of the .LBR file, and in this listing, all the files are shows with the middle letter of the extension transformed into a Z, i.e. .PAS becomes PZS, and .INC becomes .IXC.

However, looking further down the file, to the actual data for each file, there the filename is shown with the correct filename, i.e. .PAS and .INC (as per the examples already used.

This suggests to me that the compress (or crunch) process is a part of the archive process, and they've both been done at the same time (else the archive would not know what the original file name was)?

Did the version of LU you used have an inbuilt crunch/compress option? And an UNCR option? Otherwise, we need to find a library utility that does. Finding a separate CRunch utility may NOT be the answer, as you may already have found.

I'll look and see what I have on my many CP/M disks.


July 7th, 2017, 01:18 PM
You may also want to look at NSWEEP--it was a "do everyting" archiver that saw quite a bit of use.

"Z" in file extension names usually implies SQ being used to compress. NSWEEP can handle those too.

July 7th, 2017, 03:26 PM
Not sure that NSWEEP could do that. The version I have (NSWP) can do various file processes, incl SQ and USQ, but it does NOT appear to do anything with .LBR files The USQ process seems to assume that the middle char of the extension is changed to a Q, not a Z.

I've been trying the LBR file with NULU 1.1 - this will OPEN the .LBR, and display the file list, but it gives a CRC error. Any process to extract (and unsqueeze) a file locks the computer. The doc suggests that NULU 1.1 uses a different CRC system, compared to say 1.1 - seems like we need to find a version of LU/NULU earlier than NULU 1.1, but later that ?? so it still has the facility to uncompress files.

I do have a version of UNCR, which was on a CP/M PD software disk along with some *.?Z? files. This prog DID unpack the compressed files OK (no error reported). Version 2.8. But OP tried that.

Still looking.


July 7th, 2017, 03:34 PM
Well, I'll D/L the file and have a look tomorrow. I'll let you know what I find.


I tried processing it on the "swiss army knife" of CP/M LBR-unarchivers, lbrate.

?z? files should be "crunched", but neither lbrate nor uncr handles them without throwing a CRC error.

Stupid question, but if this file was obtained through ftp, was it transferred as a "binary" file?

July 7th, 2017, 06:31 PM
OK, apparently that file was just corrupt. I got a good version of the files from here: http://www.classiccmp.org/cpmarchives/cpm/mirrors/oak.oakland.edu/pub/cpm/apple/

July 8th, 2017, 07:30 AM
No response from OP?

My guess is that this .LBR was created using NULU 1.0 - I'm looking for a version of that, but not found anything yet. NULU 1.1 is slightly different, and the doc for the latter indicates CRC differences with 1.0.

NULU 1.1 includes facilities for SQUEEZE and CRUSH, with the middle letter of the ext becoming Q or Z as appropriate. I'd guess that 1.0 will do the same, but using the different CRC method.

Regarding the binary question, I've used a hex browser on the file, and I'd say it is OK. As I understand it, transferring a binary file as text will introduce CR/LF characters and maybe other things as well, and there is no trace of such things. You can clearly see the boundary between the separate files, and they are fully aligned right through to multiples of 16 bytes (maybe 256 or 512, I've not counted out the lines). If any spurious chars were added, this alignment would be lost.

I've checked versions of LU, and this does NOT seem to support either Sq or Crunch. Hence OP was only able to extract, and hence his problem.

Again, I think (guess, suspect?) that NULU 1.0 is needed. Need to try and find one?

I trust that OP is still looking for a solution????


July 8th, 2017, 09:23 AM
Hmmm, the plot thickens.

I've found some docs for NULU, and I'm wrong.

NULU supports Squeeze and Unsq, but the Krunch facility is something quite different. This relates to recovering space within the .LBR file after members are deleted.

So, my new assumption is that the ?z? members in the OP's library have been 'crunched' by some other program, and then added to the library. I assume using a version of LU that does NOT support it's own Squeeze process.

So, back to what OP originally asked, which Squeeze/Crunch prog was originally used?

By the way, I've just found a version of NULU 1.5, this does NOT report any CRC error with the .LBR, and extracts members fine, but the UnSqueeze process does not recognise the members as Squeezed and does nothing with them.

Apologies for running up a false path!


July 8th, 2017, 09:29 AM
I've got a couple of variations on the UNCR program, I'll give those a try later today.

July 8th, 2017, 11:51 AM
OK, apparently that file was just corrupt. I got a good version of the files from here: http://www.classiccmp.org/cpmarchives/cpm/mirrors/oak.oakland.edu/pub/cpm/apple/

Guessing the last few replies missed this post by the OP.

July 8th, 2017, 01:34 PM
Yup, sorry--blew right past it. I assume that OP has his (correct) files extracted?

July 8th, 2017, 01:38 PM
Yes. Thanks for that. I'd NOT spotted that message.

Well, I suppose that answers the original question. But raises another.

If the file was 'corrupt', it was a pretty spectacular 'corrupt', so I wonder how THAT happened.

I've got the second file too.

The two file sizes are the same. The internal structure of the two files is identical (as far as I can see). The index/header in both files looks similar, although there are some differences with some of the indexing numbers. The structure of the rest of the file, i.e. the packed 'member' units, looks OK in both files, and similar, although a visual check suggests there are some differences in some digits. Pieces of clear text, i.e. the filenames both in the index header and the body of the file seem OK. The packing bytes (where each file is packed out to the block boundary with 1A bytes) seem NOT to be affected.

I cannot think what sort of accidental corruption could have caused such differences.

This is even more intriguing than the original problem!!


July 8th, 2017, 01:57 PM
When I used LU to un-LBR the files (the same applies for other programs as well, such as DELBR and the aforementioned Linux lbrate, not all of the files look correct. In particular, one or two are missing the "filename header" that gives the original file name. If you're really curious, I can extract them again and relate what I see.

But this seems to be a moot point now.

July 8th, 2017, 02:19 PM
I tried the second URL to download the file and then imported it into myz80. I tried LT31.COM (LT31.LBR) to extract the source files.

It worked fine. I have them on my user 15 of A:. I can zip them and send them, if they are still needed.
I can also furnish LT31.LBR


Will extract all the files.


The files on this disk are:

Article "Apple graphics from CP/M" and formatted program listings
(WordStar files).

"INCLUDE" files for Turbo Pascal, ready for use as described in
"Apple graphics from CP/M."

6502 source code ready for PCPI's cross-assembler, as described
in "Apple graphics from CP/M."

Turbo Pascal source file for demo of low resolution graphics
functions, as described in "Apple graphics from CP/M."

Turbo Pascal source file for demo of high resolution graphics
functions, plus an "INCLUDE" file that facilitates hi-res
scaling, as described in "Apple graphics from CP/M."

Turbo Pascal source files to: dump high resolution graphics
display to a printer; save a hi-res page to disk; restore a hi-
res page from a file that had been saved to disk by SAVSCRN. All
are as described in "Apple graphics from CP/M."

18432 Jul 8 17:27 APLGRAFX
40192 Jul 8 17:26 LISTINGS
3968 Jul 8 17:26 PLOTTER.INC
3456 Jul 8 17:26 PCP.INC
6016 Jul 8 17:26 APLGR-L.INC
7296 Jul 8 17:26 APLGR-H.INC
1920 Jul 8 17:26 APLGR-G.INC
2560 Jul 8 17:23 LORES.A65
1152 Jul 8 17:23 -READ.ME!
4224 Jul 8 17:22 SINES.PAS
2176 Jul 8 17:22 SAVSCRN.PAS
1536 Jul 8 17:22 LOWRES.PAS
2304 Jul 8 17:22 GETSCRN.PAS
2176 Jul 8 17:22 DUMPSCRN.PAS


July 8th, 2017, 06:52 PM
Yup, I managed to get the good copy of the file. Now I have a new problem. When I run SINES.PAS it crashes to the monitor. I suspect this is because I'm on a IIgs and am going to test on a IIe soon.

July 10th, 2017, 07:28 PM
For anyone interested, here's what the crash to the monitor looks like: https://youtu.be/3I6KyOb0Q14