Notice française de CPC_T. Compacteur shareware version 1.0. Par MadRam 7/96. Fichiers : CPCT .BIN CPCTDOC .FRA CPCTDOC .ENG COMPACTEUR ? Un compacteur (cruncher) réduit la taille de vos fichiers. La perte de temps due au décompactage est compensée par le gain de temps lors du chargement. SHAREWARE ? Vous pouvez garder, distribuer et essayer un programme shareware gratuitement. C'est seulement si vous l'utilisez qu'il vous faudra envoyer une contribution financière. Vous serez alors "enregistré" et tenu au courant des nouvelles versions. La participation des utilisateurs engage l'auteur à sortir de meilleurs versions. De plus sur CPC, le shareware permet de pallier a un manque de structures commerciales. Pour CPC_T, la participation est de 32 Frs. Enregistré ou non, vous pouvez demander des améliorations, toutes les remarques seront prises en compte. CPC_T Tout d'abord je précise qu'il existe beaucoup d'autres crunchers, dont CHEESE (v2.2 à cette date), eux entiérement gratuits (freeware). CPC_T ne fonctionne pas sur 64 ko. Il compacte uniquement les fichiers binaires, de longueur maximale #A6BC. Le compactage dure au plus 2 minutes (si le prog s'éternise, il est probablement planté, chose qu'il serait bon de me signaler !). Le nom vient du mot ComPaCTeur, formant ainsi les lettres magiques CPC, clés d'une porte donnant sur un monde merveilleux. COMPACTAGE J'ai moi-meme trouvé la méthode utilisée (ce qui ne veut pas dire qu'elle soit originale). De plus je pars de l'idée : essayons de rendre un fichier compacté le plus "recompactable" possible. C'est pourquoi CPC_T compacte plusieurs fois le fichier de départ (ce qui rallonge le temps de décompactage...). Il est possible que le fichier obtenu soit encore compactable, par CPC_T ou par un autre cruncher. FICHIER COMPACTE A chaque compactage, on obtient un fichier compacté (données compactées + routine de décompactage) relogeable (sauf dans 1 cas, voir plus loin). La routine de décompactage est toujours placée après les données. CPC_T essaie d'abord de placer le fichier compacté a une adresse aussi proche que possible de l'adresse du début du fichier source mais telle que lors du décrunchage, les données décompactées n'écrasent pas les données compactées qui n'ont pas encore "servi". Ainsi si vous chargez le fichier compacté à une adresse supérieure à celle indiquée, pas de problème, mais à une adresse inférieure ne serait-ce que d'1 octet, il y aura écrasement. Le fichier ainsi placé peut dépassé l'adresse #FFFF (cas d'un fichier source dans la mémoire écran). Le fichier compacté sera alors mis de façon à ce que son dernier octet soit en #8000. Dans ce cas là il peut évidemment etre chargé à une adresse plus petite. Il peut aussi dépassé l'adresse #A6FB. Le prog le place alors avant le fichier source. Dans ce cas, vous ne pouvez pas le charger après l'adresse indiquée, sinon quoi les dernières données compactées seraient écrasées par les premières données décompactées. S'il n'a y pas de place avant le fichier source, le fichier obtenu se terminera en #A6FB ; lors de l'exécution, la routine sera copiée en #C000, puis les données à une adresse telle qu'il n'y aura pas d'écrasement. Une partie de la RAMDOS est ainsi détruite. Pour de chargement, il faut penser à sauver le lecteur actif avant de décruncher. Dans ce tout dernier cas, le fichier n'est pas relogeable (les adresses de départ pour les recopies sont absolues). DECOMPACTAGE La routine coupe les interruptions, écrit sur la pile pour entre autre sauvegarder les registres secondaires, et RETABLIT les interruptions. Elle n'utilise aucun buffet, mais comme le fichier à été compacté plusieurs fois, il est possible qu'outre la zone du fichier décompacté, d'autres espaces mémoires soient utilisés. L'AUTEUR MadRam fan de CPC, alias YVES GEREY Les pataudes 87220 BOISSEUIL FRANCE Tel : 55 31 17 97 ou retrouvez moi sur minitel 36 14 (0.36 Frs la minute ou 0.13 après 22h30) CNX. A bientot dans ma démo et dans une nouvelle version de MAGIC-COPYFILE (Copieur de fichiers). ------*-*------

CPC_T English notice. Shareware cruncher version 1.0. By MadRam 7/96. Files : CPCT .BIN CPCTDOC .FRA CPCTDOC .ENG CRUNCHER ? A cruncher reduce the length of your files. The loss of time due to the uncrunchage is compensated by the earnings of time then loading. SHAREWARE ? You can keep, distribute and try a shareware software gratuitously. It's only if you use it that you must sent a financial contribution. Then you will be "registered" and informed of new versions. Users's participation urge the author to release better versions. And, on CPC, shareware permit to palliate to a lack of commercial structure. For CPC_T, the participation is 32 Frs (4 pounds). Registered or not, you can ask for improvement, all the remarks will be taken into account. CPC_T Before all I state precisly that there are a lot of other crunchers, of which CHEESE (v2.2 to this date), them completly gratuitous. CPC_T doesn't work on 64 kb. It only crunch binary file, of maximum length #A6BC. Crunching lasts the most 2 minutes (if the soft stretches, it must be planted, which you should signal me). Name comes from the word ComPaCTer, forming the magic letters CPC, keys of a gate looking into a wonderful world. CRUNCHING I have found myself the used method (which doesn't mean that it's original). And I rise from the idea : let try to make a crunched file the most "recrunchable" possible. It's why CPC_T crunch several times the file (which lengthens decrunchage duration...). The obtained file may be crunchable again, by CPC_T or by another cruncher. CRUNCHED FILE At each crunching, we obtain a crunched file (crunched datas + decrunchage routine) relocatable (except in 1 case, see farther). The decrunchage routine is always put after datas. CPC_T first try to put crunched file at an adress as near as possible that source file's beginning adress, but such that while decrunching uncrunched datas don't crush not-yet-decrunched datas. So, if you load the crunched file to a higher adress that the indicated one, no problem, but to a lower adress (even only 1 byte), there will be crushing. The so put file can pass the #FFFF adresse (case of a source file in screen memory). Then the crunched file will be put such that its last byte be at #8000. In this case, it can of course be loaded at a lower adress. It also can pass the #A6FB adress. Then the soft put it before the source file. In this case, you can't load the file higher that the indicated adress, if not the last crunched datas would be crushed by the first uncrunched datas. If there isn't place before source file, the obtained file will finish at #A6FB. Then starting running, the routine will be copied at #C000, and the datas at a such adress that there won't be crushing. A part of RAMDOS is destroyed. For a loading, you must think to save the current drive before decrunching. In this very last case, the file is not relocatable (beginning adresses for copies are absolute). DECRUNCHING The routine disable interruptions, write on pile for save secondair registers, et ENABLE interruptions. It doesn't use buffer, but as the file may be crunched several times, it is possible that, farther the decrunched file zone, some other memory spaces be used. THE AUTHOR MadRam fan of CPC, alias YVES GEREY Les pataudes 87220 BOISSEUIL FRANCE See you soon in my demo and in a new version of MAGIC-COPYFILE. ------*-*------