What Crunchers do you guys prefer?

[Photon]

I think you misunderstood some points. But the first quote there was mostly to provoke thought about "what makes a demo run on the most machines".

A coder's approach would depend on which machine he cares about. Right now, I still care about making it run on "the machine that everyone got to run all the games", if you know what I mean. And newer ones.

Ofc, if you do have a more expanded Amiga, then you have more ram and there would be no problem quitting to DOS. But Amigas with 512k chip are special, and I think it's better that the demo starts on a machine that can run it, than not. That's the reason I brought that up at all.

Decrunch exe over itself: of course, that's what everyone does. I discussed this one sentence after your quote ended... The text you selected hilights the problems a first-timer could experience when he crunches his first demo.

About 512k: well, let's all make impressive demos that require 68060 @ 80 MHz, AGA and 64 MB ram, and fails to start or looks like crap on all other machines. All 200 persons in the world will enjoy them immensely.

About checking: I meant checking for stuff that allows the demo to start, such as memory checks. It's true that for each check you make that exits to CLI if failed, blocks a subset of Amigas from running the demo.

[StingRay]

Originally Posted by Photon

A coder's approach would depend on which machine he cares about.

According to you I'm no coder then.

Originally Posted by Photon

But Amigas with 512k chip are special, and I think it's better that the demo starts on a machine that can run it, than not.

They aren't special, they are just Amigas with not much RAM. However, where's the point to have a single file demo that can't be quit? You can make it a trackmo as well then.

Originally Posted by Photon

I discussed this one sentence after your quote ended...

Not really. At least I can't see that you mention overlap decrunching anywhere.

Originally Posted by Photon

The text you selected hilights the problems a first-timer could experience when he crunches his first demo.

A first demo rarely needs all the 512k IMHO.

Originally Posted by Photon

About 512k: well, let's all make impressive demos that require 68060 @ 80 MHz, AGA and 64 MB ram, and fails to start or looks like crap on all other machines. All 200 persons in the world will enjoy them immensely.

Sure, that's how I do all my demos... But I'll do like you now, I'll care about the maybe 5 users that still watch demos on a 512k only Amiga and will avoid any additional checks (because they need more memory and thus the demo wouldn't be able to start on a plain 512k machine). Welcome to 1988! It might be a good idea to not only think in black and white because you go from one extreme to the other!

[pmc]

@ Photon - as a side question - do you put some kind of check into your demos to deliberately prevent them running on all but a vanilla OCS A500 with 512Kb?

I only ask cos when I try to run Blitter Sweet on my A500+ it always just immediately quits back to the CLI prompt without running the demo...

Sort of like the Retrolock routine I coded once that forced < AGA.

[Photon]

pmc: never but certainly there could be a mistake in the code, I'm not perfect. Is it the official release from Pouet? Maximum memory free? (disable external floppies + 1-bitplane CLI window command may have to be invoked).

Originally Posted by StingRay

According to you I'm no coder then.

Why do you say that? Don't you code for the platform you care for?

Originally Posted by StingRay

They aren't special, they are just Amigas with not much RAM. However, where's the point to have a single file demo that can't be quit? You can make it a trackmo as well then.

The point of a single file demo that doesn't quit is to overwrite the system if necessary Just kidding. But is it better that it doesn't run on a single A500? Or should the demo be stripped of some nice sounds, graphics or effects that don't fit, so it "always works with whatever memory the A500 user has left after his startup-sequence"?

Plenty of demos maximized the precious 512k chipmem this way, you ofc know packdisks with special bootblocks to disable drives and commands to make CLI one bitplane as above.

Single file demos are easier to make, take less space than at least ADF. And if I made it a trackmo, I bet you or at least users would complain that they had to write a floppy and reboot twice to see it.

Also, single file demos allow users to patch/load drivers for any expansions/accelerators they have to get their rig initialized properly.

Originally Posted by StingRay

Not really. At least I can't see that you mention overlap decrunching anywhere.

I mentioned that it's impossible to extend the already allocated memory where the crunched exe was loaded by the OS, and suggested a ds.l (if you use a decrunch source) to extend it before "Writing Object" to fix it.

Originally Posted by StingRay

A first demo rarely needs all the 512k IMHO.

I agree, although the info was not only for the very first demo someone makes. And it might, if the demo gfx artist/coder isn't experienced in optimizing/converting graphics, optimizing code/thinking of cleverer solutions to make buffers or tables smaller while giving the same effect. Or if they don't know to overlap-decrunch.

Originally Posted by StingRay

Sure, that's how I do all my demos... But I'll do like you now, I'll care about the maybe 5 users that still watch demos on a 512k only Amiga and will avoid any additional checks (because they need more memory and thus the demo wouldn't be able to start on a plain 512k machine). Welcome to 1988!

1988 <3

Jokes aside: no, I think there should be all kinds of demos for all kinds of models. And the 68060@80 platform makes perfect sense - why code for anything less? It's certainly "Elite" (c) 1988 to code something great for it. On no other platform [Edit: Amiga platform] does a demo have a greater chance of looking its best. But it's also a bit too Elite for the viewers and for other coders "wanting to join in that scene", because they can't easily get such a machine to enjoy the demo, or to code demos of their own on.

If we want more people in the Amiga scene, platforms must be found that are broader, or nobody (viewers/gfx/music/coder guys) can join. 1MB OCS (+expansions) is a good and broad platform, and so is A1200 (+expansions).


And make no mistake, you should ofc write as system-friendly code as you can, always. It's just that when checking for all the different Amiga configurations since A500, you might have to write very tricky code to accomodate them all. If one check is mutually exclusive with another, you've unnecessarily blocked a part of the Amiga family. Example: if you write a demo that doesn't need more than OCS and doesn't use more than 420KB memory, if it doesn't start on an A500 due to a compatibility check, have you really written the most compatible code then?


For the minimalist, here's the only things you have to do to ensure maximum audience:

1. If user has too little memory left: Turn off system, copy crunchdata to below demo start address, overlap-decrunch backwards from demo top to demo start. Make sure you don't trash the stack if you exit.
2. If you use interrupts: check if CPU >= 68010 and get VBR to get & set them correctly. Also clear intreq twice at the end of the interrupt, in case an A4000 is running it.
3. Don't count on any timings, like memory speed or CPU speed. (Chipset speed is more predictable, especially blitter. But make sure you predict/write variants for AGA doublespeed DMA (or halve it) and how it interacts with the rest of the chipset. It's easier to not count on that timing either...) For example, use proper blitwaits, unless you know the target machine is cycle exactly like the one you wrote it on
4. Write code that works with caches on. (Usually is easy, if you stay away from desperate tricks to save a few cycles.)

So if you absolutely HAVE to utilize the A500 to the max (and I must! I must! (c) Blazing Saddles), taking over the machine permanently and using correct interrupts and blitwait will work on every single Amiga out there, except 256K A1000... That's all I mean. If the requirements are smaller or memory is bigger, you should ofc write proper startup and exit code.

Back in the day bytekiller like everyone else, because you COULD force it to depack over places that commodore didnt want us to.
Wrote the sourcecode independant, but compiled it to sit at certain memory locations and you could just tell bytekiller where to stick stuff and exec it from that jump point. Perfect coder tool.
On the memory mapping, Im from photon's school, we knew where we could load stuff and what we could blow away and still have the thing working for the duration of the demo. With a a500 we didnt care if it wouldnt exit back to cli for a full blown demo as you could just power cycle it and be back there quickly and that was the accepted norm.
The issue of compatibility doing this only came up when commodore furtled around with the chipset locations without taking the above into consideration. They just issued a blanket statement that we should all have been programming the thing "correctly" (and by commodores logic, that meant using the C libraries for access to the hardware and other such slow crippling stuff), so really they forced the whole memory map incompatibility mess when hitting the hardware direct by having no regard whatsover for people trying to push the hardware boundaries in the best way rather than their corporate dictated way. Typical cbm attitude Im afraid, and why the sun shone when I moved onto other hardware not controlled by one manufacturer...
When I needed more space, I made a bootloader that took over trackdisk, and controlled everything from that for the duration of whatever I could fit on a floppy as a multipart, unpacking the next segment in memory while doing a sort of bootloader mini intro. Worked good too.

[StingRay]

Originally Posted by MrFluffy

The issue of compatibility doing this only came up when commodore furtled around with the chipset locations without taking the above into consideration.

Right... Of course Commodore's fault that they dared to change the KS/Chipset... And of course it was impossible to have "clean" code before, which is why each and every hw banging demo didn't work on 2.0+/AGA machines, right? *sigh*

Originally Posted by MrFluffy

They just issued a blanket statement that we should all have been programming the thing "correctly" (and by commodores logic, that meant using the C libraries for access to the hardware and other such slow crippling stuff)

Ever checked the HRM? So much for "using C libraries to access the hardware"

Originally Posted by MrFluffy

Typical cbm attitude Im afraid

Right...

Originally Posted by StingRay

Right... Of course Commodore's fault that they dared to change the KS/Chipset... And of course it was impossible to have "clean" code before, which is why each and every hw banging demo didn't work on 2.0+/AGA machines, right? *sigh*

Ever checked the HRM? So much for "using C libraries to access the hardware"

Right...

Im talking v1.2 to v1.3 ks revisions, let alone the aga stuff. That was the shape of things to come right back there and while all my stuff just worked on both, the 1.3 was definitely the poor cousin to the almost identical 1.2 in demo circles for a while, and it wasn't exactly the big leap ahead in performance to warant the pain either. And that was the official commodore press release to the mags in the uk. Anything which didnt work after the transition was "badly coded and not conformant, and people should take it up with their supplier". There was also some waffle about correct coding using the c libraries to access the bit blitter and other stuff so it would play nicely.
IIRC quite a few commercial products fell flat on their face too, and for a while people were having to stick v1.3 compatible stickers on their software etc. So we were all officially crap coders because we didnt do it their way...

Ever check the hrm? its all I had! a1000 version because when I got my german import a500 they hadnt released the a500 english version. So that and lots of picking things apart to see how they worked. Because then, it was still a very new thing. The drive platter control is still a mystery to me mind.
See my first point about the C libraries.

disclaimer, Ive never had a aga amiga, nor the real temptation to get one. I have my 2000 for nostalgia and to remember my "illusions of grandeur" as photon put it

[Toni Wilen]

There is no way to make code that only works on 1.2 without really attempting to do something extremely stupid.. (like jumping directly to ROM or poking random system structures which both are both big no no)

[StingRay]

Originally Posted by MrFluffy

Im talking v1.2 to v1.3 ks revisions, let alone the aga stuff. That was the shape of things to come right back there and while all my stuff just worked on both, the 1.3 was definitely the poor cousin to the almost identical 1.2 in demo circles for a while

Most common problem were direct ROM jumps to acknowledge IRQ's and I don't think you can blame C= that they dared to change some things in the 1.3 ROM so certain (rather stupid IMHO) "tricks" didn't work anymore.

Edit: Toni was faster and said almost the same

Yes, I read the jump vectors out of the registers at runtime by some happy accident, probably the guys that hard coded jump vectors deemed the cycles from doing this at startup and caching were a overhead too far
But my point is (in the uk anyway) c= came out with a press release sent to mags etc that belittled everyone who made stuff that didnt work, while all the time quoting the C libs standard line. THATS what I mean about typical cbm attitudes...
If they'd have come out and suggested alternate ways of getting the jump vectors and a few fixes instead of trotting out all that use the system libraries and finger pointing at the people who'd done the tricks nonsense then maybe they'd have had a bit more respect from me at the time. And its a old wound that still bugs me. And a memory map of where we could steal absolute locations would have been really nice, I lost track of the time I spent mapping everywhere out finding the limits etc

We know now theyre stupid tricks, but thats what pushed it along, tricks and undocumented hacks and doing stuff with it that the designers never intended. Nobody knew it was a stupid hack without the benefit of years of hindsight.
But this thread is about depackers, and my post was how demos of the day did it from a historical aspect. With a bit of politics from the day thrown in

[Galahad/FLT]

I was going to comment in depth before Toni and Stingray did, but frankly, you are fundamentally wrong.

Stupid programming practices were the cause of most problems, not CBM.

Processor timed loops for delays?!?!?!

Lack of blitwaits for blitter intensive code?!?!?!?!

Pretty much all of the KS1.2/1.3 problems were caused solely by programmers ignoring practiced guidelines set down by CBM.

Directly accessing ROM code without using exec or libraries..... they were there for a reason!

As for memory mapping? What are you talking about?

If you disable the system, ALL memory is available to you, even the Vector Base area.

If you use the system and use alloc mem routines, again, you don't need to map shit, you just need to use avail mem to know whether or not your stuff will fit in the system you're programming for.

Damn Commodore for upgrading the Amiga, fitting faster processors, stupid damn Commodore!

[Plagueis/KRX]

Originally Posted by MrFluffy

But this thread is about depackers, and my post was how demos of the day did it from a historical aspect. With a bit of politics from the day thrown in

Actually I started this thread, and it did begin about depackers, but what it has evolved into is actually more educational to me (someone who has started coding on the Amiga for the purpose of making demos) than it's original intent. My main aim has already been met...I've found out what crunchers the demo guys around here use, and why, and now the thready had evolved into a discussion much much more interesting!

-Brett

[StingRay]

Originally Posted by MrFluffy

If they'd have come out and suggested alternate ways of getting the jump vectors and a few fixes instead of trotting out all that use the system libraries and finger pointing at the people who'd done the tricks nonsense then maybe they'd have had a bit more respect from me at the time.

There never was any need to use direct ROM addresses. Want to acknowledge your IRQ? Just write to $dff09c (INTREQ). Want to use a certain library function? Open the library and call the function. And it was always that simple! There never was any need to use direct ROM accesses (the ONLY exception I make here are Bootblock intros (or other extremely size optimized routines) but these are really special cases).

Originally Posted by MrFluffy

I lost track of the time I spent mapping everywhere out finding the limits etc

Umm, I'm sorry, but what was so hard about that? Chipmem goes from $0-$80000 on a plain 512k A500, that really wasn't much of a secret, was it? If you want to use all mem, disable the system and have fun but don't ever return to the OS.

Originally Posted by MrFluffy

We know now theyre stupid tricks, but thats what pushed it along, tricks and undocumented hacks and doing stuff with it that the designers never intended.

Are you sure you're speaking about Amiga here? What you say is true for the C64 and other platforms such as the Atari ST [(side)border stuff springs to mind], there wasn't anything like that on Amiga.
(Yes, there were a few undocumented features of course, but I'm pretty sure these weren't found by direct ROM accesses =)

Originally Posted by MrFluffy

Nobody knew it was a stupid hack without the benefit of years of hindsight.

Apparently enough people knew that accessing ROM directly wasn't a very clever idea, otherwise everyone would have done it. Fortunately, that wasn't the case.

[pmc]

I think a lot of the stupid hacks that were done by demo guys in the early days were about proving how "clever" they were by doing something in the wrong way yet still getting the desired results.

In my opinion it was an ego thing: "Commodore said don't do this but I'm gonna prove I know their machine even better than they do and do what I like and it'll still work..."

And it did, right up until Commodore went and made changes to the stuff they warned they were going to make changes to all along.

Commodore getting annoyed with guys coding stuff that ignored their basic rules is fair enough - there's a section right at the front of the HRM that lays it out: if you're gonna code level then follow these few simple guidelines. When people didn't and software broke it reflected badly on Commodore and the Amiga and made people think twice about upgrading. People not wanting to upgrade == bad for business if you're trying to sell the latest version of your hardware.

Originally Posted by pmc

I think a lot of the stupid hacks that were done by demo guys in the early days were about proving how "clever" they were by doing something in the wrong way yet still getting the desired results.

Way back in the early days, it felt like to me that there was a dearth of info about "hitting the hardware" and it was frowned on, and I could never find anywhere to tell me WHAT I should be doing only that I shouldnt be doing it. All I had access to was my (a1000) hardware reference manual, and what I could glean from picking stuff apart. And others were in the same boat. This was long before the mags started doing coding tutorials, and sourcecodes were jealously guarded and passed only within the groups.
For the memory mapping, yes its common knowledge that you can do that, but not way back then, we just messed round with things. The documentation available wasnt "disable the os, then you can have the entire address space but thats it game over for returning to a cli", because I would have done that in a instant because it would have freed up bits of the memory space that I knew to avoid if I wanted to avoid a crash. It was "use the proper memory allocation proceedure", so yes, we did mess round with everything until we found out what areas we could write to without triggering a guru etc. Even reading #6 of bfe001 was a hack in the terms of the period, let alone playing with the led status (which we did because the hw ref had a appendix detailing the bit mappings of bfe001, and while your reading that section...)
Yes I did return control to the system after trapping the VB interrupt and redirect it to my routines (Im sure that was common practice too) and not giving the original interrupt routines control back caused it to guru. And as a result my stuff exited cleanly back to cli despite hitting the hardware. Accidentally, because thats how the stuff I'd picked apart worked.
With the 1.3 chipset, the "here be dragones" bits in the memory address space moved. And that fubar'd some stuff up for people that had been doing the same.

So, maybe I and some other people were just stupid kids in our bedroom looking in the wrong places and asking the wrong people the wrong questions, but where the hell in the early days of the a500 was all this info documented? It wasnt, we just stuck it where we knew it would work, until it didnt with the newer roms. And then c= made a point of publically chiding us for being stupid in official press releases which got printed in the mags.
But hey, what do I know, Im probably just a stupid middle aged programmer now.

[Galahad/FLT]

Originally Posted by MrFluffy

Way back in the early days, it felt like to me that there was a dearth of info about "hitting the hardware" and it was frowned on, and I could never find anywhere to tell me WHAT I should be doing only that I shouldnt be doing it. All I had access to was my (a1000) hardware reference manual, and what I could glean from picking stuff apart. And others were in the same boat. This was long before the mags started doing coding tutorials, and sourcecodes were jealously guarded and passed only within the groups.
For the memory mapping, yes its common knowledge that you can do that, but not way back then, we just messed round with things. The documentation available wasnt "disable the os, then you can have the entire address space but thats it game over for returning to a cli", because I would have done that in a instant because it would have freed up bits of the memory space that I knew to avoid if I wanted to avoid a crash. It was "use the proper memory allocation proceedure", so yes, we did mess round with everything until we found out what areas we could write to without triggering a guru etc. Even reading #6 of bfe001 was a hack in the terms of the period, let alone playing with the led status (which we did because the hw ref had a appendix detailing the bit mappings of bfe001, and while your reading that section...)
Yes I did return control to the system after trapping the VB interrupt and redirect it to my routines (Im sure that was common practice too) and not giving the original interrupt routines control back caused it to guru. And as a result my stuff exited cleanly back to cli despite hitting the hardware. Accidentally, because thats how the stuff I'd picked apart worked.
With the 1.3 chipset, the "here be dragones" bits in the memory address space moved. And that fubar'd some stuff up for people that had been doing the same.

So, maybe I and some other people were just stupid kids in our bedroom looking in the wrong places and asking the wrong people the wrong questions, but where the hell in the early days of the a500 was all this info documented? It wasnt, we just stuck it where we knew it would work, until it didnt with the newer roms. And then c= made a point of publically chiding us for being stupid in official press releases which got printed in the mags.
But hey, what do I know, Im probably just a stupid middle aged programmer now.

Sigh.

To put things in perspective, I have stuff I wrote on my Kickstart 1.2 Amiga A500 that worked on ANY machine I tested it on, that includes A4000, A1200 and A1200 tower with an 68060 processor card.

The only way stuff would not work between Kickstarts is if you were not using proper library calls using the correct offsets and just accessing ROM directly.

Seriously, using exec and dos.library really was no big deal.

[Photon]

MrFluffy, overwriting occupied memory has less to do with following proper programming guidelines and more to do with 512k chip machine compatibility. If you don't care if all users that CAN run it WILL be able to run it, you can allow exit. All the code to do it either way should be proper, ofc. You could also lower the chipmem use ofc; removing some memory-hungry effects or using a smalled module for the music.

I agree about the documentation thing - we were "all" 15yo kids whose parents perhaps didn't feel like ordering books from abroad at 60€ a pop after buying a 400€ computer - even if they knew the books existed and which ones to buy! American programmers have no such excuses, ofc.

For me, it's easy to decide when it's okay to use OS routines or not. If the OS is turned off, you should access hardware directly, if it's on, both hardware-direct and OS is available, and you should use the OS routines for OS stuff - they were put there for a reason.

[pmc]

@ MrFluffy - What Galahad said. There's no reason you can't take over the machine and do what you want and *still* have your code work across all variations of machine & kickstart. You just take over the machine and do what you want (and restore everything on quit again if required...) in the correct way.

[dalton]

about crunchers again:

I should say that I never crunch individual demo parts. I make an exe, usually only two sections (one fast, one chip) and then I crunch it all together. Here's my opinions:

*CrunchMania: very good packing ratio but crashes on modern cpu
*Stonecracker: fast and reliable but not very good ratio
*Crunch (cru): best cruncher on aminet imho
*Blueberry execruncher: uses massive amounts of memory and cpu time when crunching, but has the best ratio I've ever seen. Good for 4k's
*Natcracker: Good for 40k's, better ratio than cru, stc, cm

don't know anything about the old crunchers like titanics etc..

[pmc]

@ dalton - I agree about Blueberry's cruncher - easily the best ratios I've seen. Only thing I don't like is that decrunch takes a while on 68000 Amigas and there's no indication it's happening.

I've never used Crunch or Natcracker - I'd better check them out too.