Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!waikato.ac.nz!comp.vuw.ac.nz!actrix!ewen
From: ewen@actrix.gen.nz (Ewen McNeill)
Newsgroups: comp.os.cpm
Subject: Flame returned (was Re: VT100KAY.LBR problems)
Summary: The flame is unfair under the circumstances.
Keywords: Amstrad, CP/M+, UNCR, UNCRLZH, bug, BIOS
Message-ID: <1991Mar19.054726.11637@actrix.gen.nz>
Date: 19 Mar 91 05:47:26 GMT
References: <1991Mar17.183608.26443@odin.diku.dk> <9g9Zy1w164w@ijpc.UUCP>
Organization: Actrix Information Exchange
Lines: 81
Comment-To: ianj@ijpc.UUCP

In article <9g9Zy1w164w@ijpc.UUCP> ianj@ijpc.UUCP (Ian Justman) writes:
> ankh@diku.dk (Klaus Ambrass) writes:
> 
> > Well, I had that prob myself once.
> > Way back then, it was due to the packing format applied by who ever packed
> > the file in the first place.
> > 	I have an Amstrad cpc6128 and found that sometimes, when you CRUNCH a
> > file you can UNCR it, but not UNCRLZH it. I know it sounds loony, but the
>                             ^^^^^^^^^^^ FALSE, FALSE, FALSE!!!!!!
> > two programs are in fact different.
> 
> (flamethrower on maximum and enjoying it!!!!)
> 
> YOU'RE ABSOLUTELY DEAD WRONG!!!!!!
> 
> I USE UCRLZH.COM TO UNCRUNCH ?Z? FILES ALL THE TIME!!!!!!
> 
And YOU don't really know what you are talking about.  I have had the
same problems as Klaus has had -- I also own a CPC6128.  The problem he
describes is exactly true, for the CPC6128.  There is a bug (somewhere)
in the Bios. I am going to have to go reverse-engineering it (there is
no Bios source available to my knowledge).

FTR, I have successfully used UCRLZH to uncrunch files (.?Z?), so it
definately does work.  This was not off the floppy drives on the
Amstrad, however (this is where the bug is).
 
So the real answer is that you are both right....  :-)  Sortof.

> IF YOU WANT TO MAKE ME EAT MY WORDS, TRY IT!!!  I know I'm right
> about this one.  I know because I've used it. Have YOU tried it?
> UCRLZH11.COM _WILL_ uncrunch ?Q?, ?Z?, and ?Y? files.  What you
> just said is one of the biggest crocks I've ever seen!
If you own an Amstrad, and you haven't had any problems, I would love to
hear what you do.  Otherwise, YOU don't know exactly what you are
talking about.

May I suggest, in future, that you don't jump in with all guns blazing
(to mix metaphors), and instead find out why the person made the
statement?

Also, FTR, the reason that one program works (UNCR), and another doesn't
(UNCRLZH), seems to be connected with the amount of register
preservation they do, the amount of use they make of the extra Z80
registers, what they actually call, and a few other things.

For instance, unzip (David Goodenough) doesn't work too well on the Amstrad
drives for some reason.  It works fine off my Ram disk (the patch for
which appears to have been made (autoinstall program) at a higher level
than the bug) however. [BTW, this is nothing against David's program --
it SHOULD work perfectly on the Amstrad, and does on other systems]

Unarc (I forget who wrote it at the moment), on the other hand, works
perfectly.  I looked through the source, and saw lots of places where it
used the extra registers very carefully, and preserved them all the way
through (interupts off), etc.   The comments mentioned problems with
extra register usage on "various computers".

Further information, (for those with advice rather than flames!), it
appears that everytime this bug occurs the same piece of code/whatever
is copied into the disk-sector buffer, rather than the sector required.
Only 128 bytes long, but morethan enough to scamble anything that is
supposed to be being decompressed.  I discovered this when one of my editors
(ZDE - I don't have any source to check what it does) had the same problem.  

One more little thing to note, the problem doesn't occur all the time,
and as far as I can tell it happens at random.  This cannot be true, but
I haven't discovered what causes it yet.  One possible lead is that
sometimes a file will fail, and then if the operation is tried again
after resetting the drives, it will work.  [This is CP/M+, BTW, the
drives are supposed to auto-reset when needed]

Sorry, everyone, that this has got this long.  It was intended to rebut
the flame, but the opportunity to seek others opinion on the problem
couldn't be missed.

Any useful suggestions are welcomed, and any off-the-cuff flames will be
dealt with in a suitable manner (ie, probably ignored!).

-- 
Ewen McNeill.				Email: ewen@actrix.gen.nz