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.

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 !!

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.

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...

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.

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.