=-=-=-=-=-=-=-=-=-=-=-=> StoneCracker v4.10.3 <=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Questo compattatore puo' comprimere eseguibili, dati, e anche programmi non
rilocabili, cioe' assemblati con "ORG" e "LOAD" a degli indirizzi assoluti
(fissi) e salvati con il WB (Write Binary) anziche' con il WO.

Decruncher per eseguibili: gli hunk (ossia le SECTION) sono compattati, poi
all'inizio del file viene "attaccato" il decruncatore e il rilocatore, che
provvedera' a scompattare gli hunk (data_C, code ecc.) e ad allocarli nella
memoria giusta. Fatto questo viene fatta partire la section code iniziale.
nota: le data e instruction cache sono azzerate prima di partire.
nota2: il file compattato e' autosuffuciente, non richiede la stc.library.

Data files - viene compattato il file, qualsiasi cosa contenga, e non e'
attaccato nessun decruncher.

Programmi ad ind. assoluti - Questo tipo di programmazione e' la peggiore
possibile al mondo, non fate mai programmi di questo tipo. Comunque per
comprimere uno di questi file occorre immettere questi dati:

Load - $xxxxx indirizzo dove scompattare il file, lo stesso dell'ORG & LOAD
Jump - $xxxxx da quale address far partire l'esecuzione, normalmente si
	comincia dall'inizio, ma dipende da come avete organizzato la memoria

Ci sono 5 tipi di packmode, ossia di compressione. La piu' potente e' quella
a 16k, poi ci sono 8k, 4k, 2k, 1k. Conviene usare sempre quella a 16k, tranne
nei casi che il file da compattare sia piu' piccolo di 16k, in questo caso
puo' succedere che venga piu' corto il file con la compressione a 8k o 4k.
Questo numero e' la massima distanza di ricerca di stringhe uguali per la
compressione.

DataID - e' il suffisso che viene aggiunto alla fine dei file data compressi.

- In sostanza, l'uso di questo compattatore puo' essere di due tipi:

1) Compattare il file eseguibile salvato con "WO" da ASMONE, se questo file
   non e' "immenso". Il problema e' che se un file, ad esempio, e' lungo
   250Kb, e compresso viene 100Kb, per scompattarsi in memoria occorrono
   ben 100Kb+250Kb, perche' deve essere caricato in memoria il file compresso
   lungo 100Kb, e questo deve trovare altri 250Kb per "copiarci" il file
   decompresso. Se il file deve scompattarsi su Amiga con 1Mb, occorre tener
   conto del fatto che se fosse lungo 650Kb decompresso e 400Kb compresso,
   occorrerebbero 650+400=1050Kb, e solitamente ne rimangono liberi per
   un file circa 850-900!! Per quanto riguarda produzioni AGA, occorre
   tener conto il limite dei 2MB, anziche' 1MB. La miglior scelta e' quella
   di provare a compattare l'eseguibile con StoneCracker, e verificare se
   si decompatta sul computer di base. Se non ce la fa, allora si deve optare
   per il TitanCrunch, che e' piu' lento e meno efficiente, ma decomprime
   5Kb alla volta, liberando man mano la memoria, e cio' permette la
   decompressione di qualsiasi cosa.

2) Compattare dei dati, da caricare e decomprimere nel nostro programma.
   A questo scopo, e' presente la routine di decompressione. Per usarla,
   basta includerla nel nostro listato, ed eseguirla dandogli l'indirizzo
   dove si trova la figura, la musica o quant'altro compresso in a1, e
   l'indirizzo del buffer azzerato dove dovra' decomprimere i dati in a0:

	LEA	DEST,A0		; DESTINATION ADDRESS
	LEA	CRUNC,A1	; CRUNCHED DATA
	BSR.W	DECRUNCH

Vi sconsiglio vivamente di usare la compressione di file ad indirizzi assoluti
perche' non hanno futuro.


********* Documentazione originale sul formato del file compresso ***********

	Decrunch info header & decrunching

        Every file crunched with Stc4.02a or Stc4.10.3 has following header
        (16 bytes) at the beginning of the crunched data:

            "S404" or "S403"    ; cruncher version - string
            Security length     ; overlap size - longword (security)
            Original length     ; decrunched length - longword
            Crunched length     ; crunched length - longword
               .                ; crunched data starts
               .
               .

        Security length is always 16 + something.

        There are also two control words at the end of crunched data. For
        historical reasons it's quite wierd. I'll explain it with a 
        following picture:

        <<- Lower memory                           Higher memory ->>

                  +------------ Crunched length ------------+
                  |                                         |
        InfoHeader|......................LastWord|BitCounter|MaxBits
                            ^                 ^       ^         ^
                            |                 |       |         |
            Crunched data --+                 |       |         |
                                              |       |         |
                         Last crunched word --+       |         |
                                                      |         |
           How many used bits there are in LastWord --+         |
                                                                |
                         Efficiency (packmode - only in S404) --+

        If both crunched data and destination memory overlap there must
        be atleast 'Security length' distance between the start of the
        crunched data and the start of the destination memory:

        <<- Lower memory                               Higher memory ->>

                  <<<-------------- Decrunching direction --------------

        InfoHeader|......................LastWord|BitCounter|MaxBits
        ^
        |             |<------------ Destination memory starts here ....
        |             |
        +-- SecLen ---+
        |
        +---------------> Crunched data starts here..