What Crunchers do you guys prefer?

[Plagueis/KRX]

I was wondering what crunchers you guys use to crunch your demo parts? I know I remember something about Photon saying he just finished coding a crunching utility for Scoopex, and I've heard some other utilities mentioned in the past, but I can't recall the name of the main one that was associated with a lot of the old school demos...I believe it was responsible for a lot of the multicolored flashing that was so reminiscent of scene releases of those days, when they loaded up. You knew the "good stuff" was about to hit the screen when that happened!

I have Defjam cruncher that I downloaded from somewhere, and of course no docs, since if you weren't lame, you were supposed to already know what to set all the offsets and pointers to. I can probably blunder my way through using this, but if anyone has any tips or dox, please feel free to post, or PM me.

I'm at the point right now where I've learned how to set up a copper list, make some nice multi-colored bars on the screen, and I've even stumbled on how to make them look diagonal, and how to get a bunch of 8 bit wide splits on the screen. Now I'm fooling around with bitplanes, and sprites, and I'd like to have a way to crunch my programs and send them to PMC and others in order for them to check out my progress.

Greets to Paul, and the Retro crew for making it possible for me to leap from the c64 scene and start also coding on the Amiga. I'd also like to thank Galahad/FLT and Photon/Scoopex, Stingray/Scarab, and other coder/crackers whose posts have been educational for me.

-Brett

PS: If there was already a thread regarding this subject, please point me to it. Thanks!

[Galahad/FLT]

ByteKiller 1.3 and Tetragon Packer were the two main ones used 'back in the day'.

Generally I use a decent data file packer like FileImploder or RNC Propack and code my own header to relocate the file to be depacked.

Crunchmania is an ok one if you need a pro-decrunch capable depacker, Defjam packer has a bug in it.

[Leffmann]

For running anything from inside the AmigaOS you don't want to decrunch to fixed addresses, unless you intend to force a reboot afterwards. Crunch-Mania and Stonecracker are AFAIK the best crunchers, and they can take care of all these memory details for you. This also allows you to split your code and data into sections to make better use of the memory.

[Plagueis/KRX]

@Galahad: Yeah, Tetragon Packer was the one I was trying to remember. At some point I had tried to find it by searching the web and I came up with a website or text file that claimed DefJam's version had fixed some bug in Tetragon. I guess that wasn't the case.

I was mainly looking for opinions about which cruncher would be suitable for demos, and sharing assembled code I write, etc. Something fast. I'll try out some of the ones you guys suggest if I can find them. Crunchmania sounds good. Thanks!

PS: Ok, there's a huge crunchers section on Exotica...I can't believe I didn't look there first. I'll have to use the good old method of trying 20 or 30 until I decide on my favorite. In the meantime though, all opinions welcome

[pmc]

My advice on this personally would be to use one of these three:

Powerpacker (latest version you can find)
Imploder 4.0
Titanics Cruncher

All of these crunch nicely and in my experience are system friendly so you know your one file demo is going to work OK - as long as you've coded it to be as friendly as possible itself that is.

If you're crunching for demo type stuff where you don't care about the system at all then you could do worse than Photon's cruncher available from the Scoopex website as there's docs and a decrunch source too.

By the way, DP - if you want any of the ones I mentioned I can send them to you - just shout.

[StingRay]

I use CrunchMania most of the time, still the best packing ratio (beats RNC most of the time!), decruncher source is included in the package and it works reliably.

[WayneK]

Crunchmania & RNC pack 'best', StoneCracker is usually close to the same ratio and has a much faster depack (well, slightly faster than crunchmania - much faster than RNC), and can also take care of all the setup (CIA, cache etc.) if you want it to...

[Leffmann]

Here's a big archive of various exe and data crunchers, and archivers:

http://amigarealm.whdownload.com/ami...ols/tools1.htm

[Plagueis/KRX]

Originally Posted by Leffmann

Here's a big archive of various exe and data crunchers, and archivers:

http://amigarealm.whdownload.com/ami...ols/tools1.htm

Nice...thanks...I noticed there's a DPaint unpacker in there too, that might be useful for my demo making toolkit.

-DP

[StingRay]

Originally Posted by Plagueis/KRX

I noticed there's a DPaint unpacker in there too, that might be useful for my demo making toolkit.

That's most probably just a byterun unpacker (i.e. IFF to raw) which you can easily code yourself, would be a good exercise at least. =)

[Plagueis/KRX]

Originally Posted by StingRay

That's most probably just a byterun unpacker (i.e. IFF to raw) which you can easily code yourself, would be a good exercise at least. =)

Great, I'll put that on my list.

-DP

[pmc]

Originally Posted by WayneK

StoneCracker is usually close to the same ratio and has a much faster depack (well, slightly faster than crunchmania - much faster than RNC), and can also take care of all the setup (CIA, cache etc.) if you want it to...

I must admit I hadn't really used StoneCracker but I downloaded the latest one from Aminet and played around with it a bit. Really nice.

It crunched one of my executables smaller than Powerpacker, did the crunching much faster too.

Decrunch on load was quicker as well but I missed the coloured bars.

It's not old skool feeling enough for me without all that $dff180 interference on the screen.

Is there a way to turn that on in Stonecracker? Maybe I should go and RTFM...

[StingRay]

Originally Posted by pmc

Is there a way to turn that on in Stonecracker?

There isn't. However, you can always modify the decruncher that is included in the STC package if you want to have those color flashes. A "move.w dx,$dff180" at the right place and woohoo. :P

[pmc]

Originally Posted by StingRay

There isn't.

Boooooo! Hiss! Jeer!

Originally Posted by StingRay

However, you can always modify the decruncher that is included in the STC package if you want to have those color flashes. A "move.w dx,$dff180" at the right place and woohoo. :P

\o/

[Frog]

I think Crunch 1.4 is worth to check.
Crunch packs relocatible & data files using different methods:
- Normal
- Segment
- Data
and also can use Titanics DeCruncher type
I remember ratio and speed decrunch were quite good.
This packer was used in most of TBL prods.

[Plagueis/KRX]

Originally Posted by pmc

Boooooo! Hiss! Jeer!

\o/

heh, yeah...that's one of the things I wanted as well ($dff180 cycle effects during decrunching) to get that feeling you were talking about. Of course I want to be able to send you stuff I code for you to check out in WinUAE without having to load up Devpac, assemble, and run it.

-Brett

[Skylight]

For pure EXE crunching i would rather use "CrunchyDat"
http://aminet.net/search?query=crunchydat

It's giving usually better ratios than CrunchMania and the decrunch header got no cache flush issues on 68060 CPU's unlike CrM.
It's very fast, very easy to use and even ur beloved $dff180 flashes are included by choice.
But beware the unpacked file will be overwritten with the crunched one, so always use a copy.

For data crunching and special features CrunchMania is still the tool of choice.
And the trial version 1.91t is good enough for these purposes.

U can still go with the real old skool crunchers like ByteKiller 1.3.
But for what reason?


Ciao, Rick ...

[Photon]

I quit crunching exes when I got a bigger harddisk for my A500, it slowed down loading something awesome even on 68000 ... I remember about the same time, I used Powerpacker for modules (but I quit that since some trackers didn't like it and it was a pain in the a to save...) and for documents (PPmore to read, etc).

For demos I used a friend's (Syncro/Science 451) cruncher. Then I made the Qik*D*Pak binary cruncher, PicPac, a pixel cruncher and also a sample cruncher. Nowadays I use Scoopex-Cruncher.

I think the first demo I made was uncrunched and the first demo that I did crunch was probably Supersinus, and I think I used a commandline cruncher from Northstar.

For exes I used Imploder and I guess it's perfectly OK for that still, certainly it's easy to plop a small intro into it and you're done.

Originally Posted by Leffmann

For running anything from inside the AmigaOS you don't want to decrunch to fixed addresses, unless you intend to force a reboot afterwards. Crunch-Mania and Stonecracker are AFAIK the best crunchers, and they can take care of all these memory details for you. This also allows you to split your code and data into sections to make better use of the memory.

Yes, fixed addresses are actually used to enhance compatibility and make better use of the memory

Let me explain. Consider the 512k chip only platform. Dude makes a 400KB demo that is 200 KB crunched. 400 KB fits in 512K, and naturally he wants 512k users to be able to run it. But if you load the decrunch source and include the crunched file, you get a 201 KB exe. When this is run, there is <300 KB left and there is no way of "extending" the already allocated ram where the exe resides at runtime.

You could add a ds.l statement in the decrunch source; this would very efficiently prohibit the exe from even starting if you have 1 byte too little memory free.

OK, go from this to 420KB - he added a nice graphic to the demo. Now, it will still start fine on a bare nekkid 512k machine; you just have to disallow exit (or reboot on exit-click), because you might need the memory hogged by f.ex. the CLI/WB screen. You could say to all the A500 users: hey, get >512k memory. But if the demo is really heavy on the chipmem stuff (5K code, rest gfx and music) it won't help ofc.


Anyway, if you do it system-friendly with f.ex. a ds.l, you could end up with an exe that doesn't load on a machine that can run it (without exit). If it doesn't start, it can't even CONSIDER taking over the system, show the demo and disallow exit.

Bottom line is: too much checking and you may mistakenly block users that COULD see it from seeing it. But just checking if you have to disallow exit or not and then just starting it will enhance compatibility (by running it on the full set of compatible machines) and certainly make better use of memory (than giving up if you happen to have a DF1: connected, f.ex.).

If your demo does NOT utilize a rock standard A500 fully, then ofc you should be 100% system-friendly. But there is a conflict between the two. Only on the A500 is the chipmem so precious (256K module+some screen buffers, and you're upto 400K already, not much left for 'stuff'!), and few demos on A1200+ need it so desperately (because 400K is only 20% filled then...)

There are 3 ways around this:
- loading it in small buffers and decrunching on the go (Titanics-Cruncher). Only the small buffer and the size of the loader is the overhead. But you can't utilize max memory ofc, since you can't turn off the system while loading... a trackloader can do that tho.

- Make a "loader" CLI-command that can load any crunched relocatable binary to any address. The trick is that it checks if the machine can run it; if yes, it checks if it can decrunch it with the system on; if yes, then it runs the demo with exit, otherwise turns the system off and disallows exit.

- split up the demo, so that some big graphic or music is either loaded later, or included but not decrunched until later.


I think the time spent being paranoid about OS-friendliness is better spent on compatibility with other processors (interrupts, caches, blitwaits...). Just loading it and checking if you need to turn the system off temporarily or until reboot will make it load on the most possible machines.

No part in the above paragraph is very hard; the only part that's a little tricky is checking that you don't overwrite the stacks on chip only machines. It can sometimes be in very strange places

[Plagueis/KRX]

Originally Posted by Skylight

For pure EXE crunching i would rather use "CrunchyDat"
http://aminet.net/search?query=crunchydat

@Rick: Cool, I will try Crunchydat, sounds useful to me at this point, of course I've started to try a few others to. Other than nostalgia you're correct, there's no reason for me to want to use the really old crunchers like Bytekiller, Tetra, etc. But then nostalgia is a pretty strong reason to me, since I want to feel like I've "been there and done that" with a lot of things.

@Photon: That's a lot of nice information you've given there. It'll go into a text file about demo preparation for me.

[StingRay]

Originally Posted by Photon

Yes, fixed addresses are actually used to enhance compatibility

*cough* *cough*
Most of the time you don't need to use fixed addresses if you know what you're doing! They can be useful under certain circumstances of course (trackmos etc) but that fixed addresses enhance compatibility, well... *cough* *cough*

Let me explain. Consider the 512k chip only platform. Dude makes a 400KB demo that is 200 KB crunched. 400 KB fits in 512K, and naturally he wants 512k users to be able to run it. But if you load the decrunch source and include the crunched file, you get a 201 KB exe. When this is run, there is <300 KB left and there is no way of "extending" the already allocated ram where the exe resides at runtime.

And what hinders you to decrunch the exe over itself? That way no memory is wasted! Loads faster (since the exe is smaller) and it would still run on a 512k machine!

If it doesn't start, it can't even CONSIDER taking over the system, show the demo and disallow exit.

If your demo needs all the 512k make it a trackmo as then nobody would expect it to quit back to DOS anyway. If a single file demo won't allow me to quit back to DOS these days I'd consider it a failed attempt.

Bottom line is: too much checking and you may mistakenly block users that COULD see it from seeing it.

Yeah, because 512k machines are standard nowadays *sigh*. I'd rather say too little checking and it won't run on most actual machines! But that might just be me.