Automation Packer
AUTOMATION 5.0.1 PACKER
~~~~~~~~~~~~~~~~~~~~~~~
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
shell.
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
size.
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 !!
Introduction
------------
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 !!
Instructions
------------
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
GEMDOS.
+---------------------------+
| 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
assembler.
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
unpacked.
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
below the other. DON'T FORGET THE EXTRA ZEROES TO PAD THE FILENAMES OUT
TO 16 CHARACTERS IN LENGTH.
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