Logicielsmoto.com

Voici un fichier K7 que j'ai fait compressé par EXOMIZER2. Le binaire d'origine fait 29-30ko, et on récupère un binaire de 6ko à la fin, soit un temps de chargement K7 divisé par 5.

Pour le faire marcher, placez le curseur en haut de l'écran (vous comprendrez plus tard lors du chargement), puis tapez sous basic1. Sous basic2 ca doit marcher en précisant "CASS:".

Pour les curieux j'ai réalisé un exe qui crée des binaires "EXOmizer"isés.. Plus de détails bientôt j'espère.

Edit: sous basic2, ca merdouille un peu. La cause est la pile qui pointe en plein milieu du code décompressé. Je vais devoir modifier le décompresseur pour qu'il se positionne la pile dans la page 0 (il va grossir de 3 octets... C'est énorme!)

hey hey joli coup Sam !

joli de voir qu'on gagne que 12 octets sur 6 Ko quand on range un fichier exomizer dans un zip

Sur MO5, j'aimerais beaucoup combiner ca avec un codage k7 plus optimal, je suis sur qu'on peut gagner encore un facteur 2 sur le signal K7 ...

Combien de temps a la louche pour la decompression proprement dite ?

Et tu charges en memoire puis tu decomprimes ou tu decomprime a la volee depuis la cassette ?

Oui probablement. Similairement, sur TO je me suis déjà demandé pourquoi on devait utiliser 5 periodes a 4.5KHz et 7 periodes a 6.3Khz et pas seulement 2 ou 3 de chaque? Les erreurs K7 probablement, mais on pourrait utiliser des code correcteurs d'erreurs.


3 secs à la louche.


Oui c'est un binaire thomson comme un autre. Il est chargé en mémoire puis décompressé. Le fait que ce soit un binaire standard permet de le copier avec les outils convetionnels.

L'outil que je me suis fait pour convertir les ".BIN" en ".EXO" (notez la proximité avec .EXE) détermine une adresse de chargement du fichier EXO qui n'écrase pas le fichier d'origine. Dans le cas de l'exemple, le binaire est gros et occupe quasiment toute la mémoire. L'outil de compression a trouvé que le mieux était que le ".EXO" se charge en RAM-écran et du coup on voit à l'écran le code compressé. Il faut faire gaffe à ce que le curseur reste "au dessus" de cette zone pour ne pas trasher le résultat. Si on se permet d'avoir un loader + gros on pourrait envoyer le code a moniteur pour effacer le curseur dans ce cas. A prévoir pour les évolutions futures.

Sinon j'ai dans mes cartons un décompresseur EXO depuis K7/D7 qui n'a pas besoin de mémoire tampon. Avec lui la partie résidente en mémoire sera très faible, mais ce sera pour plus tard.

L'électronique qui fait la détection a besoin d'un peu de temps pour s'aligner sur la fréquence qu'elle reçoit. Je pense qu'avec 2 ou 3 périodes c'est difficile de faire un détecteur fiable avec de l'électronique analogique. C'est d'ailleurs probablement pour ça que le MO5 utilise un système différent.




Est-ce qu'on ne pourrait pas mettre le code ASCII 14 dans le nom du fichier ? Il est supposé masquer le curseur, mais je ne sais pas si c'est restauré par l'affichage des messages de chargement du basic.

Si 5 est suffisant, 3 ne devrait pas être trop différent. Là dessus on décide le bit en fonction de la majorité des 3 échantillons (1ère correction d'erreur), et si ca ne suffit pas on peut utiliser un code correcteur [7,4,3] (4 bits nécessitent 7 bits envoyés et on peut corriger 2 erreurs). Au final pour 4 bits récupérés on aura besoin au pire de 7*3 périodes à 4.3Khz, soit 4883us, donc un débit "au plus lent" de 208bauds.. Argh c'est hyper mauvais. Le code correcteur [7,4,3] mange toute la bande passante.



Je pense que le basic ne touche pas au curseur, sinon on le verrait s'allumer sporadiquement dans les codes basic qui font des LOADM"" séquentiels.

Ta technique pourrait marcher pour les K7, mais le pb existe aussi pour les chargements depuis D7. Or, et c'est là où on a de la chance, le clignotement curseur est atomique par rapport au chargement. Je veux dire par là que le chargement ne vient pas écrire des trucs en ram vidéo alors que la routine de clignotement calcule le complement. De son point de vue, la ram video est toujours cohérente. Du coup je pense que si on efface le curseur après le chargement, on retrouve la mémoire vidéo comme si elle n'avait pas été polluée par le curseur. La solution "générique" est donc de faire un ldb #$1F; jsr $E803. Ca fait perdre 5 octets, mais c'est plus sur. A la limite si on détecte que le loader ne va pas en ram vidéo l'outil de compression n'aurait pas besoin d'ajouter ce bout. Je vais implémenter cette idée (ainsi que le fait de charger la pile S avec un truc loin de la zone de décompression).

ça c'est en numérique avec un système similaire à celui du MO5. Sur le LEP du TO, il me semble que la détection est faite en analogique. Dans ce cas, il faut que le filtre analogique aie le temps de réagir au signal.

Sur le MO5, on a assez d'une seule période pour détecter un bit




On peut aussi passer en mémoire couleur, qui n'est pas touchée par le curseur ?

A une époque j'avais décortiqué la doc technique sur le LEP. En réalité il y a 2 filtres indépendants. Un comparateur compare le niveau de sortie des deux filtres, et celui qui est le plus "fort" emporte la décision. Avec ses 900bauds, un bit dure 1.1ms ce qui me semble relativement long. Il faudrait faire des mesures à l'oscillo, mais je ne serais pas surpris si avec seulement 3 périodes (467µs ou 667µs) le décodeur distingue fidèlement les 0 des 1. Du coté soft, en 400µs, on doit pouvoir récupérer une centaine d'échantillons, dont la valeur majoritaire donne au final le bit lu. Bon c'est de la théorie devant être confrontée au filtre de l'expérience.
Sur TO7/70 et plus, oui ca marcherait. Cependant c'est vraiment plus moche qu'en mémoire forme et nécessite un poke juste avant le loadm. C'est un peu de la triche, car quitte à faire du basic, autant faire "locate,,0" directement.

Sur les TO7, la RAM couleur n'a que 6bits. Les deux derniers bits de poids forts sont toujours à 1. Ca ne marchera pas

C'est à voir .
Côté soft, il est facile de faire beaucoup de mesures et de les accumuler directement dans un registre, et de prendre une décision en fonction d'un seuil (registre > au seuil = "c'est un 1").

A mon avis le problème est surtout de rester synchronisé avec le magnétophone. La vitesse de défilement de la bande est assez variable. Sur MO5, les timings utilisés permettent d'avoir un truc comme 30% d'erreur sur la vitesse de défilement de la bande sans avoir de problème. Je ne sais pas si ça marche aussi bien avec les filtres à fréquence fixe du TO.
En tout cas, en faisant plein de mesures successives, on risque de se décaler et de mesurer entre 2 bits ce qui rend la détection difficile. C'est pour ça que les blocs sont assez courts et ont une tonalité pilote de synchronisation qui permet au minimum de s'aligner sur la vitesse de la bande, et au mieux de détecter la polarité des oscillations, la vitesse exacte, etc.

Le codage du MO5 est plutôt bien fait et s'en sort avec une durée de synchro très courte tout en étant très tolérant sur les variation de vitesse et de polarité. C'est plutôt bien joué.



J'avais oublié ce détail.
Pour passer en mémoire couleur ma solution est d'avoir un bloc de 1 byte chargé à l'adresse du PIA qui permet d'activer les couleurs. Mais ce n'est pas très propre...

Sinon, j'ai pensé à un truc : Exomizer est un décompresseur séquentiel. Il commence à lire les données par un bout et finit par l'autre, et le résultat décompressé est stocké dans le même sens. Du coup, on peut presque entièrement superposer les données compressées et décompressées, et mettre seulement le code de décompression à côté. On doit arriver à un overhead de quelque chose comme 200 octets, qui doit tenir dans la zone de l'écran non visible, à l'abri du curseur, ou bien à côté des données compressées s'il y a la place.

Hum.. en cherchant un bug dans une intro pour la forever15, je suis tombé sur un truc spécial: mon code crunché (par mon compresseur de binaire) bug à mort, mais la version d'origine ne bug pas du tout.

En fait ce qu'il se passe est que le décrunch ne produit pas la même chose que le code original!

Je ne sais pas encore où se situe le soucis. Est-ce le décruncheur ASM qui bug ou est-ce le cruncher ? Est-ce l'utilitaire de compression que j'ai fait qui bug ? Je ne sais pas et à vrai dire je ne sais pas trop comment aborder le problème. Mais il est certain qu'il y a un truc pas normal qui se trame dans le bazar

Ce que j'ai identifié pour le moment est que lorsque le décrunch produit un exe divergent, c'est suite à une mauvaise valeur dans "offs". Résultat: en mémoire on décompresse aux bonnes adresses, mais les valeurs sont recopiées d'un mauvais endroit. La valeur "mauvaise" de offs est $0402 (qui est aussi la 1ère valeur de tab1).

Pfff... maintenant comment trouver d'où vient cette mauvaise valeur de offs ... hum.. bon déjà je vais voir si le décrunch en C produit aussi un code foireux. Si c'est le cas, c'est que le (de)compresseur est buggé. Sinon: c'est que notre version ASM n'est pas fidèle au C.

affaire à suivre...

J'ai déjà entendu des histoires semblables sur z80...
De mémoire, les trucs à vérifier sont:

- Qu'il y a assez de place sur la pile
- Que le "safety offset" est respecté (c'est une valeur donnée par le cruncher, qui indique l'écart minimal entre le début des données compressées, et le début de la zone décompressée). Sinon, les données décompressées écrasent les données compressées avant qu'elles ne soient lues
- Que le cruncher n'utilise pas de "literal sequences". Je ne sais plus si le code de décompression 6809 sait les décompresser? (C'est désactivable à la compression)
- Vérifier que tu utilises bien la dernière version du cruncher. A ce jour, c'est la version 2.0.7.

Sinon, en effet, il va falloir trouver le souci dans le code 6809...

Pour la pile ca devrait être ok.
Pour le safety offset aussi (3).
Pour literal le compresseur me dit "Literal sequences are not used and the safety offset is 3."

Pour la dernière version, je ne sais pas trop où trouver cela dans les sources C/H.

Ce qui est dingue c'est que l'erreur n'est pas systématique. Pour certains binaires il n'y a pas d'erreurs.

Pire: quand je change l'adresse de chargement du binaire, l'erreur n'apparait pas à la même position. C'est étrange ca. Mais peut-être que l'optimisation est différente.

Je viens de tester le décompresseur C: le résultat décompressé est identique à l'original. Donc le pb se situe dans le code 6809.. aie aie aie.

Il va falloir que je fasse du pas à pas dans le code 6809 pour voir à quel moment il diverge du décodage fait en C. pfff... zut! je pensais pas à tomber sur un truc aussi chi*nt (il ya 17Ko de data à produire octet par octet).

Eureka!

La bonne nouvelle est que le code 6809 est ok. La mauvaise est que mon décompresseur n'initialise pas la pile qui se retrouve pile au milieu de la zone où la décompression a lieu ($9FF8).

Je vais devoir modifier le décompresseur pour initialiser la pile en page 0 plutôt que là où le basic la laisse. Ca va être chi*nt car le décompresseur va grossir un peu et que tous les offsets dans le prefix binaire vont être impactés.

Bref j'ai du taf sur la planche. Mais le bon coté est que j'ai bien identifié le pb qui n'est pas si dramatique que ca finalement.

(Sinon pour cette 3eme intro, je ne sais pas si je vais pouvoir la présenter: elle se compresse en 1091octets et elle n'est pas terminée).

Il existe des "astuces" pour tenter de gagner un peu de place. Il faut essayer d'avoir du code ou des données les plus répéptitifs possibles.
Donc, par exemple, au lieu d'avoir:

0000, 0010, 0020, 0030, ...

Il vaut mieux stocker:
00,00,00,00,...
00,10,20,30,...

Selon les données, on peut découper en demi octets ou même en bits (mais ça devient un peu compliqué à recomposer, et le code de décodage prend de la place...)

Pour le code, par exemple du code généré par un compilateur C se compresse souvent mieux, car il y a plein de séquences très répétitives (toutes les entrées et sorties de fonctions, par exemple). Sur 6809, je pense qu'il est mieux de faire systématiquement un PSHS/PULS de tous les registres, plutôt que de sauvegarder uniquement ceux qui sont vraiement modifiés. C'est un peu plus lent, mais l'opcode est toujours le même et on gagne un peu en compression. Souvent c'est mieux d'"inliner" et de répéter du code que de le mettre dans une sous-routine. Le code répété prend à peine plus de place qu'une seule version, et on économise la place prise par tous les CALL.

Bonne chance!

Oui j'utilise bien tout ca. Le code est inliné au max et prends 17Ko une fois expandé. Le taux de compression est de 95%: le volume après compression vaut 5% du volume initial. C'est pas mal, mais là pour le coup c'est pas suffisant: j'en suis à 1102 octets. Je ne sais pas trop où trancher pour gagner 80 octets. Peut être que j'ai vu trop gros dans les data (j'ai un sprite 48x37 = 222 octets). Si j'y arrive pas tant pis. C'est pas bien grave car j'ai 2 autres intros qui sont bien dans les limites.

[edit] j'ai ajouté le lds (et un orcc) dans le décruncheur et miracle: le code compressé marche comme attendu. Youpie Le compresseur est dispo ici: exobin.exe. Je pense qu'il ne marche que sur le memory mapping TO, mais c'est adaptable. Le code source est dispo ici: exobin.c

Bon il doit y avoir autre chose, parce que là la pile est bonne, les interruptions desactivées, mais la version décompressée est complètement démentielle: rien ne correspond avec le source

[Edit] il y avait effectivement autre chose: un mauvais alignement du décompresseur. Du coup les accès via DP à bitbuf pointaient au mauvais endroit!! Je n'avais pas bien décalé tous les offsets dans le décruncheur après avoir ajouté le lds et le orcc. Une fois cela corrigé, effectivement ca marche mieux.

Source corrigé: exobin.c
Binaire corrigé:

J'espère que ce coup-ci c'est la bonne!