J'ai récupéré plusieurs jeux au format TAP, la plupart se chargent correctement et certains plantent et je ne sais pas vraiment pourquoi. Quand je regarde comment sont séparés les différentes séquences d'un fichier TAP, certains présentent 3*0x16 (octets de synchro) et 1*0x24 au début de chaque séquences, jusque là pas de soucis mais d'autres n'ont que 2*0x16 certains 4*0x16 et même on peut trouver 256*0x16, est-ce que ça signifie quelque chose de particulier (pause, vitesse de transmission etc) ?
Voila le lien de référence pour les formats TAP. Tous les trucs qui ne répondent pas à ce std présenteront des difficultés de chargement sur un systeme ou un autre.
Document très utile, je me rends compte que Oricutron respecte bien les 4 octets de début contrairement aux fichiers TAP que j'avais.
Parmi mes jeux en TAP que je n'arrive pas à lire, quand je les lis avec mon Erebus il n'y a pas de soucis, je n'arrive toujours pas à comprendre ce qui cloche.
dans le but de rendre compatible mon lecteur sd avec tous les fichiers TAP, j'essaie de comprendre comment ces fichiers sont organisés. J'ai récupéré plusieurs jeux au format TAP, la plupart se chargent correctement et certains plantent et je ne sais pas vraiment pourquoi. Quand je regarde comment sont séparés les différentes séquences d'un fichier TAP, certains présentent 3*0x16 (octets de synchro) et 1*0x24 au début de chaque séquences, jusque là pas de soucis mais d'autres n'ont que 2*0x16 certains 4*0x16 et même on peut trouver 256*0x16, est-ce que ça signifie quelque chose de particulier (pause, vitesse de transmission etc) ?
J'ai cherché un peu partout mais je ne trouve pas de réponse...
C'est historique.
Les premiers émulateurs (1995) qui ont créé le format .TAP, ont voulu économiser de la place, et donc au lieu d'avoir 256 (environ) 0x16 dans la synchro, en ont gardé:
- un seul pour Amoric (donc on avait 0x16 puis 0x24 comme amorce dans le .TAP)
- au moins trois pour Euphoric (donc trois 0x16 puis 0x24 comme amorce dans le .TAP)
Mais, afin de pouvoir lancer tous les fichiers .TAP qui existaient sur le Net, donc y compris ceux créés pour Amoric, Euphoric a évolué pour accepter un seul 0x16. Ceci étant, les outils de conversion WAV=>TAP sur PC continuaient à produire trois 0x16 en entrée.
Ceci est resté la norme jusqu'en 2011, où nous avons réalisé, avec Dom et Fabrice, que la séquence 0x16+0x24 existait dans les données de quelques programmes en plusieurs parties (par exemple Hadès de Ere Informatique), et donc les TAP de ces programmes trompaient parfois Euphoric, et plantaient au chargement !
Est donc alors apparu un nouveau format supplémentaire: les TAP avec quatre 0x16 et un 0x24 en guise de synchro.
A partir d'Euphoric 1.014, quand il rencontre cet en-tête, il bascule vers un mode de chargement qui exige que toutes les parties suivantes utilisent aussi 4*0x16 (c'est d'ailleurs le nombre requis par la ROM: un 0x16 pour se synchroniser, et trois pour valider la synchro).
Ainsi, on pouvait construire des fichiers .TAP utilisant quatre 0x16 pour la synchro, dans lesquels un 0x16 0x24 perdu dans le code ne serait pas pris pour une synchro cassette. Euphoric restait compatible avec les anciens TAP, et peut charger soit ces nouveaux formats, soit les anciens, selon le nombre de 0x16 qu'il rencontre au début du fichier .TAP.
Je ne suis pas expert d'Oricutron, mais je pense qu'il génère des fichiers avec quatre 0x16, mais sait lire ceux avec trois... A confirmer !
Le problème, c'est que j'étais sur le point de mettre à jour les outils de conversion WAV => TAP en 2016 pour qu'ils produisent quatre 0x16, mais:
- j'ai rencontré des difficultés sur d'autres options en cours d'ajout (STORE/RECALL, vitesse lente, ...), et la vie a repris le dessus
- il existe tant de forks que quasi plus personne ne va chercher la version qui, il y a 20 ans, était "la seule" (aujourd'hui sur Sourceforge)
Donc les outils de conversion continuent, j'imagine, à produire majoritairement trois 0x16 aujourd'hui.
Note annexe: de temps en temps, des gens produisent des TAP multi-part, avec quatre 0x16 au début, et les parties suivantes n'en ont que trois. Du coup, ça ne charge pas sur Euphoric, qui exige quatre 0x16 pour toutes les parties d'un TAP qui commence par quatre 0x16. Il y a eu quelques soucis remontés sur les forums à ce sujet, mais je pense que ça se raréfie car Euphoric, excellent émulateur mais sous MS-DOS, a perdu du terrain au profit d'Oricutron.
Il n'était en outre plus possible, en 2011, de changer le format du fichier .TAP et d'exiger d'avoir quatre 0x16 uniquement, car il existait déjà des milliers de fichiers .TAP, tous dupliqués partout sur internet.
Conclusion: bonne chance pour une synthèse et une lecture universelle de tous les TAP existants 😀
PS: ceux qui contiennent 256 fois 0x16 signifient simplement que l'outil de conversion WAV vers TAP n'a pas détecté une fin de partie/début de partie suivante, et a continué à décoder le WAV comme si les données continuaient. Le TAP contient donc en général quelques octets "parasites" liés au blanc entre les deux parties (non lus au chargement du TAP car la ROM de l'Oric sait où arrêter la lecture, et ils seront zappés car avant la synchro suivante), et ensuite tous les 0x16 qui existaient sur la bande d'origine.
A noter que ces octets parasites gênent quand même certains outils de re-conversion TAP vers WAV, c'est mieux de ne pas les avoir. Mais... Comme d'hab, ils ont existé sur internet et sont donc dupliqués partout, il faut faire avec ou accepter que de temps en temps quelqu'un viendra se plaindre que quelque chose ne "marche pas" 😉
Parmi mes jeux en TAP que je n'arrive pas à lire, quand je les lis avec mon Erebus il n'y a pas de soucis, je n'arrive toujours pas à comprendre ce qui cloche.
Envoies moi si tu veux les TAP. je regarderais.
Un grand merci Symoon pour ces précieuses explications, j'ai pu modifier mon code, maintenant les fichiers TAP que je sauvegarde auront bien 4 octets de synchro, et en lecture il accepte maintenant 4, 3 ou 2 octets de synchros. Cette histoire me décalait la position où l'Oric attend un bit de stop supplémentaire à la fin du header. Sans ce bit l'Oric indique qu'il y a une erreur de transmission même si le programme est bien chargé en mémoire.
Didier, je veux bien, je vais essayer de regrouper les fichiers TAP qui plantent encore et je t'envoie ça.
