Logicielsmoto.com
http://www.logicielsmoto.com/phpBB/

Exomizer
http://www.logicielsmoto.com/phpBB/viewtopic.php?f=3&t=421		 Page 3 sur 5
Auteur:  PulkoMandy [ 27 Oct 2011, 19:04 ]
Sujet du message: 
L'intervalle entre les blocs donne le temps de stopper le moteur le temps de traiter le bloc, puis de le relancer quand on est prêt à lire le bloc suivant.
Auteur:  Prehisto [ 27 Oct 2011, 19:06 ]
Sujet du message: 
Tout à fait. De plus, rien n'empêche de charger le fichier entier et de le décompresser une fois chargé, comme on pourrait le faire avec le lecteur de disquettes.
Auteur:  PulkoMandy [ 27 Oct 2011, 19:12 ]
Sujet du message: 
ça dépend. Sur MO5 c'est bien pratique de ne pas avoir à jongler entre le fichier compressé et la version décompressée. Il est beaucoup plus facide de trouver de la place pour un bffer de la taille d'un bloc de cassette (ou un secteur de disquette :))
Auteur:  Prehisto [ 27 Oct 2011, 19:20 ]
Sujet du message: 
Si le fichier peut être décompressé à l'intérieur même de son espace d'implantation, il n'y a pas besoin de chercher de place.
Auteur:  megar [ 27 Oct 2011, 20:40 ]
Sujet du message: 
Prehisto a écrit:
Si le fichier peut être décompressé à l'intérieur même de son espace d'implantation, il n'y a pas besoin de chercher de place.


L'intérêt de décompresser en temps réel est double:
1/ augmenter la vitesse de chargement
2/ épargner le temps de décompression à la fin du chargement.

Si on lit le bloc normallement et qu'on le décompresse ensuite, il n'y a pas vraiment d'évolution, certains programmes devaient déjà le faire à la belle époque des MO6, non ?

PulkoMandy a écrit:
L'intervalle entre les blocs donne le temps de stopper le moteur le temps de traiter le bloc, puis de le relancer quand on est prêt à lire le bloc suivant.


Tu dois parler des enregistrements type séquentiel (print #1,data), où effectivement, les blocs sont espacés par une seconde de blanc, mais pour des blocs continus, il n'est pas possible d'arrêter le moteur (inertie) et de le redémarrer instantanémement (montée en vitesse de croisière). (je ne suis pas sûr de cette affirmation mais ça m'étonnerait énormément)

Reste la possibilité d'insérer des blancs de durée optimale manuellement en faisant un programme qui compresse les données et sort un .WAV.

Pour info, avec la routine actuelle, quelle vitesse de décompression obtenez-vous ? Il faudrait qu'on se donne un programme de 20/30 Ko, pour qu'on puisse comparer avec un exemple réaliste. Une proposition ?
Auteur:  Daniel Coulom [ 27 Oct 2011, 20:51 ]
Sujet du message: 
PulkoMandy a écrit:
L'intervalle entre les blocs donne le temps de stopper le moteur le temps de traiter le bloc, puis de le relancer quand on est prêt à lire le bloc suivant.

Je pense comme megar. L'intervalle standard entre les blocs d'un fichier binaire sur cassette MO5 est de 5 centièmes de secondes. Je ne crois pas que l'inertie du mécanisme permette un arrêt et un redémarrage en si peu de temps. Il faut probablement augmenter l'intervalle.
Auteur:  gilles [ 27 Oct 2011, 20:57 ]
Sujet du message: 
il doit être possible de calculer le temps de décompression lors de la compression sur PC (en embarquant le code et un émulateur de 6809), et du coup de mettre cette valeur plus une petite marge pour l'intervalle entre 2 blocs. Arreter le moteur est une mauvaise idée dans la pratique, le signal ne sera pas stable car le moteur ne va pas se stabiliser immédiatement.
Auteur:  Prehisto [ 27 Oct 2011, 21:09 ]
Sujet du message: 
Daniel Coulom a écrit:
Il faut probablement augmenter l'intervalle.

Voilà qui va à l'encontre de l'effet recherché. Le mieux serait de raccourcir au minimum l'intervalle de bloc pour la lecture, et de tout décompresser après chargement. La compression serait alors bien meilleure que bloc par bloc. C'est se compliquer la vie pour pas grand chose.
Auteur:  megar [ 27 Oct 2011, 21:27 ]
Sujet du message: 
gilles a écrit:
il doit être possible de calculer le temps de décompression lors de la compression sur PC (en embarquant le code et un émulateur de 6809), et du coup de mettre cette valeur plus une petite marge pour l'intervalle entre 2 blocs. Arreter le moteur est une mauvaise idée dans la pratique, le signal ne sera pas stable car le moteur ne va pas se stabiliser immédiatement.

Oui, c'est ce que je voulais dire par "insérer des blancs de durée optimale dans un .WAV".

Et il ne faut pas oublier que le MO6 peut utiliser une vitesse double (2400 bauds au lieu de 1200 si mes souvenirs sont exacts). Bref, il faudrait savoir la vitesse de décompression obtenue avec la routine d'Edouard.

Je repose ma question : il y a un programme qu'on pourrait utiliser pour se faire une idée, qu'on puisse aisément charger avec LOADM, qui se chargerait d'une traite, sans changer d'adresse ? Il suffirait juste de le charger, de l'envoyer sur PC pour le compresser, et le réinjecter dans un TO/MO (même émulé), où on mesurerait le temps de décompression, pour se faire une idée...
Auteur:  Prehisto [ 27 Oct 2011, 21:46 ]
Sujet du message: 
La compression par motifs, qui est une composante d'Exomizer, fait la plus grande partie de son efficacité. Si la taille des données est réduite, ça réduit aussi le nombre de candidats pour cette méthode.

Au final, ce sont même tous les points que tu as cités, Megar, qui vont en souffrir: non seulement la vitesse de chargement sera ralentie, mais la compression sera bien pire.

EDIT: C'est vrai qu'on n'est pas obligé de compresser bloc par bloc. J'ai parlé trop vite. Mais la décompression d'un fichier de 16ko prendrait quelques 3 secondes, ce qui correspond grosso-modo au temps que met le lecteur de cassette pour charger deux ou trois blocs de 128 octets de plus. On ne peut pas dire que le gain serait très conséquent.
Auteur:  Prehisto [ 28 Oct 2011, 15:56 ]
Sujet du message: 
Daniel, ton intervention a été reportée dans "Matériel Thomson" sous le titre "Emulation du LEP", puisqu'elle n'a plus de rapport avec le sujet. J'espère que tu es conscient de ce que tu risquais de déclencher comme réactions... en chaîne ;)
Auteur:  Fool-DupleX [ 31 Oct 2011, 12:20 ]
Sujet du message: 
Ce que je ne comprends pas, c'est pourquoi se limiter au format de bloc thomson pour l'enregistrement. On peut faire virtuellement n'importe quoi en termes de signal d'enregistrement et en calculant les cas limites, on doit pouvoir s'assurer que la synchro soit correcte. J'ai personnellement toujours trouve que les blocs a la thomson etait un systeme naze. Certains editeurs de jeu le pensaient aussi du reste :lol: puisqu'ils ont fait leur propre codage.

Exomizer a ete choisi a l'origine justement pour son taux de compression, la vitesse n'etait pas le critere principal. Il se prete malgre tout assez bien a la decompression temps reel, puisqu'il prend en entree un flux de bits. Dans une routine de lecture k7 standard, il y a enormement de boucles de temporisations. Utiliser ce temps CPU a bon escient est justement le but d'un tel exercice de style.

Cela etant dit, si tu as quelque part un code assembleur, on pourrait s'amuser a le porter pour voir la difference.
Auteur:  PulkoMandy [ 01 Nov 2011, 09:23 ]
Sujet du message: 
Le format de bloc Thomson prend peu de place pour chaque bloc (ok, on pourrait enlever les deux octet de type) et permet de charger des trucs à plusieurs endroits de la mémoire en une seule fois. Exomizer a un peu de support pour ça avec le format du C64 (mais c'est presque pareil). ça permet tout simplement de compacter plusieurs fichiers/zones de mémoire d'un coup en utilisant les répétitions /similitudes entre ces différentes zones, pour un gain supplémentaire.

Dans le fichier exomizer résultant on ne trouvera pas les blocs Thomson, mais des trucs supplémentaires pour le decruncher du genre "saute 800 bytes sans rien écrire dedans"; ou alors on peut écrire "n'importe quoi" à ces addresses inutilisées, si possible en s'arangeant pour que ça permette de mieux compresser ce qu'il y a autour.

Utiliser le format Thomson en entrée d'Exomizer est un moyen comme un autre de définir les zones utiles et les zones vides. C'est simplement pratique de pouvoir lui donner un truc qui sort directement d'un assembleur/linker générant ce genre de fichiers (celui de gcc-6809 par exemple), plutot que d'avoir à définir ces zones avec un fichier de defines quelconque.
Auteur:  Fool-DupleX [ 01 Nov 2011, 15:00 ]
Sujet du message: 
C'est justement la que je trouve l'approche inappropriee : pourquoi ne pas plutot definir un codage k7 en fonction d'exomizer plutot que d'adapter exomizer a un format existant mais mal fichu ?

La place et le format du bloc en memoire m'importe peu, ce qui m'interesse c'est la vitesse de transfert depuis la cassette et le bloc thomson de ce point de vue la est vraiment pas terrible. Faut ouvrir un peu les fenetre et faire entrer de l'air frais ...
Auteur:  PulkoMandy [ 01 Nov 2011, 15:06 ]
Sujet du message: 
Oui bien sur, au niveau du codage cassette on peut faire autre chose.

L'idée c'est d'utiliser le format Thomson en entrée du packer Exomizer sur PC, d'extraire les "blocs" à partir de ça et de reconstruire un fichier compressé comme il faut. Le format Thomson est donc simplement une façon de dire au packer Exomizer de quelle façon on veut remplir la mémoire. Après, il peut en faire ce qu'il veut.

On a donc un truc du genre (en tout cas chez moi) :

Codes sources > Assembleur > Fichiers .o > Linker > Fichier "Thomson" unique > Exomizer > Fichier compressé custom

Donc, le binaire final sur cassette peut ne plus rien avoir avec le format Thomson, mais ce dernier reste pratique comme format d'échange et de travail.
Page 3 sur 5 Heures au format UTC + 1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/