Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!um-math!hyc
From: hyc@math.lsa.umich.edu (Howard Chu)
Newsgroups: comp.sys.atari.st
Subject: Re: ARC 5.21b
Message-ID: <391@clio.math.lsa.umich.edu>
Date: 3 Aug 88 06:27:53 GMT
References: <386@clio.math.lsa.umich.edu> <1309@percival.UUCP>
Sender: usenet@math.lsa.umich.edu
Reply-To: hyc@math.lsa.umich.edu (Howard Chu)
Organization: University of Michigan Math Dept., Ann Arbor
Lines: 55
UUCP-Path: {mailrus,umix}!um-math!hyc

In article <1309@percival.UUCP> russ@percival.UUCP (Russ Schwartz) writes:
>Since people seem to be porting ARC over to the ST and making mods to it
>anyway, why not add a buffer that allocates as much memory as it needs for
>the compressing/decompressing process so it will speed it up?
>
My intent was simply to port the MSDOS program, making as few changes as
necessary to get a running program. The idea is to make everything look as
much like the original as possible. Of course, we don't have people like Phil
Katz writing 68000 assembly code for the ST just yet, so lumping in PKARC
compatibility into this program seems like a reasonable thing. Gratuitous
modifications probably aren't the way to go. At least, not if you're going
to call your program "ARC" of any form or another. (Look what's happening with
Katz - he's got a lawsuit to worry about now.) In any case, I'm not sure that
a large buffer will be such a speedup. I'd expect that it buys as much speedup
as simply using a large enough RAMdisk. Running my system on a 1.4meg RAMdisk,
I can say that it's godawful slow. I don't think throwing more memory at the
problem is the solution.

>There is a program (sharware) called DCOPY by Ralph Walden that does this
>very thing but it's attached to a menu driven shell that does a lot of other
>stuff I could do without.
>
DCOPY is kind of nice. I still don't think the buffer buys too much, but what
the heck. I think the basic idea is right - if you want it faster, rethink the
algorithms, and code it in assembler. I haven't had time yet to look up all the
background theory & such behind it, though I plan to. So far I've paid as little
attention as possible to the fundamentals, trying to locate all the nitpicky
superficial details. Ralph Walden seems to have the background down. I bet it's
not going to be long before we see a new ARC-compatible utility for the ST that
runs at a respectable speed. I agree on that point - I don't want all the other
functions DCOPY has. Just a fast ARC... I've never been too eager to jump on it
though, knowing there are other people out there already working on it.

>Anybody willing to try it?
>
>Russell Schwartz                    ["This is another fine myth you've gotten
>...!tektronix!reed!percival!russ      me into!" - Lar L. & Har D.]
>voice: 503-643-2786
>  BBS: 503-292-1321 (Sysop @ IBBS - FoReM Node #4 - 3/12/2400 - PCPursuitable)

Just a matter of time, I'm sure. In the mean time, it'd probably be a good idea
to start thinking about more advanced archiving methods. I think the good ol'
Unix(tm) tar & compress utilities are perfect. Port PDtar, latch onto a decent
C compiler that can handle arrays of 320K and up, and hey - fast compression,
plus full directory hierarchies.
Something to consider, at least. ARC is nice, but it shows its CP/M heritage
too well - designed for a flat filesystem. Sure MSDOS has evolved beyond CP/M
now, but a lot of that design philosophy still shines thru, and it'd be a
terrible thing to saddle down a sleek machine like the ST with that kind of
anachronistic burden...
--
  /
 /_ , ,_.                      Howard Chu
/ /(_/(__                University of Michigan
    /           Computing Center          College of LS&A
   '              Unix Project          Information Systems