STONE CRACKER v2.99d - We Fixed It Thank you for your interest to Stone Cracker crunchers. Firts of all I hope you remembered to copy the cruncher itself and the docfile. Please try to spread them together. Stone Cracker is a Public Domain program mainly for demomaker etc. users purposes. It is quite common within these users to program into absolute memory locations which surely has some advantages. Because I'm a part of that user group I developed an 'absolute address - non system - demo cruncher'. Because there are several different Stone Cracker versions around I think it's better make a list of them (all versions aren't listed) and explain each one a bit. ·v2.69 - Somebody got this one? ·v2.70 - The first real Stone Cracker version. It had all the needed features and worked just fine. ·v2.71 - Some little improvement. ·v2.80 - Similar to v2.71. Only few improvements. Never spread! ·v2.81 - Quite similar to v2.71 & v2.80. Few improvement done to user interface and especially to decruncher. Not spread that much. ·v2.90 - A test version and never released. ·v2.91 - A test version too and never released. ·v2.92 - Totally different when compared to earlier versions. Even the crunching algorithm was changed. Because of reprogramming the whole cruncher it had several bugs and couldn't handle all kinds of data (areas longer that 64Kb of crunchable data bugged). ·v2.99 - Better version of v2.92. New features were added like hunk relocator and no any limits to the data to be crunched. But anyway there were few very odd(??) bugs around. Never spread! ·v2.99b- The official v2.99 release. Worked just fine and some little improvements. But I wasn't satisfied with it because after a while I noticed that not everybody codes like I do. Others could face some unexplained things like the cruncher freezed itself at the end of crunching process for a couple of minutes but then continued like nothing had happened. ·v2.99c- A better version of v2.99b. Those nasty little thing were removed and few bigger improvements were done. The megacrunch - option was removed and low memory address - option was added to quarantee 100% workablity for the programs. Not spreaded very much. ·v2.99d- Some minor improvements. Speedup buffer (???) removed and code optimized a bit. New default value for Max equal lenght. ** ELF-CO edited the following ** ·v3.00- More of a gfx fix really. Some more minor improvements, like the on-line docs (help files, activated with *h at anytime) I am not too sure about all the improvements Jouni put in, as he hasn't sent me the updated docs for it. I can tell you that I spent four hours with it on my system (9 megs ram/14mhz) and it worked just fine on every file. When I get more info, I shall post it for you. When you run this cruncher it doesn't matter whether you run it from Cli or WorkBench. A window will appear into the screen and some credits are shown. Note that you can exit the cruncher any time by typing '*' into any question. Both mousebuttons will abort crunching. ·Buffer size: # - Work area for the cruncher. You program should fit into this memory area. Note! You give the size in kilobytes (decimal). ·File to load: - Nothing to explain... If your program looks like a relocatible program (cruncher finds the hunk area) next question will appear. ·Fix address: $ - Now you can fix your relocatible program into any address you want. If there are such hunks that this relocator can't handle an error will occur. Note! You can skip the relocation by pressing the enter. If your program looks like a raw data next question is this. ·Efficiency (0-5) - This is the lenght of the area where the cruncher searches for equalities. The longer the area is the better the result is but at the same time the crunching time gets longer. ·Max equal lenght: # - This option is just for shorting the crunching time. If you define Max equal lenght to #2000 bytes always when the cruncher finds a crunch- able area that is #2000 bytes or more it will crunch it immediately and DON'T start searching for a better case. This is very use- ful if your program includes long empty areas! ·crunch crunch... zz zz zzzz z z zzz ·Save exec. or data: - You can save the crunched data whether with the decruncher header or not. If you choose data next question will be: File to save. ·Decruncher type: - There are two different decruncher for the program: normal and system killer. If you choose normal next question will be: Decruncher location. These questions are for the system killer only! ·Supervisor Stack (SSP) - You must relocate the stacks. Note!! NEVER put it inside your programs area!! ·User Stack (USP) - You must relocate this stack too. Note!! NEVER put it inside your programs area!! ·Status Register (SR) - You can define the whole Status Register like supervisor bit, interrupt priorities & flags. ·Int Ena ($dff09a): $ - You can define which interrupt is on etc. ·Dma Con ($dff096): $ - Same as below but for Dma channels. ·Adk Con ($dff09e): $ - Again the same... Here continues the questions for normal decruncher. ·Decruncher address: $ - The decruncher is always taken away from the data to avoid overwriting it and quarantee better workability for the program. The decruncher is very short: only #236 bytes and don't use much stacks (4 bytes). ·Start address: $ - Decruncher will place your program here. ·Low memory address: $ - This feature is sometimes very useful. If the first bytes of your program didn't get crunched, uncrunched data might in some cases overwrite the crunched data source. It would of course cause unwanted effects! To avoid this you can define Low memory address a bit under Start address (e.g. $100 bytes is enough in most cases). This address is the lowest address the cruncher uses. ·Jump address: $ - After decrunching the program will jump here. ·File to save: - Nothing to explain... ·Save again: - If you answer yes next question is: Save executable or data. ·Crunch more: - If you answer yes next question is: Buffer size. Now you should be able to take full advantage of this cruncher. Next things to tell are default values because this cruncher has quite many of them. Here are all the default values that can be selected with pressing the . ·Fix address: $ - default: No Fixing ·Efficiency - default: 2=#2048 bytes ·Max equal lenght - default: #126 bytes ·Save executable or data - default: E=save executable file ·Decruncher type - default: N=normal decruncher ·Decruncher location: $ - default: $100 ·Low memory address: $ - default: same as start address ·Jump address: $ - default: same as start address ·Save again - default: Y=save again ·Crunch more - default: Y=crunch more files ·IntEna ($dff09a): $ - default: $7fff ·DmaCon ($dff096): $ - default: $7fff ·AdkCon ($dff09e): $ - default: $7fff ·Status Register (SR): $ - default: $2700 Because this cruncher is a piece of individual work and was purely developed by a human being it has its own special features and habbits. I'll tell you something of them. Sometimes during the crunch process the display seems to freeze and you can't even abort the cruncher. Well it's because the cruncher is at the moment examing a long crunchable area. For example it takes a hell of a time to examine 50 kilobytes of zeroes. That's why there is Max equal lenght- option included. During the decrunch process all interrupts (tasks), dmas and floppys are turned off. Something about the efficiency of this cruncher. The crunching algorithm is very efficient to crunch lots of crunchable data. It's also efficient to crunch uncrunchable data if the data is in short pieces. But if you crunch for example long samples that aren't very crunchable the algorithm loses it's nice features and stars enlarging the file. You can see these cases from the lenght display during the crunching process (original lenght adds in $40 bytes steps). Probably I'll try to improve the algorithm for smaller data lost when crunching uncrunchable data. I have already got some nasty ideas for a logical algorithm which changes itself all the time to give the best result. Anyway this cruncher is good a tool to crunch code, graphics and what ever you want. I combined my experiments with crunchers and made this tool to fulfil the needs of a democoder. The crunched data can be easily seperated from the decruncher because the information of the original file is included into the crunched file. The sourcecode of the decruncher is at the end of this docfile so you can't miss it. All (lame)trackdemo coders should be happy of this feature. If you find any bugs from this cruncher or want to write me a long letter here's my address. Note! I don't have time to answer all letters but I'll try my best. Jouni Korhonen Hiihtomajantie 11120 Riihimaki FINLAND * If you would also like to talk to Jouni about other programming, or just to chat, he can also be reached on our W.H.Q. BBS in the coders section. If you are a coder, just give us a ring, and we shall get ya in touch. ECHO-BBS CAVE WORLD H.Q. 403-265-1991 HIGH SPEED RUNNING AMI-EXPRESS ON A 2000 WITH 9 MEGS OF RAM AND 210 MEGS [ 1.3 GIG SOON! ] CONFS FOR: CODERS/PROGRAMMERS, HACKING/PHREAKING, DEMOS, NEWEST WAREZ, TOP 100 GAMES. MOVEQ #0,D0 ;succeful exit RTS ;bye The Drcruncher for STC3.0 is built in... so no need for a source file, but just in case you have some older version kicking around, here is the source to the last update as well. ;DeCruncher for StoneCracker v2.99 destination= $28000 j: lea $dff180,a6 lea data(pc),a3 lea 12(a3),a5 lea destination,a0 move.l a0,a4 add.l 8(a3),a5 add.l 4(a3),a0 moveq #127,d3 moveq #0,d4 moveq #3,d5 moveq #7,d6 move.b 3(a3),d4 move.l -(a5),d7 deloop: moveq #0,d2 lsr.l #1,d7 bne.s not_empty0 move.l -(a5),d7 roxr.l #1,d7 not_empty0: bcc.s copydata bytekpl: move d5,d1 bsr.s getbits add.l d0,d2 cmp d6,d0 beq.s bytekpl byteloop: move d6,d1 bytebits: lsr.l #1,d7 bne.s not_empty2 move.l -(a5),d7 roxr.l #1,d7 not_empty2: roxr.b #1,d0 dbf d1,bytebits move.b d0,-(a0) subq.l #1,d2 bne.s byteloop bra.s test copydata: moveq #2-1,d1 bsr.s getfast moveq #0,d1 move.l d0,d2 move.b 0(a3,d0.w),d1 cmp d5,d0 bne.s copyfast lsr.l #1,d7 bne.s not_empty3 move.l -(a5),d7 roxr.l #1,d7 not_empty3: bcs.s copykpl copykpl127: move d6,d1 bsr.s getbits add.l d0,d2 cmp d3,d0 beq.s copykpl127 add.l d6,d2 add.l d6,d2 bra.s copyskip copykpl: move d5,d1 bsr.s getbits add.l d0,d2 cmp d6,d0 beq.s copykpl copyskip: move d4,d1 copyfast: addq.l #1,d2 bsr.s getfast copyloop: move.b 0(a0,d0.w),-(a0) subq.l #1,d2 bpl.s copyloop test: cmp.l a0,a4 blo.s deloop rts getbits: subq #1,d1 getfast: moveq #0,d0 bitloop: lsr.l #1,d7 bne.s not_empty1 move.l -(a5),d7 move d7,(a6) roxr.l #1,d7 not_empty1: addx.l d0,d0 dbf d1,bitloop rts ;------ crunched datafile data: