Logicielsmoto.com

Je relance ici le topic sur Exomizer, qui n'aurait pas du parasiter les demos de Puls, je suppose.

J'ai ecrit un code assembleur 6809 qui pour le moment fait autour de 250 octets, sans les tables et les variables. Cette partie etant de toute maniere incompressible et cree a la volee, elle ne nous interesse pas. Le code est testé et validé sur MO5 avec deux archives generees par Exomizer sur PC.

Je pense qu'on peut faire mieux. Je vais donc encore reflechir un peu a sa structure avant de vous en faire part.

250 octets c'est déjà bien.
Tu as codé une version qui décode dans le même espace ou bien avec des buffers séparés?

_________________
http://www.alternative-system.com

Séparés. Mais en même temps, le concept de même espace me déroute un peu : vu que le code decomprimé est forcément plus grand que le code comprimé, il va forcément rattraper ce dernier un jour et l'écraser, donc comment faire ? un recouvrement partiel par contre est envisageable, mais ca ne change strictement rien au code, car l'algo deroule le contenu de la partie comprimee sans jamais revenir en arriere. Les litteraux sont pêchés dans le code décomprimé. il suffit de bien choisir ses pointeurs in et out.

si tu connais la taille du out a priori, tu peux éventuellement le charger cadré à la fin du buffer (mais il y a peut être des cas extremes ou tu vas recouvrir tes données d'entrée...).

ce serait surtout utile pour les MO5/TO7, sur les TO8 et 9+ il y a de quoi faire entre la ram en espace ROM et les banques.
au pire on peut faire le in en vram... en remplissant à x00 la page couleur ca ne se verra même pas... (il faudra changer la couleur du tour de temps en temps pour montrer que c'est encore vivant).

_________________
http://www.alternative-system.com

En effet le décompresseur "in-place" travaille soit avec les données compressées à la fin du buffer, soit en décompactant à partir de la fin du fichier. Il y a des variantes du compacteur pour aller avec si je me souviens bien.
Bonne optimisation en tout cas, on attend tes résultats avec impatience

Oui tout a fait.
Comme l'algo recopie l'octet decompressé loin de la zone où l'on écrit, et qu'on lit les données précédemment décompressées, les données devant être lues sont toujours préservées je pense. Du coup le pb en question ne doit pas se produire.
Un truc sympa serait d'appeller K7CO dans get_compressed_byte() pour récupérer les octets en flux-tendu sans buffer. FoolDuplex a même suggéré de lire les bits un à un dans le PIA directement depuis la K7 dans get_bits().. Bref cet algo ouvre pas mal de possibilités de customisations sympatoches sur thomson.

sam.

PS: question taille mon petit doigt m'a dit que cà peut tenir dans bcp moins que 200 octets sur 6809 quand on adapte l'algo à un proc 16bits plutôt que 8bits.

Sam et moi on se tape la compèt'. Je suis en train de finir mon code en utilisant une de ses optimisations, il a utilise une des miennes, on va voir a combien j'arrive, mais c'est prometteur, je devrais aussi etre en dessous des 200 octets.

En ce qui concerne le recouvrement des buffers, la situation simple est celle ou on ne connait pas la position du dernier litteral dans les donnees d'entree (il faudrait parser a l'avance et fournir l'info dans le format du fichier) et dans ce cas, recouvrir les donnees d'entree est dangereux: dans le cas limite, les 3 derniers octets pourraient etre un litteral. A l'inverse, on peut construire un cas ou il y a beaucoup de litteraux des le debut du buffer, mais avec de longues chaines de repetition de sorte que la sortie va submerger le buffer d'entree. Pour toutes ces raisons, j'ai du mal avec la notion de buffer in recouvert, sauf si on sait a l'avance que le buffer de sortie s'arretera avant la lecture du dernier litteral dans le buffer d'entree.
Cette info pourrait etre rajoutee dans le fichier dans le cas ou on aurait vraiment peu de ram a dispo. Mais comme on dit, "32 KB ought to be enough for everybody"

Lire les bits directement depuis la cassette permettrait d'eviter le buffer d'entree, de gagner du temps (decompression simultanee avec la lecture) et de la place (plus besoin de routine getbits). C'est un peu moins simple a faire sur MO5, car il faut respecter des timings stricts, mais sur cette machine, couple a un format cassette optimise, ca pourrait arracher.

Je sais que le décompresseur z80 n'utilise pas les literal sequences (et il y a une option dans le compresseur aussi). Je sais pas ce que ça fait, mais en tout cas ça marche très bien pour la décompression in-place...

C'est tres simple : ca compresse moins bien sans les litteraux. Et il est clair aussi que tu peux decompresser in place sans les litteraux puisque l'algo n'a plus a aller chercher de l'info dans la source, c'est comme derouler un tapis.

Bonne nouvelle ! Grâce aux suggestions de Sam et Prehisto, j'ai un code fonctionnel qui fait la totale, avec litteraux et preservation du contexte d'execution, en seulement 195 octets (sans la table, mais avec les variables).

Alors que je pensais avoir atteint le but ultime, v'la-t'y pas qu'Prehisto en remet une couche et trouve encore 3-4 octets a economiser. C'est les soldes, faut profiter.

Peut-etre une version finale d'ici demain matin.

A propos de table (il est midi, mais ca n'a rien à voir).. il y a une zone de 192 octets en fin d'écran qui est +/- dispo. C'est un bon endroit pour y stocker la table de 3*52=156 octets.

Bon par contre je sais que le moniteur en utilise un bout (stockage de palette, date et mode écrans je crois?). Connait-on quelles zones précises dans ces 192 sont utilisées par le monitor, et si l'on pourrait y trouver une zone de 156 octets libre indépendamment de la version du moniteur?

Moi j'ai toujours trouvé que cette zone de 192 pouvait être utile de temps en temps, et là c'est plutôt bien indiqué je trouve avec le fait que si on utilise l'algo pour compresser les écrans on peut avoir automatiquement une table pour la RAMA et une différente pour la RAMB.

sam.

Je n'ai pas eu l'impression que les literal sequences étaient utilisées très souvent. Enfin, si ça marche avec, tant mieux

Pour la zone libre en fin d'écran, elle n'est pas utilisée sur MO. C'est déjà ça de pris

A la fois vrai et faux. Cette zone est utilisée par Logo, LSE et surtout par le Nanoreseau.

Notons au passage que si cette zone existe bien sur TO7 aussi, la page de couleur ne contient pas des octets mais des mots de 6 bits.

Sans les litteraux, on pourrait probablement encore gagner 20 ou 30 octets, peut-etre meme plus. Ca peut etre interessant d'essayer. Mais dans ce cas, on tend vers un LZ77 plus classique et je pense que les performances seront proches de celles des algos deja mis au point par Puls, qui tiennent en 128 octets.

L'interêt d'Exomizer est surtout à chercher du côté du compresseur qui fait beaucoup d'efforts pour trouver une solution optimale. Je ne sais pas si vos algos ont un compresseur aussi efficace ?

Du côté de la décompression il n'y a rien de très compliqué, mais la compression fait en sorte que ça soit assez efficace.

Ah oui ca va marcher beaucoup moins bien s'il manque 1/4 des bits. Pour ma culture générale: on récupère quoi comme bits en lisant la RAMB du TO7 pour ces bits manquants: 0, 1 ou du bruit?

sam.

Je ne suis pas sur, je pense qu'on lit 11.

Petit point sur l'algo : apres rabotage severe par notre maitre venere la version actuelle fait 183 octets. 12 octets de mieux que ma version, je suis vraiment mauvais

Mais on approche du final. Nous sommes en train d'optimiser un peu la vitesse.