cruncher/packer?
Rune Elvemo
I am currently looking for a good cruncher/packer for demo coding etc.
Anything you people could recommend?
---
Rune Elvemo
elv...@sn.no
http://www.sn.no/~elvemo
Nameless
>I am currently looking for a good cruncher/packer for demo coding etc.
>Anything you people could recommend?
XPK, so the user can use the packer of his choice.
--
This excellent message was brought to you at 16-Sep-96 13:47:48 by
Name...@ask.himolde.no <> Nameless @ IRC <> http://www.himolde.no/~espen
=============================================================================
A friend with weed is a friend indeed.
Haavard Pedersen
Rune Elvemo wrote:
> I am currently looking for a good cruncher/packer for demo coding etc.
CrunchMania is the best. It packs terrific and unpacks fairly fast. It
also has all the options your heart could desire.
-- =
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/H=E5vard Pedersen aka Howard / Mental Diseases, comp. science student._=
/
_/ URL: http://www.cs.uit.no/~haavardp IRC: Howard_MD in #amiga _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Michel Vissers
In a message of 16 Sep 96 Rune Elvemo wrote to All:
RE> I am currently looking for a good cruncher/packer for demo coding etc.
RE> Anything you people could recommend?
stonepacker...erm...tetra (with a few modifications), titan
I think you should go for the first one, however consider first if you
really need a packer.
Ja!
Michel
__________________________ ________________________________________
/ /\ / /\
/ Michel Vissers / // Home base #2 of Oranda no Manga !!! / /
/ mic...@hell.xs4all.nl / // Mail 4 info or anime related stuff. / /
/_________________________/ //_______________________________________/ /
\_________________________\/ \_______________________________________\/
-- Via Xenolink 1.984, XenolinkUUCP 1.1
John van Alphen
elv...@sn.no (Rune Elvemo) wrote:
>I am currently looking for a good cruncher/packer for demo coding etc.
>Anything you people could recommend?
StoneCracker v4.10 definitely !! It's the fastest i know and it has
some of the best compression rates...
So if you're going for speed (important with demos) you got to find
STC...
John van Alphen
Email: FiSta...@NeuroKNF.Medfac.LeidenUniv.nl
Yannick Vansevenant
Rune Elvemo wrote:
>
> I am currently looking for a good cruncher/packer for demo coding etc.
>
> Anything you people could recommend?
Well to really compress very good and decompress fast use StoneCracker
for data, even for executables when writing small demos ( the decrunch
buffer memory must also be available before your demo runs ).
If you write really big demos that must run on 2mb chip A1200's for
example, you should use the Titanics cruncher, that uses a very small
decompression buffer and decrunches while loading and not after loading.
Greetings !
--
>>> yannick_v...@EDC.MENTORG.COM <<<
Markus Schmall
elv...@sn.no (Rune Elvemo) benutze seine Tastatur am 16.09.1996 um 07:56:59 Uhr, um
folgenden Text unter dem Betreff "cruncher/packer?" zu erzeugen:
> I am currently looking for a good cruncher/packer for demo coding etc.
>
> Anything you people could recommend?
CrunchMania is an excellent packer. It`s available on aminet (util/pack). A 68060
compatible decrunchcode for the LZ huffman mode will be available within one
week.
Greets
M.Schmall
Fabio Bizzetti
John van Alphen (FiSta...@NeuroKNF.MedFac.Leidenuniv.nl) wrote:
>elv...@sn.no (Rune Elvemo) wrote:
>>I am currently looking for a good cruncher/packer for demo coding etc.
>>Anything you people could recommend?
>StoneCracker v4.10 definitely !! It's the fastest i know and it has
>some of the best compression rates...
>So if you're going for speed (important with demos) you got to find
>STC...
Have you tried CrunchMania? Last time I checked it vs StoneCracker the
last was worse (at least as crunching ratio), so at least for intros
I would certainly recommend the newest CRM (CrunchMania).
BTW: does anybody have a LZH crunched/decruncher ANSI C source?
TIA
---------------------------------------
Fabio Bizzetti - bizz...@mbox.vol.it
Pablo dÔAngelo
M.SC...@LDB.han.de (Markus Schmall) wrote:
> CrunchMania is an excellent packer. It`s available on aminet (util/pack). A 68060
> compatible decrunchcode for the LZ huffman mode will be available within one
> week.
Really? If you have the code/source please mail it to me!
>
> Greets
>
> M.Schmall
>
ciao
Pablo / Retire ^ LSD | pa...@ag-trek.rhein-ruhr.de | coder!=)0d3r
Mats Magnusson
In a message of 19 Sep 96 FiSta...@NeuroKNF.MedFac.Leidenuniv.nl (John van
Alphen) wrote:
JvA> elv...@sn.no (Rune Elvemo) wrote:
>> I am currently looking for a good cruncher/packer for demo coding etc.
>> Anything you people could recommend?
JvA> StoneCracker v4.10 definitely !! It's the fastest i know and it has
JvA> some of the best compression rates...
JvA> So if you're going for speed (important with demos) you got to find
JvA> STC...
No! Don't use it! It's not that hard to code so the program i relocateable, and
then, use powerpacker.
The reason why many old demos fail if you don't make special precautions, is
the bad crunchers that decrunch to fixed adresses (stonecracker for example).
They might have been usable in the 80's when almost everyone had the same
configuration (1.2 or 1.3, 512k chip 512k fast, bare 68000, one extra diskdrive
and no harddisk). However, on a chipram-only A1200 all theese demos fail even
when you have 2Mb instead of the old total 1Mb. The reason is that those demos
decrunc to absoulte adress $20000 or so, and as the machine only has chipram,
important system structures are located there, so the result is a system-crash.
After all, you want your demo to _work_, or ? ;) Use Powerpacker, or if you
don't have powerpacker, use the old titanicscruncher or maybe just pack the
stuff with LHA. Today, most of us have temporary space for the uncrunched
file...
/Mats Magnusson, ma...@plea.se
K-P Koljonen
>After all, you want your demo to _work_, or ? ;) Use Powerpacker, or if you
>don't have powerpacker, use the old titanicscruncher or maybe just pack the
>stuff with LHA. Today, most of us have temporary space for the uncrunched
>file...
>/Mats Magnusson, ma...@plea.se
PowerPacker is inferior to Imploder. Imploder has better compression ratio
and faster decrunch routine. Also it only uses 1.5 x (decrunched data
length) memory when decrunching. PowerPacker uses 2 x.
--
+---------------------------------------------+
| K-P Koljonen / Hippopotamus Design / iNSANE |
| k...@kalahari.ton.tut.fi k...@pcuf.fi |
| http://kalahari.ton.tut.fi/~k-p K-P@IRC |
+---------------------------------------------+
Jouni Korhonen
Mats Magnusson <ma...@plea.se> wrote:
: In a message of 19 Sep 96 FiSta...@NeuroKNF.MedFac.Leidenuniv.nl (John van
: Alphen) wrote:
: JvA> elv...@sn.no (Rune Elvemo) wrote:
: >> I am currently looking for a good cruncher/packer for demo coding etc.
: >> Anything you people could recommend?
: JvA> StoneCracker v4.10 definitely !! It's the fastest i know and it has
: JvA> some of the best compression rates...
: JvA> So if you're going for speed (important with demos) you got to find
: JvA> STC...
: No! Don't use it! It's not that hard to code so the program i relocateable, and
: then, use powerpacker.
: The reason why many old demos fail if you don't make special precautions, is
: the bad crunchers that decrunch to fixed adresses (stonecracker for example).
Heh.. StoneCracker does allow compressing _relocatable_ executables and
also allows fixed addresses. Up to user which one to use..
In my opinion these exe packers/crunchers are useless, the idea and
working principle is, though, interesting. I for example don't have a
single packed exe in my HDD (excluding those few intros/demos I have
there). XPK is another issue.. Like many other packers/crunchers
StoneCracker was intended into the demo/cracker scene (ja suutari
pysyköön lestissään). And who cares if old demos fail?
--
// www.cs.helsinki.fi/~jikorhon/ - Dept. of Computer Science
\X/ a3k/plus needed - Dead Coders Society
Jyrki O Saarinen
: No! Don't use it! It's not that hard to code so the program i relocateable, and
: then, use powerpacker.
: The reason why many old demos fail if you don't make special precautions, is
: the bad crunchers that decrunch to fixed adresses (stonecracker for example).
: They might have been usable in the 80's when almost everyone had the same
: configuration (1.2 or 1.3, 512k chip 512k fast, bare 68000, one extra diskdrive
: and no harddisk). However, on a chipram-only A1200 all theese demos fail even
: when you have 2Mb instead of the old total 1Mb. The reason is that those demos
: decrunc to absoulte adress $20000 or so, and as the machine only has chipram,
: important system structures are located there, so the result is a system-crash.
: After all, you want your demo to _work_, or ? ;) Use Powerpacker, or if you
: don't have powerpacker, use the old titanicscruncher or maybe just pack the
: stuff with LHA. Today, most of us have temporary space for the uncrunched
: file...
. You dont have to use absolute crap with STC .. ;)
Martin Kalms
Mats Magnusson (ma...@plea.se) wrote:
: In a message of 19 Sep 96 FiSta...@NeuroKNF.MedFac.Leidenuniv.nl (John van
: Alphen) wrote:
: JvA> elv...@sn.no (Rune Elvemo) wrote:
: >> I am currently looking for a good cruncher/packer for demo coding etc.
: >> Anything you people could recommend?
: JvA> StoneCracker v4.10 definitely !! It's the fastest i know and it has
: JvA> some of the best compression rates...
: No! Don't use it! It's not that hard to code so the program i relocateable, and
: then, use powerpacker.
It's time for you to give STC v4 a second look, I think :)
It supports three formats: Reloc Executable, Data and Absolute.
^^^^^
it DOES have this, yes...
If you've already seen STC v4 I think you misunderstood the gadgets: The
contents of "decr addr" and such string gadgets is only used when type is set
to Absolute.
I use it. It works good (although the cruncher crashes if it runs out of mem,
but that error only pertains to the STC.EXE decruncher (the stub-decruncher
doesn't)), it is faster and gives better results than PP, it works on
040/060...
As I don't have time to spend on writing and optimizing a cruncher of my own,
I'll continue using my favourite cruncher!
///Mikael Kalms
Pablo dÔAngelo
ma...@plea.se (Mats Magnusson) wrote:
> In a message of 19 Sep 96 FiSta...@NeuroKNF.MedFac.Leidenuniv.nl (John van
> Alphen) wrote:
>
> JvA> elv...@sn.no (Rune Elvemo) wrote:
>
> >> I am currently looking for a good cruncher/packer for demo coding etc.
>
> >> Anything you people could recommend?
>
>
> JvA> StoneCracker v4.10 definitely !! It's the fastest i know and it has
> JvA> some of the best compression rates...
> JvA> So if you're going for speed (important with demos) you got to find
> JvA> STC...
>
> No! Don't use it! It's not that hard to code so the program i relocateable, and
> then, use powerpacker.
>
> The reason why many old demos fail if you don't make special precautions, is
> the bad crunchers that decrunch to fixed adresses (stonecracker for example).
Ehhm, only if you want to. If you crunch your Prog with the
"Executable" Filetype nothing is bad, and guess, this is the default
setting! Then your Programms relocates properly.
>
> /Mats Magnusson, ma...@plea.se
Haavard Pedersen
Mats Magnusson wrote:
> JvA> StoneCracker v4.10 definitely !! It's the fastest i know and it h=
as
> JvA> some of the best compression rates...
nd
> JvA> STC...
> =
> No! Don't use it! It's not that hard to code so the program i relocatea=
ble, and
> then, use powerpacker.
Which version of StoneTracker are you refering to? V1.0?!?!?!
StoneCracker v4.10 packs relocatable files without any problems, just as
smoothly as PP and TitanicCruncher. I've been using it on my A1230 50MHz
w/20 meg fast for ages without problems.
John Girvin
On the subject of StoneCracker vs. CrunchMania:
StC compresses and decompresses faster, but CrM gets better compression
ratios. I use StC to crunch most of the exe's on my HD, and CrM to crunch
any data files (gfx, samples etc.) that my program loads.
Thats my 0.00000000000002!
BTW, any news on the new version of CrM that was supposed to be coming?
/John.
__________________________________________________________________________
|00 John Girvin: developing software for Unibol Inc., speaking for myself|
|\/jgi...@bfs.unibol.com | Amiga,!PC,net,SciFi,MTB,TaiJutsu,house,techno|
|gi...@girvnet.demon.co.uk | Youll never take me alive, Macro$loth fiends!|
\A1200/030-40/10M/3.0 A500/000-7/2M/2.04 464/Z80-4/0.0625M/1.0 Team AMIGA/
John van Alphen
> JvA> StoneCracker v4.10 definitely !! It's the fastest i know and it has
> JvA> some of the best compression rates...
> JvA> STC...
>No! Don't use it! It's not that hard to code so the program i relocateable, and
>then, use powerpacker.
Why ???? Powerpacker is old and obsolete... It WAS the best when Nico
Francois released it, but now.... Nop...
>The reason why many old demos fail if you don't make special precautions, is
>the bad crunchers that decrunch to fixed adresses (stonecracker for example).
Not...
>They might have been usable in the 80's when almost everyone had the same
>configuration (1.2 or 1.3, 512k chip 512k fast, bare 68000, one extra diskdrive
>and no harddisk). However, on a chipram-only A1200 all theese demos fail even
>when you have 2Mb instead of the old total 1Mb. The reason is that those demos
>decrunc to absoulte adress $20000 or so, and as the machine only has chipram,
>important system structures are located there, so the result is a system-crash.
That is correct, but newer versions of Stonecracker also support
Relocatable code, as well as fixed addresses... (Check aminet in
/util/pack/)
>After all, you want your demo to _work_, or ? ;) Use Powerpacker, or if you
>don't have powerpacker, use the old titanicscruncher or maybe just pack the
>stuff with LHA. Today, most of us have temporary space for the uncrunched
>file...
Titanics is also a nice cruncher... (It decrunches while loading), but
this is only usefull for executables.. If you want to use external
datafiles (common with larger demos), I still recommend StoneCracker..
Grtz,
John van Alphen
Martin Kalms
John Girvin (jgi...@bfs.Unibol.COM) wrote:
: On the subject of StoneCracker vs. CrunchMania:
: StC compresses and decompresses faster, but CrM gets better compression
: ratios. I use StC to crunch most of the exe's on my HD, and CrM to crunch
: any data files (gfx, samples etc.) that my program loads.
ok, just remember NOT to use CrM for executables, as the stub-exe-depacker
hangs on 060 (not 040 I think). Probably a missing CacheClearU() call :/
///Mikael Kalms
Jyrki O Saarinen
: Titanics is also a nice cruncher... (It decrunches while loading), but
: this is only usefull for executables.. If you want to use external
: datafiles (common with larger demos), I still recommend StoneCracker..
Titanics ISN'T a nice cruncher, it is very slow and very inefficient.
Jyrki O Saarinen
: ok, just remember NOT to use CrM for executables, as the stub-exe-depacker
: hangs on 060 (not 040 I think). Probably a missing CacheClearU() call :/
It does that with 040 - bigger caches problem I guess.
--
Jyrki Saarinen - (09)8058003 - University of Helsinki, Computer Science
Mats Magnusson
In a message of 02 Oct 96 FiSta...@neuroknf.azl.nl (John van Alphen) wrote:
>> JvA> StoneCracker v4.10 definitely !! It's the fastest i know and it has
>> JvA> some of the best compression rates...
>> JvA> So if you're going for speed (important with demos) you got to find
>> JvA> STC...
>> No! Don't use it! It's not that hard to code so the program i
>> relocateable, and
>> then, use powerpacker.
JvA> Why ???? Powerpacker is old and obsolete... It WAS the best when Nico
JvA> Francois released it, but now.... Nop...
Ok...
>> The reason why many old demos fail if you don't make special precautions,
>> is
>> the bad crunchers that decrunch to fixed adresses (stonecracker for
>> example).
JvA> That is correct, but newer versions of Stonecracker also support
JvA> Relocatable code, as well as fixed addresses... (Check aminet in
JvA> /util/pack/)
Well, sorry all guy's, i wasn't aware of anything above STC 3.00. When i saw
powerpacker, i just threw STC in the garbage, sort of.
>> After all, you want your demo to _work_, or ? ;) Use Powerpacker, or if
>> you
>> don't have powerpacker, use the old titanicscruncher or maybe just pack
>> the
>> stuff with LHA. Today, most of us have temporary space for the uncrunched
>> file...
JvA> Titanics is also a nice cruncher... (It decrunches while loading), but
JvA> this is only usefull for executables.. If you want to use external
JvA> datafiles (common with larger demos), I still recommend StoneCracker..
Well, bad thing of titanics is the compression, atleast compared to LHA it's
really bad, and also it takes really long time to crunch in Titanics.
However the 'while loading' decrunching is really a good idea, as it both saves
memory, and also speeds up things when you have slow i/o (floppy).
Well, the thing you say about data files, that's just a effect of bad
dos.library documentation. All the stuff you have in the data file could be in
a few overlay hunks, and also the different parts of the demo could be.
However, then you would need a cruncher that has it's decruncher implemented as
a link library that you could call and the lib functions itself would load the
requested overlay hunk into memory. AFAIK overlay's can be used for both data
and code, and also AFAIK the only well-known programs that use it is old
versions of DeluxePaint, and Titanics cruncher...
Anyway, someone stated "who cares if old demo's doesn't work"... Atleast I do,
for nostalgic reasons. Just a short while ago, i dissassembled the boot-sector
of an old trackloaded demo that only worked on kick1.2, and found out at what
abosulte adresses and disk locations all demo parts should be loaded, then i
did load those parts with a small hack i did, and saved them as files. Finally
i wrote a 'loader' that loades each part into memory and executes it. I also
had to write a 'memeat' utility that i had to put at the beginning of
startup-sequency, so i could be sure that the abosulte memory used by the demo
parts wasn't in use by the system. Then it was only to run the whole thing with
degrader... ;) B.T.W., the i wrote the 'loader' in C, and i had to declare the
demoparts rather nice to be shure that the compiler put all registers on the
stack before calling the demo parts, but it worked ;) ;)
/Mats Magnusson, ma...@plea.se
Jouni Korhonen
Mats Magnusson <ma...@plea.se> wrote:
: Well, the thing you say about data files, that's just a effect of bad
: dos.library documentation. All the stuff you have in the data file could be in
: a few overlay hunks, and also the different parts of the demo could be.
As all hunk stuff for object files is documented 'lightly' in RMKs. But
all that stuff is in Guru-Book. Anyone have a spare?? ;)
: requested overlay hunk into memory. AFAIK overlay's can be used for both data
: and code, and also AFAIK the only well-known programs that use it is old
: versions of DeluxePaint, and Titanics cruncher...
And Cube-O-Matic that has Buddha's own overlay decruncher..
: Anyway, someone stated "who cares if old demo's doesn't work"... Atleast I do,
: for nostalgic reasons. Just a short while ago, i dissassembled the boot-sector
Nostalgia.. yes I know. When I upgraded to ECS a2000 with a 030 and 3.1.
I checked all ~400-500 disks containing filedemos/intros and ~200 disks
of megademos I had collected during -88-92. At the end I had ~50 disks
of filedemos/intros that I remembered to be somehow worth keeping and if
needed were reworked to work in my setup (like some old Fairlight/Megaforce
demos that depend on 1.2/1.3 kick and PAL 7.14HMz code/timings are pain to
get work even somehow on 030 & 3.1 & ECS..) Well after few megademos I
gave up. This about a month project made me finally dislike democoding ;)
Then a bit later I switched to a3000 and most of those 'reworked' demos
blew up b'cos of a bit faster chipmem access and I thought I better buy a
cheap used a500 if I need to watch those demos.. The two most important
still work: Thrust's Ottifanten and Knight Hawk's Mordillo intro.
Conclution: no lesson learned ;)
--
// www.cs.helsinki.fi/~jikorhon/ - Dept. of Computer Science
\X/ a3k/plus needed - Dead Coders Society
All wars are civil wars, because all men are brothers ... Each one owes
infinitely more to the human race than to the particular country in
which he was born.
-- Francois Fenelon
Yannick Vansevenant
Read the message, it decrunches while loading, meaning that you can run
a demo of 1.8MB on a 2MB machine and still crunch it ... This is not
possible with ANY other cruncher, as far as I know ...
Greetz !
--
>>> yannick_v...@EDC.MENTORG.COM <<<
John Girvin
[Titanics Cruncher decrunches while loading...]
:)
Does the XPK LoadSeg patch 'xloadseg' decrunch while loading? Im fairly
sure it does, but Ive never confirmed it. I suppose it depends on whether
or not the sublibrary supports streamed decompression.
What I have done is load a bigish exe (900K uncompressed) into a 1Mb
A500 using xloadseg...so it looks as if it might decrunch while loading.
I used the NUKE sublibrary for that.
Of course, with xloadseg you have the disadvantage that you have to
spread the patch/xpk(master|sub).library with your program.
How does Titanics work? Does it crunch the file in blocks eg: 20K ?
If so, then that could explain the crap compression rates.
Stefan Boberg
John Girvin <jgi...@bfs.Unibol.COM> wrote:
>[Titanics Cruncher decrunches while loading...]
> <...>
>How does Titanics work? Does it crunch the file in blocks eg: 20K ?
>If so, then that could explain the crap compression rates.
I don't know exactly how the compression algorithm itself works (I'd
expect it to be some LZ77 variation with static Huffman coding,
though), but the decompression during loading is probably accomplished
by using HUNK_BREAK (or whatever it's called), which is really
intended to be used for overlayed executables. When the executable
loader encounters this hunk it stops loading, and returns with the exe
file handle still open. You can then use this to stream in the data,
which BTW doesn't necessarily have to be compressed in separate
chunks.
I once used this technique to do an exe-packer using TetraPack
decompression routines, and to also store data resources in the exe
file (like in Windows, f.ex.).
>|00 John Girvin: developing software for Unibol Inc., speaking for myself|
>|\/jgi...@bfs.unibol.com | Amiga,!PC,net,SciFi,MTB,TaiJutsu,house,techno|
--
=====================================================================
Stefan Boberg bob...@team17.com
Fabio Bizzetti
Stefan Boberg (bob...@team17.com) wrote:
>John Girvin <jgi...@bfs.Unibol.COM> wrote:
>>[Titanics Cruncher decrunches while loading...]
>> <...>
>>How does Titanics work? Does it crunch the file in blocks eg: 20K ?
>>If so, then that could explain the crap compression rates.
It uses 5K blocks.
> I don't know exactly how the compression algorithm itself works (I'd
>expect it to be some LZ77 variation with static Huffman coding,
>though), but the decompression during loading is probably accomplished
>by using HUNK_BREAK (or whatever it's called), which is really
>intended to be used for overlayed executables.
I think it's simply made this way:
You've the decruncher executable, that is let's say 1000 bytes long, then
it finds the programname (EXEC's FindTask will do the job IIRC), opens the
file, seeks to 1000 and starts reading like from a normal data file.
There're no special hunks, just a normal executable and the data joined
after it.
>>|00 John Girvin: developing software for Unibol Inc., speaking for myself|
>>|\/jgi...@bfs.unibol.com | Amiga,!PC,net,SciFi,MTB,TaiJutsu,house,techno|
BTW Stefan: do you have any good LempelZivHuffman cruncher/decruncher in
two data-compatible versions (Amiga and PC)? 80x86/680x0 assembly sources
would be welcome++, if not C would be ok to look at, not C++ anyway.
Thanks in advance (in any case).
>--
>=====================================================================
>Stefan Boberg bob...@team17.com
John Kenneth Grytten
>How does Titanics work? Does it crunch the file in blocks eg: 20K ?
>If so, then that could explain the crap compression rates.
besides, its quite old.. i heard of a guy writing a replacement about
a couple years ago, but it never showed up.
btw: i'd like info on how to utilize the xpk package in demo-coding
a xpk-lib-handler-routine.s would be nice!! anyone, how about
releasing it on aminet?
John K. Grytten (Cyberstarr/Ephidrena) coder
--------------------------------------------------
e-post/mail: cyber...@east.no a m i g a
- "The best way to accelerate an Intel is at 9.8 N (...)"
Jouni Korhonen
Jyrki O Saarinen <jxsa...@cc.Helsinki.FI> wrote:
: : Buddha had his own overlay thingie. Also the Stc has/had an experimental
: : relocator that did the same thing, even without overlay (i.e. no
: : loading while decompressing ;) For example it could decompress ~1.8Mb
: : file in a stock a1200.
: How the hell it did the job then without overlay?
A big kludge. It was based on current implementation of OS'es memory
managing and I bet it breaks many rules of 'good programming' but that's
what exe packers already do. One thing to notice is that the ~1.8Mb
_must_ be continuous.
The basic idea is that after decompression hunks are moved inside the
decompressed data a bit (i.e. to ensure the 8 bytes alignment but I
recall I did it already during the hunkpreprosessing phase). If some
hunk needs to be in different memtype as it is after decompression (i.e.
chiphunks if the decomp. data is in fast) then some extra space must be
allocated and move the data there. Also bss hunks must be allocated 'in
fly'. Then just do the relocation. That would basically be enough to run
a demo..?
The relocator actually did a lot more (the really dirty part) and parted
the huge continuous mem block into as many parts as there were hunks in
the original file and freed all unnecessary data. To the system the
decompressed file looks like any other exe prg loaded using system
functions. With a decompressor ~1Kb of code.
Although the system _works_ it's useless because it really is dirty (it
may/will brake in future OS) and can't handle merged hunks.
--
// www.cs.helsinki.fi/~jikorhon/ - Dept. of Computer Science
\X/ a3k/plus needed - Dead Coders Society
"If you go on with this nuclear arms race, all you are going to do is
make the rubble bounce"
-- Winston Churchill
Jouni Korhonen
Yannick Vansevenant <yannick.v...@EDC.mentorg.com> wrote:
^^^
As far as I remember Chyreseis (or what ever it is) had an overlay
'decompress while loading' (de)compressor that was based on PowerPacker.
Buddha had his own overlay thingie. Also the Stc has/had an experimental
relocator that did the same thing, even without overlay (i.e. no
loading while decompressing ;) For example it could decompress ~1.8Mb
file in a stock a1200.
--
// www.cs.helsinki.fi/~jikorhon/ - Dept. of Computer Science
\X/ a3k/plus needed - Dead Coders Society
Collaboration, n.:
A literary partnership based on the false assumption that the
other fellow can spell.
Jyrki O Saarinen
: Buddha had his own overlay thingie. Also the Stc has/had an experimental
: relocator that did the same thing, even without overlay (i.e. no
: loading while decompressing ;) For example it could decompress ~1.8Mb
: file in a stock a1200.
How the hell it did the job then without overlay?
--
Jyrki O Saarinen
: > Titanics ISN'T a nice cruncher, it is very slow and very inefficient.
: Read the message, it decrunches while loading, meaning that you can run
: a demo of 1.8MB on a 2MB machine and still crunch it ... This is not
: possible with ANY other cruncher, as far as I know ...
True. I would use CrM or STC to crunch data files and load them in
small pieces instead.
Stefan Boberg
bizz...@mbox.vol.it (Fabio Bizzetti) wrote:
>Stefan Boberg (bob...@team17.com) wrote:
>> I don't know exactly how the compression algorithm itself works (I'd
>>expect it to be some LZ77 variation with static Huffman coding,
>>though), but the decompression during loading is probably accomplished
>>by using HUNK_BREAK (or whatever it's called), which is really
>>intended to be used for overlayed executables.
>I think it's simply made this way:
>You've the decruncher executable, that is let's say 1000 bytes long, then
>it finds the programname (EXEC's FindTask will do the job IIRC), opens the
>file, seeks to 1000 and starts reading like from a normal data file.
>There're no special hunks, just a normal executable and the data joined
>after it.
Well, yeah. That's what the HUNK_BREAK is for. Unless I remember
completely wrong, LoadSeg will barf on an executable if there's hunk
after the last HUNK_END. That's why you need the HUNK_BREAK. As a
bonus, LoadSeg then leaves the file open, and puts the file handle
somewhere near the beginning of the first code hunk.
I remember now that I used this for LhASFX, to avoid having to load
all compressed data into RAM. It actually only needs 32K or something
to decompress any size archive.
>BTW Stefan: do you have any good LempelZivHuffman cruncher/decruncher in
>two data-compatible versions (Amiga and PC)? 80x86/680x0 assembly sources
>would be welcome++, if not C would be ok to look at, not C++ anyway.
Sort of, but I don't use them anymore, so I'm not sure where they
are. You could have a look at 'gzip' though. The code is fairly clean,
and would be simple to optimize.
>Fabio Bizzetti - bizz...@mbox.vol.it
Mats Magnusson
In a message of 09 Oct 96 John Girvin <jgi...@bfs.Unibol.COM> wrote:
JG> [Titanics Cruncher decrunches while loading...]
JG> :)
JG> Does the XPK LoadSeg patch 'xloadseg' decrunch while loading? Im fairly
JG> sure it does, but Ive never confirmed it. I suppose it depends on
JG> whether
JG> or not the sublibrary supports streamed decompression.
JG> What I have done is load a bigish exe (900K uncompressed) into a 1Mb
JG> A500 using xloadseg...so it looks as if it might decrunch while
JG> loading.
JG> I used the NUKE sublibrary for that.
JG> Of course, with xloadseg you have the disadvantage that you have to
JG> spread the patch/xpk(master|sub).library with your program.
JG> How does Titanics work? Does it crunch the file in blocks eg: 20K ?
JG> If so, then that could explain the crap compression rates.
Well, the file it generates is splitted inte overlay-hunks. I assume you are
right that it also crunch in blocks. There is no need to split the _crunching_
into small blocks, it's fully possible to do only the decrunching in small
blocks.
It's a shame that there is so little documentation on dos.library, the only
programs using overlay hunks is titanics and old deluxepaint :(
/Mats Magnusson, ma...@plea.se
Jouni Korhonen
: : Read the message, it decrunches while loading, meaning that you can run
: : a demo of 1.8MB on a 2MB machine and still crunch it ... This is not
: : possible with ANY other cruncher, as far as I know ...
: True. I would use CrM or STC to crunch data files and load them in
: small pieces instead.
Btw.. is there really a need for an overlay - like Titanics - exe
packer. I might try to find old Stc sources and hack an overlay
decompressor (I have done overlay stuff before) for it (that would mean
worse compression ratio b'cos I don't know any better method to compress
an exe file than hunk by hunk. So a program with many short hunks would
lead to poor compression).
u13sac
John Kenneth Grytten (cyber...@east.no) wrote:
: >How does Titanics work? Does it crunch the file in blocks eg: 20K ?
: >If so, then that could explain the crap compression rates.
It's not _that_ bad :-) Just slow.
: besides, its quite old.. i heard of a guy writing a replacement about
: a couple years ago, but it never showed up.
version from 1992 that doesn't ever work, no matter what emulation things
I throw at it.
: btw: i'd like info on how to utilize the xpk package in demo-coding
: a xpk-lib-handler-routine.s would be nice!! anyone, how about
: releasing it on aminet?
routine here on Monday. (thinks: If _only_ my Amiga was online itself :-)
BTW: XFD is better than XPK for simple decrunching.
--
.-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-.
| _ __ _________ ____ http://www.abdn.ac.uk/~u13sac u13...@abdn.ac.uk |
| | |/\ \_/(__ / __) __ \ My opinions are not that of Aberdeen University |
| | (\ // /| _)| / or AUCC, thankfully. NEW!: ky...@hotmail.com |
| |_|\_\|_|/____)___)_|\_\ Adamant: telnet://130.83.9.19:4711 |
| 100% Amiga, always. |
`-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-'
Andreas Mixich
jgi...@bfs.Unibol.COM wrote about "Re: cruncher/packer?" on "01-Oct-1996
14:11:34" at comp.sys.amiga.programmer:
> ratios. I use StC to crunch most of the exe's on my HD, and CrM to crunch
> any data files (gfx, samples etc.) that my program loads.
Maybe you should try the XPK sublibrary system.
It not only has a mode to use both CRM and CRM2 compressors, but also
offers crunchers, that are, partly, more efficient then CRM. If your
machine is fast, you might want to pack nearly all with xpkGZIP, it has the
best ratio. Or if your machine is slower (020/030) you can benefit from
other sublibraries, like SQSH for Modules, MASH for ASCII data, RAKE for
exes and so on. The only problem is, none are self-extracting you MUST have
either the xloadseg patch installed or use XFH partitions.
But on the long run, it is better then CRM on its own.
--
Ciao, Andreas
hum...@tomate.tng.oche.de
Martin Blom
bob...@team17.com (Stefan Boberg) writes:
>ma...@plea.se (Mats Magnusson) wrote:
>>It's a shame that there is so little documentation on dos.library, the only
>>programs using overlay hunks is titanics and old deluxepaint :(
> Not quite. LhASFX does, along with some other software I've written
>but never released widely.
And I made a dentro once, that put up a loader screen with starfields and scroller
while the rest of the program was beeing loaded... ;)
Stefan Boberg
ma...@plea.se (Mats Magnusson) wrote:
>It's a shame that there is so little documentation on dos.library, the only
>programs using overlay hunks is titanics and old deluxepaint :(
Not quite. LhASFX does, along with some other software I've written
but never released widely.
>/Mats Magnusson, ma...@plea.se
Mats Magnusson
In a message of 09 Oct 96 jxsa...@cc.Helsinki.FI (Jyrki O Saarinen) wrote:
> : Buddha had his own overlay thingie. Also the Stc has/had an experimental
> : relocator that did the same thing, even without overlay (i.e. no
> : loading while decompressing ;) For example it could decompress ~1.8Mb
> : file in a stock a1200.
JOS> How the hell it did the job then without overlay?
Maybe overwriting the crunched data with the decrunched data ? ;) That
certainly gives some problems when coding, but it could be done...
/Mats Magnusson, ma...@plea.se
Dirk Stoecker
Hi,
> : btw: i'd like info on how to utilize the xpk package in demo-coding
> : a xpk-lib-handler-routine.s would be nice!! anyone, how about
> : releasing it on aminet?
> CadOS has this, courtesy of XFD. Just for you, I'll release the load
> routine here on Monday. (thinks: If _only_ my Amiga was online itself :-)
> BTW: XFD is better than XPK for simple decrunching.
May change in the future! Then only a call to XpkExamine and XpkUnpack is
needed. Passwords and xfdmaster.library are called automatically by
xpkmaster.library. Is this easy or not? - I hope it will work!
As I know xfd decrunching is a lot more complicated!
Ciao
____ _ _ ____ _ _ _ _ ____
| | | | | | \ / | | | the cool Gremlin from Bischofswerda
| __ | ____| | \/ | | |
| | | | | | | | PGP key available.
|____| _|_ |____| _|_ _|_ |____| I hope AMIGA never ends to be the best!
***************************************************************************
* snail-mail: Dirk Stoecker * e-mail: *
* Geschwister-Scholl-Str. 10 * stoe...@rcs.urz.tu-dresden.de *
* 01877 Bischofswerda * phone: *
* GERMANY * GERMANY 03594/706666 *
***************************************************************************
H}kan Hjort
Mats Magnusson (ma...@plea.se) wrote:
If the cruncher is a LZ type this is no problem, you just need the unpacked-
length of memory + maybe some bytes or two. Ofcorse this is very dependent
on the organization of data. If you have a cruncher with two streams it
would be necessary to keep one of the streams in an other part of memory.
Single streamed data on the other hand would be fine and could even be loaded
partially, just keeping track of the "state" the De-compressor is in while
loading the next buffer, not restarting it every 5K.