Automation Packer

From Atari Wiki
Jump to navigation Jump to search

Hi Guys.....

EGB brings you yet more useful goodies
for your ST. This time it is the latest
version of the Automation packer. The
main reason for this version is that 
the ICE packer from AXE was much faster
than the old Automation packer, but it
did not look as nice, did not have 
chunk options and even had some bugs
(yes AXE.. Bugs!!). Anyhow, this packer
is basically the ICE packer in a new 

Along with the packer, comes 3 pieces 
of source code.

DEPACK1.S    Depack code from A0 to A0
DEPACK2.S    Depack code from A0 to A1
LUMP501.S    Depack code for Chunk/Lump

When using Chunk/Lump source, you will
need to change a few bits. 

First change the lump name (if you are
using one).

Then change the program name which you
want to load. 

Then change space reserve size to chunk

A few people have to be thanked for
this production, namely :-

Axe - For writing ICE at all
    - and for putting up with ENGLISH
    - people last new year!!!

Duck (Dack renamed) - For bugging me to
    - actually do something, and even
    - send him some disks. For writing
    - those god awful lump depack routs
    - Now CAN you write a fast version?

Arn - For bugger all... and I mean all!

Zippy - For, and I quote 
    - Any lamer can use a chunk packer?
    - Yup, I agree... and some can only
    - use a chunk packer...

Vapour - For patience... you might yet
    - get that intro from me.

Monster - For supplying a decent Lump
    - join facility (still needs an
    - upgrade though!).               

                | Instructions for 'Lump/Chunk/Normal Packing' |
                |                 Revision v3.0                |
                |              (10th October 1991)             |
                |                                              |
                |          For Automation Packer v5.0.1        |
                |                                              |
                |by:- I Wonder Who Wrote This Trash Industries |

Once again, I've updated this document. The only reason for updating this
documents/source is because I was bored !!  If you distribute this source
any further than yourself, please include all the source files (including
the old Automation v5.01 sources !!) with this document.

The files you should have are:

SOURCES.OLD     - contains the original Automation v5.01 sources

  3F_ONLY.S     - Standard Trap #1 loader
  DEPACK1.S     - Depack from A0 - A0 source
  DEPACK2.S     - Depack from A0 - A1 source
  LUMP_501.S    - Lump/Chunk loader
  SINGLE.S      - Depack to an address & call address
  READ_ME.S     - The original 'instructions' !!

SOURCES.NEW     - contains my updated source code

  3F_ONLY.S     - Enhanced Trap #1 loader
  LUMP_501.S    - Enhanced Lump/Chunk loader
  ULTRA501.S    - Enhanced Ultraload II for v5.01 packer

Main Directory  - contains all the other bits required

  INSTRUX.501   - Guess what you're already reading !!!
  LUMPY.PRG     - Slightly better lump-file creator
  PACK501.PRG   - Automation v5.01 packer
  PACK501.RSC   - & it's resource file

Updates from revision 2 of these documents/sources
  i) All source listings have same 5 options for switching on/off as
     and when they are required:-

    a) Text printing on/off
    b) Wait for keypress before continuing on/off
    c) Low resolution set on/off
    d) Restore Trap #1 after quitting a program
    e) Turn depack flash on/off - also three different 'flashes' to
       choose between

 ii) standard Trap #1 loader (with above extras)
iii) dug up & revamped Ultraload II (with above extras)

Whatever functions that I have added to these source codes since the
previous revisions are purely additional extras.  My knowledge of 68000
is not as much as the original authors of the packers/sources, but at
least I've made them easier to understand !!


This document covers packing with the new Automation v5.01 packer.  Which
is basically Ice Packer v2.31 in a nice shell with a few added extras
including chunk packing !!  The reason for these instructions being written
and updated several times since, is that if you look at the original
instructions and source codes, you would of needed a lot of trial and
error to get what you wanted, whereas with these hnady instructions, you
can jump straight in (print them out first - makes life easier) and
create your own packed bits & pieces !!

I, the author, make no claims that this document is the complete guide to
to packing (especially concerning the lump/chunk packing side), but it is
a gigantic leap past the almost non-existant intructions that came with
the original release of the Automation v5.01 packer !!

I've written seperate sections to cover each different type of depack
loader.  This is probably the reason why this document has almost doubled
in size since revision v2.

All of the source files contain conditional assembly sections that are
easy enough for anyone to understand.  Try to make sure that you know
what you want to do before you start !!  Please ensure that you possess
a decent assembler (I use Devpac v2.25) before attempting to work with
these source files.

I've kept my anonimity so that the authors of these original sources and
packer cannot ring me up or send the 'lads' round !!

Have fun ............

Packing Sources Contents

  1.    Standard Trap #1 Loader

  2.    Ultraload II for v5.01 packer

  3.    Chunk loader

  4.    Lump loader

Look up the relevant section you are interested in, and follow the
instructions exactly.  I cannot be held responsible if you choose the
inappropriate loader for whatever it is you want to pack !!

One final note is that I have assumed that anyone who uses the packer
and these sources, will be packing games with it and possibly demos.
So to compromise on extra typing I have used the word 'game' throughout
this documentation instead of 'game/demo'.  I know that this may offend
some people and delight others - but due to the fact that I'm a lazy
shit, I don't really care !!

Before you start ....

If you are packing a game (in the official sense of the word - piracy),
the protection must of been removed.  Use an Empire or Replicants crack -
or any other type of crack where the files have NOT already been packed !!

Check ALL Replicants cracks for the usage of the 'Anti-Bitos' by Illegal.
Stay away from these loaders, unless you're a whizz at 68000, or you've
got plenty of common sense to look for the original cracked file-loader
with an Ultimate Ripper !!  To get past the Anti-Bitos, press SPACE to
exit the cracked intro, hit the reset button with the Ultimate Ripper
switched on, and then search memory for the original loader.  Once you
find the loader, add up the Text, Data, BSS & occasionally the Symbol
table lengths and save out the file.  Test that the loader works before
continuing !!

If you are doing a demo then please make sure that all the hidden files
have been 'un-hidden' and that no checks are made for sectors on your
packed disk.

| 1. Standard Trap #1 Loader |

Well this source has got to be the easiest to use but the least useful !!
It is very small in size (850 bytes max !!) and does the following job.

It latches on to the ST's GEMDOS vector ($84), and starts an interrupt
which will look at a data (not programs !!) files' header and check
for the existence of special marker (eg. 'AU5!').  If this marker is
found, then the routine will depack this file to the address that it was
originally loaded at.  Then it returns control to GEM for anything else.
The GEMDOS command that is intercepted (the ONLY one it intercepts) is
$3f (f_read), and if this command is not sent to GEMDOS, then the
packers' interrupt ignores it and lets GEMDOS handle it !!


1) Copy all the files to a blank disk - so that if everything cocks up,
   you've got a backup !!

2) Load up the packer and select 'Multi File Packer' option from the main
   menu.  Select the option to 'Multi Pack All' files, insert the disk
   with all the files on, sit back and read a book or go and watch a
   good film.  This all depends on how many files there are and how
   big they all are !!

3) Load up GENST2, and load the source code '3FONLY.S'.  This is the
   source required to install the new interrupt that will depack all the
   files from the game as they are loaded in - simple isn't it !!

4) You are now presented with 5 'conditional assembly' options.  Inserting
   yes/no as to your own personal preference - with the exception of
   'res84' which needs to be set to 'yes' if the game has a quit to desktop
   desktop option.  If the game is GEM-based then definitely set this
   option to 'yes' !!  For test purposes, set all the text and wait options
   to 'no'.  If the game is to be run from a menu, then you needn't bother
   with the low_res switch either.  As described above, the restore $84
   option is only required if the game has a quit option.  Finally, I suggest
   that you leave the flash option switched on, so that you know what is
   happening whilst the game loads !!

5) At the label 'execfile', enter the filename of the original loader
   program (the one you click on to run the game originally).

6) Assemble this source to the test disk.  Switch off, and run this
   program.  If everything is OK then a game should appear before you !!

7) Now go back to the source, switch on the text and waitkey options
   if you require.  Alter the text (don't forget to put 13,10 at the
   end of each new line !!) to say what a good job you've done and
   re-assemble your new loader !!  Give yourself a pat on the back if
   it was your first time (uh oh ..  sexual inneuendo time !!) .....

8) Problems ??  There are many problems associated with packing.  Simple
   ones are that the game opens a file, reads some bytes from that file
   and then closes it (eg. grabbing a palette from a picture file).

   Another known problem is when a game loads in a picture as a backdrop
   and loads another piece of picture data onto the screen - this causes
   untold corruption on the screen, and possibly undescribable crashes !!

   This game will have to use the Ultra501 loader, which contains a buffer
   option where files are depacked to, before control is handed back to

| 2. Ultraload II for v5.01 |

This is basically an enhanced version of the standard Trap #1 loader
described above, except that it intercepts a few more GEMDOS calls - as
well as $3f - to provide an easier way of dealing with the programs
that open & close a file, after grabbing a section that it wanted.  It
also contains a buffer area - the size is set according to your needs - 
for depacking data.

1) Follow the first two steps steps outlined in the Trap #1 loader above.
   You should now have a disk with some packed files belonging to the game
   on it !!

2) Before loading GENST2, examine the packed files and write down the 
   size of the largest file.  Load in the 'ULTRA501.S' file into the

3) The first thing you must alter is the 'buff_len' label.  This tells
   the depacker/loader how much memory to use for its' depacking buffer.
   Enter the file-size that you wrote down before.  If you are using
   hexadecimal, then don't forget to preceed the value with a '$' sign !!

4) Now follow steps 4 - 7 in the instructions for the standard TRAP #1
   loader.  All being well, your packed game should appear before you !!

5) As with the Trap #1 loader, problems do occur.  Even though this
   source is more advanced, certain games will not like the fact that
   only a few GEMDOS commands are intercepted, and through it's own
   failings, will attempt to grab some data from a middle of a packed
   file and find that the data it is depacking is useless junk.  This
   is where Chunk Packing comes into it's own, and for a full explanation
   of the chunk-packing/lump-packing methods, read the description below
   written by EGB (author of the v5.01 packer !), which was released as
   part of an article from Maggie 5.0.  I have added very little to the
   paragraph, except to enlighten a few parts.

| About Chunk/Lump Packing |

Chunk packing is only of use if you have a program which reads in data
files (especially of a random access type).  If you have a data file
of say 100K length, and the program you are packing only requires to
read the first 5K of this file, a normal depack routine (of the Trap #1
variety) would have to load in ALL 100K of the file, depack ALL 100K of
afore mentioned file, just to get at the 5K that it required !!

With the Chunk Packer, you can load your data in as low as 4k chunks, so
so that to get 5k back, you would only need to load and depack 8k instead
of the original 100k.  It is unlikely in the first case that the program
you are packing would have allowed you a file buffer of 100k in which to
load in this 5k, whereas with the chunk option, you only need a 4k buffer.

Lump packing is basically the same as chunk packing, but instead of leaving
say 100 files on the disk, which could be very small, and wasting disk
space due to unused cluster sectors.  You can join all of the files on the
disk together, then pack it as a chunk file.  When you load back from this
lump file, the game will ask for a certain file, the lump loader will
look inside the main lump file (or files), pick out which chunks to load (the
ones containing the required file) and depack it.  Using this method can save
you a lot of disk space.  If the disk has many small files, then you can get
greater pack results because instead of packing one small file at a time,
you can pack 20 or 30 small files at the same time, and get the benefits
of size reduction if some of the files have similar patterns (eg. map data).
It also uses much less directory space, and has no cluster wastage.  A file
which is 50 bytes in length wastes 984 bytes of disk space, because each
file takes up a minimum of 1 cluster, which is 1024 bytes long !!!

| 3. Chunk Packing |

Did you know that the lump packer source ('LUMP_501.S') also doubles as
as a chunk depacker routine ???  Well now you know that it does here's
how to access it !!

1) Copy all the data files to a blank disk.  

2) Multi-Chunk them on whatever size you require (but if you have files
   whose size is greater than a chunk option, do not use a larger chunk
   value - eg.  file size = 30000, DO NOT USE 64K chunk option !!).
   Do not - I repeat - do not use the Offset Pack option as it will not
   depack pictures properly.

3) Pack the original loader and place it onto your test disk.  You cannot
   chunk pack a program file (what would be the point ??), so use the
   Pack Program File option.

4) Alter the source code at the point where the options to turn the
   lump & chunk options on or off.  Swap the options around (so that
   lump is 'no' and chunk is 'yes' - lame-brain !!).

   Next alter the chunk size that you have packed your files with.  For the
   complete lamers, use this table !!

   Chunk Used           Value To Enter
   ----------           --------------

   4K                   4096
   8K                   8192
   16K                  16384
   32K                  32768
   64K                  65536

5) Assemble this chunk-depack loader to your test disk and .... test it !!!
   Once it works fully, alter the text etc. and reassemble the loader.

Whilst testing this source on Quartet v1.5, by Microdeal, I found that you
cannot Chunk Pack the '.4V' files, but you can pack the '.SET' files ??
Does anyone know why this happens ??

| 4. Lump-Packing |

In order to start Lump-Packing a game, you will need three things.

1) The original source of the game - please note that the word original
   is not meant as in 'original packaging etc.', but as in the files are all

2) Two blank disks.  The Joiner program still does not like hard-drives
   as it assumes that you want to lump from the default drive.  At least
   it doesn't bomb out like the earlier version did when a hard-drive
   was attatched !!

   The Joiner program will only take the files from the ROOT directory
   and no folders are scanned for files.  Remove obvious files like
   'DESKTOP.INF' and 'HISCORES.DAT' etc.  The first file is not needed unless
   your game is GEM-based, and the second is probably a read-write file
   and therefore shouldn't be placed in the lump-file.  Do not put any
   resource files on the lump disk, as these are loaded via the TRAP #2
   loader, and not via the TRAP #1.

   As a suggestion for the authors of the 'forthcoming GEM version', how
   about the use of file-selector and the option to use wild-cards when
   lumping a disk.  Something along the lines of ArcShell, where you can
   add/remove files ???  Just a small suggestion !!

Right, you're now ready to start Lumping.

1) Copy all the DATA files to one of your blank disks.  That is all the
   files except for the program file.  Please ensure that you understand
   my obvious descriptions for files that you SHOULDN'T include !!

2) Run the 'LUMPY.PRG' and insert the disk you've just prepared with all
   the files on it.  It is easier to run LUMPY.PRG from a set disk with
   all these source/program files on it, then to insert your disk with
   the files to be lumped on.  

   The joiner program will load in all the files on your disk, and then
   it will ask you to insert another disk (this is where your other blank
   comes into play).  It's best to use a blank formatted disk, but if you
   have enough room on the first disk, then use that one.

   The joiner program now wants a filename.  A new file containing all the
   previous multitudes of files will be saved to your disk - providing that
   no errors occur !!  DO NOT type in a folder name, as the input routine
   is only looking for a maximum of 11 characters !!  You can save the
   output file to a hard-drive, but you are still ONLY allowed to use 11
   characters (that includes the 'e:\' or whichever partition you are
   saving the lump file to !!).

3) Load up the Automation Packer v5.01, and pack the lumped file with the
   Chunk option using whichever compression type & chunk size you can be
   bothered waiting for - although credit where it's due, the packing 
   speed is a HELLUVA LOT better than Automation v2.51, so congratulations
   go to EGB for a well-worth-the-wait upgrade !!!

   As for the choice of chunk-size option, look at the original sizes of
   the files, and work out for yourself which chunk size is the best.

   For the complete idiots, who are totally lost by what they have
   just read, go and re-read the introductory explanation to see why you
   should be looking at the original file sizes !!

4) Now pack the executable program with a good packer.  It doesn't have to
   be the Automation Packer - so if you've got no patience and the program
   file is a big bastard then use any of the following (which you should
   be in possession of - if you're any good that is !!);

   JAM Packer v4.0 - the best on big files, but takes ages to depack
   Ice/Fire Packers - not as good as JAM, but faster depacking time
   Atomic v3.33 - again, not as good as JAM, but fast depack time

   Unlike the previous versions of the Lump Packer source, this version
   doesn't mind (for now ??) you packing the executable file with either
   the Ice/Fire Packer (Ice v2.31/Fire v2.01 !!).

5) Now to the source code.  This is pretty self-explanatory, but here goes
   anyway.  Load up GENST v2.20 (or later versions) and alter the filename
   under 'srch' to the filename of the large data file.  Alter the filename
   under 'gam' to the program file.  Alter the chunk size & the no. of files
   open to their required values.  The 'files open at once' value is best left
   at 10 if you are doing a game that loads in all the files and doesn't
   access the disk any further !!  And finally alter your message to
   'Joe Bloggs presents blah! blah!' etc.

6) Assemble the above source code to your second disk.  This disk should now
   contain your lumped file, your packed executable file and the assembled
   loader.  Run it and make sure it works - if it doesn't then go back to
   your source code and increase the 'files open at once' value.  If it
   still doesn't work, then remove obvious filenames like 'HISCORE' and
   'SAVEGAME' from the lump file.

   You will have to use a bit of common sense if you want succeed.  Don't
   forget that you will have to re-lump & re-pack the files - even if you
   remove the smallest hi-score table !!  A pain in the arse, but if you
   want to lump-pack, you'll have to persevere !!

7) Shove the (working) result onto your menu disk !!!

8) Release your menu.

9) This documentation MIGHT be updated, if and when, I ever get hold of
   the impending 'GEM-Version' of the Lump-Packer.  Who knows, you
   might even get some PROPER documentation by the authors, instead of
   my ramblings !!

| Hints on Lump Packing |

If, for example, you are doing a two-disk game, I suggest that you do both
disks as seperate lump files.  Once both files are packed, load up the
source file, and under the 'srch' label, enter the two filenames, one

Eg.   srch    dc.b    'disk_1.lmp',0,0,0,0,0,0
              dc.b    'disk_2.lmp',0,0,0,0,0,0
      endsrch dc.b    0

It is best to add a root-directory selector ('\') to the filenames above
unless you are putting the lump-files within a folder.  If so, then leave
them as the above examples.  Remember that when the game you have lumped
is looking for 'a:\example.bin', the lump routine is forcing the program
to look for 'example.bin' within the lump file - which is why you shouldn't
use folder names within your lump source code !!  If at all possible, examine
the original loader and alter all examples of 'a:\filename.ext' to the
more obvious 'filename.ext' and zero the other unused bytes out.

End Bit

Well I hope you found this document file easier to understand from
a laymens point of view instead of the clever bastards who wrote this
packer originally !!  

No doubt people are going to use these updated source codes on their
their own packs - now a little credit in your menus or your pack loaders
will suit me fine !!

See y'all

(c) I Wonder Who Wrote This Trash Industries - October 10th 1991

Back to Packer/Depacker