{SHIFT-@}hd3:-<>-,Self Dissolving Archives,{CBM-Z}(C){CBM-X}1987 - Ampere Metal
{SHIFT-@}ft2:,,18 Jan 1987
{SHIFT-@}ai+4:ju1
If you're reading this text file, then you've probably already gone through the process of dissolving the archive that was used to distribute it. Pretty easy huh? Well, thats what self-dissolving archives (SDarc's) are all about. It takes the pain (or confusion) out of dissolving archives.
Not only are SDarc's easy to use, but since the archives created are self dissolving, it is no longer nessessary for people recieving such files to have ARC installed and running before they can dissolve them. All you have to do is LOAD and RUN an SDarc. This is probably what most people do to downloaded programs anyway, so instructions are not even nessessary. For those of you that have only a single 1541 or 1571, you'll appreciate the convenience of just LOADing the SDarc into RAM, switching disks, and depositing the un-ARCed files on a fresh disk.
SDarc's are also very easy to create. All you have to do is attach the short 4 block SDA program to the beginning of the archive as outlined below.
But, convenience has a price. In order to keep the SDA program as short as possible, we've made a few simplifying assumptions about the archives they are to dissolve. After all, one of the nice things about ARC is that it saves you disk space and up/download time. If the SDA header were too large, we'd lose that advantage. The limitations imposed by these assumptions are as follows:
{SHIFT-@}lm10:ai-3
1) The SDarc must be created using an ARC program numbered 2.xx That is, it must be a version 2 archive.
2) The SDarc must NOT contain any crunched files. It may contain any combination of stored,packed squeezed, or squashed files. Crunched files require about 28K of RAM as workspace, and this would impose too much of a restriction on the maximum size of an SDarc. It would also double (or more) the size of the SDA header.
3) The SDarc must not contain any RELative files.
4) SDA is machine sensitive. The 64 version won't work in 128 mode on the 128, and the PET version only works on the PET and so on. Incidentally, the PET version is for BASIC 4.0 only.
5) You have to watch out how big the SDarc is. If you try to load a program bigger than about 200 blocks into the 64, you'll wipe out the memory mapped I/O and crash the 64. SDarc's can be larger than 200 blocks on the C-64. The maximum size is about 243 disk blocks, ($0801-$F9FF) but you will have to write your own boot program so that it gets loaded into {CBM-C}RAM{CBM-V} properly. See the notes below for size restrictions for the various versions of SDA.
{SHIFT-@}lm2:ai+1
{SHIFT-@}fp
Creation of SDarc's is quite simple.
First, select the correct version of the SDA header program. If you're ARCing 64 stuff, use the 64 version; for PET stuff, use the PET version. You'll need to make a copy of the SDA program, because it will be 'used up' by the SD-archive.
Next rename the copy of SDA to the name of the archive you want to create. The name you choose will have to end with the filename extension '.arc'.
Next use ARC 2.30 to append to the SDA program using ARC/AZ
Next, rename the SDA to whatever you feel like. Its not really an archive, so avoid the '.arc' filename extension.
Finally, LOAD and RUN it, and make sure it works before uploading it to a bunch of bulletin boards. Make sure you don't neglect this step! You never know what might go wrong.
A sample session, with ARC active, might go something like this. We'll assume all the needed files are on drive a:
>c0:newfile.arc=0:sda230.64 (make a copy)
arc/az newfile whatever you want in it (make the archive)
ren newfile.arc newfile.sda (rename it)
dload"newfile.sda" (check it out)
run
An alternate method would be to first create the archive using ARC/CZ, and then use DOS to append the archive to the SDA program.
When you RUN an SDarc, it assumes that the archive follows immediately after the SDA program. Make sure that you avoid using XMODEM to transfer the SDA program (in un-ARCed form) because this will change its file size and it will think that the XMODEM padding is the first archive entry, and will abort since the header will no doubt be invalid.
The very first file in the SDarchive is not extracted to disk, but is typed to the screen instead. (I get a little nervous when a program starts right off writing to disk without any explanation.) This first file can, of course be squeezed or squashed, and should contain instructions for the user, copyright notices or whatever you think is appropriate.
After displaying this first file, SDA waits for the user to hit a key. If the key is the RUN/STOP key, then SDA just goes to the READY prompt and won't extract the SDarchive. If any other key is pressed, it goes ahead and extracts the remaining files to the disk in drive 0 of unit 8.
As the file is extracted, you will see the names of the files being created displayed one at a time. If, after extraction, the checksum is ok SDA prints "ok" after the filename. If there is a checksum error, SDA prints a question mark. (?)
{SHIFT-@}fp
Size restrictions:
$0200-$0230 is used by SDA. (All versions)
$0100-$0116 is used by SDA. (All versions)
$FA00-$FEFF is used by SDA in the C=64 and C=128 versions.
$7B00-$7FFF is used by SDA in the PET version.
$0401-$07F6 SDA header in the PET. Max size of an SDarchive = 119 blocks.
$0801-$0BF6 SDA header in the 64. '' '' '' 201 ''
$1C01-$1FF6 SDA header in the 128. '' '' '' 223 ''
This means that in the PET, your SDarchive can be as big as $7AFF-$0401, or a maximum of 119 blocks when stored on disk. In the 64, it can be $D000-$0801 or about 201 blocks on disk. If you want to construct your own BOOT program, then it could be as large as $FA00-$0801, or about 243 disk blocks. In the C-128 it can be $FA00-$1C00, or about 223 CBM disk blocks.
Note that we've padded the length of the SDA header to an exact multiple of 254 bytes. This way it will take up exactly four blocks on disk. If, for some reason you wish to convert it to a regular archive, then all you have to do is boot up your favorite disk doctor and change the (track,sector) pointer to the first block in the file so that it points to the fifth block in the file, and the job is done.
