Lone a écrit : Hello,
Effectivement, quand on développe un emu (ou qu'on dump des logiciels) il faut toujours être sceptique (au sens ancien) : Ca n'est pas parce que ça marche que c'est bon, et ça n'est pas parce que ça ne marche pas que c'est mauvais.
C'est vrai 
Citer : Exemple : Chicago 90' (et d'autres dsk a Gap) : Le gap enregistré est court (plus que sur l'original). Du coup, ces jeux ne marchent que sur des émulateurs qui ne font pas tourner le disque, mais envoient les data au fur et à mesure.
Un émulateur plus précis ne le fera pas marcher.
Effectivement, ça veut donc dire que la zone GAP n'est pas imagée correctement dans ce cas
Citer : Pour ça, les formats interprétant le moins possible les données sont le mieux : L'erreur ne viendra pas de là (elle peut venir d'ailleurs, mais pas de l'interprétation erronée des données du disque)
suis d'accord
Citer : Je dirais qu'après, a chaque dump sa vérité....
Mais de manière générale :
- Si le format "original" (wav) passe et pas le format "interprété" (cdt), c'est le cdt qui est en cause
Faux et pas d'accord. Explication :
1) si le WAV passe, c'est qu'il contient toutes les informations, donc il marche (sur vrai CPC et sur émulateur)
2) le format CDT n'est pas un format "d'interprétation" comme tu dis, mais le format de stockage par excellence. Les gens de la communauté Spectrum l'ont mis au point en prenant en compte toutes les particularités possibles et imaginables en terme de protection.
3) Si le CDT ne passe pas alors que le WAV est bon, c'est que :
A) soit celui qui l'a crée n'a pas utilisé le bon type de block, et donc le vrai CPC n'en voudra pas ;
B) Soit la protection n'est pas supportée par Samp2cdt => utilisation d'un bytelogger obligatoire
C) Soit le timing des pauses et ou les informations liées à la vitesse de lecture n'ont pas été correctement reportés dans le CDT. Certains jeux sont protégés à ce niveau là, et j'en connais même un qui vérifie que le block de démarrage basic soit bien un bloc en Speedwrite 1 (vitesse rapide), sinon reset. Certains jeux speedlock sont de la même trempe, si la pause entre le loader encrypté du départ et le premier bloc speedlock n'est pas conforme, la protection en déduit que c'est une copie et fait faire un reset au CPC.
Citer : - Si le format "original" (wav) ne passe pas, c'est sans doute l'émulateur (surtout si ce wav peut être redumpé sur une cassette, et fonctionne sur un vrai CPC qui est le juge de paix)
C'est pas aussi simple. Pourquoi ? Il faut savoir que de base un jeu peut utiliser une protection noyée dans le bruit, ou qui comporte des parasites insérés industriellement dans le signal, ou entre les blocs.
Il m'est arrivé de dumper des jeux cassettes qui tel quels en WAV ne passaient pas (ou plus) ni sur un vrai CPC ni sur émulateur. Après un coup de nettoyage avec CSW1, plus un filtrage avec une commande adéquate, j'ai même réussi à obtenir un fichier VOC (et non plus WAV fonctionnel).
J'ai encore des K7 avec moi dont c'est le cas. Et pour info, je dumpe toujours une cassette en lisant le signal sur un vrai CPC 464 ou + afin d'être sur de mon coup, sans compter que mon PC est équipé d'une carte son très haut de gamme faite pour, en plus de l'usage de Goldwave, mon partenaire et compagnon de toujours.
J'ai dumpé des cassettes qu'aucune personne ici n'aurait pas passer en CDT, et qu'on avait jamais vu sur le net avant que je ne m'y colle.
Exemple : les jeux opera soft tel que Goody, Trigger, Gonzallezzz pour ne citer qu'eux. Sans lecteur de cassette tip top comme celui que j'ai, ni même goldwave et un vrai CPC 464+ pour faire le monitoring en même temps que l'enregistrement, et l'utilisation du bytelogger de CNGSOFT, JAMAIS ces cassettes n'auraient pu être imagées.
A tel point que les espagnols m'ont envoyé toutes leurs cassettes du même accabit, car même eux n'y arrivaient pas, et ils sont loin d'être mauvais pour dumper, loin loin de là.
Donc comme je disais, c'est faux, l'émulateur n'est PAS nécessairement en faute, mais ça peut être le système de protection et d'enregistrement qui est en faute, sans parler des bits sur la bande qui se détériorent et qui évoluent avec le temps.....
Citer : - Si un CDT ne marche pas, mais que le dump via cdt2wav marche sur un cpc.... Alors, il faut faire passer le résultat du cdt2wav sur l'émulateur, et on ne peut conclure avec assurance concernant le cdt.
CDT2wav fait lui aussi quelques interprétations qui peuvent fausser la manip.
Tout les jeux que j'ai dumpé (des milliers) en cassette ont tous été testés de la même façon, en étant lu sur un vrai CPC pendant l'enregistrement. CDT2WAV comporte des bugs comme les autres outils de conversion tel que TZX2WAV et autres. Il faut en essayer plusieurs (j'ai fais des test à de nombreuses reprises parce que je voulais faire des fichiers Mp3 directement utilisable, et ça s'est avéré hyper galère et pas pratique du tout).
Et oui CDT2WAV fait aussi des erreurs lors de la conversion en WAV.
Citer : Pour ta list, Mask par exemple nécessite une implémentation particulière du CDT, qui est de faire le changement de niveau à la fin de la durée, pour chaque pulse (et non l'inverse). Grosso modo, si nouvelle pulse, on garde le level en cours, on y mets la durée spécifiée, et on inverse le level en cours.
Pas d'accord. Le cdt de Mask présent sur cpc-p0wer et CPC-rulez fonctionne en WAV sur un vrai CPC si on le converti avec un outil qui ne bugge pas à la conversion. J'ai testé le jeu après l'avoir converti en WAV depuis mon CDT généré par CNGSOFT avec son bytelogger sur mon CPC 464 et mon 464+ (avec mon petit loader).
Mes CPC lisent le WAV généré sans aucun problème, et j'ai même pu finir le jeu.
Donc non, pas d'implémentation particulière nécessaire pour obtenir un fichier WAV fonctionnel qui tourne sur amstrad CPC.
A ta disposition pour toute information complémentaire
|
!
je te remercie pour ces explications 
!
avec les vrais timming cpcs émulation à 16Mhz 
j'ai mis quelques screenshoots histoire d'illustrer !
Cette version de gryzor fonctionne sur CPC 464 ET 6128.