>Wongck at 12:28, 12 October 2011

2011-10-12T12:28:01Z

← Older revision		Revision as of 08:28, 12 October 2011
Line 434:		Line 434:
	Back to [[Packer/Depacker]]		Back to [[Packer/Depacker]]
	[[Category:Compression Software]]		[[Category:Compression Software]]
	~~[[Category:Atari ST software]]~~

>Silver Surfer: clean up

2009-05-03T10:29:55Z

clean up

← Older revision		Revision as of 06:29, 3 May 2009
Line 430:		Line 430:
	21/09/95		21/09/95
	</pre>		</pre>
	~~<br><br>~~

	Back to [[Packer/Depacker]]		Back to [[Packer/Depacker]]
	[[Category:Compression Software]]		[[Category:Compression Software]]
			[[Category:Atari ST software]]

>Silver Surfer: Added category

2009-05-02T19:44:05Z

Added category

← Older revision		Revision as of 15:44, 2 May 2009
Line 432:		Line 432:
	<br><br>		<br><br>
	Back to [[Packer/Depacker]]		Back to [[Packer/Depacker]]
			[[Category:Compression Software]]

>Zorro 2 at 14:32, 31 October 2006

2006-10-31T14:32:49Z

New page

<pre>
<<<---------------------------------------------------------------------->>>
<<<---------------------------------------------------------------------->>>
<<<--- --->>>
<<<--- >>> 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
</pre>
<br><br>
Back to [[Packer/Depacker]]

ADP - Revision history

>Wongck at 12:28, 12 October 2011

>Silver Surfer: clean up

>Silver Surfer: Added category

>Zorro 2 at 14:32, 31 October 2006