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.
Quote:
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