Logicielsmoto.com

Nous sommes le 28 Mar 2024, 10:01

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 66 messages ]  Aller à la page 1, 2, 3, 4, 5  Suivante
Auteur Message
 Sujet du message: Exomizer
MessagePosté: 26 Juil 2011, 09:28 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 26 Juil 2011, 11:48 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 253
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


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 26 Juil 2011, 13:08 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 26 Juil 2011, 13:26 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 253
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


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 26 Juil 2011, 18:15 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 454
Localisation: France
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 :)


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juil 2011, 00:10 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
gilles a écrit:
si tu connais la taille du out a priori, tu peux éventuellement le charger cadré à la fin du buffer
Oui tout a fait.
Citation:
(mais il y a peut être des cas extremes ou tu vas recouvrir tes données d'entrée...).
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.
Citation:
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).
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juil 2011, 08:50 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
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" :lol:

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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juil 2011, 18:03 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 454
Localisation: France
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...


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 28 Juil 2011, 09:59 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 28 Juil 2011, 12:31 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Fool-DupleX a écrit:
(sans la table, mais avec les variables).


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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 28 Juil 2011, 18:01 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 454
Localisation: France
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 :)


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 29 Juil 2011, 08:21 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 29 Juil 2011, 18:06 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 454
Localisation: France
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 29 Juil 2011, 18:41 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Fool-DupleX a écrit:
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.

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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 02 Aoû 2011, 16:39 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
Je ne suis pas sur, je pense qu'on lit 11.

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

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


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 66 messages ]  Aller à la page 1, 2, 3, 4, 5  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 38 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com