ADP
<<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> <<<--- --->>> <<<--- >>> Auto-D-Pack 1.2 <<< --->>> <<<--- 03/11/95 --->>> <<<--- --->>> <<<--- --->>> <<<--- (C)oderigth : Kasar / PoSiTiViTy --->>> <<<--- GEM Interface : K-Woul / TNT --->>> <<<--- --->>> <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> Some words before starting : Excuse me for my poor english ! In the next paragraphs, the name Auto-D-Pack will be replaced very often by ADP, in order to optimize this ASCII file... <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> <<<--- ADP : What is it ? --->>> <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> ADP is a resident program which diverts the system-calls relative to the file loadings in order to depack every kind of data. ADP should (!) work on every Atari with 68000 to 68030 processor. It was tested on STE (2 Mb) and on Falcon 030 (4 Mb). <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> <<<--- Why ADP ?? --->>> <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> A long time ago, in a distant galaxy ... Hum no, sorry ! We start again : Some years ago, on our good Atari ST/F/E, several really pleasant packers appeared : Jek/Jam Packers, Automation Packer,Ice Packer, Atomik Packer, SpeedPacker, etc... Most of them were swapped with depack-routs in assembly language, and some of these routs were able to depack data automatically. Indeed, we put a little program in AUTO folder and from this moment, our favorite soundtracker was able to depack modules, something it was not able to do before. Then the Falcon 030 arrived. Because a lot of F030 owners were ST-users before, and because several packers still work on F030, some of them should have tried these little auto-depack-programs. And obviously, these programs don't work anymore, even without cache or every compatibility-program. I noticed myself the crashes and thought I would check why they were not working anymore one day. And shame on me : I don't check this problem for 2 years... until the day I received a lot of soundtrack modules. Among these modules, some were packed with Atomik 3.5, others with Ice 2.4, and others were unpacked. As a not so bad amount of space is gained when we pack modules, I thought I should keep them packed. But problem : how to read them ? According to the modules-players or soundtrackers, all the packers are not depacked. One player will depack the Ice, another will d‚pack the Atomik... And very few players/soundtrackers depack the SpeedPacker 3, the best module packer... At this moment, I decided to react. And after some thought, I start coding Auto-D-Pack. I took some old auto-depack-routs and I tried to understand why they crashed on F030. I solved quickly the problem and I coded an auto-data-depacker which was able to depack the Atomik 3.5, Ice 2.4 and Speedpacker 3. But I thought I had to do better : being able to depack the files which are read gradually, and trying to activate the depack-routs only on precise programs, like XPK on Amiga... And after some hard-coding days, I think I have reached my objectives. The result of my hard work is in your hands. <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> <<<--- ADP's characteristics --->>> <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> * ADP needs very few memory (5 to 10 Kb). * ADP depacks Ice 2.4, Atomik 3.5 and SpeedPacker 3 data-files. * ADP can depack the packer(s) you want... * ADP can depack in memory, or on Disk thanks to a temporary file, and in this way it can depack the files not read totally. * ADP gives to programs the original size of packed files to avoid any bad memory reservation. * ADP can reserve some memory when it is started, in order to use it to depack files even when a program keeps the whole memory. * ADP can be easily (des)activated because it installs a cookie. * Last (but not least!), ADP can make efficient its auto-depack system only on precise programs (defined by the user). Of course, these programs are not altered. <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> <<<--- Use of ADP --->>> <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> When you execute A-D-P.PRG, a window appears and allows you to configurate ADP. * Under 'Depack', click on the buttons correspondent to the depack-routs that ADP will use. * The 'Depack ALL prgs' button, when activated, can make ADP always efficient (on any programs). In this mode, a Popup appears and allows you to choose the depack-method : 'In Memory' or 'On DisK' depending on the files-loading-mode used by the programs. * The 'Use Buffer' button allows ADP to make a memory reservation when it is executed. If this button is activated, choose the size of this buffer (equal to the original/depack size of your biggest packed file). * The 'Choose Temporary File Path' button allows you to choose the path of the temporary file that ADP will use. The 2 buttons under 'Personal Depack' must be used only if the 'Depack ALL prgs' is not activated. * The 'Add Executable' button allows you to choose the programs on which ADP will be efficient. Choose the wanted program and its depack-mode : 'Memory' or 'Disk' depending on the files-loading-mode used by this program. * The 'Modify Executable' button opens a window showing all the programs on which ADP will be efficient. Use Up/Down arrows to scroll the program names. Click on a program name to modify it. Click on 'Delete' to delete a program. Use the Popup under 'Depack' to change the depack-mode applied to the program. * The 'Desactivate' or 'Activate' button allow you to (des)activate ADP. * The 'Generate' button allow you to create the resident program AUTODPCK.PRG. Put it in the AUTO folder if you want or just execute it. It's of course this program, containing the auto-depack-routs, which must be executed in order to make your programs able to load packed files. * Click under 'EXECUTABLE GENERATION PATH' to choose the path where you want to create the resident program AUTODPCK.PRG. <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> <<<--- Use advices --->>> <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> When you want a program to be able to auto-depack the files it is going to load, if you know it loads them totally, choose the depack-mode 'In Memory'. If you know it loads the files gradually, choose the depack-mode 'On Disk'. If you know it needs the whole memory, use a buffer whose size is equal to the original size of the biggest packed file. If you don't know the files-loading-mode of a program, choose the depack- mode 'In Memory' because it is the fastest one and 'coz it needs few memory. If the program loads the files without depacking them or if you encounter crashes, choose then the depack-mode 'On Disk'. If the program still doesn't depack the files, use a buffer whose size is equal to the orginal size of the biggest packed file. If there's still a problem, contact me !!! No, in fact there shouldn't be any problem. Except maybe if you use a buffer whose size is really important, because in this case, the program wouldn't have enough memory to work properly. If you want to pack data like ASCII, sounds, MOD, S3M, MTM, GTK, DGT, MGT... modules, TGA, XGA, IMG, IFF, FLI, FLC... pictures, use Speedpacker 3 without optimisation, except for : * for the big sound samples, use SpeedPacker 3 with the Seq2 option. * for the little soundtrack modules of all kinds (MOD, S3M, MTM, GTK, DGT, MGT...), use SpeedPacker 3 with the Seq2 option or Atomik 3.5. As you probably noticed, SpeedPacker 3 is often better than Atomik 3.5 (which is better than Ice 2.4). For example, I packed more than 100 modules of any kinds, and only 4 of them were better packed with Atomik 3.5. The size difference with SpeedPacker 3 was really minimal (about 100 bytes). But, the biggest the modules are, the most important the gaps between Atomik 3.5 and SpeedPacker 3 are (sometimes about 10 Kb in favour to SpeedPacker 3). So pack your modules with SpeedPacker 3, and forget the other packers ! After all my packing tests, I noticed that : * Ice 2.4 is the less powerfull, but it is fast and isn't problematic with executables. * Atomik 3.5 is the slowest, and sometimes the more powerfull. But, it causes sometimes crashes with some executables. * Speedpacker 3 is really often the most powerfull and it is the faster ! But, it doesn't work on Falcon when packing executables because it needs a program called AUTO_SP3.PRG (to be put in AUTO) which doesn't work. According to this, SpeedPacker 3 is not really clean despite its qualities (writing in $380, protection/crypter ...). New : I have just found a program called SP3_PROG.PRG which converts a SpeedPacker 3 data-file to an executable and it's running on Falcon ! <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> <<<--- Bonus !!! --->>> <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> You probably think : "Ok it's better packing with SpeedPacker 3, but it doesn't work very well on Falcon, so how can I do ???". You're right, SpeedPacker 3 is protected and we can't use it on Falcon without desactivating the cache. This is not very practical. But, I have a surprise for you... I give you SpeedPacker 3 whose I removed the 'little' protection. --> you don't need to desactivate the cache to use SpeePacker 3 ! Nice, isn't it ? But warning ! Only use Speedpacker 3 to pack data-files, because I noticed some bugs when depacking... And I give you the Ice 2.4, Atomik 3.5 and Atomik 3.5+ (Falcon patch by DMViolator) with of course the depack-routs source-codes and also New Depack 1.1 ... <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> <<<--- Unavoidable troubles --->>> <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> * When depacking 'On Disk', ADP uses only one temporary file. So, a program loading several files at the same time won't work properly. * When diverting the FsFirst and FsNext Gemdos fonctions, the search directory is saved in a 173 bytes buffer. This allows ADP to reach at the most 14 directories/sub-directories. I refer to the Desktop limit which I think it's satisfactory enough. * Diverting the fsFirst and Fsnext Gemdos Fonctions to test the packed files prolongs the directories read duration. So try to desactivate the 'Depack ALL prgs' option, because when it is desactivated, only the programs on which ADP is efficient will be slow- downed when they will read directories. * When using the 'On Disk' depack-mode, the file-accesses are slow-downed (because packed file test then depacking then saving in temporary file). * In 'Personal depack' mode, ADP can only handle 30 successives Pexec, which seems to be enough. This means that 30 programs can be executed the ones after the others. * In 'Personal depack' mode, on TOS < 1.4 computers, 112 bytes are lost after a program is executed (Pexec 6 wasn't born !). <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> <<<--- Further informations --->>> <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> ADP was conceived in order to be able to manage any depack-routs, choosen by the user. This saves memory, and the addition of new depack-routs is really easy and quick. If you want more depack-routs, contact me ! ADP diverts the Fsfirst/Fsnext Gemdos fonctions in order to force the system to give the orginal size of a packed data (the original size of the file is returned in the DTA buffer, instead of the size of the packed file). This is very important because a lot of programs reserve a memory space equal to the file size they are going to load. If this size would be the one of the packed file, the 'In Memory' depack- mode should provide crashes very often. ADP can depack in memory. When a file is loaded (Fread Gemdos fonction), ADP tests the file header to know if it is packed. If yes, no memory reservation is made and ADP depacks the file where it was loaded. ADP offers the possibiliy to depack a file on Disk, in order to depack the files which are read gradually (Fseek Gemdos fonction!!). In this case, when a file is opened by a program (Fopen Gemdos fonction), ADP tests the file to know if it is packed. If yes, ADP reserves some memory and depacks it, then saves it in a temporary file and returns the handle of this temporary file to the program. Some programs keep the whole available memory. In this case, ADP can't reserve some space to depack data and to save them in a temporary file. To solve this problem, ADP can reserve some memory when it is executed and it can use this space later, even if a program don't free any memory. ADP can activate its depack-routs only on precise programs. For that, ADP diverts the Pexec Gemdos fonction and tests at every program execution if this program is part of those which are allowed to depack. The test concerns the Text, Data and Bss sections sizes, and on a part of the Text section. ADP installs a cookie when it is executed. The identifier cookie is 'ADP!'. The cookie value is an adress of the ADP (des)activating variable. This variable is a byte whose value is 0($00) or -1($ff). -1 activates ADP et 0 desactivates ADP. ADP was tested with total success on the following programs : Falcplay 1.6, Digital Tracker Demo, Graoumf Tracker 0.7311, MegaTracker 0.94b, Studio Photo Demo, Contrast 1.2, Shower 1.0, ApxTGA 3.0, ApxFLC 3.0, Backtrack 4.01. Programs configurations : * Falcplay 1.6 -> Depack In Memory. * Digital Tracker Demo -> Depack On Disk + Use Buffer. * Graoumf Tracker 0.7311 -> Depack On Disk + Use Buffer. * MegaTracker 0.94b -> Depack In Memory. * Studio Photo Demo -> Depack On Disk. * Contrast 1.2 -> Depack On Disk + Use Buffer. * Shower 1.0 -> Depack In Memory. * ApxTGA 3.0 -> Depack On Disk. * ApxFLC 3.0 -> Depack On Disk. * Backtrack 4.01 -> Depack On Disk. <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> <<<--- Next version --->>> <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> If this version has success, the next one will permit : * to depack the Amiga PowerPacker 2.0. * to depack any other packer you think it is essential. Send me if possible the depack-routs, because I don't possess all ones ! (I have all the ones of the Professional Mega Ripper of course) * to have several temporary files for the 'On Disk' depack-mode. * to do something you will suggest to me... <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> <<<--- The End --->>> <<<---------------------------------------------------------------------->>> <<<---------------------------------------------------------------------->>> ADP is shareware. If you want the complete version, send me : * 60 French Francs or equivalent in Dollars/DeutchMarks/Pounds. or * 15 HD new disks You can get in touch with me for any other reason (suggestions, swap, musical swap...) (Kasar / Positivity) Ludovic BEVAND 228 Chemin de Gerbassier 74330 POISY FRANCE Internet e-mail : lbevand@cur-archamps.fr Please, think about sending me some money if you often use ADP. If you consider the amount is to big, instead of not sending anything, send me a little donation ! In opposite, you can send some (or a lot!) more than the wanted amount... You are free to think about the shareware merit... If you want to contact with K-Woul ,for example, to congratulate him for his marvelous GEM interface , or to get his last 'C'est Quoi Donc ?' or 'The Filler' versions (send 1 disk + stamps/IRC), write to : (K-Woul / TNT) R‚mi VANEL 15 Rue de la DonziŠre 74600 SEYNOD FRANCE Hello : Silver Eagle, Captain Schmurtz, Dracula, Stelex, Anneli, Spearhead, Kelvin St Mixes, Nikom, Dump, Exocet, old Replicants/Fuzion/Vmax members TNT (Kwoul, The Ace, Alexandre & Alexandre), Michel le fleuriste, Supernova Bliss, DMViolator, Rboy, Dumbo, Axel Follet, Baloub, Jack/Tbs, Fast Easy, Altair, Corewar, Laurenzo, Martin Lethaus, Pascal Delanef, Serge Jougleux, Dnt-Crew (Nullos), Fatal Design (Simplet, Skynet, Haltero), Adrenaline (Dr Computer), EKO (Maxx-Out 'foir‚!, Major-X, Createur), MJJ-Prod, Megabusters (Imperator), Dune, Faucontact, Hemoroids, Binaris And all I have forgotten ... sorry ! Respect : Axe, The Firehawks (sorry for the protec!), Crac, Marc Bourlon Avena, Aura, Agression, Lazer, Independent, Griff, Sanity, Digital Chaos, Inter, Light, Mugwumps, New Trend, NPG, Sentry Brainstorm (Assemble+Adebug : yeah!), Black Scorpion (Apex : great!) No Respect/Fuck : TT-Axel's. Jacques Chirac : stop those stupid nuclear testings ... Most of French people don't agree with your attitude. Musical inspiration during ADP coding : Nine Inch Nails, Front 242, Ministry, Aphex Twin, The Orb, William Orbit, Orbital, LFO, 808 State, ScanX, Laurent Garnier, WinX, HardFloor, Prodigy, Bjork, Massive Attack, Neneh Cherry, Bomb The Bass, Depeche Mode, ... Electronic Music is Good For You !!! Kasar / Positivity 21/09/95
Back to Packer/Depacker