Logicielsmoto.com

A mon tour de jouer avec le port LEP...

J'y ai branché ce que j'avais sous la main, à savoir une carte V-USBDev. Cette carte est équipée pour utiliser V-USB, une stack USB logicielle pour microcontrôleurs AVR.

L'idée est de coder/décoder les bits reçus via USB au format LEP (dans un premier temps, après on verra pour le mode rapide), afin de pouvoir facilement transférer des fichiers entre PC (ou autre tant qu'il y a un port USB) et MO.

Pour l'instant la génération du signal MO5 fonctionne. Il reste à faire le décodage dans l'autre sens. Le logiciel sur PC permet d'envoyer un bloc au choix d'un fichier K7, le reste étant pour le moment fait avec un script bash.

Il reste à faire la détection du signal motor pour pouvoir chaîner plusieurs fichiers en laissant le MO5 décider quand il veut charger le fichier suivant, avant de compléter le logiciel et de le rendre plus agréable à utiliser (barre de progression, rembobinage, tout ça).

Le firmware
Le logiciel PC (tout OS équipé de libusb)


Notes techniques :
* La stack V-USB étant entièrement loicielle, elle est assez rigoureuse sur les timings. Donc, les données pour le MO5 sont générées sous interruptions à l'aide du timer 1. La méthode utilisée peut surement servir pour d'autres projets ici...
* Les requêtes USB Control Transfer avec V-USB sont limitées à 254 bytes. ça tombe bien, c'est justement la taille maximale des données dans un bloc cassette MO5! Les infos supplémentaires (type de bloc et taille) sont transmises dans le header USB (qui a justement des champs "type" et "taille". Le signal de synchro en début de bloc et le checksum sont générés à la volée. Dans ce mode, on ne peut donc transfére rque des blocs "valides". Mais je vais réfléchir à un mode plus générique...
* La piste son des cassettes n'est pas gérée. Je pense me diriger vers une solution du genre "lire un MP3 sur PC et le synchroniser avec le signal MOTOR".lire un MP3 sur PC et le synchroniser avec le signal MOTOR

Petit test de vitesse :

J'ai essayé de voir jusqu'ou on pouvait aller sans toucher le code de chargement du MO5.

Conclusions :
* Il y a 16 octets d'en tête (01 01 01...), mais 2 sont suffisants.
* 0n peut augmenter la fréquence de 612 à 829Hz (609microsecondes/bit au lieu de 830) sans que ça ne dérange le MO5.

Résultat: une accélération de 30%, quand même

Tu prends la stack v-usb, tu la mets dans un ATTiny, tu mélanges avec la proposition de Gilles et ca fait un câble USB-LEP haute vitesse (l'ATTiny est tellement petit physiquement qu'il tient dans une prise DIN). Plutôt sexy ...

Oui, c'est un peu l'idée.
Par contre je sais pas si on peut trouver un ATTiny avec les pins nécessaires pour V-Usb (interruptions externes), plus une pin avec la sortie Timer 1, plus 2 pins pour motor on et les data en enregistrement... ça fait déjà 5 pins plus l'alimentation, c'est juste... Je préfère garder le quartz car c'est souhaitable pour les timings précis... Du coup ça passe pas sur les attiny à 8 pins.

Bon, j'attends gilles pour essayer d'être compatible avec lui pour le loader rapide

Je teste mon système avec différents fichiers...

Pour l'instant j'utilise des fichiers K5 de logicielsmoto. Mais certains sont "modifiés pour fonctionner en émulation"... Est-ce que cela empêche la lecture sur un vrai MO5 ?
Il n'y a jamais eu d'autre format à part les K5/K7 et les WAV ? Il me semble qu'un format du genre le TZX utilisé sur Spectrum et Amstrad CPC serait pas mal pour pouvoir tenir compte des différents codages sans perdre autant de place qu'un WAV.

En tout cas cela m'arrangerait bien pour ce projet si on veut pouvoir charger des trucs non standard.

D'autre part, est-ce qu'il existe une liste un peu complète des protections utilisées, éventuellement avec des infos techniques dessus ? ça me permettrait de voir ou sont les difficultés. Pour le moment je peux passer tout ce qui reste dans des blocs standard (254 octets + checksum + type + taille + synchro 0x3C5A). Est-ce qu'on trouve d'autres types de synchro par exemple ? Des formats de bits autres que le MFM ? Des blocs plus grands (jusqu'à quelle taille ?)?

Tu n'as pas besoin de tout ca sur ton ATTiny. La clock interne est suffisamment precise, le coeur developpe suffisamment de puissance. Le quartz du MO5 dérive probablement beaucoup plus que celui d'un ATTiny. C'est aussi pour cela qu'il y a les salves de synchro au debut des blocs. Et pourquoi un timer ?

J'ai récemment secoué une v-usb dans un attiny2313 pour le boulot avec de l'i2c modifié de l'autre côté, le tout en polling, sans timer et sans quartz externe, ca marche nickel à condition de maitriser parfaitement ton code assembleur. Demande a Prehisto, le roi du cycle gagné c'est bien lui ;-)

L'ATTiny85 par exemple a 512 octets de RAM, largement de quoi faire un buffer pour un bloc de données et la seconde de blanc entre chaque bloc laisse de quoi transmettre 100 fois ca sur l'usb.

Pour ce qui est du format de donnée, le MO5 permet d'imaginer absolument n'importe quel codage dans les limites physiques de la tête d'enregistrement.

Des blocs plus grands ? Essaye le jeux pulsar : le jeu entier fait un seul bloc sur la cassette :-)

Plus de vitesse ? L'éditeur Cable a produit une série de compilations à 1800 bauds, Le MO6 peut travailler à 2400 bauds, Sapiens utilise un codage spécial aussi, qui fait mal aux oreilles tant il est aigu.

Quant aux protections, elles n'ont rien de bien particulier, il s'agit rarement d'un bloc de données bizarre (mais ca existe). Toutes les K7 sont reproductibles avec un double deck, ce qui m'a toujours laissé songeur sur l'utilité réelle de ces fameuses protections.

Enfin pour ce qui est des formats d'image, personne n'a jamais fait l'effort reel d'imposer un standard valable. J'avais développé il y a tres longtemps un format comprimé qui avait les limitations de ma méconnaissance de l'époque en théorie de l'information, et que j'ai moi-même abandonné. J'ai depuis réfléchi à un autre format basé sur le codage de formes d'ondes, afin de reproduire le plus fidèlement possible le signal K7, mais il est resté sur le papier.

Les formats utilisés actuellement sont médiocres. Il ne contiennt pas de méta-information sur le logiciel imagé, ils ne sont pas comprimés, ils ne permettent pas de reproduire le signal audio de manière fidèle, donc ne permettent pas de reconstituer une k7 utilisant un format vraiment bizarre.

La difficulté dans ce projet est que les timings du signal cassette sont assez critiques (surtout si o veut faire un mode "super rapide"). Sur de l'I2C tout est synchro avec une clock commune au maître et à l'esclave, donc ça se passe assez bien. Dans le cas du signal cassette, on risque de dériver (une communication usb peut prendre jusqu'à 50µs d'après la doc de V-USB) et rater un bit.
L'utilisation d'un timer permet de rester en phase tout en faisant autre chose avec le CPU sans trop se fatiguer. Tout le firmware est écrit en C pour le moment.

Cela permet également de traiter les communications USB pendant la génération du signal cassette, entre deux bits. Du coup on peut envisager de transférer des programmes avec des blocs plus gros que la RAM de l'AVR.

L'attiny2313 est un peu à part dans la famille tiny, il s'agit en fait d'une version améliorée de l'AT90S2313. Il est beaucoup plus équipé que le reste de la famille ATTiny, donc en effet une version pour celui là est possible. Par contre les ATTiny85 et compagnie je ne pense pas (pas avec mon code en tout cas).

Bon, du coup dans un premier temps je garde mon support "artisanal" du format K5 pour les programmes non protégés, et je vais plutot essayer de faire un loader de wav en attendant mieux...

Pourquoi l'attiny85 ne fonctionnerait pas ?

En mode super-rapide comme tu dis, au contraire, toute limitation est affranchie. Pour une raison simple : on oublie les routines standard et on ecrit son propre code coté MO5. Du coup, on peut renverser la vapeur et mettre le mo5 en slave pour toutes les operations, soit en utilisant un handshake approprié, soit encore mieux en detournant la ligne motor on qui est cablee sur l'interruption du PIA et ainsi synchroniser tous les echanges avec la communication USB par interruption du MO5.

Le mode super rapide est un peu plus eleve que les 115200 bauds standard pour un byte, mais un peu moins eleve en comptant l'overhead du protocole. En tout cas, on peut faire des echanges a 115200 bauds avec un FT-232R, ca fonctionne, j'ai testé (si on accepte que la bordure d'ecran fasse de jolies couleurs ou reste orange en permanence, indice).

hello,
bon en fait je n'ai pas encore tout sorti de mes cartons, je viens de déménager...
Pour le moment je n'ai testé que le loader en mode 1200 bauds (en fait j'ai même testé une conversion du format .k5 avec respect des pauses telles qu'implémentées dans l'utilitaire de fool k52wav (avec une partie du code source modifié pour rentrer dans l'avr)).
Pour le protocole rapide je pensai utiliser le suivant, utiliser la ligne motor comme horloge avec positionnement du bit préalable sur la sortie.
Le microcontroleur étant nettement plus rapide que le MO5 il devrait suivre sans problème.

A un niveau plus élevé on peut partir d'un octet de commande, suivi d'une taille sur 16bits (toujours à l'initiative du MO5).
Le contrôleur renvoit un handshake (lorsqu'il est prêt) sur la ligne d'entrée

(le plus court possible). avec possibilité de dire niet.

puis selon la commande, le MO5 envoie soit les data et les impulsions d'horloge, soit les impulsions d'horloge et lit le résultat.

Je prévoit des commandes dans le style:

_ DIR
_ SELECT FILE
_ ERASE FILE
_ CREATE FILE
_ LOAD FILE
_ WRITE FILE
_ LOAD BLOC
_ WRITE BLOC

et peut être aussi la possibilité de rester en mode émulation de K7 à vitesse 1200, après un select file par exemple.

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

En effet on peut faire le mode rapide avec moins de contraintes, et donc ça pourrait éventuellement passer sur un attiny85. Mais pour le moment j'essaie de faire quelque chose qui soit compatible avec les formats existants, MO5 d'abord et puis pourquoi pas d'autres (Amstrad CPC, ZX Spectrum... et bien sûr les TO ).

Donc je préfère prévoir "large" sur le matériel (encore que j'aurais pu prendre une carte LPCXpresso avec un ARM à 100MHz:)) pour pouvoir tester différentes solutions et expérimenter avec. Après on verra .

en fait mon principal problème est que le teensy n'a pas beaucoup de ram. Mon but est d'avoir un lecteur de SD mais tout un fichier .k5 ne tiendra pas en RAM donc il va falloir ruser un peu pour le mode compatible.
Il n'est pas possible d'utiliser la flash, techniquement c'est possible mais cela va amoindrir fortement la durée de vie de l'interface.

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

Comme dit plus haut j'ai utilisé un timer pour générer le signal MO, du coup ça occupe assez peu de CPU pour me permettre de communiquer en USB pendant la génération d'un bloc. Je suppose que tu peux en faire de même pour l'accès à la carte SD ? (lecture de la fin d'un bloc sur la SD pendant la génération du début, avec un buffer approprié).

Pour l'instant j'utilise un ATMega8, donc j'ai 1K de RAM. Si ça pose problème je peux passer à l'ATMega328, qui est pin-compatible mais avec 2K.

le problème de la SD c'est qu'on est dans un filesystem plus ou moins complexe, donc difficile d'avoir un temps de réponse en temps constant. de plus avec 1ko on est plus que limite car on est en permanence en train d'aller relire la FAT (car il est impossible de mémoriser la FAT et le secteur en cours)... mais je n'en suis pas encore là...

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

Il me semble qu'on mélange 2 ou 3 projets différents là :-)

J'ai toujours pas ma réponse : pourquoi l'ATTiny 85 ne fonctionnerait pas ?

Utiliser une ligne comme clock pour les données n'est pas efficace du point de vue de la vitesse, car il faut la gérer en soft. On est pas sur TO, qui peut generer des salves avec le 6846. Ce sera lent, trop lent. Il est preferable de travailler en asynchrone avec éventuellement un recalage sur un bit de start. Vous semblez douter de la qualité des horloges, que ce soit celle du MO5 ou celle de l'Atmel :-) L'exécution au cycle près est peut-être un art mais il est maitrisé par plusieurs personnes par ici.

Et je ne comprends pas non plus pourquoi il est nécessaire d'avoir beaucoup de RAM, un buffer d'échange devrait suffire.

Mais avant toute chose, je crois que je n'ai pas compris l'objectif du projet : liaison d'échange rapide avec un PC, émulation de LEP ou mémoire de stockage indépendante pour MO5 ?

Le projet sur lequel j'avais réfléchi en son temps étaut une liaison rapide entre MO et PC, d'abord avec puis sans apport de logiciel externe (i.e. la meme idee que gilles de fournir un bootstrap directement depuis le cable).

je n'ai pas envie de gérer le mode synchrone sur l'atmel pour des questions de portabilité, un jour une instruction prendra 2 cycles, dans un batch suivant ce sera 1 cycle, pas de problème pour le MO5 par contre, il est maitrisé de ce point de vue.
Oui il faudra gérer en soft mais cela ne prendra pas énormément de temps non plus, au lieu de positionner 1 bit il faut en positionner 2.

Le but de mon projet est double:
_ fournir un mode rapide pour de nouveaux développements et des conversions de softs existants mais avec un bootstrap compatible avec le basic du MO5 (avec un écran de séléction).
_ assurer la compatibilité avec les fichiers .K5 ou .K7
Le tout dans un petit boîtier autonome, simple à réaliser et avec des fichiers stockés sur une carte SD.

C'est la lecture du filesystem sur la SD qui demande une ram non négligeable. On n'est pas obligé d'utiliser un filesystem mais c'est tout de même pratique.

L'autre, et peut être le principal but de ce projet à bien y réfléchir, est de s'amuser avec ce microcontroleur atmel, de bidouiller, de tester.

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