This program is FREEWARE: it may be freely copied and used as long as all the files are unaltered and the application is not sold for profit etc. Putting it on a public file server is okay. You're also allowed to use your crunched files and the Decrunch module where you want, even in commercials... Of course I cannot be held responsible for any data loss... Use of the Decrunch module in commercial products is allowed at the conditions that 1) You don't claim the module is your work, and 2) You don't sell the module for itself, so only the contents of your work can justify the price...
*Important*: This is NOT an archiver! The files created are crunched and stay crunched for ever, at least for executables!
This application is the multitaking version of an old tiny executable made by me to compress executables just as Acorn's Squeeze does, but usually more efficiently when mixed data is involved. The latest non multitasking very non user friendly version was 'CrunchC030'. By the way, the very first version was a conversion from the CBM64...
Now the interface and the algorithms have been completly reworked in order to be easy to use and fast. Those who used the older version will notice the difference in compression speed.
The application works fully multitasking with the interface looking like RISC OS 3 filer operations windows...
As a bonus, clicking ADJUST on the Cruncher icon will bring a RM merger window. It allows to build an executable that'll install a given number of modules in RMA when run. Of course you can later compress it with Cruncher to gain disk space.
However, it is probable that this program will not be of full interest to real users, but would rather be enjoyed by real programmers.
Features
--------
- Launch the !Help application for more info.
- Should work on all versions of RISC OS and all ARM processors, although it has been tested only on RISC OS 3.11, 3.5 and 3.7 (StrongARM).
- Should work on any configuration, like floppy-only (like me!) or 1Meg-only.
- Can handle a selection of files dragged to its iconbar icon. Files to crunch are simply queued until the current crunch job is finished. This method is more efficient than crunching all the files in parallel, both in the point of view of file access (seek time) and memory usage (have you noticed how multiple filer operations are slow and memory hungry on RISC OS 3?)
- You can alter a parameter in the !Run file to set the maximum memory claimable by Cruncher: more memory speeds up the algorithm a LITTLE bit and could be an advantage when filing is on floppy. You can also set it to the minimum since in that case the application will only grab the minimum memory it really needs.
- When dragged to !Crunch, Absolute, load/exec, BASIC, Module and Sprite files are crunched and converted to Absolute type.
- Depending on your choice at crunch time, crunched files can later either be run or uncrunched using the SWI's provided by the Decrunch module to be found in this application directory.
- Restrictions: when crunching sprites, only a screen dump of the right width and no wastage and no mask will be handled correctly. Tip: if a crunched screen gets the colours wrong then: 1) *ScreenLoad the original, 2) *ScreenSave to something, and 3) Crunched that something. It should work.
- Reliability: it's possible for a file containing no compressable data at its start to not decrunch properly, although I've not seen such until now. So always check it runs as it should!
Some tricks from control window
-------------------------------
- The exec address can be entered relative to the load address by prefixing with a '+'.
- When crunching a data file, the output is forced to data type. In that case the exec address field provides the default load address of the data.
- When crunching files other than data, giving an 'Other' load address of zero produces a data file. In that case an 'Other' or the filetype default exec address also sets the reload address of data.
Technical details
-----------------
- The decompression code uses only at most 604 bytes at the decompressed data
top. It doesn't need any extra workspace.
- All is written in pure ARM code.
- When running the decompression routine is in SVC mode with interrupts
unaltered. R13's registers are not used and not corrupted. On exit processor
mode and interrupts and R13 are unaltered, the rest is corrupted.
About efficiency: usually more efficient than Squeeze or any LZW algorithm when mixed code is involved, I mean something like demo or application code. LZW can be a little bit better on pictures and Squeeze a little bit better on ARM-code-only data. In fact I noticed recently that my algorithm is a kind of LZ77 compression scheme!
Decompression speed: it IS FAST. I think I can't make it faster since all registers are fully used... It's not as fast as Squeeze since it's byte oriented; Squeeze is word oriented so it can use LDM/STM but the drawback is 'lack' of compression efficiency.
Decrunch module SWI's
---------------------
--- Decrunch_Decrunch (SWI &C0AC0) ---
Decrunch crunched data
Entry: R0= % b4 b3 b2 b1 b0 (flags, other bits must be 0)
b4= force destination address
b3= use hourglass
b2= decrunch data from memory
b1= use a file handle instead of a filename pointer
b0= assume magic string not present
R1: case b2 b1
0 0 : R1= source filename pointer
0 1 : R1= source file handle
1 0 : R1= pointer to source data in memory
1 1 : Undefined behaviour
R2: case b4= 1 : R2= destination address in memory
b4= 0 : R2= irrelevant
Exit: if V set then R0= pointer to RISC OS error block
other registers preserved
file pointer unchanged (if using file handle)
else
R0 preserved
R1= case b2 b1
0 0 : R1 preserved
0 1 : R1 preserved
file pointer advanced for further use
1 0 : R1 points to the end of source data for further use
R2= load address found in the source data
R3= length of uncrunched data
All else is preserved
Processor mode: the decompressor works in SVC mode so you can decrunch to protected memory.
--- Decrunch_Get (SWI &C0AC1) ---
Get information about crunched data.
Entry: R0= % b3 b2 b1 b0 (flags, other bits must be 0)
b3= use hourglass
b2= decrunch data from memory
b1= use a file handle instead of a filename pointer
b0= assume magic string not present
R1: case b2 b1
0 0 : R1= source filename pointer
0 1 : R1= source file handle
1 0 : R1= pointer to source data in memory
1 1 : Undefined behaviour
Exit: if V set then R0= pointer to RISC OS error block
other registers preserved
file pointer unchanged (if using file handle)
else
R0, R1 preserved
R2= load address found in the source data
R3= length of uncrunched data
File pointer unchanged (if using file handle)
All else is preserved
The latter SWI is fast because the data does not need to be uncrunched to get information about uncrunched data.
Beside RISC OS errors, both SWI's can also return a special Decrunch error indicating that the source data format is not recognized:
Error number &C0AC0: Data not crunched
--- Notes ---
Decrunching from memory:
The source data must not overlap with the space where the uncrunched data is put.
Skipping the magic string:
At the start of each data file produced by !Crunch there is an 8-byte magic string so that Decrunch can check whether it can cope with the file. You can bypass that check when you use "unmagical" files (i.e. with the first 8 bytes removed) by setting bit 0 of the flags.
However, using files with no magic string does not allow Decrunch to check for newer versions of the format and compression scheme, and so these files won't be compatible with such newer decrunchers.
Memory:
The decruncher does not requires any extra memory when decrunching.
That's it for now... I hope (and I've already heard) that you enjoy !Crunch and hello to other cool hackers! (and not to lame crackers)
--
The latest version of !Crunch can be found at:
http://gate-fun.cediti.be/~bju/myprogs.html
My email address: bju@cediti.be
Bernard Jungen for BASS, February 1994/June 1995/November 1996.
