Logicielsmoto.com

Nous sommes le 12 Déc 2019, 21:07

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 60 messages ]  Aller à la page Précédente  1, 2, 3, 4  Suivante
Auteur Message
 Sujet du message:
MessagePosté: 27 Oct 2011, 19:04 
Hors ligne

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


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Oct 2011, 19:06 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Oct 2011, 19:12 
Hors ligne

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


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Oct 2011, 19:20 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Oct 2011, 20:40 
Hors ligne

Inscription: 28 Jan 2007, 14:00
Messages: 33
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 ?


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Oct 2011, 20:51 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 592
Localisation: Provence (France)
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Oct 2011, 20:57 
Hors ligne

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

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


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Oct 2011, 21:09 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Oct 2011, 21:27 
Hors ligne

Inscription: 28 Jan 2007, 14:00
Messages: 33
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...


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Oct 2011, 21:46 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 28 Oct 2011, 15:56 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
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 ;)


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

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


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 01 Nov 2011, 09:23 
Hors ligne

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


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 01 Nov 2011, 15:00 
Hors ligne

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


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 01 Nov 2011, 15:06 
Hors ligne

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


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

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 7 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