Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Ce jeu en cassette est une cassette spéciale :
csw2cdt -c 2 -5 -z 1 -r 1
-c 2 : permet de retirer du bruit, enlevé en fusionnant les signaux plus court que 2 samples. -5 : met les trailers byte correctement ('FFFFFFFF') -z 1 : (pour dire à CSW2CDT de ne PAS encoder les blocks au format spectrum; ces blocs n'ont pas le champ contenant la quantité de pilot tone et de ce fait ne permettent pas de définir la polarité). -r 1 : le système de chargement est dépendant de la polarité (Polarité paire)
La subtilité, c'est que les constantes des blocs spectrum sont fixes, non modifiables, hors ça ne permet pas d'incorporer la polarité paire.
Je joins le CDT pour update.
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
dlfrsilver a écrit :
Ce jeu en cassette est une cassette spéciale :
csw2cdt -c 2 -5 -z 1 -r 1
-c 2 : permet de retirer du bruit, enlevé en fusionnant les signaux plus court que 2 samples. -5 : met les trailers byte correctement ('FFFFFFFF') -z 1 : (pour dire à CSW2CDT de ne PAS encoder les blocks au format spectrum; ces blocs n'ont pas le champ contenant la quantité de pilot tone et de ce fait ne permettent pas de définir la polarité). -r 1 : le système de chargement est dépendant de la polarité (Polarité paire)
La subtilité, c'est que les constantes des blocs spectrum sont fixes, non modifiables, hors ça ne permet pas d'incorporer la polarité paire.
Je joins le CDT pour update.
Hello,
Je m'interroge sur ton post pour savoir si c'est de la bidouille pour que ça marche avec CPCEC ou pour rentrer dans la conformité du format TZX https://worldofspectrum.net/TZXformat.html ou autre cas ?
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Salut,
Il ne s'agit pas de bidouille.
Je ne valide aucun test par le biais des émulateurs. Rappel : Si ça passe sur un vrai CPC et pas en émulation, ce n'est pas mon problème. Je ne m'occupe pas des bugs ou des problèmes liés aux émulateurs, c'est aux programmeurs de corriger et de rectifier le tir. Quand j'encode un jeu, soit ça marche sur mon CPC 464, soit ça ne marche pas. Si le jeu fonctionne sur mon 464, c'est bon, je valide, et ensuite seulement je teste sous CPCEC. Si ça ne marche pas sous CPCEC, je laisse César voir ce qui ne va pas et corriger le bug.
Ici, le problème qu'on m'a remonté, c'était un problème d'encodage (je le savais), puisque le CDT ne tournait sur aucun émulateur : ni CPCEC, ni caprice forever, ni sugarbox, etc etc etc.
L'explication :
Les auteurs du logiciel ont voulu utiliser le système de chargement défini dans la rom du spectrum pour la version CPC de leur jeu, mais ils se sont plantés, et l'ont mal ou incorrectement copié.
Je réexplique : les timings ou constantes de la ROM spectrum sont figées, on ne peut pas les changer. Le problème est que comme c'est un format qui ressemble à du spectrum mais qui au final n'en est pas, si on encode au format Spectrum le jeu avec csw2cdt, le loader foire le chargement, car les constantes figées de la rom spectrum ne correspondent pas à ce que le loader attends.
Si tu encodes le jeu avec le format de bloc standard Spectrum, le CDT crashera sur tout les émulateurs. Tout simplement parce que le nombre de "pilot tone" est figé dans les blocs au format spectrum, alors que le nombre en question doit être "odd" (paire en fait) en terme de polarité.
Rappel : la polarité n'est pas liée à un émulateur mais aux constantes utilisées sur la cassette par la compagnie de duplication (voir éventuellement le programmeur du jeu/protection), et que le loader vérifie. Si ça ne correspond pas, le loader appelle une routine qui stoppe le chargement et dit en français "Erreur sur la cassette" et te renvoie au prompt.
En fait, il faut encoder le jeu avec une commande spéciale csw2cdt, car c'est un cas spécial. C'est pas des blocs Amstrad "turbo load" pur, et ce n'est pas non plus des blocs spectrum pur (faux positif).
En bref, pour dire les choses simplement, les constantes/timings de la cassette sont en quelque sorte protégées contre la copie, et le jeu utilise un système de blocs hybrido-caviardé CPC/spectrum.
J'espère que c'est clair pour toi.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
dlfrsilver a écrit :
Salut,
Il ne s'agit pas de bidouille.
Je ne valide aucun test par le biais des émulateurs. Rappel : Si ça passe sur un vrai CPC et pas en émulation, ce n'est pas mon problème. Je ne m'occupe pas des bugs ou des problèmes liés aux émulateurs, c'est aux programmeurs de corriger et de rectifier le tir. Quand j'encode un jeu, soit ça marche sur mon CPC 464, soit ça ne marche pas. Si le jeu fonctionne sur mon 464, c'est bon, je valide, et ensuite seulement je teste sous CPCEC. Si ça ne marche pas sous CPCEC, je laisse César voir ce qui ne va pas et corriger le bug.
Ici, le problème qu'on m'a remonté, c'était un problème d'encodage (je le savais), puisque le CDT ne tournait sur aucun émulateur : ni CPCEC, ni caprice forever, ni sugarbox, etc etc etc.
L'explication :
Les auteurs du logiciel ont voulu utiliser le système de chargement défini dans la rom du spectrum pour la version CPC de leur jeu, mais ils se sont plantés, et l'ont mal ou incorrectement copié.
Je réexplique : les timings ou constantes de la ROM spectrum sont figées, on ne peut pas les changer. Le problème est que comme c'est un format qui ressemble à du spectrum mais qui au final n'en est pas, si on encode au format Spectrum le jeu avec csw2cdt, le loader foire le chargement, car les constantes figées de la rom spectrum ne correspondent pas à ce que le loader attends.
Si tu encodes le jeu avec le format de bloc standard Spectrum, le CDT crashera sur tout les émulateurs. Tout simplement parce que le nombre de "pilot tone" est figé dans les blocs au format spectrum, alors que le nombre en question doit être "odd" (paire en fait) en terme de polarité.
Rappel : la polarité n'est pas liée à un émulateur mais aux constantes utilisées sur la cassette par la compagnie de duplication (voir éventuellement le programmeur du jeu/protection), et que le loader vérifie. Si ça ne correspond pas, le loader appelle une routine qui stoppe le chargement et dit en français "Erreur sur la cassette" et te renvoie au prompt.
En fait, il faut encoder le jeu avec une commande spéciale csw2cdt, car c'est un cas spécial. C'est pas des blocs Amstrad "turbo load" pur, et ce n'est pas non plus des blocs spectrum pur (faux positif).
En bref, pour dire les choses simplement, les constantes/timings de la cassette sont en quelque sorte protégées contre la copie, et le jeu utilise un système de blocs hybrido-caviardé CPC/spectrum.
J'espère que c'est clair pour toi.
Hello,
Je te remercie pour cette clarification...
au final ce que tu m'expliques c'est que le CDT produit est conforme au format TZX... et c'est cela l'essentiel !
--> d'ailleurs le CDT n'est composé que de blocs "TURBO SPEED DATA BLOCK" au final !
Ce que tu expliquais, c'est plus une évolution de l'outil 'CSW2CDT' de César pour prendre en compte ce type de codage et en faire un CDT propre au format TZX !
Je te remercie encore une fois pour tout ce travail de préservation !!
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Megachur a écrit :
dlfrsilver a écrit :
Salut,
Il ne s'agit pas de bidouille.
Je ne valide aucun test par le biais des émulateurs. Rappel : Si ça passe sur un vrai CPC et pas en émulation, ce n'est pas mon problème. Je ne m'occupe pas des bugs ou des problèmes liés aux émulateurs, c'est aux programmeurs de corriger et de rectifier le tir. Quand j'encode un jeu, soit ça marche sur mon CPC 464, soit ça ne marche pas. Si le jeu fonctionne sur mon 464, c'est bon, je valide, et ensuite seulement je teste sous CPCEC. Si ça ne marche pas sous CPCEC, je laisse César voir ce qui ne va pas et corriger le bug.
Ici, le problème qu'on m'a remonté, c'était un problème d'encodage (je le savais), puisque le CDT ne tournait sur aucun émulateur : ni CPCEC, ni caprice forever, ni sugarbox, etc etc etc.
L'explication :
Les auteurs du logiciel ont voulu utiliser le système de chargement défini dans la rom du spectrum pour la version CPC de leur jeu, mais ils se sont plantés, et l'ont mal ou incorrectement copié.
Je réexplique : les timings ou constantes de la ROM spectrum sont figées, on ne peut pas les changer. Le problème est que comme c'est un format qui ressemble à du spectrum mais qui au final n'en est pas, si on encode au format Spectrum le jeu avec csw2cdt, le loader foire le chargement, car les constantes figées de la rom spectrum ne correspondent pas à ce que le loader attends.
Si tu encodes le jeu avec le format de bloc standard Spectrum, le CDT crashera sur tout les émulateurs. Tout simplement parce que le nombre de "pilot tone" est figé dans les blocs au format spectrum, alors que le nombre en question doit être "odd" (paire en fait) en terme de polarité.
Rappel : la polarité n'est pas liée à un émulateur mais aux constantes utilisées sur la cassette par la compagnie de duplication (voir éventuellement le programmeur du jeu/protection), et que le loader vérifie. Si ça ne correspond pas, le loader appelle une routine qui stoppe le chargement et dit en français "Erreur sur la cassette" et te renvoie au prompt.
En fait, il faut encoder le jeu avec une commande spéciale csw2cdt, car c'est un cas spécial. C'est pas des blocs Amstrad "turbo load" pur, et ce n'est pas non plus des blocs spectrum pur (faux positif).
En bref, pour dire les choses simplement, les constantes/timings de la cassette sont en quelque sorte protégées contre la copie, et le jeu utilise un système de blocs hybrido-caviardé CPC/spectrum.
J'espère que c'est clair pour toi.
Hello,
Je te remercie pour cette clarification...
au final ce que tu m'expliques c'est que le CDT produit est conforme au format TZX... et c'est cela l'essentiel !
--> d'ailleurs le CDT n'est composé que de blocs "TURBO SPEED DATA BLOCK" au final !
Ce que tu expliquais, c'est plus une évolution de l'outil 'CSW2CDT' de César pour prendre en compte ce type de codage et en faire un CDT propre au format TZX !
Je te remercie encore une fois pour tout ce travail de préservation !!
=> Pas du tout
Un CDT peut être composé de blocs tout à fait différents, et pas que des blocs "Turbo Speed data" !
Csw2cdt n'a subi aucun changement. Le problème en tant que tel c'était de pouvoir encoder correctement ce jeu qui est un cas spécial.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
dlfrsilver a écrit :
Salut,
Il ne s'agit pas de bidouille.
Je ne valide aucun test par le biais des émulateurs. Rappel : Si ça passe sur un vrai CPC et pas en émulation, ce n'est pas mon problème.
Je pense que j'ai déjà dû posé cette question mais j'avoue que je ne comprends pas cette phrase.
Si j'ai bien compris, tu récupères une cassette que tu passes dans un lecteur pour obtenir une image numérique. Que tu passes enfin dans une moulinette pour obtenir un fichier CDT.
Mais c'est là que je ne comprends pas... Tu dis que tu testes ce CDT en le passant à un CPC !!
C'est surement moi car j'ai dû raté quelque chose, mais un CPC ne possède pas de lecteur de fichiers CDT.
Du coup, comment ton CDT peut passer sur un vrai CPC ??
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Fredouille a écrit :
dlfrsilver a écrit :
Salut,
Il ne s'agit pas de bidouille.
Je ne valide aucun test par le biais des émulateurs. Rappel : Si ça passe sur un vrai CPC et pas en émulation, ce n'est pas mon problème.
Je pense que j'ai déjà dû posé cette question mais j'avoue que je ne comprends pas cette phrase.
Si j'ai bien compris, tu récupères une cassette que tu passes dans un lecteur pour obtenir une image numérique. Que tu passes enfin dans une moulinette pour obtenir un fichier CDT.
Mais c'est là que je ne comprends pas... Tu dis que tu testes ce CDT en le passant à un CPC !!
C'est surement moi car j'ai dû raté quelque chose, mais un CPC ne possède pas de lecteur de fichiers CDT.
Du coup, comment ton CDT peut passer sur un vrai CPC ??
J'utilise un TZXduino, et j'utilise également une réversion du CDT en WAV. Si le CDT est bon, le WAV le sera aussi. si le CDT est pas bon, le WAV ne sera pas bon, et le CPC 464 le ou les rejettera.
_________________ SPS Community Expert (SPS CE) / SPS France
J'utilise un TZXduino, et j'utilise également une réversion du CDT en WAV. Si le CDT est bon, le WAV le sera aussi. si le CDT est pas bon, le WAV ne sera pas bon, et le CPC 464 le ou les rejettera.
Hello,
Même si effectivement le test sur CPC est indispensable (en considérant qu'un wav va passer sur plusieurs CPC différents), j'espère que tu te rends compte du nombre de biais expérimentaux présent dans cette phrase :
- cdt -> wav via tzxduino, - WAV vers entrée cassette - L'électronique de la lecture cassette elle-même...
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
dlfrsilver a écrit :
J'utilise un TZXduino, et j'utilise également une réversion du CDT en WAV. Si le CDT est bon, le WAV le sera aussi. si le CDT est pas bon, le WAV ne sera pas bon, et le CPC 464 le ou les rejettera.
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Lone a écrit :
dlfrsilver a écrit :
J'utilise un TZXduino, et j'utilise également une réversion du CDT en WAV. Si le CDT est bon, le WAV le sera aussi. si le CDT est pas bon, le WAV ne sera pas bon, et le CPC 464 le ou les rejettera.
Hello,
Même si effectivement le test sur CPC est indispensable (en considérant qu'un wav va passer sur plusieurs CPC différents), j'espère que tu te rends compte du nombre de biais expérimentaux présent dans cette phrase :
- cdt -> wav via tzxduino, - WAV vers entrée cassette - L'électronique de la lecture cassette elle-même...
-Le TZXduino gère directement les CDTs. pas besoin de convertir le fichier.
Ensuite, c'est hyper simple : si le WAV est pas bon, le 464 ne le chargera pas.
Si tout est OK, le WAV ou le CDT se chargera. Et si ça marche pas en émulation, problème d'émulation.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Fredouille a écrit :
dlfrsilver a écrit :
J'utilise un TZXduino, et j'utilise également une réversion du CDT en WAV. Si le CDT est bon, le WAV le sera aussi. si le CDT est pas bon, le WAV ne sera pas bon, et le CPC 464 le ou les rejettera.
Heu... Le TZXduino... ce n'est pas un émulateur ?
Non ce n'est pas un émulateur, il s'agit d'un boitier qui n'est rien de plus qu'un petit système qui lit ou converti à la volée des fichiers CDT en flux compréhensible pour le 464 (ou le 6128).
C'est l'équivalent du lecteur TAP pour le C64, qu'on trouve dans l'Ultimate 1541-II.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
dlfrsilver a écrit :
Fredouille a écrit :
dlfrsilver a écrit :
J'utilise un TZXduino, et j'utilise également une réversion du CDT en WAV. Si le CDT est bon, le WAV le sera aussi. si le CDT est pas bon, le WAV ne sera pas bon, et le CPC 464 le ou les rejettera.
Heu... Le TZXduino... ce n'est pas un émulateur ?
Non ce n'est pas un émulateur, il s'agit d'un boitier qui n'est rien de plus qu'un petit système qui lit ou converti à la volée des fichiers CDT en flux compréhensible pour le 464 (ou le 6128).
C'est l'équivalent du lecteur TAP pour le C64, qu'on trouve dans l'Ultimate 1541-II.
Ben... Comme ce n'est pas un vraie cassette... c'est donc un émulateur de cassette !!
Apparemment, il y a plusieurs modèles de TZXDuino. Au mieux, c'est un modèle qui tient dans le facteur de forme d'une cassette et qui remplace une cassette. Au pire, le modèle s'affranchit de la partie audio du lecteur de cassette.
Dans tous les cas, c'est bien un logiciel qui va interpréter ton CDT pour en sortir un état physique (analogique ou pas).
Si j'ai bien compris, lorsque tu dis "Si le jeu fonctionne sur mon 464, c'est bon", il faut comprendre que le CDT fonctionne avec ton montage audio et la version logicielle de ton TZXDuino.
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Citer :
Si j'ai bien compris, lorsque tu dis "Si le jeu fonctionne sur mon 464, c'est bon", il faut comprendre que le CDT fonctionne avec ton montage audio et la version logicielle de ton TZXDuino.
C'est ça. Si mon 464 valide la lecture, les émulateurs doivent valider derrière. Et si un d'eux valide pas, c'est pas mon problème
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
L'ennui, c'est que tout le monde sait que les CDT sont très souvent trafiqués. Un peu comme les WAV d'ailleurs car c'est encore plus facile de copier des samples par ci, par là.
Ta méthode pourrait fonctionner si on était sûr de l'intégrité, voire de l'authenticité, de ce CDT. Et dans ce cas, fournir la chaine qui a conduit à l'obtention de ce fichier, à savoir : - Le WAV Original - Les options de conversions - Les versions des outils utilisés.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 12 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
!
!
