>-------L-------!-------!-------!-------!-------!-------!-------!------------R

CPC_T v3.1  - Nécessite  128 kb

8 Mars 2004

   Fichiers :  CPCT    .     :  Version disc.
CPCT31FR.TXT  :  Vous etes en train de le lire.
CPCT31EN.TXT  :  Message en anglais.         
OVL22   .ROM  :  Version ROM.
        

Remarques préliminaires (le meilleur, parait-il)
________________________________________________

La version ROM est intégrée avec DAMS-OVL v1.2, formant ainsi è la ROM OVL v2.2 (vous pouvez chercher à comprendre).  
Aussi, les notices de DAMS-OVL ont été jointes à ce pack, une è bonne chose de faite.
Les ceusses ayantinstall鐐 DAMS-OVLremplaceront è avantageusement cette ROM par OVL22. Je rappelle quela RSX ùBURN è autorise la programmation de la ROM dont elle est issue. C'est aussi è ça, Overlanders.


Utilisation
___________

ùCPC_T,"nom" [,"newname"]

Si "newname" est omis, le fichier compacté sera enregistré è avec le meme nom que le fichier source.
Attention, cette syntaxe rompt avec la logique de ùREN !


Le format "RSX" permet de lancer un compactage tout aussi è rapidement que s'il fallait passer par un menu et choisir un fichier è avec le curseur. Cependant, meme en version ROM, il ne s'agit pas è d'une RSX "transparente" :lancée avec
 paramètre, elle copie des è choses en BANK, en #BE00, en #BEB0, puis charge le fichier en #40...
L'abscence d'interface ne doit pas laisser croire qu'on puisse è retrouver ses données en mémoire (source, courrier intime sous è Protext, ...) à la fin du compactage.
Cette restriction provient de mon manque de courage à jongler è avec Himem, Lowmem, ... (*). De toute façon, pour les gros fichiers, è il aurait bien fallu faire place nette. 

CPC_T essaye plusieurs méthodes. Cette première phase n'est è qu'une simulation ! Les données compactées ne sont pas stockées, car è rien ne garantit que tout rentrerait en mémoire (le logiciel aurait pu è etre un peu plus intelligent, en essayant 
de stocker quand meme, quite è à écraser au fur à et mesure la version la moins bien compactée (*)).
Bref, ceci explique pourquoi il faut encore attendre, une fois è la méthode choisie, que le fichier soit réellement compacté (Sauf pour è la méthode #18 !).

(*) J'attends les facilités de gestion mémoire d'ANA pour introduire ce genre ède jonglage.

La phase de simulationest court-circuitée par l'appui sur CONTROL au è lancement de la RSX (à moins d'etre très rapide, cela revient à è valider la commande en appuyant sur CONTROL + RETURN au lieu de è RETURN) ou à la fin du chargement.


Venise sur le bateau, l'indication "Time" fournit une è mesure de la duréede décompactage, en milli-secondes (ou kilo-NOP !).


Restrictions
____________

Les fichiers BASIC ne sont pas encore gérés. S'il s'agit d'un è programme LM inclu dans un programme BASIC (qui se résume à un simple è CALL), il vous faudra isoler le code, le compacter, et l'inclure de è nouveau dans un lanceur BASIC.  

Pour l'instant, la taille maximale des fichiers est déterminée è par l'emplacement ram de l'AMSDOS. Par défaut, cela donne A700-40 = è A6C0. Cette limite n'est plus vérifiée, et CPC_T essayera de charger è le fichier dans tous les cas, quite à écra
ser l'AMSDOS.
En attendant le compactage de flux, unebidouille simple est è envisageable : initialiser l'AMSDOS plus haut (on gagne #500 octets) ! è Je ne l'ai pas fait, de façon à ce que la main soit rendue au BASIC en è cas de fichier non trouv鐠(il serait em
betant d'avoir à relancer la è version disc pour une simple erreur de frappe, non ?).



Emplacement du fichier compacté
_______________________________

CPC_T place le fichierde façon à ce que la zone de è chevauchement (entre données source et destination) soit maximale : è tout est calculé de façon à ce que les données compactées écrasées è soient celles qui ont déjà servi. Alo
rs, charger le fichier ne è serait-ce qu'un octet plus bas compromet gravement le décompactage. 
 
Mais ceci peut amener le fichier à dépasser #A700, rendant son è chargement improbable. CPC_T tente alors deplacer le fichier en #40, è et s'arrete là si cela ne déborde pas sur la zone destination.

Sinon, CPC_T propose une relocation automatique, en ajoutant è un LDDR qui copiera le fichier compacté à l'endroit adéquat è précédemment évalu鐠(écrasant forcément A700 : si vous souhaitez è récupérer le lecteur actif, il faudra patc
her).
Attention, la manipulation écrasera éventuellement le système è (si la zone dépasse B100). Le LDDR est précéd鐠d'un DI, ce qui è garantit un décompactage correct. Mais si le programme décompacté è utilise les vecteurs système (ne serai
t-ce que pour changer les è couleurs), il y a de grandes chances de plantage. Peut-etre qu'une è prochaine version proposera de rétablir le système.
La copie pourra meme atteindreC000. Dans ce cas, la pile est è entièrement prise en charge : elle est momentanément placée à un è endroit sur (juste après la routine de décompactage, elle-meme placée è à la fin de la zone copiée). Puis elle est
 replacée en C000. L'adresse è de retour est précieusement sauvegardée (sauf si le fichier d'origine è avait une adresse d'exécution non nulle, auquel cas il n'y a pas de è retour mais un saut direct dans le programme). En revanche, les autres è mots 
de la pile ne sont pas conservés.
De telles finesses permettent par exemple de lancer la version è compactée du fichier principal de Ghost'n'goblins sans aucune è intervention. On remarquera simplement que le programmeur du jeu a è raboté certaines initialisations.
Ceci dit, j'INSISTE une dernière fois sur le fait qu'en cas de è "relocation" écrasant le système (c'est à dire atteignant #B100),  ilè devient fort probable que l'exécutable obtenu plante (par exemple en è changeant de mode par l'appel système #BC
0E). Ce n'est PAS un défaut è de CPC_T !

Vous pouvez sans problème charger votre fichier ailleurs (du è moment que cela respecte les contraintes de chevauchement susdites).
EXCEPTION : cas du fichier "auto-relogé", car les adresses du LDDR è sont absolues.

Le cas des fichiers écran (en #C000) amène un petit è désagrément : la zone proposée déborde de #ffff. Théoriquement è acceptable, il vous faudra en pratiquecharger le fichier compacté en è RAM centrale, et recalculer l'adresse d'ex
écution.


La routine de décompactage
__________________________

Relogeable, elle n'utilise pas les registres secondaires, et è cohabite parfaitement avec le firmware et BASIC (d'ailleurs les è interruptions ne sont pas coupées pour les méthode #10 à #13).
La routine #18 coupe les interruptions, sans les rétablir. La è plupart du temps, cela ne changera rien, car elle seront autorisées de è nouveau au premier appel système ou par le programme lui-meme. 


Comparaison avec CPC_T 2
________________________

Il n'y a plus de signature dans le fichier. Seule la routine è de décompactage et la faible taille du fichier témoignent du doigté è d'Overlanders.

Méthode 10 : Il s'agit du meme principe que la méthode 00 (recherche è de chaine identique parmi les &100 dernières données décompactées), è mais implément鐠différement : la distinction chaine / nouveau è caractère ne se fait plus par un fl
ag, mais par un octet L codé comme è suit :
- Si L < 192, alors il s'agit d'une chaine de longueur L+3 (car les è chaines de longueurs 2 ne sont pas intéressantes).
- Si L >= 192, alors il y a L-191 nouveaux caractères à copier.

Ce type de codage ne semble avantageux que lorsqu'on cherche è des chaines sur une plus grande fenetre - methode 12 ou 13.
Mais les méthodes 10 à 13 reposent sur les memes routines, et è je n'ai pas jugé nécessaire de réintroduire la méthode 00, car, meme è dans le cas où elle serait plus efficace que la méthode 10, elle se è verrait sans aucun doute surpassé par une 
des autres méthodes.

Le gain en vitesse du compactage découle uniquement de è l'optimisation de la routine de recherche de chaine.

Méthode 18 : le système de codage des chaines devient "dynamique". On è codera une chaine courte et proche en 1 octet, tandis qu'une chaine è lointaine bénificiera d'un codage sur 3 octets.
La possibilité de se référer à n'importe quel endroit depuis le début è du fichier a réintroduit des durées de compactage inadmissibles, è malgré une tentative d'optimisation. 



Détails techniques
__________________

La version 1 de CPC_T utilisait une méthode "statistique" : les octets è les plus fréquents sont codés avec moins de bits. Par exemple la suite è ABADAACAC aboutirait à :
A -> 0
C -> 10
B -> 110
D -> 111

Cependant le codage n'était pas optimal. La méthode (codage de è Huffman) reviendra bientot, améliorée. 

Cette version là utilise un principe de subsitution. On écrit une è séquence de nouveaux caractères ou une chaine déjà rencontrée, définie è par (référence, longueur).
Par exemple la chaine BARBAPAPA se verrait codée BAR (0,2) P (4, 3). è Le (0,2) signifie la copie de 2 caractères à partir de la position 0. 

On cherche la plus longue chaine parmi lesNN dernières données è traitées (quireprésentent des données décompressées -donc è "disponibles"- à l'étape équivalente de la décompression).
NN vaut #100, #200, #400 ou #800 suivant la variante (méthodes 10, 11, è 12, 13 respectivement). Bien sur, plus NN est petit, moins on a de è chance de trouver des chaines intéressantes, mais en contrepartie le è codage de la référence prendra moin
s de bits.  

Pour les méthodes 10 à 13 (c'était aussi le cas pour les è méthodes 00 et 04), la routine de compactage ne trouve pas forcément è le meilleur codage possible. Illustration :

Imaginons la séquence AAAABCDEAAAAAA à compacter.
On obtient :   A (0,3) BCDE (0,4) (0,2)
Pourtant, le codage optimal serait : A (0,3) BCDEA (8,5)  
Ce dilemme se rencontre à chaque succession du meme chr. L'idée serait è alors de choisir automatiquement le codage "CHR + chaine" dans un tel è cas, mais ce n'est pas si simple. Prenons la séquence è AAAABCDEAAAAAABCD.
Avec la méthode actuelle :  A (0,3) BCDE (0,4) (2,5)
Notre idée est ici inopportune : A (0,3) BCDEA (8,5) (4,3)
Bref, il ne semble pas y avoir de moyen de décider localement è du meilleur codage. 


Quand une séquence de caractères n'est pas maximale (càd que è sa longueur est inférieure au maximum codable), ce qui suit est è nécessairement une chaine. A l'heure actuelle, on ne profite pas de è cette information, alors qu'on pourrait ré
assigner les codes "séquence è caractères" à une autre signification.  
Remarquez, s'il vous plait, que la routine de décompression è d'une telle variante serait en mesure de traiter les fichiers è compressés avec la méthode actuelle !


Dans le meme ordre d'idée (mais il s'agirait ici d'une è variante arbitraire et incompatible), après une chaine de longueur non è maximale, on pourrait supposer que ce qui suit est toujours un è caractère.
Reste à décider si cela serait statistiquement intéressant.


Pourquoi un nouvel utilitaire de compactage ?
_____________________________________________

C'est un domaine passionnant,notamment sur CPC, où toute è amélioration procède d'une vraie trouvaille. On ne peut guère è atteindre l'efficacité d'un archiveur (LHA, RAR, ...) : le cumul de è méthodes ou les encodages trop sophistiqu
ésse voient écartés, d'une è part pour des raisons de rapidité, et d'autre par car chez nous le è décompacteur est inclu dans le fichier. Quelprofit aurait-on à gagner è 1 ko sur un fichier, greffé d'une routine de décompactage de 2 ko ?  
Ici réside justement l'intéret particulier du compactage sur CPC : è proposer des méthodes toujours plus efficaces, sans sacrifier la è vitesse de décompactage.
Chaque nouvelle version de CPC_T montreen effet qu'on peut encore è gagner en taux de compactage de façon signicative, et ceci est une è première réponse à la question posée.

D'autre part, tous les softs existants présentent des défauts :
- lenteur du compactage (Crown, CPC_T 2 & 3.1, Elmsoft's TC)
- lenteur du décompactage (Flower Cruncher, routine Richard Aplin)
- corruption de fichier (Cheese ? CPC_T 2 ?)
- taille du fichier limitée 
- ...
CPC_T tend à devenir irréprochable.

Pour l'instant, Cheese 2.2, Flower ou Elmsoft se révèlent plus è efficaces sur certains fichiers. Mais à terme, CPC_T garantira le è meilleur résultat, ce qui évitera d'avoir à faire la tournée des è compacteurs. 

Si les productions se font rares, il reste aussi quelques è crackers passionnés à qui CPC_T est dédié. Quite à mettre un jeu en è fichiers, autant le compacter. Mais le plus important est alors de ne è pas perdre en durée de décompactage le te
mps gagné sur le chargement. è Ainsi, les déplomblages de X-OR sont quasi parfaits, mais quel dommage è d'avoir à patienter de longues secondes.
        Aussi, j'insiste là-dessus, la plus grande attention est è accordée à la rapidité de décompactage (typiquement, 2 fois le temps è que prendrait un LDIR pour déplacer les données).



A venir
_______


- Nouvelles 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 (à partir d'un fichier ou de la è mémoire), permettant de compresser des fichiers plus gros que 128 ko.
- Optimisation des routines de décompactages.


Attention ! Pour tout "report de bug", merci de préciser si è vous utilisez un émulateur, auquel cas votre descendance court un è danger.


Historique
__________


v3.1 (8/3/2004) : Sortie orificielle. Bugs introduits dans beta corrigés ! 
v3.1 Beta 2 
v3.1 Beta 1  
- Ajoute 1 méthode par substitution (#18) :
   fenetre #20 longueur 2 a 5, codé sur 1 octet.
ou fenetre #400 longueur 3 a 18, codé sur 2 octets.
ou pas de fenetre, longueur 4 a 35, codé sur 3 octets.
ou 1 à 32 nouveaux chrs.
- Essaieen priorité de placer fichier compacté au dessus de la zone è de décompactage.
- La taille du fichier n'est plus vérifiée (ce qui ne veut pas dire è que n'importe quelle taille est permise).


v3.0 : Apports mineurs par rapport à la version Beta.
  - Fichiers BASIC ou ASCII détectés (et refusés...).
- Permet de réutiliser CPC_T de suite (version disc). 
- Correction d'un léger bug dans la déclaration RSX (version disc).
- ESC annule lors du choix de la méthode à sauvegarder.
- Autorise seulement touches Y/N comme réponse. 
- Teste touche CONTROL (annulation simulation) également à la fin du è chargement.

v3.0 Beta 1 : Utilise 4 méthodes par substitution.
10 : Fenetre #100, distinction chr/chaine via codage longueur.
11 : Fenetre #200, idem
12 : Fenetre #400, idem
13 : Fenetre #400, idem

v2.0 (28/2/2000) : Utilise 2 méthodes par substitution. Compression è horriblement lente pour la 2ème. Décompression très rapide dans les è deux cas. Bon taux de compression.
Interface BASIC faite à la va-vite : la taille maximale des fichiers à è compresser s'en ressent un peu !

v1.1 : Correction bug affichage texte anglais. 

v1.0 (1995?) :Utilise un "pseudo-codage" à la Huffman. Temps de compression è honorable. Décompression horriblement lente (le fichier est è éventuellement compressé 2 fois de suite). Bon taux de compression.

                                ----***----