how can i use code3? does it write to disc like v5?
what should i do when the packing is over? reboot?

Code3 Cruncher uses 64kB of extended memory as temp-storage. After packing just reboot and then select the Linker. It will save packed prog as normal DOS file.

Note: this cruncher has to be booted under DOS which doesn't format RAMdisk.

For best results select step to 7 and offset to 3-4.

In C3C v. 3.0 step is 7 by default and you can't change its value.

Hi Heaven,

try this:

http://www.magmalu.com/files/cruncher.zip

i use it, and it works fine!

still some bugs... and emulator vs real hardware... grrr... ;)

btw... i am using this in Boinxx

* this is the depacker written by Fox/Taquart

; Uncompress data stored in the DEFLATE format.
;
; DEFLATE is a popular compression format, used e.g. in ZIP and GZIP archives,
; and the ZLIB library.  The original description of this format
; is available in RFC (Request for Comments) 1951 in the file
; ftp://www.ietf.org/rfc/rfc1951.txt.
; Both compressed and uncompressed data must completely fit in the memory.
; As the compressed data is read sequentially and only once, it is possible
; for the compressed and uncompressed data to overlap, i.e. the data being
; uncompressed can be stored in place of some compressed data which has been
; already read.  There is no general rule, but practically both data may
; overlap almost entirely, with the uncompressed data ending just a few
; bytes before the end of the compressed data.
; If you want to modify this code to support non-continuous memory areas
; for the output, you should note that the uncompressed data is used as
; a look-behind buffer, up to 32K.
; As the code is not self-modifying, it can be put in ROM.
; This source code is written in the 6502 assembly language,
; using syntax of xasm (http://xasm.atari.org).

Try Flash Pack. When you presing Return with Control it adds ROM switching procedure and you can depack to RAM under ROM. But it needs buffer and you can't use INITs... Read the doc for details.

FP2.1 refuses to pack Venus as well...all packers who can handle depacking under ROM can't start the Code at $f000 after depacking...

ok. works now...i have put a small routine into standard RAM and it now works...but sad that i need to do that...

Hmm,
but I always use FP 2.1 to pack multi-segments into *one* packed segment. It works, as long as there is no init adress, just one run adress at the end...  but I guess thats not what you mean... you are surely talking of multi-segments with several inits after each segment - they cannot be packed with FP this way...

If the total length of a program (Superpacker) or the length of a single segment (DJ-Packer) is a problem, well I always use Fast-Packer first (packs segmentally, uses page 4 to depack) and when it got the program or segment shorter than 30-32kbytes, I use the Superpacker or DJ-PAcker (the one that uses page 5+6 to depack) to pack the program further...   Example: a Tron clone (forgot its name), before packing 279 single sectors, one segment and one run adress, cannot be packed with DJ (segment is too long) nor SP (program to long); packed it first with Fast-Packer to 165 sectors, then with DJ down to 121 sectors - the packed program works fine in the end...   greetings, Andreas Magenheimer.

This is a good choice if you need high compression ratio and quick decompression.
The destination buffer must be continuous, so if you need the uncompressed data to be scattered in the memory, you need to run an additional simple routine that moves blocks in the memory. Numen, of course, contains such a routine. :)

There are several problems with packing executables with embedded INIT routines:
* should the INITs be run while loading from disk (each part before INIT is decompressed separately; should the depacker be re-loaded after each part?) or while depacking (whole file is compressed) ?
* INIT routines are free to mess with the memory in an unknown (to the packer) way, therefore the packer does not know which memory remains available
* some INIT routines do system checking such as MEMLO or whether the loaded program is already installed - these checks should be run as early/quickly as possible
* in many cases INIT routines are small and doesn't compress very well if at all

Since I found no good solution, FP simply rejects executables with embedded INIT routines.
My experience is that INIT routines are especially useful for "loading" messages and these can be easily added to the already packed executable.

Not true, FP can do that.

or this? can't remember after messing around with the versions... http://www.atariage.com/forums/index.ph … p;id=47519