Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
j'ai tenté gentillement de te le signaler...
Citer :
La chaine est la suivante : WAV (si bon) => CSW (si bon) => CDT (si bon) => réversable en WAV (si bon) = un CPC 464 lit le WAV et exécute le jeu sans erreur.
donc on résume, le CSW fonctionne sur mon émulateur. je t'ai même posté dans ce forum la dernière version v2103 de mon émulateur pour que tu puisses tester par toi même le CSW ainsi que le WAV réversé !
pour résumé : on passe par un programme tiers pour passer en CDT qui fait une erreur d'arrondi ! le CDT passe sur un/des émulateur(s) qui corrige cette erreur ou à cause d'un mauvais timming d'émulation ou d'un arrondi !!! on repasse en WAVE et hop on corrige l'arrondit dans l'autre sens...et ça marche sur CPC ! ouf ça c'est bien !
par contre que le CDT soit pas identique au CSW d'origine qui est le plus proche du WAVE d'origine, ça te choque pas ?
je pensais que le but du CDT c'était pourtant d'être le plus proche du WAV dump original...
Et juste pour information : Loïc m'a signalé certains problèmes car il teste tous ses originaux k7 et disquettes que tu as convertis sur l'émulateur CPCEPower !
cela nous a permis notamment d'identifier ces problèmes là ... et en testant : le WAV original marche, le CSW mais pas le CDT... chercher l'erreur !?
voici d'ailleurs les 2 seuls soucis restant en cours :
Harvey Headbanger (CDT) - Music during loading causes issues (dixit Denis) Gremlins - The Adventure (CDT) - Games hangs after loading at the "Resume a save game?" question. Could only get it to work with CPCE (older version of CPCEC).
sachant que j'ai ces 2 cdts du même jeu qui marchent sans pb avec la musique : Harvey Headbanger (UK) (1986) (v5-86) [Original] [TAPE] Harvey Headbanger (UK) (1986) (v12-86) [Original] [TAPE]
bizarre non ?
Après, je suis pas d'humeur à en dire plus, je te signale un problème sur cette CDT... si tu veux qu'elle ne soit pas conforme en terme de timing au WAV original et au CSW...c'est toi qui décide !
cela ne m’empêchera pas d’apprécier et de continuer à te féliciter de ton travail de préservation...
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Megachur a écrit :
j'ai tenté gentillement de te le signaler...
Citer :
La chaine est la suivante : WAV (si bon) => CSW (si bon) => CDT (si bon) => réversable en WAV (si bon) = un CPC 464 lit le WAV et exécute le jeu sans erreur.
donc on résume, le CSW fonctionne sur mon émulateur. je t'ai même posté dans ce forum la dernière version v2103 de mon émulateur pour que tu puisses tester par toi même le CSW ainsi que le WAV réversé !
merci
pour résumé : on passe par un programme tiers pour passer en CDT qui fait une erreur d'arrondi ! le CDT passe sur un/des émulateur(s) qui corrige cette erreur ou à cause d'un mauvais timming d'émulation ou d'un arrondi !!! on repasse en WAVE et hop on corrige l'arrondit dans l'autre sens...et ça marche sur CPC ! ouf ça c'est bien !
Citer :
par contre que le CDT soit pas identique au CSW d'origine qui est le plus proche du WAVE d'origine, ça te choque pas ?
Le fonctionnement de CSW2CDT n'a pas changé, Les timings des fichiers CSW sont injectés dans le CDT. ça c'est le fonctionnement casté dans la pierre depuis le début.
Citer :
je pensais que le but du CDT c'était pourtant d'être le plus proche du WAV dump original...
C'est le cas. Fait le parallèle :
CPCEC utilise la même routine pour TOUT les softs cassettes, et tout les softs passent sans exception.
De l'autre côté, tu as des problèmes avec des titres ça et là, et on ne sait pas pourquoi. On sait juste qu'à un moment tu as fait une modification, et depuis certains titres ont des problèmes.....
César vient de me confirmer ceci :
"CSW2CDT colle aux timings des fichiers CSW au plus près possible, excepté les conséquences évidentes d'arrondi de division sur les très grands nombres : c'est à dire l'usuel, on essaie de rendre toute sortes de longueurs de signaux instables en valeurs simples.
Ajouter les longueurs de milliers de signaux courts, puis essayer de les rassembler en blocks simples ordonnés ou les timings doivent être déclarés sous forme d'unités T (1/3500000) va mener inévitablement à une solution de compromis ou on calcule les valeurs moyennes les plus proches pour satisfaire toutes ces petites variations de valeurs.
Remarque comme la colonne BIT0 dans le log se révèle similaire, mais pas égal, aux valeurs de toute la cassette.
Il est évident que tout les blocks ont été enregistrés avec le même systeme, qui tourne à la même vitesse, mais malheureusement nous n'avons pas accès à la cassette master idéale. Alors on doit atteindre des compromis à l'intérieur des plus petites unités paramétriques: les blocs.
Aucune intervention manuelle n'a eu lieu ici; J'ai juste lancé l'algorithme sur le fichier CSW, et l'encodeur a deviné les valeurs qui ont assuré que le bloc final durera aussi longtemps et précisément que possible que la durée de temps originale du bloc source.
Si une modification manuelle avait eu lieu, pourquoi chaque bloc a ses propres timings? J'aurais alors utilisé le même timing unique pour tous.
C'est la même raison qui explique pourquoi CSW2CDT ne se base pas sur des constantes pré-établies autres que des intervalles vague. Le vieux SAMP2CDT forçait ses propres timings internes sur les blocks qu'il générait quand ils correspondaient à une protection qu'il reconnaissait.
En d'autre termes, et dit plus simple pour le profane, nous avons actuellement le meilleur algorithme possible, compte tenu des contraintes citées plus haut, sur des valeurs qui sont arrondies (pas d'autre choix).
Il n'y a pas de lien avec CPCEC, CSW2CDT est un outil indépendant qui génère de la façon la plus précise possible les timings d'une cassette donnée, et conformément aux spécifications du format CDT.
Ton explication et celle de César indique qu'il y a encore et toujours un problème d'arrondi dans ton implémentation CDT, et CPCEpower se gamelle les pieds dedans.
Ce que César dit aussi, c'est qu'on ne peut pas avoir en l'état de timings entier, ça ne peut être que des arrondis.
Citer :
Et juste pour information : Loïc m'a signalé certains problèmes car il teste tous ses originaux k7 et disquettes que tu as convertis sur l'émulateur CPCEPower !
cela nous a permis notamment d'identifier ces problèmes là ... et en testant : le WAV original marche, le CSW mais pas le CDT... chercher l'erreur !?
Oui Loic t'a contacté à ma demande.
Citer :
voici d'ailleurs les 2 seuls soucis restant en cours :
Harvey Headbanger (CDT) - Music during loading causes issues (dixit Denis) Gremlins - The Adventure (CDT) - Games hangs after loading at the "Resume a save game?" question. Could only get it to work with CPCE (older version of CPCEC).
Ton souci d'arrondi ou de précision pose un problème sur Harvey Headbanger cité plus haut. la protection requiert que l'émulateur gère la lecture et le décodage de façon précise. Si c'est pas le cas, le jeu part aux marrons.....
Pour Gremlins the adventure, attention, 2 version différentes, une qui a été commercialisée et qui n'a jamais fonctionné (vérifié par César, le jeu fait une opération qui ne fonctionne pas, le programmeur a été obligé de corriger la routine clavier si ma mémoire fait pas défaut, et l'à remplacée par une autre qui elle fonctionne, et a générer une version du jeu mise à jour. Loic a eu une chance inouie de tomber sur cette version 1).
CPCE est totalement abandonné en terme de support. Le fait que le jeu ait pu marcher avec n'a été possible que parce que César avait mis un correctif dans l'émulateur. CPCEC a un fonctionnement qui est conforme a un vrai CPC : le jeu plante pareil que sur un vrai 464.
Citer :
sachant que j'ai ces 2 cdts du même jeu qui marchent sans pb avec la musique : Harvey Headbanger (UK) (1986) (v5-86) [Original] [TAPE] Harvey Headbanger (UK) (1986) (v12-86) [Original] [TAPE]
bizarre non ?
Après, je suis pas d'humeur à en dire plus, je te signale un problème sur cette CDT... si tu veux qu'elle ne soit pas conforme en terme de timing au WAV original et au CSW...c'est toi qui décide !
cela ne m’empêchera pas d’apprécier et de continuer à te féliciter de ton travail de préservation...
Je ne décide de rien, César a expliqué en détails pourquoi et comment sont les choses. On ne peut pas avoir les timings strictement identiques et figés dans un CDT, ce n'est pas possible.
La cassette est conforme aux timings de la cassette dans le sens ou les arrondis effectués sont au plus près du WAV original.
Par ailleurs, ton problème met en lumière aussi un autre aspect de ton émulateur CPCEpower :
Il n'a pas de garde fou pour s'assurer que les données sont lues correctement depuis le CDT.
Pour que les choses se déroulent correctement César a mis en place ceci pour CPCEC pour la gestion de la lecture des cassettes :
"CPCEC émule les cassettes en step by step. Il n'effectue aucune division; Il utilise des timers internes pour savoir quand avancer le curseur interne de playback des cassettes. C'est très intensif en terme de calcul mais ça assure que les timings sont respectés.
Utiliser des divisions rendraient les choses plus faciles, mais ça introduirait une imprécision sous la forme de décimales perdues. Rappelle toi, On parle d'un timer qui tourne 3500000 fois par secondes.
A côté de ça, souvenons nous d'écueils comme les fichiers TZX cadencés à 3.5 MHz tandis que le CPC est cadencé à 4 MHz (ou si on travaille sur une base d'unité NOP, 1 MHz), ou les champs TZX utilisent quelques fois des unités T et quelque fois des millisecondes."
Là encore Megachur, fonction des explications de César, fait le rapport avec ta propre façon de gérer les CDTs, et le playback de ces derniers.......
A noter également qu'il a des suspicions concernant ton problème qu'il puisse y avoir le souci suivant :
Soit tu as un souci d'arrondi (récurrent), les autres suspicions sont la perte des signaux au début ou à la fin (peut-être à cause du fait de ne pas compter le champ des "bits dans le dernier octet", peut-être parce qu'ils sont fusionnés avec la pause).
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
Citer :
Ton souci d'arrondi ou de précision pose un problème sur Harvey Headbanger cité plus haut. la protection requiert que l'émulateur gère la lecture et le décodage de façon précise. Si c'est pas le cas, le jeu part aux marrons.....
mon soucis est justement de traiter de la même manière le WAV, CSW et CDT... donc pour finir en conclusion :
le code de mon émulateur ne faisant aucun traitement, il considère que les données sont justes et les traite exactement de la même façon ensuite en terme de lecture ! d'ailleurs volontairement, le traitement PPI/Tape et indépendant du format lu en entrée WAV, CSW et CDT... et contrairement à César, je ne fais aucun calcul en 'live' ou autre ajustement qui tromperait justement un erreur sur le format... tout est déjà mis en format 'pulse, durée' équivalent au CSW... La seule conversion est le calcul en "float" oui au maximum de précision possible dans mon émulateur contrairement à d'autres car le format CDT et un format spectrum TZX au départ et donc en terme de 'conversion', la seule est du au fait que pour ce format TZX : "The timings are given in Z80 clock ticks (T states) unless otherwise stated.1 T state = (1/3500000)s "
alors que pour le z80 sur le CPC, le vrai timming est 4Mhz soit 1/4000000 !
J'adore le travail de César, mais si tu regardes le code de CPCEC : CPCEC-K7.H qui gère la partie K7 tu t'aperçois qu'il calcul ces timing en int donc en 32bits !!!
et moi j'ai une précision au float 64 bits et tu me dis sans savoir : c'est ton émulateur qui doit pas être précis !????
si le WAV et le CSW passent mais pas le CDT... que conclure ?
moi j'en conclus que sur des milliers de CDT testées (en fait toutes celles disponibles sur cpc-p0wer ou ailleurs), une seule ne passe pas sur mon émulateur...
c'est comme pour la TAPE POLARITY je sais pas... ça existe pas, on fait un patch dans CPCE pour passer à cause d'une erreur de timing et c'est pas normal que les autres ça marchent pas...
au contraire pour moi, ce que je crois c'est justement que c'est parce que c'est l'un des plus précis que le WAVE et le CSW passe mais pas la CDT !!! tout en étant conscient que je peux avoir une erreur quelque part... mais dans ce cas, pourquoi je ne ne l'aurai pas sur toutes les CDTS bleepload v1 ??? pourquoi cette CDT de cette protection est la seule qui ne passe pas ?
c'est comme pour la protection MBC K7 Marmelade, et surtout pour Rat Connection .... les waves marchent très bien sur mon émulateur... la CDT de Marmelade aussi et pas de CDT pour Rat Connection ? CSW2CDT et CPCEC ne sont peut-être pas assez précis ?
et ensuite bien faire attention quand tu utilises les CDTs avec CPCEC... en effet en mode turbo César change complétement les timings en fonction des instructions Z80 :
Code :
case 9: // BLEEPLOAD(1+2) ("SENTINEL", "THRUST" V2) // INC E // XOR C:JP NS,.. if (z80_de.b.h==0x01&&FASTTAPE_CAN_FEED()&&((i=z80_tape_fastfeed(z80_tape_spystackadd(2)))==20||i==21)) // skip PUSH BC j=fasttape_feed(),tape_feedskip=z80_de.b.h=128+(j>>1),z80_de.b.l=j&1?-1:0,FASTTAPE_FEED_END(z80_bc.b.l>>7,9); else fasttape_add8(z80_bc.b.l>>7,9,&z80_de.b.l,1); break;
je dis pas que ça marche pas... mais c'est de la bidouille quand même ! donc rester en mode 'normal' serait mieux pour valider une CDT quoi qu'il arrive !
dans CPCEPower : le timing de la K7 pour moi c'est le temps qui passe les 16MHz du GA, 4MHz du Z80, 1MHz du PPI et de l'AY, tout est en cohésion et dans les timings comme sur le hardware du cpc... comme le hardware du player de K7 qui est relié au PPI, pas au Z80 directement, je dirais même qu'ils sont indépendant et c'est plutôt le Z80 qui demande au PPI ce qui est lut sur le lecteur de K7 à son rythme !
et puis pendant qu'on y est, César change des données de la rom aussi pour assurer une chargement plus rapide cf encore CPCEC.C :
Code :
#if 0//1 // fast tape hack!! if (equalsiiii(&mem_rom[0x2BF9],0x0B068201)) mem_rom[0x2BF9+2]/=2;//mputii(&mem_rom[0x2BF9+1],1); // 664+6128+PLUS HACK: reduced initial tape reading delay! else if (equalsiiii(&mem_rom[0x2A89],0x0B068201)) mem_rom[0x2A89+2]/=2;//mputii(&mem_rom[0x2A89+1],1); // ditto, for CPC464 #endif
et pour finir toujours dans CPCEC.C :
Code :
if (tape_enabled) // TAPE MOTOR ON? { if ((tape_delay-=t)<0) tape_delay=0; if (tape_delay<=TICKS_PER_SECOND/15) // reject accidental "clicks" (cfr. "RUN THE GAUNTLET") tape_main(t),audio_dirty|=(size_t)tape; // echo the tape signal thru sound! } else // delay later readings { if ((tape_delay+=t)>TICKS_PER_SECOND/14) // MINILOAD (>3) and Opera Soft (<25) tapes hinge on this! tape_delay=TICKS_PER_SECOND/14; }
CPCEC introduit lors de la lecture des délais nécessaires pour le simulation du moteur sinon ça marche pas... cela peut être aussi différent que sur un vrai lecteur de k7...
DONC c'est bien plus complexe qu'il n'y parait ... et c'est pour cela que j'utilise dans CPCEPower le même format (pulse, durée) quelque soit le format WAV, CSW, CDT, etc... au départ...
donc si un CDT est différent d'un WAV ou du CSW qui a permis sa génération... ça se voit sur CPCEPower, y'a pas de bidouille pour le faire passer, juste de la même précision de calcul quelque soit le format !
de plus si c'était une erreur d'émulation sur la partie TAPE, Z80 ou PPI... le WAV et le CSW qui sont encore plus précis que le CDT ne passeraient pas !
c'était pour faire avancer le schhhhimliiiiblik et en espérant que CSW2CDT s'améliore et CPCEC également bien sûr... et bien sûr tous les autres émulateurs y compris CPCEPower !!!
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
En complément d'analyse, je t'engage à faire le test suivant :
nous allons profiter de que le loader bleepload v1 est réentrant avec contrôle d'erreur au moins sur la première partie :
1) on met le CDT en question Helichopper (UK) (1986) (v6-86) [Original] [TAPE].cdt en chargement sur CPCEPower v2103. 2) Error block 02 not found ! 3) on prends CSW2CDT (dernière version csw2cdt-20191102), on convertie/décode le cdt Helichopper (UK) (1986) (v6-86) [Original] [TAPE].cdt en csw et en wav. 4) on mets le csw ou le wav reconstruit depuis le cdt avec CSW2CDT 5) on press play à nouveau... on attends... et... le loader trouver bien le block 02 et charge tout jusqu'au jeu... conformément au test que tu as fait sur ton 464+ !!! Egalement bien sûr, si on commence le chargement avec le csw ou le wav reconstruit depuis le cdt avec CSW2CDT : no problemo, c'est conforme !
voilà comme cela on est d'accord, le csw/wav reconstruit depuis le cdt avec CSW2CDT fonctionne bien sur le vrai hardware et aussi sur CPCEPower...donc je dois pas être si mauvais en timing alors, non ?
quelle conclusion sur les timings de ce CDT et sur l'encodage / décodage de CSW2CDT avoir maintenant ? --> peut-être un manque de précision, est-ce une limite du code dans CSW2CDT ou de l'encodage du format TZX ??? --> pourquoi on a pas ce soucis sur les autres bleepload v1 ?
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Citer :
c'est comme pour la TAPE POLARITY je sais pas... ça existe pas, on fait un patch dans CPCE pour passer à cause d'une erreur de timing et c'est pas normal que les autres ça marchent pas...
Comme indiqué, le support de CPCE est définitivement abandonné. César ne s'occupe que de CPCEC, et le problème concernant TAPE polarity était lié à Samp2cdt et ses timings auto calculés et qui ne reposaient sur rien. C'était même pas CPCE qui était en cause.
Ce problème de TAPE polarity a disparu depuis qu'on est passé sur CSW2CDT, c'est à dire fin 2015 ! On est en 2021, tu as du retard ! ça fait 6 ans presque maintenant que ce souci n'est plus d'actualité, et les jeux ont été redumpés et de nouveaux CDTs regénérés.
Citer :
et ensuite bien faire attention quand tu utilises les CDTs avec CPCEC... en effet en mode turbo César change complétement les timings en fonction des instructions Z80 : Code : case 9: // BLEEPLOAD(1+2) ("SENTINEL", "THRUST" V2) // INC E // XOR C:JP NS,.. if (z80_de.b.h==0x01&&FASTTAPE_CAN_FEED()&&((i=z80_tape_fastfeed(z80_tape_spystackadd(2)))==20||i==21)) // skip PUSH BC j=fasttape_feed(),tape_feedskip=z80_de.b.h=128+(j>>1),z80_de.b.l=j&1?-1:0,FASTTAPE_FEED_END(z80_bc.b.l>>7,9); else fasttape_add8(z80_bc.b.l>>7,9,&z80_de.b.l,1); break;
je dis pas que ça marche pas... mais c'est de la bidouille quand même ! donc rester en mode 'normal' serait mieux pour valider une CDT quoi qu'il arrive !
C'est normal, plein de jeux ne supporteraient pas sinon un chargement en accéléré à cause de leur protection contre la copie. Mais c'est une sauce interne à CPCEC, ça ne touche ni ne modifie les timings dans le CDT
Citer :
et pour finir toujours dans CPCEC.C :
Code : if (tape_enabled) // TAPE MOTOR ON? { if ((tape_delay-=t)<0) tape_delay=0; if (tape_delay<=TICKS_PER_SECOND/15) // reject accidental "clicks" (cfr. "RUN THE GAUNTLET") tape_main(t),audio_dirty|=(size_t)tape; // echo the tape signal thru sound! } else // delay later readings { if ((tape_delay+=t)>TICKS_PER_SECOND/14) // MINILOAD (>3) and Opera Soft (<25) tapes hinge on this! tape_delay=TICKS_PER_SECOND/14; }
CPCEC introduit lors de la lecture des délais nécessaires pour le simulation du moteur sinon ça marche pas... cela peut être aussi différent que sur un vrai lecteur de k7...
Mais bien évidemment, c'est ni plus ni moins l'émulation des délais pour la simulation du moteur.
Tu aurais fait quoi à la place ?
Ensuite, la spécificité de CPCEC, c'est qu'il charge sans souci les CSW et CDT, mais charge difficilement les WAV tirés directement des cassettes. Pourquoi ? Tout simplement parce que les WAV contiennent des erreurs et des imperfections, qui entrainent le plantage du chargement.
Si les WAV étaient parfaits, on aurait pas besoin de fichiers CSW, et les fichiers CDT n'existeraient pas.
De l'autre côté, CPCEpower charge sans souci les WAV tirés des cassettes, avec les erreurs et les imperfections, mais par contre rencontre des soucis aléatoires pour charger un CDT dans lesquels les données sont parfaites, avec des timings au plus près de ceux du CSW dont il est tiré ?
Y a pas quelque chose qui te chiffonne quelque part ? Pour moi, qui peut le plus peut le moins, si tu arrives à charger des WAV imparfaits avec de la cochonnerie dedans, aucune raison comme ton traitement est le même pour WAV, CSW, CDT que ça déconne sur le CDT. Y a forcément une couille dans le potage.
PS : j'utilise également un émulateur de lecteur de cassette, qui se connecte sur le CPC (6128), et je charge directement des CDTs sans faire de conversion en WAV. C'est le moyen le plus idéal pour vérifier qu'un CDT est fonctionnel ou non.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
j'attends que tu es bien relu mon dernier post avant d'avancer sur le sujet...car tu n'as pas répondu à tout...
j'ai même l'impression que tu n'as pas tout compris ???
Citer :
De l'autre côté, CPCEpower charge sans souci les WAV tirés des cassettes, avec les erreurs et les imperfections, mais par contre rencontre des soucis aléatoires pour charger un CDT dans lesquels les données sont parfaites, avec des timings au plus près de ceux du CSW dont il est tiré ?
Une précision : quand je parlais de WAV original, je parlais de celui que tu m'as fournis... je n'ai pas le WAV (non filtré / propre) tiré de cette K7...
d'après mes essais, il faut que le WAV original (qui a souvent bcp de bruit), soit quand même très propre pour le lire directement avec CPCEPower... même si c'est possible d'en obtenir un quelque fois directement j'imagine si la bande de la k7 / lecteur sont de super qualité... mais comme pour les disquettes, elles ont souvent + de 30 ans d'age et pas toujours bien conservé... même après le nettoyage physique/chimique que tu leur fais habiltuellement !
--> bon lecture en espérant que César trouve le problème sur le passage correct en CDT du CSW qui fonctionne...
Dernière édition par Megachur le 20 Mars 2021, 19:42, édité 3 fois.
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Lone a écrit :
Juste pour dire que je lis avec attention tout cela, en me rappelant avec nostalgie de cette fameuse inversion de polarité !
Oui, qui a été une raison de la création de CSW2CDT. De prime abord César ne comprenait pas d'ou venait le souci, il a donc ajouté ce hack dans CPCE. Pour finalement voir que Samp2cdt était la source du problème.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Megachur a écrit :
j'attends que tu es bien relu mon dernier post avant d'avancer sur le sujet...car tu n'as pas répondu à tout...
j'ai même l'impression que tu n'as pas tout compris ???
Tu peux préciser sur quel aspect ? J'ai répondu sur les points les plus importants je pense.
Citer :
De l'autre côté, CPCEpower charge sans souci les WAV tirés des cassettes, avec les erreurs et les imperfections, mais par contre rencontre des soucis aléatoires pour charger un CDT dans lesquels les données sont parfaites, avec des timings au plus près de ceux du CSW dont il est tiré ?
Une précision : quand je parlais de WAV original, je parlais de celui que tu m'as fournis... je n'ai pas le WAV (non filtré / propre) tiré de cette K7...
Le WAV original que je t'ai fourni est celui non filtré tiré de la K7 de Loic pour Helichopper.
Citer :
d'après mes essais, il faut que le WAV original (qui a souvent bcp de bruit), soit quand même très propre pour le lire directement avec CPCEPower... même si c'est possible d'en obtenir un quelque fois directement j'imagine si la bande de la k7 / lecteur sont de super qualité... mais comme pour les disquettes, elles ont souvent + de 30 ans d'age et pas toujours bien conservé... même après le nettoyage physique/chimique que tu leur fais habiltuellement !
Le problème est le même que pour les disquettes concernant les cassettes : Les fichiers WAV des cassettes sont des fichiers de travail tout comme les dumps en flux pour les disquettes.
WAV comme flux contiennent les données, plus du bruit/saleté/etc..... Pour avoir quelque chose de propre, on filtre et ensuite on encode. C'est exactement ce qu'on fait finalement avec le format IPF pour les disquettes. Le format CTraw correspond dans les faits au format CSW
Citer :
--> bon lecture en espérant que César trouve le problème sur le passage correct en CDT du CSW qui fonctionne...
Il te répondra surement que comme tout les jeux en CDT tournent à 100% autant sur CPCEC que sur un vrai CPC 464, y a rien à chercher.....
J'ai par ailleurs regénéré un autre CDT, mais qui ne passe sur aucun émulateur..... sauf CPCEC.
Sugarbox : le chargement est stoppé sans raison après la lecture des blocs amstrad du loader Caprice Forever : plantage au bloc 2 CPCepower : plantage au bloc 2 CPCEC : chargement du début à la fin que ce soit en mode lent, rapide ou turbo.
_________________ SPS Community Expert (SPS CE) / SPS France
Il te répondra surement que comme tout les jeux en CDT tournent à 100% autant sur CPCEC que sur un vrai CPC 464, y a rien à chercher.....
J'ai par ailleurs regénéré un autre CDT, mais qui ne passe sur aucun émulateur..... sauf CPCEC.
Sugarbox : le chargement est stoppé sans raison après la lecture des blocs amstrad du loader Caprice Forever : plantage au bloc 2 CPCepower : plantage au bloc 2 CPCEC : chargement du début à la fin que ce soit en mode lent, rapide ou turbo.
Juste pour rappeler que ça n'est souvent pas si simple : La conversion CDT->Wav, si elle est immédiate (avec des wav carrées) ne va pas aboutir directement au PPI, a part avec le fameux montage ou l'on injecte directement le wav vers les pins qui vont bien (utiliser pour sampler le "traitement" de la cassette, voir les dumps de JMD). On a donc là un sérieux biais.
Tout comme dire que "ca marche sur tel machin donc c'est bon", servait à justifier la polarité à une certaine époque : On a pu voir, malgré les évidences, que c'était finalement bien incorrect.
Garder un peu d'humilité serait donc sans doute une bonne chose (et ne pas utiliser le fameux argument d'autorité, qui ne prouve éventuellement que le melon de celui qui l'utilise).
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Perso, je commence à me poser des questions sur ces nouveaux CDTs.
Par exemple, "3D Stunt Rider (UK) (1985) [Amsoft 183] [Original] [TAPE].cdt" ne passe pas sur Caprice alors que la version qui se trouve sur "C.P.C. P.o.w.e.r" ne pose aucun problème.
Là, je me dis que j'ai un souci avec l'émulateur. Alors, afin de lever mes doutes, je convertis ces 2 CDT en WAV en utilisant CSW2CDT de 2019.
Le WAV de la version qui se trouve "C.P.C. P.o.w.e.r" passe sur CPCEC. Alors que le WAV de ce nouveau CDT ne passe pas sur CPCEC.
Puisque le WAV est le résultat de l'interprétation du CDT, comment se fait-il que le WAV ne passe pas alors que le CDT passe ?
Hormis de commencer à croire que ces CDT sont spécialement encodés pour CPCEC.
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Citer :
Juste pour rappeler que ça n'est souvent pas si simple : La conversion CDT->Wav, si elle est immédiate (avec des wav carrées) ne va pas aboutir directement au PPI, a part avec le fameux montage ou l'on injecte directement le wav vers les pins qui vont bien (utiliser pour sampler le "traitement" de la cassette, voir les dumps de JMD). On a donc là un sérieux biais.
Un sérieux biais, c'est à dire ? tu peux développer plus ?
Citer :
Tout comme dire que "ca marche sur tel machin donc c'est bon", servait à justifier la polarité à une certaine époque : On a pu voir, malgré les évidences, que c'était finalement bien incorrect. Garder un peu d'humilité serait donc sans doute une bonne chose (et ne pas utiliser le fameux argument d'autorité, qui ne prouve éventuellement que le melon de celui qui l'utilise).
Encore la polarité ? Ok, je reprends de zéro : pendant plusieurs années, les outils conçus pour le CPC était pourris, pour pas dire buggés, et donc les fichiers en sortie était mauvais !
Le problème de "TAPE Polarity" auquel vous vous référez tous était une conséquence des timings érronés de samp2cdt. concernant CPCE, César avait mis en place un fix/patch, appelle ça comme tu veux pour y pallier.
Jusqu'au moment ou il s'est dit "y en a marre d'avoir des outils pourris et mal fait, je vais créer une nouvelle suite d'outils".
En bref, CSW2CDT a été crée suite à ce problème. Et la création après de CPCEC a suivi car l'émulation de CPCE était pas bonne ou pas assez bonne.
Aujourd'hui, CPCEC a une compatibilité totale avec tout les jeux sortis en cassettes (aucun soft ne plante dessus), soit 100% de la logithèque Amstrad K7. Et c'est la même chose pour les softs en disquettes. Hormis Discology, et peut-etre 2 ou 3 autres softs, 99,8% des logiciels tournent dessus.
Par comparaison, CPCEC a même un taux de compatibilité supérieur à ACE (l'émulateur dit comme étant le plus abouti, César l'utilise régulièrement pour vérifier la compatibilité).
Quand à moi, mon rôle est simple : j'ai testé plusieurs milliers de softs avec csw2cdt, l'outil est actuellement à maturité, et en parallèle avec mon TZXduino pour les CDT, et les WAV avec ma cassette digitale sur mon 464. Aucun soft ne m'a planté ou ne m'est resté sur les bras. ceci en dehors des logiciels utilisant des keytones, qu'il est plutôt difficile de réverser en WAV.
Ensuite quand tu viens de me parler de melon, pardon, mais c'est la pastèque qui vient faire la leçon au melon
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Fredouille a écrit :
Perso, je commence à me poser des questions sur ces nouveaux CDTs.
Par exemple, "3D Stunt Rider (UK) (1985) [Amsoft 183] [Original] [TAPE].cdt" ne passe pas sur Caprice alors que la version qui se trouve sur "C.P.C. P.o.w.e.r" ne pose aucun problème.
Là, je me dis que j'ai un souci avec l'émulateur. Alors, afin de lever mes doutes, je convertis ces 2 CDT en WAV en utilisant CSW2CDT de 2019.
Le WAV de la version qui se trouve "C.P.C. P.o.w.e.r" passe sur CPCEC. Alors que le WAV de ce nouveau CDT ne passe pas sur CPCEC.
Puisque le WAV est le résultat de l'interprétation du CDT, comment se fait-il que le WAV ne passe pas alors que le CDT passe ?
Hormis de commencer à croire que ces CDT sont spécialement encodés pour CPCEC.
Les CDTs sont encodés suivant un principe simple fredouille :
Les WAV sont filtrés et compressés en fichier CSW, qui a son tour est encodé au format CDT.
A savoir qu'on ne peut pas avoir dans un CDT des valeurs entières, mais uniquement des arrondis. C'est ainsi que le format a été conçu. Donc Il n'y a pas de problème concernant les CDTs à proprement parler, on a affaire à un problème d'émulateur.
D'ailleurs pour répondre à Megachur concernant Helichopper, César a fait le débugging du problème ce matin à l'aide de Caprice Forever, qui permet le débugging, et il a trouvé d'ou vient le bug concernant ce CDT, et qui concerne CPCEpower comme Caprice Forever :
"J'ai débuggé avec Caprice Forever tout en chargeant le CDT en même temps que CPCEC. Le bloc qui va de traviole a juste un bit incorrect dans Caprice Forever: le tout dernier bit de 0 est transformé en 1."
(Là, j'apporte ma propre connaissance du système Bleepload v1 : ce système n'est pas doté d'octets de trailing classique comme on peut le voir sur le système Ricochet, Cassys, Amstrad ou alkatraz par exemple. L'émulateur ne doit pas se gauffrer sur les bits de trailing de fin de bloc+la pause qui suit. Autrement ça entre de facto une erreur de lecture.)
on poursuit :
"Ca daube le dernier échantillon qui a fusionné avec la pause qui le suit, au lieu de s'assurer qu'il s'agit du problème opposé."
" Bleepload1 gère le BIT0 comme une bordure courte (short edge) et le BIT1 comme une longue (long edge), et la fusion de la pause avec le dernier bit (qui était censé être un court) transforme efficacement la dernière bordure de court à long: d'où le dernier bit, 0, devient 1 et la somme de contrôle n'est plus correcte."
=> J'invite donc Fredouille comme Megachur à vérifier leurs routines de ce point de vue, dont le bug cité ci-dessus est la source du problème.
A vous de jouer, vous avez l'explication du problème rencontré.
Je ne connais pas les détails in fine car je ne connais pas les rouages internes de Caprice Forever. Le problème ici n'est pas la précision de la lecture TZX/CDT, mais la gestion des échantillons de fin et les pauses qui les suivent."
_________________ SPS Community Expert (SPS CE) / SPS France
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 62 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