Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pro-sol.cts.com!andyn
From: andyn@pro-sol.cts.com (Andy Nicholas)
Newsgroups: comp.sys.apple
Subject: HyperC and ShrinkIt
Message-ID: <8903030116.AA29235@crash.cts.com>
Date: 3 Mar 89 00:33:49 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: pnet01!pro-sol!andyn@nosc.mil
Organization: The Internet
Lines: 58

There seems to be some confusion regarding ShrinkIt 0.95 and HyperC --

>From what I know (I don't have HyperC, but I obviously have ShrinkIt :-)
HyperC is supposed to have a proprietary DOS, CDOS, which somewhat can
masquerade as ProDOS.  From this, and people's reported attempts to get
ShrinkIt to unpack on a 3.5" drive (when the original was a 140k disk), I
think either of the following may have happened:

(1) Shrinkit 0.95 optimizes ProDOS disks on the fly as is packs them.
    This pre-supposes that the disk being packed *IS* a ProDOS disk
    with an available bitmap (usually on block 6, but the pointer
    to it should be on block2, which is what ShrinkIt reads).  If
    there would be no proper bitmap, ShrinkIt would try to optimize
    the disk based on totally false information and end up *REALLY*
    munging the disk.

    This is an error on ShrinkIt's part.  In v1.0, I don't assume anything
    and only optimize the disk if you explicitly tell ShrinkIt to do it.

    How does this help you?  It doesn't.  If ShrinkIt zeroed the wrong
    blocks, all is lost and the archive is irrecoverable.

or....

(2) If CDOS is close enough to ProDOS so that it *HAS* a bitmap that
    got optimized, but something else strange is going on with the OS
    so it won't work on a 3.5" disk, then when ShrinkIt patches the
    bitmap and # of blocks on the disk when it extracts the 140k image
    onto the 3.5" disk, it is somehow creating something HyperC knows
    nothing about --

    Apparent solution?  Unpack it to a 140k floppy drive.  Can this
    be fixed in ShrinkIt 1.0?  I'm not sure.  Could Someone *MAIL*
    me (US Mail) a working copy of the HyperC that caused this mess?
    I'd like to take a look at what went wrong and fix it if at all
    possible.

ShrinkIt 1.0 does not (unfortunately) support disk swapping.  There
simply isn't enough memory available... yet.

I'm working on a Q&D 40-column version of Shrinkit that will work
on II+'s and Unenhanced IIe's.  No frills, just archive stuff.

The next version of ShrinkIt will also have a delete record from archive
function.  It will be a little slow since the entire contents of the archive
will have to be rewritten, but it'll work.

By the time this message hits the newsfeeds, ShrinkIt 1.0 should be out the
door and available on apple2-L and AppleLink PE.

andy



Andy Nicholas                 CsNet: nicholaA@moravian.edu
Box 435, Moravian College  InterNet: nicholaA%batman.moravian.edu@relay.cs.net
Bethlehem, PA  18018       ALink PE: ShrinkIt
                               Bang: rutgers!liberty!batman!nicholaA