[ posted and mailed ]

Doug Mitton <doug_mitton@hotmail.x.com> wrote:
>>It sounds like an end-of-line conversion to me, though I don't know where
>>it would be happening.  I also would have expected it to get a CRC error
>>on the first file, unless it was very small or just didn't happen to have
>>an EOL-like sequence in it.  Can you verify that the file length of the SHK
>>files are the same on both sides?
>>
>>If you send the SHK file that doesn't work with NuLib2 to me I'll poke at it.
> 
> 
> I just forwarded the file archive I created by email to you.  The
> nulib2 that I just downloaded and compiled today (Thurs) is V1.1.0.
> Thats very strange if I should have found V2.x.  I downloaded from
> planetmirror.com.

The file is getting trashed by an end-of-line conversion.  Every single
occurrence of CR (0x0d) is followed by LF (0x0a), which is very unlikely
for compressed binary data.

If you perform an integrity check (nulib2 -i archive.shk) it'll fail
while trying to uncompress the data.  The only reason the archive is
being accepted at all is that there's no 0x0d in the header.

There *are* some 0x0a bytes in the header, so it looks like something
converting CR to CRLF, which I would expect from a program that knows
it's copying Apple II data to a PC.  You will probably find that the file
length of "archive.shk" is larger on the PC than it is on the IIgs.

Because *every* occurrence of 0x0d is expanded to 0x0a, it's possible to
un-corrupt the archive.  If you run the following program (compile with
"gcc fixit.c -o fixit", run as "./fixit < ARCHIVE.SHK > fixed.shk), you
will find that "nulib2 -i fixed.shk" passes with flying colors.

#include <stdio.h>

int main(void)
{
    int ic;
    while ((ic = getchar()) != EOF) {
        if (ic == 0x0d) {
            putchar(0x0d);
            ic = getchar();
            if (ic == EOF) {
                break;
            } else if (ic != 0x0a) {
                putchar(ic);
            }
        } else {
            putchar(ic);
        }
    }
    return 0;
}

% nulib2 i fixed.shk
DONE verifying  BASIC.SYS
DONE verifying  NO.RAMFAST
DONE verifying  PRODOS
[...]
DONE verifying  UTILITY:ZipGS.SYS16
DONE verifying  UTILITY:zippy

It would be best to find the flaw in your file copying process, but
this'll get you going.

BTW, the latest version of NuLib2 can be found on http://www.nulib.com/.

And I'm pleased to see that "zippy" lives on. :-)  If you want source
code see http://www.fadden.com/dl-apple2/index.htm#zippy

-- 
Send mail to fadden@fadden.com (Andy McFadden) - http://www.fadden.com/
CD-Recordable FAQ - http://www.cdrfaq.org/
CiderPress Apple II archive utility for Windows - http://www.faddensoft.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/