CPC_T v2.0 Routines de compressions/décompressions. Overlanders 2000.
Nimporte'naware.
Fichiers : CPCT .BAS : Interface. Utilise les binaires.
CPCT .SCE : Source routine compression
CPCT-1 .BIN : Binaire de la méthode 1.
CPCT-2 .BIN
CPCT-U .SCE : Source routine décompression.
CPCT-U1 .BIN : Binaire de la routine de décompression.
CPCT-U2 .BIN
CPCTDOC . : Vous etes en train de le lire.
CPCTHIST. : Historique des versions.
CPCTSAVE.BIN : Sauvegarde à une adresse arbritaire.
CPCTSAVE.SCE :
- Ask for English Documentation. If you make a translation, please
send it to me it'll be included next time -
. Pourquoi un nouvel utilitaire de compression ?
On peut toujours faire mieux dans ce domaine. Pour l'instant deux
méthodes sont proposées :
- Une très lente (autant que celle du Crown Cruncher).
- Une pas trop lente !
La deuxième n'est pas forcément moins efficace que la première.
Dans les deux cas, la décompressionsera vraiment très rapide (un
peu plus rapide que celle du Crown Cruncher).
De plus, on ne sait pas toujours ce que font les routines de
décompression des autres utilitaires. Ici,cette notice décrit
leur comportement, les sources sont fournis, et beaucoup
d'indications sont (ou seront lors de prochaines versions !)
indiquées lors de la compression.
Par exemple, CPC_T indique les adresses auxquelles charger le
fichier compressé, telles que lors du décrunchage, les données
décompactées n'écrasent pas les données compressées qui n'ont pas
encore "servi".
On peut imaginer un fichier compressé placé de #4E7E à #8313 qui
fourni sans problème des données s'étalant de #100 à #8054.
. A venir :
- Interface assembleur, qui permettra de gérer des fichiers plus
gros !
- Accélèration de la compression.
- Autres méthodes de compressions (et amélioration de celles
existantes).
- Détection de fichiers déjà compressés par d'autres utilitaires,
avec possibilité de décompresser avant de tester les méthodes de
CPCT !
- Détection du type de fichier pour proposer des routines dédiées
(affichage de Windows OCP, etc...)
- Gestion de "flux" de données, pour compresser des fichiers plus
gros que 128 ko.
. Comparaison avec la version précédente (1.0) :
Il n'y a que le nom de commun. En effet on a perdu l'interface
assembleur (qui reviendra reliftée bientôt), et les méthodes
sont complétement différentes. Plus de détails vous attendent dans
le chapitre technique et dans "CPCTHIST.TXT".
. Nimporte'naware ?
La précédente version était shareware. Merci à GREES, TOM&JERRY et
SHAP !
Celle-ci est nimportenaware.
Le concept est plus sérieux que le nom ; il s'agit d'envoyer une
participation dépendant de :
- l'utilisation que vous faites du logiciel.
- la valeur à laquelle vous l'estimez.
- vos propres moyens.
De plus, je ne demande pas obligatoirement d'argent. Vous pouvez
m'envoyer des choses plus originales ou personnelles (n'en
profitez pas pour me fourguer des saloperies !). Au cas où, voici
quelques-uns de mes centres d'intérêts :
- le Hard Rock (Heavy Metal, Progressif couillu...), la BD
européenne, le cinéma, le sexe (heu... je plaisante, Maman !).
Merci d'avance, Dieu (ie le grand Tout) ne vous le rendra pas
forcément !
. Un logiciel non-gratuit sur CPC ?
Une rénumération m'évitera autant d'heures de travaux avilissants,
que je pourrais alors consacrer au CPC, pour votre plus grand bien
:-)
. Détails pratiques :
Plusieurs routines de décompressionsseront proposées, suivant le
contexte dans lequel vous comptez les utiliser (utilisation
possible ou non des registres secondaires, etc).
L'une d'entre elles devrait même permettre de récupérer les
données petit à petit, séquentiellement.
Les versions "Fast"(cf source) utilisent #200 octets,à partir de
l'adresse de type #XX00 (XX pair) la plus proche de la fin de la
routine (adresse "dynamique" qui dépend d'où vous chargez le
fichier).
Par contre, le gain en vitesse n'est pas flagrant par rapport au
temps de décompression total. Je vous déconseille donc cette
variante !! D'ailleurs l'interface BASIC ne le propose meme pas.
Je l'ai laissée au cas où...
Les versions normales n'utilisent par contre aucun tampon ! Les
seules données écrites (outre le fichier décompressé évidemment)
le seront dans la pile.
Les interruptions ne sont pas coupées, les routines cohabitant
parfaitement avec le système.
. Détails techniques :
La version 1 utilisait une méthode "statistique" ; les octets les
plus fréquents sont codés avec moins de bits. Par exemple la suite
ABADAACAC se coderait :
A -> 0
C -> 10
B -> 110
D -> 111
Cependant le codage n'était pas optimal. La méthode (codage de
Huffman) reviendra, améliorée, dans la version 3.
Cette version là utilise un principe de substitution. Un flag
indique s'il faut recopier un nouveau caractère X ou une chaine
déjà rencontrée, définie par (référence, longueur).
Par exemple la chaine BARBAPAPA se verrait codée B, A, R, (0,2),
P, (4, 3). Le (0,2) signifiant qu'on copie 2 caractères à partir
de la position 0.
Dans la première variante, on cherche la plus longue chaine parmi
les données déjà traitées (qui représentent les données
décompressées -donc "disponibles"- à l'étape équivalente de la
décompression). La recherche est naïve, ce qui explique que la
durée de compression soit exponnentiel. Ceci sera corrigé
bientôt.
La référence est stockée sur 2 octets, ce qui gâche de la place
si le fichier d'origine ne fait pas plus de 32ko, mais ce qui
accélère la décompression.
La longueur est codée sur 1 octet (longueur max de chaine 258).
Dans la deuxième variante, on introduit la notion de "fenêtre
coulissante" : on ne cherche les chaines que parmi les N dernieres
données traitées. La durée de compression est alors linéaire.
Bien sûr, les chaines trouvées sont moins longues (ou de taille
égale dans le meilleur des cas) que sans fenêtre, ce qui tendrait
à diminuer l'efficacité de la compression. Mais si N=#100, ceci
est compensé par le fait qu'on puisse stocker les références sur 1
octet seulement.
La longueur est aussi codée sur 1 octet (longueur max 257).
Avantage pratique : on n'a plus besoin de conserver les premières
données, ce qui permet par ailleurs de compresser des "flux" de
données dont la taille totale peut dépasser 128ko.
C'est cette variante que j'utilise pour la compression des
fichiers AY/YM (avec la possibilité d'étendre la fenetre à n*#100
octets).
. Signature de compression.
La méthode de compression utilisée est stockée dans la signature,
du type CPCT2.0(x) où x répond aux attributions de la liste ci-
dessus. Un même numéro désignera toujours la même méthode,
indépendamment de la version de CPCT utilisée, qui n'est indiquée
dans le fichier que par souci de... "traçabilité" on va dire.
00 : Fenêtre #100, longueur stockée en négatif, référence relative.
01 : Réservé
02 : Réservé
03 : Réservé
04 : Sans fenêtre, longueur stockée en négatif, référence absolue.
----***----