[TO7] k7towav

Dans fr.comp.ordinosaures Samuel Devulder nous expliquait:

Le bon coté est que si le WAV produit par les scripts python passe dans
MESS il devrait passer partout!

L'état actuel des choses :

- Fichier arkanoid.k7 testé Ok
- Traitement arkanoid.k7 > arkanoid.wav (avec bits de départ et d'arrêt)

- Lancement de mess avec la commande :
mess to770 -cart ./.mess/cart/basic.m7 -cass ./.mess/k7/arkanoid.wav

- La commande run"" (qui sur le fichier k7 affiche searching puis FOUND
arkanoid.bas et le charge) affiche searching puis FOUND arkanoid.bas et
plante sur une une IO ERROR en cours de chargement.

- En relançant la même commande run""
dans la foulée, le TO7/70 affiche searching puis FOUND arkanoid.bin et
plante sur une FM ERROR en cours de chargement.

A noter que :
- le support du wav n'est que partiellement supporté par l'émulateur en
stipulant que seuls les wav créés par l'émulateur sont susceptibles
d'être chargé correctement.
- Le signal envoyé n'est pas "carré" comme semblerait l'enregistrer le
magnéto.
- Sans bit de départ/arrêt, la commande run"" affiche
searching... et tourne sans rien trouver (logique).

--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]

Doug713705 a écrit :

Dans fr.comp.ordinosaures Thierry Sundgau [nntp] nous expliquait:

Si quelqu'un dispose d'assez de temps pour tester ce prgramme...

Je vais tacher de trouver le temps de tester ce week end.

La dernière version est en ligne ici :
http://doug.letough.free.fr/to7/

Elle prend en compte les bits de départ et d'arrêt et utilise
wave.writeframesraw() qui en effet est _beaucoup_ plus rapide.

J'ai testé le décodage avec le wav2k7 d'ici:
http://nostalgies.thomsonistes.org/archives/k7tools-2.1a-dosexe.zip

Hélas, le arkanoid.wav ne semble pas être reconnu et produit un
arkanoid.k7 de 0octets!

En fait j'ai regardé un wav sous audacity et regardé ce qu'il génère. Je
trouve que ca ne colle pas. Typiquement les échantillons sont
bizzarement calculés. Du coup J'ai modifié ton script pour rendre plsu
explicite les calculs d'echantillons. J'en ai profité pour accelerer le
tout nettement en précalculant une chaine de caracteres pour les bit0 et
bit1. J'ai fait en sorte que le volume du bit 0 et du bit 1 ne soient
pas les même de sorte qu'avec un afficheur de courbre (audacity) on lise
directement les bits sans avoir à compter les période.

Le code est accessible sur: http://pastebin.com/f79619a11
(j'espère qu'il y restera un certain temps).

J'ai testé sur arkanoid, le wav produit redonne bien le fichier k7
d'origine.

Tout devrait être bon à présent.

Si tu es ok, et si quelqu'un confirme que ca passe sur un vrai thomson,
j'aimerais mettre un msg sur logicielsmoto pour stocker le code ailleurs
pour ne pas le perdre (vu qu'on a un peu galéré pour trouver l'encodage).

sam.

Samuel Devulder a écrit :

En fait j'ai regardé un wav sous audacity et regardé ce qu'il génère. Je
trouve que ca ne colle pas. Typiquement les échantillons sont
bizzarement calculés.

En fait non.. Les deux calculs sont équivalents sauf que wav2k7 attends
du 8 bits.. c'est ca qui coince en fait!

Bon ma modif ne sert pas à grand chose sauf si tu veux un truc + rapide.

sam (il se fait trop tard pour avoir une pensée lucide).

Dans fr.comp.ordinosaures Samuel Devulder nous expliquait:

En fait j'ai regardé un wav sous audacity et regardé ce qu'il génère. Je
trouve que ca ne colle pas. Typiquement les échantillons sont
bizzarement calculés. Du coup J'ai modifié ton script pour rendre plsu
explicite les calculs d'echantillons.

Pour le coup j'ai juste pompé le code et changé les valeurs de
fréquence !
A part les quelques boucles for...in.., il n'y pas grand chose qui
m'appartienne dans ce code ;-)

J'en ai profité pour accelerer le tout nettement en précalculant une
chaine de caracteres pour les bit0 et bit1.

Ca c'est vu ;-) La différence est flagrante.

J'ai fait en sorte que le volume du bit 0 et du bit 1 ne soient
pas les même de sorte qu'avec un afficheur de courbre (audacity) on lise
directement les bits sans avoir à compter les période.

Le code est accessible sur: http://pastebin.com/f79619a11
(j'espère qu'il y restera un certain temps).

J'ai testé sur arkanoid, le wav produit redonne bien le fichier k7
d'origine.

Tout devrait être bon à présent.

Je viens d'essayer dans mess, le resultat est toujours le même IO ERROR.
Il faut donc un teste sur un vrai TO7.
Théoriquement je fais ça ce week-end (il faut encore que je trouve un
inverseur de genre peritel, un cable jack/DIN 5 broches et que mon
pote apporte son TO7 !)

Si tu es ok, et si quelqu'un confirme que ca passe sur un vrai thomson,
j'aimerais mettre un msg sur logicielsmoto pour stocker le code ailleurs
pour ne pas le perdre (vu qu'on a un peu galéré pour trouver l'encodage).

Aucun problème pour moi d'autant que je n'ai pas fait grand chose sinon
copier/coller des bouts de code !

--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]

Doug713705 a écrit :

Je viens d'essayer dans mess, le resultat est toujours le même IO ERROR.
Il faut donc un teste sur un vrai TO7.

J'ai une idée, si le fichier K7 contient 2 fichiers il peut y avoir un
soucis avec la conversion.

Sur un vrai TO, à la fin d'un fichier il y a un motor stop.. puis pour
le 2eme fichier un motoron. Ces arrets/démarages du moteur introduisent
une certaine latence. L'absence de cette latence fait que sur un vrai TO
ou sur MESS, les 1er bits du 2eme fichier sont sautés et donc il ne
trouve jammais ce 2eme fichier et cela se termine par une IO error. Il
faudrait introduire quelques secondes de silence entre chaque fichiers
dans le WAV.

La fin de fichier est présentée par un motif particulier, ca doit
pouvoir se détecter. A suivre...

sam.

Dans fr.comp.ordinosaures Samuel Devulder nous expliquait:

Sur un vrai TO, à la fin d'un fichier il y a un motor stop.. puis pour
le 2eme fichier un motoron. Ces arrets/démarages du moteur introduisent
une certaine latence. L'absence de cette latence fait que sur un vrai TO
ou sur MESS, les 1er bits du 2eme fichier sont sautés et donc il ne
trouve jammais ce 2eme fichier et cela se termine par une IO error. Il
faudrait introduire quelques secondes de silence entre chaque fichiers
dans le WAV.

J'ai lu sur le manuel du magnetophone qu'en l'absence de mot à envoyer,
la ligne de transmission était positionner à 1.

Par contre, comment détecter les la fin d'un fichier, mystère mais je
suppose que le wav2k7 ne faisiat que retranscrire le signal audio bit à
bit (le contraire de ce que nous essayons de faire).

Finalement, je ne vois pas trop pourquoi cela poserait problème.

Par contre en ce qui concerne les cables de raccordement au TO7, l'idée
que j'ai en tête est la suivante :
- Brancher la sortie audio (jack) du PC à l'entrée audio du TO7 (DIN 5),
par contre bien que disposant du schema de la prise DIN entrée/sortie du
magnétophone, je ne comprends pas vraiment comment fabriquer mon cable.

Sur la prise DIN 5 on a :
- Piste 1 : raccord vers TK03 avec dérivation vers TK01 / TK02
- Piste 2 : masse
- Piste 3 : sortie audio
- Piste 4 : sortie digitale
- Piste 5 : entrée digitale

Sur la prise jack on :
- Piste 1 : Sortie voie audio droite
- piste 2 : Sortie voie audio gauche


Je n'ai que de (très) vagues notions d'électronique mais j'imagine bien
que l'une des 2 pistes de la prise jack doit être raccordée à la piste
5 de la prise DIN mais où raccorde t-on la voie restante ? sur le piste
1 vers le TK03 ?

Encore merci.
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]

Dans fr.comp.ordinosaures Doug713705 nous expliquait:

Sur la prise DIN 5 on a :
- Piste 1 : raccord vers TK03 avec dérivation vers TK01 / TK02
- Piste 2 : masse
- Piste 3 : sortie audio
- Piste 4 : sortie digitale
- Piste 5 : entrée digitale

Sur la prise jack on :
- Piste 1 : Sortie voie audio droite
- piste 2 : Sortie voie audio gauche


Je n'ai que de (très) vagues notions d'électronique mais j'imagine bien
que l'une des 2 pistes de la prise jack doit être raccordée à la piste
5 de la prise DIN mais où raccorde t-on la voie restante ? sur le piste
1 vers le TK03 ?

'y'a des fois comme ça où je me demande comment j'arrive à réfléchir de
travers à ce point !

Ce qui n'empèche pas que j'ai toujours une interrpgation :
- une des 2 'pistes' de la prise jack doit être connectée à la broche 3
(audio output) quand l'autre sera connectée à la broche 4 (digital
output) ? C'est bien ça ?

A savoir que je n'ai pas l'intention d'enregistrer quoique ce soit à
partir du TO7 et que je ne devrais donc pas avoir besoin de connecter
les sorties audio et digitale (broche 1 et 5).
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]

Doug713705 a écrit :

Dans fr.comp.ordinosaures Samuel Devulder nous expliquait:

Sur un vrai TO, à la fin d'un fichier il y a un motor stop.. puis pour
le 2eme fichier un motoron. Ces arrets/démarages du moteur introduisent
une certaine latence. L'absence de cette latence fait que sur un vrai TO
ou sur MESS, les 1er bits du 2eme fichier sont sautés et donc il ne
trouve jammais ce 2eme fichier et cela se termine par une IO error. Il
faudrait introduire quelques secondes de silence entre chaque fichiers
dans le WAV.

J'ai lu sur le manuel du magnetophone qu'en l'absence de mot à envoyer,
la ligne de transmission était positionner à 1.

Par contre, comment détecter les la fin d'un fichier, mystère mais je
suppose que le wav2k7 ne faisiat que retranscrire le signal audio bit à
bit (le contraire de ce que nous essayons de faire).

Oui et il ignore les blancs entre bits (transmission asynchrone). Or
entre 2 fichiers le moteur s'arrete. Le monitor Thomson laisse un blanc
d'environ 3 sec d'après la doc. Dans le fichier K7 ce blanc n'existe
pas. Résultat quand on rentranscrit la k7 en wav et qu'on la relit avec
un moniteur non bidouillé (cas d'un vrai TO et de MESS), on mange
2-3secs en début de fichier. On loupe l'en-tete et on ne retrouve plus
les billes.

De même les fichiers binaires sont organisés en blocs et il y a une
légère temporisation entre les blocs pour laisser au TO le temps de
traiter le bloc. L'absence de cette tempo peut introduire des IO errors
car on loupe une partie d'un block de donné et que le CRC devient faux.

Le format des blocs est indiqué ici:
http://www.i-services.net/membres/forum/messages.php?uid)603&sid289&idsujetY1147

Je pense qu'il ne doit pas être bien compliqué de lire le fichier K7
block par block et de faire en sorte d'introduire un blanc de quelques
ms après une fin de block data, et 3sec en fin de block "fichier".

Finalement, je ne vois pas trop pourquoi cela poserait problème.

L'absence de tempo dans le WAV fait que probablement on mange le début
des blocks data. Le CRC de fin de bloc est alors faux donc IO error.

Par contre en ce qui concerne les cables de raccordement au TO7, l'idée
que j'ai en tête est la suivante :
- Brancher la sortie audio (jack) du PC à l'entrée audio du TO7 (DIN 5),
par contre bien que disposant du schema de la prise DIN entrée/sortie du
magnétophone, je ne comprends pas vraiment comment fabriquer mon cable.

Sur la prise DIN 5 on a :
- Piste 1 : raccord vers TK03 avec dérivation vers TK01 / TK02
- Piste 2 : masse
- Piste 3 : sortie audio
- Piste 4 : sortie digitale
- Piste 5 : entrée digitale

Sur la prise jack on :
- Piste 1 : Sortie voie audio droite
- piste 2 : Sortie voie audio gauche


Je n'ai que de (très) vagues notions d'électronique mais j'imagine bien
que l'une des 2 pistes de la prise jack doit être raccordée à la piste
5 de la prise DIN mais où raccorde t-on la voie restante ? sur le piste
1 vers le TK03 ?

Là j'avoue ne pas suivre facilement. Tu veux envoyer directement les
bits décodés au TO via la fiche no 5? Dans ce cas pas besoin de wav, il
te suffit d'avoyer les bits sur la fiche 5. Il doit simplement suffire
de relier une sortie TTL du PC sur cette fiche 5 (port // ou série.. pas
facile à trouver de nos jours), et d'envoyer les bits du fichier k7 sur
ce port série. L'acia coté TO croira que ce sont des bits décodés par le
lecteur K7 et devrait ête leurré.

Si tu veux laisser le lecteur K7 décoder le wav, il faut sans doute
injecter la sortie audio du PC plus en amont dans le circuit,
probablement juste après les tetes audios. Mais je ne sais pas trop si
les tensions/courants sont compatibles.

Le moins compliqué est à mon avis d'aller regarder dans les bacs "solde"
pour y dénicher une fausse k7 avec prise jack.

Par contre ces bricolages ne reglent pas le pb de temporisation entre
blocs et fichiers.

Encore merci.

sam.

Dans fr.comp.ordinosaures Samuel Devulder nous expliquait:

Tu veux envoyer directement les bits décodés au TO via la fiche no 5?

Ben oui, c'était mon idée de départ mais...

Dans ce cas pas besoin de wav, il
te suffit d'avoyer les bits sur la fiche 5.

Je viens de comprendre (a tort ou à raison) que c'est le magnetophone
qui décode le wav, je pensais que c'était le TO7 !!

--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]

Doug713705 a écrit :

Dans fr.comp.ordinosaures Samuel Devulder nous expliquait:

Tu veux envoyer directement les bits décodés au TO via la fiche no 5?

Ben oui, c'était mon idée de départ mais...

Dans ce cas pas besoin de wav, il
te suffit d'avoyer les bits sur la fiche 5.

Je viens de comprendre (a tort ou à raison) que c'est le magnetophone
qui décode le wav, je pensais que c'était le TO7 !!

Hihi non non, depuis de début j'avais indiqué que contrairement aux
autres machines de l'epoque le magnéto K7 du TO est plus compliqué car
c'est lui qui contient les circuits pour décoder le signal K7. Ceci
devait expliquer aussi le prix de la bete par rapport aux autres
lecteurs K7 type MO dont la logique est beaucoup plus simple.

Le TO écoute son lecteur de K7 non pas via une liaison analogique (type
'jack'), mais avec une liaison numérique au niveaux TTL. C'est un ACIA
(convertiseur série->octets) qui recoit les bits décodés en série par le
lecteur k7 et les présente sous forme d'octet dans le TO.

Par contre pour l'écriture, le TO communique de façon analogique et
envoie des signaux carrés représentant les 5 périodes à 4.5khz et les 7
périodes à 6.3khz.

L'histoire ne dit pas pourquoi une telle dissymétrie entre la lecture et
l'écriture sur TO.

Un truc curieux, c'est que d'une part un TO ne peut lire des cassettes
MO, mais que par contre il devrait être à même de pouvoir en écrire. Je
ne sais pas si l'expérience a été tentée.

sam.