>-------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 ayantinstallé DAMS-OVLremplaceront avantageusement cette ROM par OVL22. Je rappelle quela 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 simulationest 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éede 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 à écraser l'AMSDOS. En attendant le compactage de flux, unebidouille 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 embetant d'avoir à relancer la version disc pour une simple erreur de frappe, non ?). Emplacement du fichier compacté _______________________________ CPC_T place le fichierde 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. Alors, 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 deplacer 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 patcher). 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 serait-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 atteindreC000. 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 #BC0E). 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 pratiquecharger 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 flag, 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 lesNN dernières données traitées (quirepré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 moins 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ésse 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. Quelprofit 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 montreen 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 temps 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. - Essaieen 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. ----***----