Bon, cette fois-ci, c'est la bonne ! Avec toutes ces infos, j'ai pu peaufiner mon algo qui lance désormais, sans trucage, les jeux suivants :
- Skate crazy (les deux wav de Denis) - Basil (le wav original, je n'ai pas testé le wav reconstitué...) - Footballer of the year II, que ça soit le dump de Denis ou de Nicholas Campbell
Voici donc ce que je fais, si d'autres veulent implémenter un truc similaire :
Considérons une sortie du wav comprise entre -1 et 1.
- J'applique un facteur empirique de 0.005 (simualtion d'une sortie a +-5mV) - Je passe un filtre de suppression de bruit, (fc=4100hz) - Filtre passe haut, fc = 7 Hz - Gain x 37 - Gain x70 - Filtre passe haut, fc = 500hz - Gain x7 - Shift de mon signal de -0.5 (pour simuler l'offset de l'ampli op a 1.7v et le passage a 2.2v de l'entrée PPI)
Et voila le travail !
Me reste à fignoler pour gérer les différentes fréquences d'échantillonage rencontrées, le problème de a sortie imprécise en CSW, et je vous proposerais une version de test.
Merci Philippe et Gérald pour vos infos !
EDIT : C'est très empirique comme fonctionnement, il est fort possible qu'on puisse l'améliorer (si vous avez des idées !)
Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
Lone a écrit :
Bon, cette fois-ci, c'est la bonne ! Avec toutes ces infos, j'ai pu peaufiner mon algo qui lance désormais, sans trucage, les jeux suivants :
- Skate crazy (les deux wav de Denis) - Basil (le wav original, je n'ai pas testé le wav reconstitué...) - Footballer of the year II, que ça soit le dump de Denis ou de Nicholas Campbell
est-ce que c'est applicable aussi aux cdts ou seulement aux waves originales ? j'ai peut-être pas tout compris !!!
Alors, le problème que nous avons, c'est qu'aucun traitement ne peut être fait sur le CDT : Il s'agit d'une représentation des données, et non du signal de la cassette. Du coup, on ne peut y faire de traitement à posteriori.
Vu que le wav passe sans soucis, mais pas le CDT, c'est que la conversion ne s'est pas faite correctement.
Pour bien faire, il faudrait reprendre ces CDT et arriver à les faire tourner sans tour de passe-passe, vu qu'on peut faire marcher les wav originales.
L'exercice des quelques dernieres pages du post consistait à tenter d'émuler au plus près le hard, pour déterminer de quelle manière le CPC arrive à lire ces cassettes. On en a sans doute désormais une meilleurs idée, maintenant, il faudrait se pencher sur la manière de générer ces CDT pour ne plus avoir de soucis.
Gros boulot à mon avis, et compliqué à automatiser, de par la nature même du cdt, qui tente d'analyser la cassette pour la convertir en "données type" (pilote, etc). On retrouve l'avantage immense du CSW, qui devrait pouvoir fournir rapidement un dump fonctionnel.
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Lone a écrit :
Alors, le problème que nous avons, c'est qu'aucun traitement ne peut être fait sur le CDT : Il s'agit d'une représentation des données, et non du signal de la cassette. Du coup, on ne peut y faire de traitement à posteriori.
Pas d'accord. Un CDT est généré d'après le signal, il ne s'agit pas d'un décodage, mais d'un passage du signal non lisible humainement parlant sous leur forme d'origine : des blocs. On ne peut pas écrire les fichiers tels qu'on les voit quand on "cat" une cassette, les fichiers sont sauvés sous forme de blocs, blocs qui sont écrits sous forme de signal sur la cassette.
Quand je génère un fichier CDT (ou une autre personne), on obtient sous forme lisible ce qui est écrit sur la cassette.
Vu que le wav passe sans soucis, mais pas le CDT, c'est que la conversion ne s'est pas faite correctement.
Pour bien faire, il faudrait reprendre ces CDT et arriver à les faire tourner sans tour de passe-passe, vu qu'on peut faire marcher les wav originales.
Citer :
L'exercice des quelques dernieres pages du post consistait à tenter d'émuler au plus près le hard, pour déterminer de quelle manière le CPC arrive à lire ces cassettes. On en a sans doute désormais une meilleurs idée, maintenant, il faudrait se pencher sur la manière de générer ces CDT pour ne plus avoir de soucis.
Ce que je peux dire, c'est que lorsque je dumpe une cassette, le signal que je vois s'inscrire dans la fenêtre d'enregistrement de Goldwave, c'est bien ce que j'ai dans mes blocs, et pareil lorsque je prends un fichier CDT, et que je le convertis de nouveau au format WAV.
Quand je prends un CDT qui ne passe pas sous Sugarbox pour cause de polarité, et que je le converti de nouveau en WAV, ce wav contient le contenu des blocs, leurs infos (pulse, pilot tone, et ainsi de suite converti), et si le CDT était érroné ou encore incorrect, CDT2WAV ne saurait pas en faire la conversion en un fichier WAV fonctionnel, et mon CPC 464 n'arriverait pas à le lire, de la même manière que Sugarbox en émulation.
Là encore, quand je dumpe, je teste mon fichier WAV durant le dump car mon 464 lit le signal, je vérifie les blocs après la conversion au format CDT, et si le jeu au format CDT nécessite l'inversion de polarité, je refais pour être sur avec ce type de jeu utilisant des formats "exotiques" de ce genre un test inverse, en convertissant le CDT que je viens de créer en WAV, donc en retour arrière.
Et tout les CDTs reconvertis en WAV, mon 464 les lit et les charge sans problème, ce qui valide donc que le CDT à l'origine du fichier WAV reconverti est bon à la base, CQFD
Ce qui est incorrect ou non fonctionnel à la base, ne peut pas être transformé en quelque chose qui marche.
Si je fais un comparato, c'est comme si je prenais un disque dur physiquement claqué, et que je dise qu'en le formatant je corrige le problème. C'est non seulement faux, mais c'est un raisonnement intenable. Un disque dur claqué physiquement est absolument irrécupérable (sauf récupération par une société spécialisée à un prix coutant 6 bras et 12 jambes).
Citer :
Gros boulot à mon avis, et compliqué à automatiser, de par la nature même du cdt, qui tente d'analyser la cassette pour la convertir en "données type" (pilote, etc). On retrouve l'avantage immense du CSW, qui devrait pouvoir fournir rapidement un dump fonctionnel.
Le format CDT, comme les IPFs nécessite une intervention manuelle. Chaque jeu est différent (hors jeux utilisant des formats standards).
_________________ SPS Community Expert (SPS CE) / SPS France
Alors, le problème que nous avons, c'est qu'aucun traitement ne peut être fait sur le CDT : Il s'agit d'une représentation des données, et non du signal de la cassette. Du coup, on ne peut y faire de traitement à posteriori.
Pas d'accord. Un CDT est généré d'après le signal, il ne s'agit pas d'un décodage, mais d'un passage du signal non lisible humainement parlant sous leur forme d'origine : des blocs. On ne peut pas écrire les fichiers tels qu'on les voit quand on "cat" une cassette, les fichiers sont sauvés sous forme de blocs, blocs qui sont écrits sous forme de signal sur la cassette.
C'est pas vraiment ça : Si tu regardes comment est écris une cassette (dans le firmware), tu verras que l'on va positionner le bit du PPI pour l'écriture de cassette sur "1" et "0", pendant des durées différentes. Au niveau de la cassette, on s'arrête là : Les blocs, pilotes, et autres CRC sont à un niveau d'abstraction supérieur (l'organisation de ces "1" et "0"). Le CDT se situe à ce niveau supérieur (sauf pour les bloc CDT de type "DRB" ou "CSW"). on peut du coup dire que le CDT, suivant les blocs qu'il utilise, peut se situer entre les deux.
Pour les wav (et csw), c'est simple : Ils se situent au niveau de ces "1" et "0".
C'est la même chose que sur les disk : Sur les disk, on encode en MFM (des 1 et des 0) des données qui, une fois mise en ordre, permettent de retrouver des schémas permettant d'avoir une vue plus abstraite des données.
Donc, le CDT n'est pas au même niveau que le WAV, il est important de faire la distinction.
dlfrsilver a écrit :
Quand je génère un fichier CDT (ou une autre personne), on obtient sous forme lisible ce qui est écrit sur la cassette.
Vu que le wav passe sans soucis, mais pas le CDT, c'est que la conversion ne s'est pas faite correctement.
C'est très juste : La conversion wav->cdt ne s'est pas faite de manière à retrouver les infos... Que le CDT fonctionne comme le WAV est une condition nécessaire (mais pas suffisante !) pour dire qu'il s'agit d'une copie conforme.
dlfrsilver a écrit :
Pour bien faire, il faudrait reprendre ces CDT et arriver à les faire tourner sans tour de passe-passe, vu qu'on peut faire marcher les wav originales.
Le CDT ne permet quasiment pas de faire des "tour de passe passe" : C'est un format qui est assez peu ambigu, une fois qu'on a compris les différentes conventions. En fait, le seul tour de passe passe consisterait... A inverser la polarité.
dlfrsilver a écrit :
Citer :
L'exercice des quelques dernieres pages du post consistait à tenter d'émuler au plus près le hard, pour déterminer de quelle manière le CPC arrive à lire ces cassettes. On en a sans doute désormais une meilleurs idée, maintenant, il faudrait se pencher sur la manière de générer ces CDT pour ne plus avoir de soucis.
Ce que je peux dire, c'est que lorsque je dumpe une cassette, le signal que je vois s'inscrire dans la fenêtre d'enregistrement de Goldwave, c'est bien ce que j'ai dans mes blocs, et pareil lorsque je prends un fichier CDT, et que je le convertis de nouveau au format WAV.
Dans ce cas, ouvre le fichier original ET le fichier généré depuis un cdt. Un petit zoom, et hop, tu vois que c'est très différent : Dans un cas, on a un signal a vaguement sinusoidal, et dans l'autre, un signal carré. Certe, on retrouve nos infos, mais dire "c'est exactement pareil" est un petit peu exagéré. En regardant de près, on est sur et certain de voir un paquet de différences. Dans la plupart des cas, ces différences ne provoqueront pas de problème, mais dans de rare cas, si (les cas qui nous intéressent, justement).
dlfrsilver a écrit :
Quand je prends un CDT qui ne passe pas sous Sugarbox pour cause de polarité, et que je le converti de nouveau en WAV, ce wav contient le contenu des blocs, leurs infos (pulse, pilot tone, et ainsi de suite converti), et si le CDT était érroné ou encore incorrect, CDT2WAV ne saurait pas en faire la conversion en un fichier WAV fonctionnel, et mon CPC 464 n'arriverait pas à le lire, de la même manière que Sugarbox en émulation.
Le CDT est correct dans sa forme, ce qui suffit à cdt2wav pour le convertir. Par ailleurs, un test intéressant serait donc de copier cette wav généré vers une cassette, et de dumper cette cassette, ne serait-ce que pour voir la différence entre le signal de cdt2wav et ce qui se trouver réellement sur la cassette.
dlfrsilver a écrit :
Là encore, quand je dumpe, je teste mon fichier WAV durant le dump car mon 464 lit le signal, je vérifie les blocs après la conversion au format CDT, et si le jeu au format CDT nécessite l'inversion de polarité, je refais pour être sur avec ce type de jeu utilisant des formats "exotiques" de ce genre un test inverse, en convertissant le CDT que je viens de créer en WAV, donc en retour arrière.
Et tout les CDTs reconvertis en WAV, mon 464 les lit et les charge sans problème, ce qui valide donc que le CDT à l'origine du fichier WAV reconverti est bon à la base, CQFD
Malheureusement c'est inexact : Ca valide juste que le cdt reconvertit en WAV donne une image fonctionnelle. Comme je le disais plus haut, tu as beaucoup d'étape susceptible de changer ton signal, et donc de retomber dans un cas qui fonctionne, ou pas.
Le seul test permettant de valider le chargement d'un dump par un émulateur (la précision de celui-ci), c'est celui là : - Réaliser un dump - Le tester sur 464 - Le tester sur emulateur.
Le reste n'a quasiment aucune valeur (autre que "le cdt fait marcher le jeu"). Tu n'as aucun moyen de dire que ton CDT marche sur 464. La seule chose que tu peux dire, c'est "le cdt passé à cdt2wav et enregistré sur une cassette fonctionen", ce qui est bien, voir suffisant, mais ne permet pas de dire que le cdt fonctionne.
dlfrsilver a écrit :
Ce qui est incorrect ou non fonctionnel à la base, ne peut pas être transformé en quelque chose qui marche.
Si je fais un comparato, c'est comme si je prenais un disque dur physiquement claqué, et que je dise qu'en le formatant je corrige le problème. C'est non seulement faux, mais c'est un raisonnement intenable. Un disque dur claqué physiquement est absolument irrécupérable (sauf récupération par une société spécialisée à un prix coutant 6 bras et 12 jambes).
J'avoue que je ne vois pas le rapport...
Pour conclure, orenons Basil par exemple, la seule chose que l'on peut dire, c'est : - Le wav issue de l'original marche sur Sbx et 464 - Le cdt ne marche pas sur émulateur - Le wav généré par cdt2wav fonctionne sur 464... Et sur ému (même si la manip correcte serait de redumper cette cassette générée...)
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Citer :
C'est pas vraiment ça : Si tu regardes comment est écris une cassette (dans le firmware), tu verras que l'on va positionner le bit du PPI pour l'écriture de cassette sur "1" et "0", pendant des durées différentes. Au niveau de la cassette, on s'arrête là : Les blocs, pilotes, et autres CRC sont à un niveau d'abstraction supérieur (l'organisation de ces "1" et "0").
C'est sous cette forme que le PPI voit les données, nous sommes d'accord. Sauf que comme je le disais, au regard de la taille que prend un fichier WAV, les duplicateurs n'ont jamais utilisé de master sous cette forme. Les PCs utilisés à l'époque pour le mastering n'avaient pas de disque dur suffisamment gros pour ça.
Les duplicateurs utilisaient donc à la base un format de fichier compact équivalent au format CDT. Facile à transporter sur une disquette
Citer :
Le CDT se situe à ce niveau supérieur (sauf pour les bloc CDT de type "DRB" ou "CSW"). on peut du coup dire que le CDT, suivant les blocs qu'il utilise, peut se situer entre les deux.
Voir mon commentaire plus haut.
Citer :
Pour les wav (et csw), c'est simple : Ils se situent au niveau de ces "1" et "0".
C'est la même chose que sur les disk : Sur les disk, on encode en MFM (des 1 et des 0) des données qui, une fois mise en ordre, permettent de retrouver des schémas permettant d'avoir une vue plus abstraite des données.
Sauf qu'un master d'un jeu sur disquette au format MFM ça pèse pas lourd, tandis qu'un master cassette au format WAV ou VOC si tu préfères, ça peut peser jusqu'à 50mo.
Citer :
Donc, le CDT n'est pas au même niveau que le WAV, il est important de faire la distinction.
Bien évidemment. Un fichier CDT contient les blocs d'un jeu ou logiciel à graver sur bande, via une unité de mastering cassette, tandis qu'un fichier WAV est un dump du signal analogique enregistré sur une cassette.
Citer :
C'est très juste : La conversion wav->cdt ne s'est pas faite de manière à retrouver les infos... Que le CDT fonctionne comme le WAV est une condition nécessaire (mais pas suffisante !) pour dire qu'il s'agit d'une copie conforme.
Le contenu du WAV est conforme à ce que contient le fichier CDT. Télécharges CDT2WAV en version 1.1, et tu verras que ce soft converti très exactement en bit 0 et 1 le contenu du CDT, et permet par ailleurs de "lire" le contenu du CDT converti, directement sur un CPC 464.
C'est pour ça que je te dis que le WAV est correct car le CDT dont il est issu est correct lui aussi.
Citer :
Le CDT ne permet quasiment pas de faire des "tour de passe passe" : C'est un format qui est assez peu ambigu, une fois qu'on a compris les différentes conventions. En fait, le seul tour de passe passe consisterait... A inverser la polarité.
Oui pas besoin globalement de faire des tours de passe passe car les formats cassette sont linéaires dans l'ensemble et "simples".
Citer :
Dans ce cas, ouvre le fichier original ET le fichier généré depuis un cdt. Un petit zoom, et hop, tu vois que c'est très différent : Dans un cas, on a un signal a vaguement sinusoidal, et dans l'autre, un signal carré.
Mais c'est juste une évidence ! Une cassette contient toujours un signal analogique, tandis que le signal venant d'un CDT est digital ! Ce fameux signal analogique est converti en digital, donc bien meilleur !
Pareil, si j'enregistre un WAV (converti d'un CDT, avec un signal propre et carré et donc digital) sur une vraie cassette, le signal sera sauvé en analogique sur la bande.
Citer :
Certe, on retrouve nos infos, mais dire "c'est exactement pareil" est un petit peu exagéré. En regardant de près, on est sur et certain de voir un paquet de différences. Dans la plupart des cas, ces différences ne provoqueront pas de problème, mais dans de rare cas, si (les cas qui nous intéressent, justement).
Pas exactement dans le sens ou un signal analogique n'a pas la même gueule qu'un signal digital, néanmoins, la protection est là, les blocs sont là, les pauses aussi, les infos pilot tone et consort aussi.
Tout ça est suffisant pour permettre la lecture d'un jeu cassette dans les deux sens, 464 vers WAV vers CDT et CDT vers WAV vers 464.
Citer :
Le CDT est correct dans sa forme, ce qui suffit à cdt2wav pour le convertir.
Pas seulement. Il convertit les informations au bit près, bit que mon 464 relit et traite sans erreur.
Citer :
Par ailleurs, un test intéressant serait donc de copier cette wav généré vers une cassette, et de dumper cette cassette, ne serait-ce que pour voir la différence entre le signal de cdt2wav et ce qui se trouver réellement sur la cassette.
J'ai pas besoin en fait de copier le WAV généré vers une cassette. Mon banc de test me permet de tester en direct le WAV reconverti sur mon CPC 464.
Ensuite, si je sauvais réellement ce wav reconverti sur cassette réelle, je retrouverais le signal sinusoidale classique qu'on a sur toute les cassettes amstrad et autres machines. Prends l'exemple de certains jeux sortis récemment sur amstrad CPC 464 par psytronik par exemple ou autre, j'ai dumpé ce type de cassette, qui ont été écrite sur un amstrad CPC (pas de mastering de tape industriel sauf erreur de ma part), hé bien j'ai un signal sinusoidal sous Goldwave lorsque je dumpe ce type de cassette.
Citer :
Malheureusement c'est inexact : Ca valide juste que le cdt reconvertit en WAV donne une image fonctionnelle.
Pas seulement fonctionnelle. Conforme à ce que contenait le CDT, puisque CDT2WAV fait une conversion bit à bit du contenu du CDT, pour injection dans un fichier WAV.
ça vient de m'être confirmé par Markus Hohmann, le programmeur de l'application.
Donc ce que je disais était valide et exact. Un CDT claqué ou incorrect sera converti en un fichier WAV incorrect ne fonctionnant pas sur un 464.
Dans le cas des jeux utilisant l'inversion de polarité, les CDTs que j'ai crée sont donc convertis en "aveugle" par CDT2WAV, ce qui veut dire que les WAV reconvertis sont donc 100% conformes aux CDTs dont ils sont issus.
Ce qui nous ramène donc au problème de base :
Pourquoi Sugarbox se prend les pieds dans le tapis avec les CDTs que j'ai généré depuis mes fichiers WAV originaux ? Pourquoi mon 464 arrive à traiter comme les WAV originaux les WAV que j'ai reconverti depuis les CDTs générés via CDT2WAV ?
Citer :
Le seul test permettant de valider le chargement d'un dump par un émulateur (la précision de celui-ci), c'est celui là : - Réaliser un dump - Le tester sur 464 - Le tester sur emulateur.
T'es gentil Thomas, mais c'est ce que je fais à chaque fois que je dumpe.
Je rappelle comment ça se passe chez moi :
J'ai un magnétophone haut de gamme, connecté à mon PC (machine haut de gamme doté d'une carte son spécifique haut de gamme elle aussi), connecté sur le port d'entrée de la dite carte son, prévue expressément pour dumper les logiciels les plus retord qui soient quelque soit l'ordinateur (CPC, C64, spectrum, etc bref, mon cul sur la commode ).
Mon CPC 464 est connecté à mon PC via une cassette digitale branché sur le port de sortie haut parleur de la carte son.
Goldwave est l'outil de pilotage et d'enregistrement pour les dumps.
Quand je lance un dump, le signal lu par le magnétophone et récupéré par mon PC, qui le logge dans goldwave, et j'ai donc un visuel sur le signal (il existe plusieurs type de signaux, suivant l'ordinateur ou la machine d'ou est issue le mastering). En parallèle, mon CPC 464 lit le jeu que je suis en train de dumper, ce qui me permet de voir si mon dump en cours est bon ou pas.
Je vois aussi si la cassette est "dégueux" sur l'écran de mon PC durant l'enregistrement, ou encore si elle est défectueuse. J'ai eu le cas dernièrement avec le jeu opération thunderbolt en version Erbe, le signal est très abimé, et impossible à récupérer correctement. Je ne pourrais pas générer de fait un fichier CDT du jeu, et mon 464 me dit d'aller me faire pendre chez les grecs.
Citer :
Le reste n'a quasiment aucune valeur (autre que "le cdt fait marcher le jeu"). Tu n'as aucun moyen de dire que ton CDT marche sur 464.
J'ai un environnement de mastering "virtuel" à la maison, qui me permet de faire des tests dans tout les sens possibles, et donc je peux dans tout les cas dire que tel dump est "bon" ou "pas bon".
Quand j'utilise CDT2WAV sur un CDT qui marche, dont le WAV original marche, et dont le WAV reconverti fonctionne, mon CPC 464 fait tourner le jeu, donc l'équivalent exact du CDT, mais sous la forme d'un WAV.
La vraie machine est la référence absolue pour dire c'est bon ou pas bon. Je me fous éperdument de savoir qu'un jeu fonctionne en émulation si mon CPC 464 n'arrive pas à le lire.
Citer :
La seule chose que tu peux dire, c'est "le cdt passé à cdt2wav et enregistré sur une cassette fonctionne", ce qui est bien, voir suffisant, mais ne permet pas de dire que le cdt fonctionne.
Tu te trompes, ton raisonnement est erroné. CDT2WAV converti en aveugle sans se poser de question le CDT en une réplique exact au format WAV.
Le fichier WAV converti fonctionne directement sur mon 464, le CDT aussi donc problème sous Sugarbox
Citer :
J'avoue que je ne vois pas le rapport...
Justement, si tu n'as pas compris le rapport, c'est que tu n'as pas compris de quoi on parle.
Achète toi un CPC 464, et fais les tests toi-même, je vois même pas pourquoi je débats avec toi, tu n'as même pas la machine originale pour faire tes propres tests et t'appuyer sur quelque chose de solide !
Citer :
Pour conclure, prenons Basil par exemple, la seule chose que l'on peut dire, c'est : - Le wav issue de l'original marche sur Sbx et 464 - Le cdt ne marche pas sur émulateur
Faux. Le CDT fonctionne sous CPCE et sous Caprice32. CNGSoft teste toujours sur ces deux là.
Il ne marche juste pas sous sugarbox.
Citer :
- Le wav généré par cdt2wav fonctionne sur 464... Et sur ému (même si la manip correcte serait de redumper cette cassette générée...)
Redumper une cassette générée
Est-ce que je redumpe les jeux passés en IPF réecrit sur une disquette vierge ?
C'est complètement schizophrène ce truc
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
@Lone : j'imagine qu'on est trompé par le CDT qui est au format digital. Il faudrait lui appliquer le même traitement qu'au wave mais en logique 0 / 1 !? ça doit être la seule façon pour que ces dumps marchent sur un vrai cpc de toute façon ! Pour valider cela, il faudrait simuler l'envoie des 0 et 1 d'un cdt au PPI sans passer par la partie k7 -> dur dur mais on verrait que ça marche pas dans ce cas je pense !
Le but s'est bien d'émuler l'hardware qui permet au signal de passer -> donc pour la partie cdt, il faut le faire en digitale (où convertir ce que tu as rajouté ; le traitement en analogue sur le wave en digital sur le cdt dit autrement) !
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
@megachur
Citer :
j'imagine qu'on est trompé par le CDT qui est au format digital. Il faudrait lui appliquer le même traitement qu'au wave mais en logique 0 / 1 !? ça doit être la seule façon pour que ces dumps marchent sur un vrai cpc de toute façon !
Salut,
Le CDT n'est pas au format digital. Ce qui est au format digital, c'est le WAV converti depuis le fichier CDT. Un signal digital est "carré", tandis que le signal analogique d'une cassette ressemble à des "dents" de requin.
Citer :
Pour valider cela, il faudrait simuler l'envoie des 0 et 1 d'un cdt au PPI sans passer par la partie k7 -> dur dur mais on verrait que ça marche pas dans ce cas je pense !
Cesar vient de m'expliquer comment, regarde plus bas
Citer :
Le but s'est bien d'émuler l'hardware qui permet au signal de passer -> donc pour la partie cdt, il faut le faire en digitale (où convertir ce que tu as rajouté ; le traitement en analogue sur le wave en digital sur le cdt dit autrement) !
argh !!!
un petit mot de césar :
"Le switch d'inversion de polarité n'est absolument pas un hack: il fait juste en sorte qu'à chaque fois que le Z80 lit le port B du PPI il obtient la valeur inverse de l'EAR (tout magnéto et tout lecteur de 464 possède la sortie "EAR", soit en français "écoute", mais plus précisément "haut-parleur") à la place de la valeur courante.
Le signal de la cassette bascule le bit de la sortie "EAR" lorsque le fichier CDT est lu. Ce bit est inverti par l'option de "polarité inverse" si elle est activée. (Dans tout les cas, CPCE est un peu malin: si le moteur du lecteur est désactivé ou "coupé", aucune inversion ne se produit; de ce fait, quand on tape PRINT INP(&F500) en BASIC sur le CPC, celui-ci renvoie la valeur 30 indépendamment de l'option de polarité).
Au passage rappel : "MIC" et "EAR" sont les bits d'entrée et de sortie.
Le bit d'entrée des cassettes est le bit 7 du port B: si vous insérez une cassette et que vous tapez :
OUT &F600,&10:WHILE 1:PRINT INP(&F500);CHR$(13);:WEND
vous verrez les valeurs 94 et 222(=128+94) basculer rapidement.
J'espère que cette explication permettra de dissiper le "brouillard" dans lequel vous vous trouvez, et de mieux saisir sur quel principe fonctionne le switch dont est équipé CPCE.
_________________ SPS Community Expert (SPS CE) / SPS France
@dlfrsilver : Merci de rester correct : Je sais bien que je n'ai pas de 464, mais je ne vois pas pourquoi ça devrait m'empêcher de réfléchir et de me poser des questions (qui fâchent visiblement).
Pour résumer, on a un problème : Celui de faire marcher un dump de Basil (au hasard), qui fonctionne parfaitement sur 464.
- 1ere hypothese, l'inversion de polarité. Pas d'explication hard (on a très bien compris ce que ça fait, mais pas pourquoi ça le fait "des fois" et pas d'autres fois)
- 2e Hypothèse, mettre en oeuvre l'émulation des filtres électronique que l'on trouve dans la doc et sur un vrai cpc.
Maintenant, je voudrais bien l'avis du public sur ces deux hypothèses : Laquelle est la plus crédible à l'heure d'aujourd'hui ? Et surtout, que reproches-tu à ma solution ?
Je laisse de côté le débat sur les CDT, on en a déjà parlé, on ne vas pas relancer la machine à troll.
@Megachur : On ne peut malheureusement pas appliquer le même traitement au cdt....
Ta méthode (envoi direct du CDT vers le PPI d'un vrai CPC ) est une excellente idée... Mais me parait vraiment complexe à mettre en oeuvre, juste pour un test.
En fait, vu qu'il n'est pas simple de traiter le CDT, il devrait correspondre aux données en entrée du PPI. D'ailleurs, à mon avis, c'est ce à quoi il est destiné. Du coup, il devrait correspondre au signal original + traitements. La conversion inverse doit de toute façon marcher a peu près tout le temps. Idem pour le csw ou le wav reconstitué. (A ce sujet, les wav de JMD, enregistré sur le port du PPI, ressemblent beaucoup à notre signal carré - Ce qui est normal, vu que le PPI attends des tensions spécifiques en entrée).
Le wav (dumpé de l'original), lui, offre un niveau d'information supérieur (vu qu'on passe de nos longueurs de 0 et de 1 a des samples qui varient bien plus finement en amplitude (ce qui permet de leur appliquer des filtres).
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Lone a écrit :
@dlfrsilver : Merci de rester correct : Je sais bien que je n'ai pas de 464, mais je ne vois pas pourquoi ça devrait m'empêcher de réfléchir et de me poser des questions (qui fâchent visiblement).
Rien ne t'empêche de réfléchir. Mais avoir la vraie machine n'est pas une option, ça devrait être une base absolue pour t'aider à avancer.
Je vois mal toni wilen, le programmeur de Winuae, avancer sans avoir d'amiga de toute sorte pour corriger l'émulation.
Et je vais même aller plus loin. Cesar a crée des jeux dits compacts, qui fonctionnent sur les émulateurs (même sur le tien entre autre), mais pas sur un vrai CPC 464, avec 64k ou 128k.
Ce qui veut dire une chose. La différence entre ton émulateur, CPCE, winape et caprice32, c'est que seul le tient possède un set d'instruction dont l'émulation est parfait, les autres ont des bugs z80.
Ce qui veut dire que le problème n'est pas lié aux instructions, mais au fonctionnement du hardware, qui n'est connu d'aucun auteur d'émulateur.
Enfin bref, je suis correct, j'ai juste l'impression d'expliquer des choses que tu ne comprends pas.
Si moi qui ne suis pas programmeur j'en comprends le concept, toi qui l'est ça devrait passer comme une lettre à la poste.
Citer :
Pour résumer, on a un problème : Celui de faire marcher un dump de Basil (au hasard), qui fonctionne parfaitement sur 464.
et sur CPCE et caprice32.
Citer :
- 1ere hypothese, l'inversion de polarité. Pas d'explication hard (on a très bien compris ce que ça fait, mais pas pourquoi ça le fait "des fois" et pas d'autres fois)
Tout les jeux n'utilisent pas cette particularité. Est-ce tu ne pourrais pas tenter de faire le lien, entre l'explication technique de César, et ce que tu as trouvé de ton côté ?
La réponse se trouve forcément entre les deux.
Citer :
- 2e Hypothèse, mettre en oeuvre l'émulation des filtres électronique que l'on trouve dans la doc et sur un vrai cpc.
ça ça va clairement dans le bon sens, et je suis avec toi sur ce sujet
Citer :
Maintenant, je voudrais bien l'avis du public sur ces deux hypothèses : Laquelle est la plus crédible à l'heure d'aujourd'hui ? Et surtout, que reproches-tu à ma solution ?
ce n'est pas une question de crédibilité. Tu soutiens des arguments qui sont incorrects, à une personne comme moi qui a dumpé la presque intégralité du catalogue cassette de l'amstrad CPC. J'ai fait des milliers de tests avec mon matériel, sur une sacrée quantitée de ces dernières, qu'est-ce que tu attendais comme réaction de ma part ?
Citer :
Je laisse de côté le débat sur les CDT, on en a déjà parlé, on ne vas pas relancer la machine à troll.
On a clairement pas le même avis sur le sujet
Citer :
@Megachur : On ne peut malheureusement pas appliquer le même traitement au cdt....
Ta méthode (envoi direct du CDT vers le PPI d'un vrai CPC ) est une excellente idée... Mais me parait vraiment complexe à mettre en oeuvre, juste pour un test.
Justement. Ca nécessiterait du matos électronique pour monitorer le bordel. Et la on est plus dans le dump, mais dans l'électronique.
Citer :
En fait, vu qu'il n'est pas simple de traiter le CDT, il devrait correspondre aux données en entrée du PPI. D'ailleurs, à mon avis, c'est ce à quoi il est destiné. Du coup, il devrait correspondre au signal original + traitements. La conversion inverse doit de toute façon marcher a peu près tout le temps. Idem pour le csw ou le wav reconstitué. (A ce sujet, les wav de JMD, enregistré sur le port du PPI, ressemblent beaucoup à notre signal carré - Ce qui est normal, vu que le PPI attends des tensions spécifiques en entrée).
Le wav (dumpé de l'original), lui, offre un niveau d'information supérieur (vu qu'on passe de nos longueurs de 0 et de 1 a des samples qui varient bien plus finement en amplitude (ce qui permet de leur appliquer des filtres).
Un wav fraichement dumpé contient le signal analogique + du bruit + des parasites.
Peut-être qu'une solution serait de faire avaler à Sugarbox des WAVs sales, et le tweaker jusqu'à temps qu'il arrive à lire le dit WAV comme un vrai CPC 464. Ca démontrerait et ça prouverait que tu as trouvé le fonctionnement exact de l'electronique du 464, et la méthode qu'il utilise pour bypasser automatiquement les cochonneries présentes sur la bande. T'en dis quoi ?
_________________ SPS Community Expert (SPS CE) / SPS France
Un wav fraichement dumpé contient le signal analogique + du bruit + des parasites.
Peut-être qu'une solution serait de faire avaler à Sugarbox des WAVs sales, et le tweaker jusqu'à temps qu'il arrive à lire le dit WAV comme un vrai CPC 464. Ca démontrerait et ça prouverait que tu as trouvé le fonctionnement exact de l'electronique du 464, et la méthode qu'il utilise pour bypasser automatiquement les cochonneries présentes sur la bande. T'en dis quoi ?
Figure toi que c'est ce dans quoi je me suis lancé... Du coup, je collecte le maximum de WAV originales qui se lancent sur 464, mais pas sur emu... Si tu en as...
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Lone a écrit :
dlfrsilver a écrit :
Un wav fraichement dumpé contient le signal analogique + du bruit + des parasites.
Peut-être qu'une solution serait de faire avaler à Sugarbox des WAVs sales, et le tweaker jusqu'à temps qu'il arrive à lire le dit WAV comme un vrai CPC 464. Ca démontrerait et ça prouverait que tu as trouvé le fonctionnement exact de l'electronique du 464, et la méthode qu'il utilise pour bypasser automatiquement les cochonneries présentes sur la bande. T'en dis quoi ?
Figure toi que c'est ce dans quoi je me suis lancé... Du coup, je collecte le maximum de WAV originales qui se lancent sur 464, mais pas sur emu... Si tu en as...
je pense à toi !
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Une info récupérée sur la protection Gremlin loader 2 qui date d'il y a un moment, annotée par un codeur spectrum (la routine existe sur Spectrum, Amstrad, et C64 apparemment) :
"Attention - A cause du concept erroné de la routine de chargement (elle détecte la bordure tombante), toutes les doubles pulses doivent démarrer avec EAR=0 pulse suivi de EAR=1 pulse! ".
C'est l'explication de base au sujet de la présence du switch pour la polarité inverse.
_________________ SPS Community Expert (SPS CE) / SPS France
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 18 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
Connexion
Inscription
FAQ
!!!
). 
