tu me demandes de la concision parce que tu ne veux pas lire ce que j'écris. Le problème c'est que vous ne lisez pas ce que j'écris.

Ce qui revient de façon invariable c'est : le CDT ou le WAV sont claqués.

Hors je sais aujourd'hui qu'on est plus dans ce cas là.



Merci ouf enfin !



Oui c'est normal et ce n'est pas une erreur de ma part

j'ai posté volontairement les logs générés par l'outil pour montrer la différence en terme de contenu avec les CDTs ancienne génération.

Si tu as attentivement regardé le log de Mask, les micro-blocs n'ont aucun CRC, et la cassette originale est composée de blocs lus à une vitesse moyenne de 2300 bauds.

J'ai redumpé dernièrement Bad Cat de Go!/Rainbow Arts, le jeu utilise des blocs enregistrés à une vitesse moyenne de 3350 bauds.

Je voudrais aussi insister sur un fait. En dehors des cas spéciaux non supportés, les CDTs nouvelle génération fonctionnent très bien dans l'ensemble avec sugarbox.

Ce serait donc sympa de ta part si tu pouvais supporter les logiciels à encodage particulier

_________________
SPS Community Expert (SPS CE) / SPS France

Merci, mais je n'en ai pas l'usage (je ne développe pas d’émulateur). Il peut être utile affin de le comparer a un dump équivalent sortant d'un émulateur.

Si un fichier wav est demandé (avec tout ses défaut), c'est pour comparer le comportement du traitement wav avec celui du traitement cdt.
Si l'un marche et pas l'autre, il y a une piste a suivre. Si aucun ne marche on n'avance pas, mais on a essayé.
Avec un wav résultant d'un CDT, il fraudait modifier le traitement du wav pour supprimer tout les traitement avant le PPI.

Sinon, le moyen le plus simple :
Faire un CAT et passer l'ensemble du CDT/wav tout en dumpant le temps entre 2 transition de l'entre PPI et comparer les deux dump, voir à un dump de l'entrée PPI d'un CPC réel.

Attention, la comparaison doit s’accommoder d'un marge sur le temps entre les transition.

tu peux m'éclairer s'il te plait au sujet des transitions, à quoi celà va servir exactement ?

_________________
SPS Community Expert (SPS CE) / SPS France

Un cdt/wav 'numerique' ne contient que des transitions (0 vers 1, 1 vers 0)
Une facon de verifier que le CDT et le wav contiennent la même information est de dumper le temp entre chaque transition.
Connaissant le niveau (0 ou 1) de début, il suffit de comparer le temps (avec une marge) entre chaque transition pour déterminer que le contenu est le même.

Ah ok oui effectivement.



Ce que tu dis est juste, néanmoins il y a un problème : on est uniquement intéressé par les transitions qui correspondent dans leur ensemble aux données. Forcément, avec un WAV brut tiré d'une K7, il y a de la crasse, et cette crasse se retrouve elle aussi sous forme de 0 et 1.

Hors on en veut pas de cette dernière, elle empêche les logiciels de fonctionner.



Justement, quand on part d'un WAV brut (la matière première), et qu'on le passe en CSW type 1, on comprime le dit WAV, les données sont complètes, simplement elles sont condensées. Dans ce CSW type 1, tu trouves les octets correspondants au timings de la cassettes, suivi des données de chaque bloc. sont gardés uniquement ces deux choses, timings + données, et quand l'outil fait le réverse du CDT en CSW type 1, c'est l'opération inverse qui a lieu, le CSW type 1 est juste dépourvu de crasse, les données en elles-même sont repositionnées telles qu'à l'origine.

En fait, si on pouvait enregistrer les wav digitaux sur cassette, on aurait un nouvel original avec les jolies dents qui plaisent à Thomas

_________________
SPS Community Expert (SPS CE) / SPS France

http://sasfepu78.fr/Others/AMSTRAD/

y'a 3 archives au format 7Z
Archives qui contiennent le dump format WAV qui fonctionne sur un vrai CPC 'testé'
Le dump format propriétaire des données PPI qui arrivent au CPC pendant le chargement du jeu.
(jeu qui a donc ensuite fonctionné, donc donnée PPI OK)

Le soft est dispo (au meme endroit) en version 32 et 64Bits
Il permet de voir dans un 1er temps les données
et les exporter en ce que l'on veux.

Voila

J'en profite pour vous demander, savez vous comment calculer la vitesse d'un bloc de CDT
en baud. ? (j'ai bien dit d'un bloc et pas d'un cdt complet)

Last Mission (F) loriciel_WAV 100% conforme.7z

mask1-uk_WAV 100% conforme.7z

bonne nouvelle, j'ai le même comportement qu'avec les CDTs, cela prouve pour moi qu'on est bien sur des choses identiques entre le CDT et WAV 100% conforme.

-> reste à expliquer pourquoi cela ne marche pas !

Je suis pas sur mais... c'est pas ce que dit denis depuis quelques thread ?
C'est quoi l’intérêt de vérifier ce qu'il dit ? (c'est pas un pic mais une question hein ok ?)

oui, je me suis mal exprimé !

cela veut bien dire que mon emulateur traduit le wav et le cdt 100% conforme en 0 et 1 qui donnent le même résultat !

je n'ai pas dit que Denis ne dit pas vrai depuis le début, mais je voulais éliminer la piste de mon code wav 44100Hz -> vers données PPI 4Mhz versus code cdt 3.5Mhz -> vers données PPI 4Mhz.

ah Ok, sur ton emul, Ok
Merci pour l’éclaircissement.

César a bien fait les choses C'est tout à fait normal que ton émulateur donne le même résultat, puisque CDT et WAV sont identique point de vue contenu.



Bien si tu veux mon avis, comme vous utilisez toi et thomas une émulation 100% correcte du z80, et des autre puces si j'ai bien compris, c'est plus un problème haut niveau que vous rencontrez.

Les systèmes qui échouent utilisent entre autre la polarité (qui repose sur les timings, Thomas disait juste à ce propos, MAIS PAS SEULEMENT. Il faut s'assurer via le débug que celle-ci s'active correctement et de la manière qu'attend le loader.)

Il y a également les bordures qui sont détectées et importantes. Comment vos émulateurs gèrent ces dernières, vous pouvez m'en dire plus ?

_________________
SPS Community Expert (SPS CE) / SPS France

Bon, césar a eu un peu de temps ce soir, je lui ai expliqué les soucis rencontrés avec le système opérasoft et
et celui de Mask :

pour le système de chez Opéra soft, il faut prévoir ceci :

"A moins que l'émulateur ne garde l'entrée cassette muette pendant un court moment, la méthode de chez Opera Soft prendra les octets trailer $FF du loader comme des pilotes valides, ce qui fait tout foirer.
Puis le moteur du lecteur de cassette devient actif, mais il ne doit fournir des données qu'après un délai de plusieurs millisecondes plus tard. Il est à noter également que le relais présent sur le CPC ne s'active pas immédiatement"

"Concernant le jeu Mask, c'est très simple dans le principe, peu importe que ce soit en WAV ou en CDT, tout auteur d'émulateur qui ne respectera pas la polarité utilisée par le loader de ce jeu verra ce dernier planter de façon systématique sans aucune autre forme de procès. La polarité n'est pas un effet de manche ou une bizarrerie sortie de ma tête, le loader l'utilise, si elle est absente dans l'implémentation de vos émulateurs, le jeu refusera de fonctionner."

Pour finir il m'a demandé ceci : "demande à ces créateurs d'émulateurs de désassembler les loaders de chaque jeu, et tout leur apparaitra de façon claire, et ils pourront corriger le tir sur leurs émulateurs respectifs, et les jeux fonctionneront."

Donc moralité de l'histoire : c'est un mélange de problème d'émulation hardware, et d'absence d'implémentation logicielle

Donc pas besoin de se faire chier à logger à la pin du PPI

A vous de jouer messieurs

_________________
SPS Community Expert (SPS CE) / SPS France

Je ne connait pas bien le format csw mais est t'il normal que les fichiers csw donné/généré ici soient en version 1.1 au lieu de 2.0.
1.1 me semble vieillo, non ?
C'est donnée comme 'OLD' dans les spec.

le format 2.0 n'apporte rien du tout si ce n'est une couche de compression inutile, et en plus c'est du 16 bits.

Problème: aucune cassette amstrad CPC n'est enregistrée dans ce format. Toutes les cassettes amstrad CPC
ont été dupliquées en 8 bits mono 44khz-48khz.

Les WAV enregistrés en 16 bits posent plus de problèmes qu'autre chose, car comme le spectre est plus large, la moindre merde présente sur la cassette se retrouve dans le WAV en format XXL.

Je fais un parallèle un peu dégueulasse mais qui parle et bien visuel.

en mode 8 bits : Admettons que tu lâches une caisse (lol), on enregistre juste le bruit de la caisse.

en mode 16 bits : admettons que tu lâches la même caisse, sauf que là, tu es en studio, et la j'ai pas seulement le bruit de la caisse, j'ai l'amplitude sonore de la trace de freinage au fond de ton slip, plus la résonance et presque l'odeur !

Très clairement, j'ai pas besoin de tout ça. J'ai juste besoin des données correspondant "à la caisse".

le mode 16 bits absorbe des parasites et du bruit impossibles à filtrer correctement.

_________________
SPS Community Expert (SPS CE) / SPS France

Je reste dubitatif sur les explications :
1. Le lecteur de cassette fournis des données au PPI tant qu'il y en a au niveau de la tête de lecture. Le relais ne commande que le moteur. Autant avec une vrai bande magnétique le temps de démarrage et d’arrêt crée une distorsion du signal de la bande en fréquence et amplitude, l'utilisation d'une fausse cassette branchée sur un PC ne peu pas reproduire cet effet : le moteur est ignoré.

2. Pour mon éducation, quelqu'un peut préciser ce que tout le monde appelle polarité ? Comment elle est représenté dans le CDT ?