SuperArc, Disk Communicator
From: Michael Current (aa700@cleveland.Freenet.Edu)
Date: 01/28/92-10:38:46 PM Z
From: aa700@cleveland.Freenet.Edu (Michael Current)
Subject: SuperArc, Disk Communicator
Date: Tue Jan 28 22:38:46 1992
Reprinted from the A.C.E.C. BBS (614)-471-8559
NOTICE: This article originally appeared in the April, 1989 issue of Atari
Interface Magazine and may be freely distributed or reprinted in non-profit
User Group publications as long as the article's author and Atari Interface
Magazine are credited AND this notice is reprinted with the article. All other
publications must obtain written permission from Unicorn Publications, 3487
Braeburn Circle, Ann Arbor, MI 48108, Phone: (313) 973-8825 before using this
article.
A look at 8bit Utilities
by Bob Puff
If you download quite a few files for your 8bit from a local BBS, or especially
from the online services, you've no doubt used Super Arc and Diskcomm at some
point in time. But have you ever wondered how these utilities were born, or
what went into their making?
First, let's talk about Diskcomm. Back in January of '85 (right after getting
my Atari 1030 modem for Christmas), I saw a need to be able to transfer entire
disks over the modem not just single files. Disk Communicator version 1.0, a
simple BASIC program, satisfied that need.
The concept behind Diskcomm was to read all the data on a disk, sector by
sector, then save it as one large file. Since files can be easily transferred,
the other user would download the file, then "uncompact" the large file back
into a full disk. This sector by sector method is needed for full-boot disks,
but also had its uses in grouping a whole bunch of files. The program became
popular locally (Rochester, NY), and I created newer versions.
Along came other programs similar to Diskcomm, some making smaller files of the
same disk: I knew my work was cut out for me! After adding more compaction
types, warp speed for XF551s, modified 1050s and Happy drives, 130XE type extra
memory support, and totally re-writing the program in all machine language, the
current version 3.2 was released in late '87.
There is a special extender reserved for Diskcommed files -- .DCM. If you
encounter a file ending with .DCM (such as MYDOS.DCM), Diskcomm 3.2 is needed
to recreate the original disk. The procedure is quite simple. Boot up your
favorite DOS, and binary load Diskcomm. If you are using an upgraded computer,
the program might ask if you will allow it to use this extra memory. If you are
using the extra memory as a RAMdisk, then answer N. Otherwise, Diskcomm will
use it to reduce the number of disk swaps needed on a single drive system.
You should now be at the main menu. Use the [C] and [D] commands to change the
source and destination drive numbers, respectively. Now press [B]. You will
be prompted for the source name. Enter the FULL name, and hit RETURN (in this
example, enter "MYDOS.DCM"). Follow the prompts, and you will end up with a
working disk! The source file need not be kept any longer.
As with any program, after it has been out for a while, you see where things
could have been done better. The addition of ".DCM" to the filename of files
created, easier access of subdirectories, and Happy fast-write are a few
suggestions I have received from users. Perhaps in the future, those as well
as a possible MIO RAMdisk backup option will be incorporated. Have any other
suggestions? Let me know!
Super Arc is in a way similar to Diskcomm, but file-oriented instead of
sector-oriented. The purpose of Arc is to take one or more files, compact them
as much as possible, and store them as a single file, characterized with an
.ARC extender. Super Arc uses 3 of the 5 total types of compression: Storing
(no compression), Packing (strings of the same character are "packed"), and
Crunching, which is the method most often used. (There is no easy way to
explain that one!)
The Super Arc/UnArc project was started in the summer of 1988. AlfCrunch had
hit our city, and was beginning to be widely used. I was amazed at how small
the programs were; only a few dozen sectors in length. I said "If he can do it
in that little bit of code, well!..." Through the help of a friend, I got the
C source to the IBM version of Arc, and studied it for a week or so. Work on
Super UnArc then began. The Storing, Packing, and Squeezing code were done in
a couple days, but the Crunching code took a bit of thinking. The IBM code
uses a lot more memory for tables than is actually necessary.
After a few more days of studying a book on the C language (I had never done
anything in C before -- just Atari Basic and 6502 machine language!), the code
was written. I was not very happy with its speed, however, even though it was
much faster than the old ARC 1.2. I went through another week of printing my
crunching code out, studying it, comparing against the original, and finding
ways of "tweaking up" things here and there. Finally, I released version 1.0
on GEnie for beta testing, and tackled Super Arc.
Here's when I got the big scare. All the time Super UnArc was being written, I
never really looked at the C code that created the arc files. They used tables
that amounted to around 30k in length! The standard 8bit, after DOS, BASIC,
and other drivers have been loaded, has around 32k of free memory. Certainly
30k of tables would not leave me enough room for the actual program! However,
after more digging into the source code, I found a way to conserve 10k in the
tables, so they are only 20k long. Once again, the process of speeding up the
code was in order. After a few weeks, it was ready for beta testing. I
certainly had a "crash course" in C programming!
Super UnArc will probably be the program that is used most often. Let's say
you download a file called MYGAME.ARC. When you set up your terminal for the
download, it is a good idea to include the extender of .ARC. That way, you
will remember to unarc it. Boot up Super UnArc, and select [A]. Now enter the
filename of your file (you need not type the extender; Super UnArc
automatically adds it for you). In this example, you would enter "MYGAME".
There's a little catch here that most people miss: If you did NOT put an
extender on your filename when you downloaded the file, you need to enter a
period after the name. An example of this: if the file on your disk were to be
called MYGAME (no extender), Super UnArc will look for MYGAME.ARC. Adding the
period after the name will disable the addition of .ARC, and find the file.
Assuming you entered the name correctly, Super UnArc will ask you for the
destination filespec. You need only type the drive number (and RETURN) for the
destination drive. There are other things that you technical users can do
here, but for the most part a number is all that's needed. That's it! Told ya
it was simple... :-)
Now let us compare Diskcomm and Super Arc. Diskcomm will compact a floppy disk
sector by sector, resulting in a 10-20% size reduction. Since it does the
entire disk, all the files on the disk can be grouped together. DOSes, Print
Shop icons, and any disk that relies upon data in certain sectors can be backed
up / transferred using Diskcomm. Super Arc will compact only the files seen by
the DOS you use. It will usually reduce the data by 30-40%. There is no limit
to how many files you can store in an arc file. Use Super Arc for file(s), and
Diskcomm for those full-boot disks.
I hope this article has at helped to clarify the uses of the above programs. I
hear that Phil Katz, author of the PKARC/PKPAK programs in IBM land, has
released PKZIP, a new standard of file compaction similar, yet better than Arc.
If and when this becomes the new file compaction standard (and it does not use
large look-up tables!), I'll do an 8bit version. (Super Arc is compatible with
any .ARC file created on the PC, including "squashed files" done with PKPAK.)
--
Michael Current, Cleveland Free-Net 8-bit Atari SIGOp -->> go atari8 <<--
The Cleveland Free-Net Atari SIG is the Central Atari Information Network
Internet: currentm@carleton.edu / UUCP: ...!umn-cs!ccnfld!currentm
BITNET: currentm%carleton.edu@interbit / Cleveland Free-Net: aa700
-----------------------------------------
Return to message index
