+----------------------------------------------+ | 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