[comp.sys.apple] Large binaries

labc-3dc@e260-3f.berkeley.edu (Andy McFadden) (02/04/89)

The Not Terribly Definitive Guide to Breaking Up Large Binary Files:

As one who has done it (MicroEMACS...), I can say that it isn't a whole lot
of fun...

The most straightforward way to go about it is as follows:
1) Get everything all nice and packed in BLU or SHK format
2) Break the binary file into chunks of about 30-32K each.
3) Run these chunks through executioner, selecting 4-bit packing (not 6)
4) Write a series of BASIC statments that will recombine the parts
5) Upload them to your system, and convert the CRs to LFs.
6) If possible, DOWNLOAD THEM AND VERIFY THAT THEY WERE PACKED CORRECTLY.
7) Post them to comp.binaries.apple2, Apple2-L, or send them to an FTP site.

Of the above, 2 is the tough one to do, 4 is the tough one to get right, and
6 is the step that most people forget to do (or aren't willing to do).

1) This is the easy one.  Make sure that you squeeze everything that needs
   to be (ShrinkIt should handle this automatically).

2) Okay... there are a couple of methods, like a short command in Davex (I'll
   let the appropriate author explain how to use it).  The method I use
   involves BASIC.SYSTEM:

   Suppose you have a file called "GAME.BQY", which is 116000 bytes long (check
   the Endfile number in the wide CATALOG listing).  This needs to be broken
   into four 30000 byte segments, which is accomplished as follows:

   ]BLOAD GAME.BQY,A$1000,L30000
   ]BSAVE GAME.1,A$1000,L30000
   ]BLOAD GAME.BQY,A$1000,L30000,B30000   <- Start reading from the 30000th byte
   ]BSAVE GAME.2,A$1000,L30000
   ]BLOAD GAME.BQY,A$1000,L30000,B60000   <- Start reading from the 60000th byte
   ]BSAVE GAME.3,A$1000,L30000
   ]BLOAD GAME.BQY,A$1000,L30000,B90000   <- ...
   ]BSAVE GAME.4,A$1000,L26000        <- Last segment is a short one

   You could make them all 30000, but that would take longer to up/download.

3) Run them through executioner, giving them names like "GAME.1.EXEC".

4) You can either put the recombining statments at the end of the last file
   (which is nice, but prevents people from using Stripexec), or you can
   include them as a separate BASIC file.  Make sure you upload this AS TEXT;
   including it in the BLU or SHK file is sort of useless...

   The statments for the above program would look like:

   BLOAD GAME.1,A$1000
   BSAVE GAME.BQY,A$1000,L30000
   BLOAD GAME.2,A$1000
   BSAVE GAME.BQY,A$1000,L30000,B30000   <- Start saving 30000 bytes farther in
   BLOAD GAME.3,A$1000
   BSAVE GAME.BQY,A$1000,L30000,B60000
   BLOAD GAME.4,A$1000
   BSAVE GAME.BQY,A$1000,L26000,B90000
   PRINT "Done!";CHR$(7)

5) Now you must upload the files (which you should know how to do), and then
   convert the carraige returns to linefeeds.  I use a quick UNIX alias:

   alias crlf	"tr '\015' '\012' < \!:1 > \!:2"

   So you would type "crlf game.1.exec game.1" and then distribute the files
   "game.[1234]" to comp.binaries.apple2.

6) If possible (and if you have the time), PLEASE download and test your
   files!  It is *most uncool* to post a five-part binary, and then be notified
   by 5000 irate users that it doesn't unpack right!  Besides the devastating
   effects upon your personal life, it costs the net a lot of money to send
   them everywhere.

7) Post them somewhere.  Use Pnews or postnews to send them to comp.binaries.
   apple2, or use the appropriate commands to send them to the LISTSERV (NOT
   comp.sys.apple or mail to Apple2-L).  Send mail to the archive site
   maintainers to figure out what they want you to do for submissions.

   When you do finally distribute them, make sure that they have DESCRIPTIVE
   SUBJECT HEADERS.  If it is for the GS only, it should say so.  If it is
   part 1/5, it should say that too.  Put the title and part # AT THE TOP
   of the file as well (in case the subject line doesn't get carried along).
   There should also be a brief description of what it is at the top of the
   first part, so that people can decide whether or not they want to download
   it.

Well, that's about it.  I'm sure I've left something out along the way, but
this should help most people along.  Good luck.

-- 
labc-3dc@widow.berkeley.edu (Andy McFadden)

kamath@reed.UUCP (Sean Kamath) (02/20/89)

<AUG!  THESIS HELL!  But I finally got my stupid mac program working
enough to get the pix to the Vax. . .>

In article <19906@agate.BERKELEY.EDU> labc-3dc@e260-3f.berkeley.edu (Andy McFadden) writes:
>[Some interresting stuff on splitting large files.]
>[the 7 steps to happiness]
>
>-- 
>labc-3dc@widow.berkeley.edu (Andy McFadden)

Sorry I've been away so long, but if I don't write a thesis, I don't
graduate.

It's interresting note that you mention using the unix-y 'tr' filter to
place CR and LF in the right place at the right time.  For those of us
on UNIX systems, the best way without doubt to split large files is the
following:

1) Package the world. Ideally, one should be able to pack a *large* set
of files, not like Executioner, which chokes on big things.

2) upload to big Unix machine.

3) run though 'split'

4) post

on the recieving side, use 'cat' to put it all back together again,
download and unpack.

Sean Kamath


-- 
UUCP:  {decvax allegra ucbcad ucbvax hplabs}!tektronix!reed!kamath
CSNET: reed!kamath@Tektronix.CSNET  ||  BITNET: kamath@reed.BITNET
ARPA: kamath%reed.bitnet@cunyvm.cuny.edu
US Snail: 3934 SE Boise, Portland, OR  97202-3126 (I hate 4 line .sigs!)