J'ai réussi à régler mes problèmes d'erreur, c'était bien à cause des bits de stop à la fin du header. J'ai dû ajouter une dizaine de stopBits. Je suis même arrivée à dépasser la vitesse maxi obtenue par Symoon ! Ca fait aux alentours de 1.67 x.
J'utilise la méthode des delayMicroseconds(), 50/50 micros secondes pour les bits 1 et 310/210 pour les bits 0. Ca marche mais j'ai quand même quelques octets erronés sur certains fichiers, je vais donc augmenter un peu les valeurs de 10 microsecondes suivant les résultats. En fait je sais pas trop si c'est des erreurs de transmission ou encore mes problèmes de stopBits...
Maintenant il faut que je règle des petits problèmes engendrés par les délais plus courts...
@atmosphere bonne nouvelle !
Le temps de régler les vitesses des impulsions, tu peux émettre 5 ou 6 bits de stop après chaque octet, tu seras tranquille le code de la ROM devrait avoir le temps de s'exécuter.
Et une fois que tu as ton optimal au niveau du signal, réduire le nombre de bits de stop petit à petit, jusqu'à ce qu'il y ait des erreurs.
Attention peut-être aussi avec un signal "hyper limite" testé sur une seule machine; il peut y avoir de petites différences. Mais ça fait partie de la mise au point, et il faut bien commencer quelque part 😉
@symoon oui je vais continuer à chercher le bon équilibre et comme tu le précise il faudra prendre en compte les différences avec d'autres Oric. Mais ça devrait aller car je dispose d'un Oric1 et deux autres Atmos, dont l'un est pourvu de la première ROM, ça me fait 3 ROM différentes c'est parfait 😀
J'ai fait une copie d'écran de l'analyseur logique pour illustrer un peu nos propos pour ceux qui sont curieux de comprendre un peu comment fonctionne la transmission cassette de l'Oric. Cet écran montre le début d'une transmission en mode normal, je ferai plus tard la même chose en vitesse F16 mais là je n'ai pas encore de capture à disposition.
Sur la capture en haut, la première ligne c'est l'entrée du signal provenant de la sortie k7 de l'Oric. Le signal d'origine passe par un ampliOp qui va fonctionner en saturation rendant le signal carré.
La seconde ligne ce sont les périodes détectées par l'esp32 donc ce sont les bits recus.
La troisième ligne c'est l'état du contact de commande magnétophone de l'Oric, on voit qu'il se ferme juste après que l'entrée soit passée à 0 et provoque des rebonds dus au contact mécanique du relais.
La quatrième ligne correspond à l'octet décodé par l"esp32, on voit en vert les 8 bits qui composent 1 octet, ici de valeur 0x16 en hexadécimal, le bit de poids fort est envoyé en premier et en dernier on voit le bit de parité en bleu.
Le bit en marron est le bit de start qui est toujours 0 et qui est précédé de 3 ou plus bits de stop (1)
Le délai d'un bit 0 est de 624 microsecondes et le bit 1 de 416 microsecondes, ces valeurs varient un peu durant la transmission.
Voilà, j'espère que ça peut aider certaines personnes qui ont envie de bricoler un peu sur le port K7.
Je mettrai une copie d'écran de la transmission F16 dès que ça sera fait.
Merci à toutes les personnes qui m'aident à avancer dans ce projet.
Bonjour, voici la suite de mes tests de vitesse avec le principe F16 de Symoon.
Comme f4goh j'obtiens à peu près 1.4 x en gain. Par contre pour le bit 1 j'ai une période de 100 micros secondes (2*50) et pour le bit 0 540 micros secondes (320 + 220), ces valeurs sont critiques et je suis obligée de mettre entre 8 et 9 bits de stops en alternance. Si on change ces valeurs ça semble marcher sur des petits fichiers mais sur des fichiers de plus de 15 ou 20 ko on a vite des erreurs.
Je vous donne la capture d'écran de l'analyseur, ça fait bizarre car les bits 1 sont beaucoup plus courts que les 0, mais impossible d'aller plus vite.
En entrée on a des 1 envoyés en permanence par l'Oric dès qu'on tape CLOAD""
En sortie on a les bits de stop (1), le bit de start (0), les bits formants l'octet en vert (ici 0x16 01101000) puis le bit de parité et à nouveau les bits de stop.
J'ai reçu les nouveaux pcb, je vais assembler un modèle et je le présenterai en détail, je ne sais pas quand pour l'instant.
Bonnes vacances pour ceux qui en prennent.
Claire
@atmosphere je suis quand même surpris que tu doives mettre autant de bits de stop derrière chaque octet, c'est étrange. Avec le F16 à 44kHz, je n'en mets que trois (au lieu des 3,5 de la ROM !) et tout va bien.
J'avais calculé le temps de chaque routine en ROM Oric, pour vérifier que ça passait (hélas je me suis fait voler tout ça avec un sac dans le train).
Donc que tu doives en mettre quatre (400µs) contre trois pour moi (345µs), ça m'aurait paru plausible. Mais là huit ?
Et tu n'as vraiment pas besoin de faire 8/9 en alternance. Si un octet peut être traité par la ROM le temps de 8 bits de stop, aucune raison qu'un autre en nécessite 9 😉
La nuit a porté conseil et je me pose une question... Est-ce que tes "1" ne pourraient pas être trop courts à 100µs ? A part dans les bits de stop, les $16 qui servent de synchro (et que tu montres sur ta capture d'écran) ont toujours un 0 à côté d'un 1, ce qui joue peut-être sur le fait que le 1 a le temps d'être décodé.
$16 avec bits de start, parité et stop: 0 01101000 0 111
Et donc dès que tu enchaines les 1 en série, tu dois en mettre pile le double (huit, au lieu de quatre disons). Ca me donne l'idée que peut-être l'Oric n'arrive à en lire qu'un sur deux, et considère donc 4 bits de stop à 200µs.
C'est peut-être un peu tordu, mais as-tu essayé de voir si l'Oric charge un bloc mémoire rempli de $FF correctement ?
@symoon oui c'est possible que mes bits 1 sont trop courts mais dans ce cas l'Oric n'arriverait pas à lire correctement les octets. D'autre part, à vitesse normale si je n'alterne pas les bits de stop 3x et 4x comme le fait l'Oric quand il envoie des données j'ai systématiquement des erreurs.
Je vais refaire des tests notamment avec un bloc mémoire rempli de $FF on verra bien.
Ce qui est surprenant aussi c'est que Anthony n'a pas pu descendre en dessous de 2*80 micro secondes pour les bits 1 alors que j'arrive à 2*50...
En fait, d'expérience, il y a plusieurs choses à considérer avec le signal cassette:
- à quel moment précis du signal le hardware Oric détecte le front montant
- le temps minimum de réaction du hardware entre deux fronts
- le temps minimum de traitement software (ROM) de l'info lue
- les différences d'un Oric à l'autre (qui ne nous préoccupent pas ici a priori)
J'ai eu des surprises à chaque fois en jouant avec les limites.
Je n'ai jamais sorti de version plus récente de Novalight car, je ne m'explique pas pourquoi, alors que sur le papier tout va bien, les chargements étaient moins fiables. Pour un gain de qqes % sur 15 secondes, le jeu n'en vaut plus la chandelle.
Et donc, le genre de chose qui faisait planter Novalight, c'était par exemple dans certains cas de figure alors que l'Oric changeait de page mémoire pour charger, ça plantait. Eh oui, lors d'un changement de page, certaines instructions mettent 3µs au lieu de 2, et cela suffisait à générer des plantages qui semblaient "aléatoires".
Et aussi, la forme du signal. J'avais fait une longue étude des formes de signaux qui réagissent le mieux. Tu peux en voir un bout ici: https://forum.defence-force.org/viewtopic.php?t=1360&hilit=experimental&start=15
Voici ce que j'utilise pour F16, qui date d'avant mes études de signal Novalight. Si ça se trouve, je pourrais gagner du temps ou de la fiabilité en changeant!
@symoon merci pour toutes ces informations précieuses.
En tenant compte de ce que tu as dit précédemment j'ai fait d'autres tests. Je suis passée à 120 micro secondes (2*60) pour un 1 et 3 bits de stop sans alternance ce qui fait 360 microsecondes.
Pour charger Doggy qui fait 39 Ko en vitesse normale je mets 299 secondes, en vitesse rapide 200 secondes et sans erreur.
@atmosphere bonne nouvelle ! Partant de là, tu peux tenter de réduire un peu et trouver la limite, genre 2*55 (soit 110, pour voir si ça passe) ? Et si ça ne passe pas avec 2*55, tu peux tenter avec la forme Novalight, ce qui donnerait:
- pour 1: 22 "bas", 2*22 "haut", et 2*22 "bas"
- pour 0: 22 "bas", 2*22 "haut", et 20*22 "bas"
Intéressant ^^
@symoon j'ai suivi tes conseils et je suis finalement arrivée à atteindre la vitesse 1.6x 😀
Avec les valeurs suivantes :
50//50 pour le bit 1
315/215 pour le bit 0
2 bits de stop !
186 secondes pour charger Doggy contre 299 secondes en mode normal.
j'ai testé sur des gros fichiers et pas d'erreur, reste plus qu'à tester sur mes autres Oric.
En fait c'est mon code pour l'affichage du directory qui bugge quand je fais aller l'Oric trop vite, je n'ai pas encore trouvé pourquoi mais l'essentiel c'est que le fichier se charge bien à la vitesse x1.6
Je n'ai pas testé le mode Novalight, ce qui serait bien ça serait d'intégrer Novalight au projet...
@atmosphere Bravo ! 😉
Novalight est autrement plus compliqué à mettre en oeuvre, il y a une double compression (RLE et dictionnaire d'octets les plus fréquents dans le fichier TAP), et la compatibilité est moindre. En outre ça occupe pas mal de place en page 1, à voir selon la place qui reste avec l'interface de chargement que tu utilises. C'est aussi optimisé parfois à la microseconde près. Mais ça doit pouvoir se faire !
Sinon attention avec seulement 2 bits de stop en F16, tu réduis peut-être la compatibilité avec les logiciels qui jouent avec les routines de chargement. Par exemple F16 avec 3 bits de stop ne permet plus de charger Trouble In Store (qui affiche un texte déroulant pendant le chargement). Lone Raider (qui joue une musique pendant le chargement et permet de changer le volume), lui, passe encore. J'avais fait un tableau:
FAST standard FAST F16 TAP2CD HIRES screen 0:56 0:34 0:08 Zorgon 4:31 2:37 0:31 Oricium 5:45 3:25 0:49 Lone Raider 5:08 2:59 fails Trouble In Store 5:14 fails fails
Ca me donne d'ailleurs envie de voir avec combien de bits de stop en plus Trouble In Store pourrait se charger, et d'en faire une option dans TAP2F16.
@symoon, Ok pour les bits de stop je peux toujours ajouter une option pour avoir 2 ou 3 bits, à voir si ça vaut le coup pour grapiller quelques secondes...
Mon système est simple, on a le choix de passer par l'affichage du directory ou d'utiliser simplement les fonctions csave ou cload, dans ce cas pas besoin de routine. Pour afficher le directory l'Oric charge un petit programme en basic de 5 lignes dès qu'on tape cload"", en mode Atmos il charge en plus une petite routine qui permet d'envoyer environ 10 octets à l'esp32 pour lui donner le nom du fichier à charger. On peut mettre cette routine où on veut. En mode Oric1 on ne charge pas de routine, le nom du programme à charger est transmit simplement par la fonction csave. L'avantage de ce projet c'est d'être simple, il n'occupe pas le port d'extension ni le port imprimante et reste compatible avec n'importe quel fichier, et en plus il est tout petit, on pourrait même l'intégrer dans un Oric.
C'est clair que Novalight est beaucoup plus complexe à mettre en oeuvre.
Pour le fun, le nombre de bits de stop nécessaires à Trouble In Store en format F16 pour un chargement complet correct est de... Neuf, rien que ça !
Donc 3min43 au lieu de 5min14.
@atmosphere ok, donc rien de méchant pour Novalight je pense.
Le truc qui risque d'être compliqué c'est que tous les timings de Novalight ont été faits pour un signal de 44100Hz, soit un peu moins de 23µs par sample, ou encore 69µs pour la période la plus courte.
Ca avait freiné ISS pour implémenter Novalight dans son programme pour Smartphone, qui ne fonctionnait qu'à 48000Hz; il aurait fallu retester toutes les formes de signaux à cette fréquence et potentiellement revoir le code.
Si tu peux émuler une période de 69µs sous la forme 23+46, c'est déjà une épine de moins.
