@dlfrsilver :

bon, j'ai enfin trouvé 5 mins pour mettre mon débugger en mode 464 sans fdc.

le résultat des investigations entre le CDT et le WAV (issu du CDT).

visiblement, pas de plantage jusqu'au chargement du bloc "ID 14 - Pure data block"

pour en être là, après le début du chargement du loader mettre un breakpoint a 0x1D2E

le nombre souligné est l'index des pulses = numéro du pulse au moment ou il change.

Rat Connection (F) (1987) (Version Basic 1.0) [Original] [TAPE].wav
194269 at cpu.pc=0xB9A9 début pulse bloc 14

1er pulse de 292 valeur 0

Rat Connection (F) (1987) (Version Basic 1.0) [Original] [TAPE].cdt
194269 at cpu.pc=0x016A début pulse bloc 14

194270 2ieme pulse at cpu.pc=0x19DA

194271 3ieme pulse at cpu.pc=0xB9AA

mon analyse c'est qu'il nous manque deux pulses sur le CDT !?
dit autrement, il faut voir pourquoi CDT2WAV génère c'est 2 pulses, et où ils sont.

Concernant la visu de la clé dans le waves, par rapport au wave généré depuis le CDT :

celui fait par César et celui que tu as fourni juste dans le post précédent :
on voit bien 3 zones et pas une sur le deuxième wave ... de plus les blocs (tone, pause et pure data) sont décalés !

mais en amont de cela -> je pense surtout que la clé n'est pas un pure tone... quand on la regarde de prêt, les valeurs hautes et bas ne semblent pas régulière...
est-il possible de généré un bloc "id 14 pure data bloc" avec les données du wave de césar à la place du bloc id 12 ?

on a peut-être été trompé par Marmelade qui n'a surement pas la même protection !


cf image :

On a la dysmétrie du signal sur les blocs en pure tone?
Sinon, c'est une erreur de lecture...
Sur l'original, est-il possible de resymétriser et uniformiser les signaux?

@dlfrsilver :

un début de piste, si je replace le pure tone du cdt comme sur le wave (cf fichier Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE]_ok.wav.7z ci-joint),
le loader ne reset plus et il commence à charger puis s'arrête.

mon problème c'est que je n'arrive pas à générer avec tapir un pure tone exactement de la même longueur que celui du fichier Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE]_ok.wav.7z ci-joint.

je laisse le spécialiste mondial m'aider !!!! et nous sortie une cdt bien faite !!!

j'ai mis un exemple de ce que j'ai fait : Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE]_tapir3.cdt

Rappel : le fichier Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE]_ok.wav.7z -> c'est le seul qui marche chez moi !

Tu prends le problème à l'envers. CPCemu plante sur le chargeur encrypté, il n'atteint même pas la clé digitale (le bloc pure tone).



T'es sur que tu sais ce que tu fais ?



On en a déjà un de CDT bien fait. le problème comme on le sait n'est pas de son côté



C'est normal, les valeurs que tu as mis pour le pure tone sont folkloriques, La longueur de pulse indiquée par Thomas était la bonne, à savoir 1444, et 1018 en nombre de pulses.

D'ou tu sors 413 ?? sur quelle base tu le calcules ?

ensuite je vois autre chose, la pause qui est à la fin du 4ème bloc du chargeur encrypté n'a pas la bonne longueur sur ton CDT, soit 3002ms au lieu de 3033ms.

Mais quid du décryptage du chargeur, ça plante mais que se passe t-il dans les registres z80 de CPCemu ??

_________________
SPS Community Expert (SPS CE) / SPS France

@Megachur

Pour rebondir sur ces différents WAV et cdt, il n'est pas certain que l'on puisse mixer les deux à loisir :

En effet, les timings sont sans doute relatifs aux longueur des pilotes (ce qui est la manière par le cpc de connaitre la vitesse du lecteur k7, et d'adapter son algo avec)

Ce ne marcherait donc que si la source était un seul et unique wav (on peut imaginer des micros variations entre deux dumps, si la protection se base sur des timings précis)

Et il est effectivement fort possible qu'un simple "pure tone" ne soit pas suffisant, on voit bien que la section que l'on appelle la "clé" est tout sauf un enchainement de pulse régulière (on y trouve un gros trou entre autre en plein milieu)


@dlfrsilver : Rendons à Megachur ce qui lui appartient. Les valeurs de pulse sont celles de Megachur, je n'ai rien calculé de tel (enfin si, vaguement sur un papier que j'ai évidemment perdu - Mais en gros, j'avais des résultats similaires, même si moins précis )

Par contre, je suis très intéressé par ta méthode pour le calculs des pulses (longueur et nombre), par ce que je ne trouve pas ça vraiment facile en comptant les samples sur Audacity.

De même, quelles raisons font que tu simplifies ces pulses en un unique pure tone ? Le wav fonctionnel montre un truc si différent que ton expérience sur le sujet m'intéresse !

Par ailleurs, certains logiciels cassette testent les timings en guise de protection (déjà vu par le passé).



Les pauses sur ces jeux sont utilisées comme timer. Il faut qu'elles durent assez longtemps, pour que le processus de décryptage ait lieu AVANT que le CPC ne poursuive la lecture vers la clé, et qu'une fois la clé lue, le second décryptage du loader custom qui permet de charger le gros bloc ait lieu.



J'ai expliqué après discussion avec César pourquoi l'utilisation d'un bloc pure tone et pas un bloc DRB (dont l'utilisation est interdite dans les CDTs).

L'explication de César que j'ai déjà donné hier, et que je répète à nouveau aujourd'hui :

Parce que le loader de la clé digitale écoute la cassette pour une durée de temps fixe et s'attend à un nombre donné de pulses. ; Par voie de conséquence, c'est clairement un bloc "pure tone" qu'il faut et qui fourni au loader les informations qu'il demande, ce qui permet la poursuite du chargement.

Je comprends que comme tu ne le sais pas, c'est que tu n'as pas désossé entièrement le loader, ce qui est juste logique.

J'arrête tout débat sur le sujet, examine le loader, au pire si tu veux commentes le, et viens nous expliquer ici ce que tu auras trouvé, les trucs intéressants comme les bizarreries.



Tu as indiqué comme valeur 1444. Ce n'est pas la valeur 413 indiquée par Megachur.

Avec 413, le WAV généré depuis le CDT modifié ne marche pas sur mon 464.



Audacity n'est pas du adapté pour ce que l'on a faire. Goldwave est plus approprié.

Pour la méthode calcul de pulses en longueur et nombre, je vais demander à César comment il fait. C'est lui qui a généré la clé digitale.

Mais j'en reviens à ce que je disais, quel intêret de se pencher sur la clé, alors que les émulateurs plantent sur le chargeur binaire encrypté ?



Le WAV fonctionnel est une conversion du CDT. On ne simplifie rien, les blocs pure tone ont été crée parce que certains logiciels font usage de ces blocs spéciaux, qui ne contiennent pas de data, et qui ne sont qu'un signal audio digital.

Voilà comment CDT2WAV gère les blocs pure tone :

_________________
SPS Community Expert (SPS CE) / SPS France

@dlfrsilver :
je tiens à te préciser que les modifications que j'ai faite sur cdt d'origine sont justement dûs au décryptage du loader z80 du jeu.

la pause 3033 est bcp trop longue par rapport au code.

d'ailleurs, quelle est l'explication de notre expert dumper de la différence entre le wave (qui fonctionne sans problème je le rappelle) où elle fait cette longueur et le cdt où elle est plus longue ?

pour ceux que ça intéresse :

mettre un breakpoing en 1D2B:JP &1CF7 -> routine qui vérifie qu'on a bien du silence = 0 avant la clé !

pour le nombre de pulse attendu, je l'ai donc laissé à 1018 puisque c'est le nombre de pulse attendus par le loader (voir César)
j'ai donc modifié la longueur à 413 pour arriver à la longueur de la clé soit 119 ms

119 x 3.5 = 420000
420000/1018 = 412,57367387033398821218074656189

par contre, que je mettes 412 ou 413 je voie qu'avec les arrondis de CDT2WAV 1.5, il génère la même durée de clé qui est inférieur à 119 ms -> elle ne fait que 115 ms !


je rappelle que je ne remets pas en cause le dump (wav reconstruit à partir de la cdt + pose de la clé par César)

seule la cdt qui ne fonctionne pas m'intrigue !

je dis juste que j'ai 30 ans de programmation dernière moi sur cpc et que c'est ce que je vois dans le code z80 !!!

donc, je le dis clairement : à ce stade de l'analyse, le cdt ne semble pas conforme au (wave + la clé) !!! et c'est pour cela que le loader z80 ne marche pas !
dit autrement : le même code z80 du loader qui tourne sur la même émulation identique ne donne pas le même résultat entre la lecture du wave et du cdt -> et je le rappelle c'est le même format qui est utilisé en interne de l'émulation pour la conversion des données waves ou cdt dans mon ému !!!

j'ai pas eu le temps hier de finaliser, mais je suis en train de coder dans l'ému, la possibilité de refaire un wave depuis le format interne
je montrerai ainsi clairement les différences entre le wave reconstruit + la clé rajouté par César et la conversion en cdt !

-> dès que j'ai le temps -> je m'y colle !

@dlfrsilver et @Lone : en tout cas, je vous remercie pour ces échanges constructifs, même si animé de la même passion, on a pas encore réussi totalement ce challenge !
de toute façon le débat : mauvais dump ou mauvaise émulation n'a pas fini d'animer les forums

parce que je vous le dis, on a pas fini d'en discuter tant que @dlfrsilver (et d'autres) nous alimenteront de nouveaux dumps !!!

Il y en a plusieurs.



3033ms c'est la longueur de pause que j'ai trouvé sur le WAV original brut venant de la cassette, que j'ai reporté dans le CDT.



J'ai reporté ce que j'avais dans le WAV original non fonctionnel. Tout simplement, Goldwave permet de relever l'information de manière très précise.



C'est totalement erroné.

Physiquement, y a :

La pause avant démarrage / Loader sur 4 bloc / zone de pause / Clé Digitale / Zone de Pause / Gros Bloc

C'est comme ça qu'est physiquement et visuellement le contenu de la cassette.

C'est absolument impossible qu'il y ait 0 (soit du silence) avant la clé.

Je le répète, La pause après le loader et avant la clé sert de timer pour le décryptage du chargeur binaire.

Si tu mets un silence avant la clé, ça revient à coller la clé au chargeur binaire.

Je te le dis sans mettre de gant : c'est un viol du système de protection, qui répondra par un reset de la façon la nette possible.

Le temps de pause après le chargeur est utilisé par le z80 pour décrypter le loader dans le chargeur qui va prendre la suite.

C'est exactement comme avec les protection speedlock, quand tu passe le loader encrypté du début, il y a une pause. Cette pause doit être suffisamment longue pour que le z80 ait le temps de décrypter le programme.
Sinon, le lecteur de cassette se déclenche trop tôt, et comme le z80 n'a pas terminé le travail, le chargement foire. Ici c'est exactement pareil.

Donc ce que tu trouves n'est pas normal. Il ne peut pas y avoir un silence avec 0ms, le système de protection et son fonctionnement l'interdisent.



ça c'est bon



119 x 3.5 = 420000
420000/1018 = 412,57367387033398821218074656189[/quote]

ça s'est pas bon, mon 464 n'en veut pas, la valeur est incorrecte.



C'est un autre souci.



Il n'y a pas de CDT qui ne fonctionne pas. Il n'y en a jamais eu. Le CDT fournit a été testé sur mon 464, fonctionne dessus.

Le problème est côté émulateur.



Clairement je ne suis pas d'accord. Explique moi pourquoi sur mon 464, et quand je teste ta modif ça ne fonctionne pas ?

ça ne t'interpelle pas ? Je ne remets pas en cause tes 30 ans de prog, je dis simplement que mon 464 n'est pas d'accord avec tes conclusions.



Vos émus n'arrivent même pas à finir le chargement du chargeur encrypté sur 4 blocs. Je n'y arrive même pas !

Donc je ne comprends pas votre entêtement au sujet de la clé, sugarbox et CPCemu restent bloqués sur le 4ème bloc du chargeur, figent, et reset !





Il n'y a pas de mauvais dump. Le CDT fonctionne sur mon 464. Pas sur les émulateurs. le problème est côté émulateur.



Certes, mais faudrait que ça avance !

_________________
SPS Community Expert (SPS CE) / SPS France

Si j'ai bien compris, tu testes ton CDT avec une casette digitale, pas avec une vraie cassette.
Ça veux dire que le contrôle du moteur fait par le CPC n'a aucun effet sur les pauses vue par le CPC.

La bonne méthode serait de faire un enregistrement sur cassette, puis une lecture de cette cassette par le CPC.
Si le CDT enregistré sur cassette fonctionne sur un 464, on pourrait en conclure que l’émulateur a un problème, pas avant.

D’ailleurs tu dis toi même que le CDT ne marche pas sans le modifier ....
Mettre une pause pour que CDT passe fait donc que le CDT ne représente pas la cassette originale !
Pour jouer, pas de problème, pour de la préservation, c'est pas terrible

@Denis : Rassure moi, c'est du troll de haut niveau tout ça ? (et on est tombé dans le panneau ?)

Sinon, au cas ou ça ne serait pas le cas...

Silence = pause = 0 signifie (@Megachur, sous ton controle) que l'amplitude de la wav est a 0 (-128->127 en 8 bits) - pas sa durée, les pause de durée nulle sont tout bêtement ignorées.

Le pure tone : L'algo de Markus est identique aux notres, vu la simplicité biblique du bloc pure tone. Qui ne sert qu'à générer un nombre défini de pulse ayant tous la même durée (on ne parle pas d'amplitude, l'amplitude n'est pas un concept connu du format cdt). Pratique pour faire (par exemple) un pilote.

Sinon, je comprends bien pourquoi il est déconseillé d'utiliser les DRB dans un cdt (autant utiliser un format plus précis dans ce cas, CSW au hasard), mais pourquoi se l'interdire ? Dans le cas ou l'on a des pulses précises, et irrégulières à placer, il semble bien plus indiqué...

Enfin, qu'entends-tu par "clé digitale" ? On parle bien du bloc vers la 53e seconde ?
Vu que l'ensemble du CDT se place à un niveau d'abstraction ou l'on n'a que des données numériques, la seule caractéristique que l'on lui trouve, c'est éventuellement de ne pas porter de données et de servir de protection de par sa forme. D'ou l'intérêt d'un DRB (plus précis, pas de donnée à transporter)

Et pour finir, vu qu'on a un wav qui passe sur emulateur ET 464, le problème ne vient pas de l'émulation de la machine, mais plutôt du fichier cdt lui-même - que ça soit notre traitement ou ses propres données. (enfin... Vu qu'on a aucun CDT générant ce fameux wav....)


@Gerald : Pour la préservation, le cdt est de toute façon bien trop interprété pour être vraiment indispensable (comme les dsk en disquette). Il faudrait l'équivalent des scp/kryoflux, voir ct-raw (excellent compromis)... Le plus proche étant sans doute le format csw, mais il n'est pas vraiment supporté, ce qui est bien dommage. Les WAV sinon, proposent ce que l'on veut (mais en étant bien trop gros pour être vraiment intéressant pour le grand public)

Sur cette protection ça fonctionne comme ceci :

Prenons le cas de marmelade par exemple. La protection est la même que sur Rat Connection, à la différence près que Rat utilise une vitesse plus rapide. Mais dans le principe c'est pareil.

donc : Le 464 charge le loader binaire encrypté qui tient sur 4 blocs, le temps de pause qui vient juste après, soit 3033ms sert de "timer". Pendant cette période de temps, le lecteur de cassette s'arrête, et le z80 prend le relais, procède au décryptage de ce qui a été chargé. ce processus de décryptage doit se terminer juste avant la fin des 3033ms. Le loader custom qui doit charger la clé digitale est alors actif et se met en écoute du port cassette. Le bloc "pure tone" est alors traité, et comme il contient ce que le loader attend (longueur de pulses et nombre de pulses), cette clé qui est chargée sert à son tour à décrypter le dernier loader, celui qui sert à charger le gros bloc. là encore il y a un bloc de pause de 1629ms, qui sert de "timer". Le lecteur de cassette est de nouveau arrêté, et le z80 prend le relais et le processus de décryptage du dernier loader prend place.
Au moment ou le z80 a fini sont travail, il rend la main au lecteur de cassette qui poursuit sa lecture, le border change de couleur, et la lecture du dernier bloc (pure data) prend place. A l'issue le jeu est chargé.



Comme je le disais plus haut, si le CDT était claqué ou ne fonctionnait pas, le WAV ne fonctionnerait pas non plus.

Hors quand je convertis le CDT en WAV, ce dernier fonctionne. Donc le CDT dont il est issu est bon. Forcément.



J'ai indiqué plus haut que je m'étais trompé, puisque la valeur donnée par Thomas fonctionne, j'ai fais le test sur mon 464.

Faudrait voir à lire ce que j'écris.....

[/quote]Mettre une pause pour que CDT passe fait donc que le CDT ne représente pas la cassette originale !
Pour jouer, pas de problème, pour de la préservation, c'est pas terrible [/quote]

Je n'ai rajouté aucune pause. J'ai juste allongé la pause sur Rat connection sur la deuxième, mais les 2 pauses sont bien là sur la cassette originale.

_________________
SPS Community Expert (SPS CE) / SPS France

C'est pas du troll, vous vous mélangez les crayons entre les WAVs et les CDTs....... J'ai du mal à me faire comprendre j'ai l'impression.....

Sinon, au cas ou ça ne serait pas le cas...



Tu peux préciser ce que tu veux dire ?



Oui et justement, j'expliquais plus haut que la raison pour laquelle césar à utilisé ce bloc, c'est que le loader de clé demande justement un nombre déterminé de pulses, et une durée fixe dans le temps.

C'est donc le bloc pure tone qui est le plus adéquat.



Les gens qui ont conçus le format CDT l'ont interdit, parce que des idiots se sont amusés à créer des CDTs contenu un gros bloc DRB, ce qui interdit de voir si il y a une erreur.

Il faut comprendre que qui dit préservation dit monitoring des données, examen et traitement manuel.

La préservation en tant que tel évacue de facto le traitement automatisé. C'est la première chose que j'ai appris chez SPS. C'est pour ça que les formats sont décrits, qu'on voit visuellement ce qu'on fait.

C'est comme si par exemple je pouvais mettre directement un fichier CT-raw dans un IPF. Non seulement c'est interdit, mais en plus c'est la porte ouverte aux conneries et n'importe quel idiot pourrait le faire.

Mais la préservation ce n'est pas ça.

Et pour rebondir sur ce que disait gérard, le format CDT est bien plus propre que le format DSK.

Le format DSK, est très souvent une approximation de ce qui est réellement stocké sur les disquettes originales. J'ai pu le constater sur les milliers d'originaux que j'ai pu dumper, ce qu'on a en sortie dans les DSKs est une simulation de ce qui est sur les disquettes originales.

Exemple : Les secteur 8k par exemple qui sont stockés dans les DSK comme un seul secteur de 6240 octets (par exemple), alors que sur une disquette originale, c'est un secteur de 512 octets suivi d'une immense zone GAP de 5178 octets, et avec un marquage BAD DATA CRC. Pourquoi ? Parce que la taille du secteur indiquée en entête ne correspond pas à la taille réelle sur la piste. Quand le CPC lit ça sous disco par exemple, il copie que les 512 premiers octets, et jete le reste !

Dans les DSK, le secteur entier de 6240 octets est stocké, et quand on regarde la tête que ça a visuellement sous AUFIT (qui permet de voir la gueule des protections des formats atari ST et Amstrad CPC), ça ne correspond pas.



J'ai expliqué plus haut ce que je définissais comme tel. Oui !

Les clés digitales sur amstrad CPC sont des sons digitaux insérés entre deux blocs de signal analogique d'une cassette, soit à la fin du dernier bloc de la cassette. Ces clés ne peuvent pas être définies dans un CDT dans un bloc de données (Turbo bloc, DRB, pure data).

Les éditeurs Rainbow Arts, Ariolasoft, et MBC sont les seuls a avoir utilisé ce type de protection.

Comme les copieurs de cassettes de l'époque ne géraient que du signal analogique, c'était plié d'avance, la copie ne pouvait pas fonctionner, puisque le signal de la clé est digital.

Quand je dumpe une cassette, si cette dernière utilise un signal digital, je le repère tout de suite à l'oreille, ces blocs spéciaux émettent un son très particulier.

quand j'ai dumpé Marmelade et Rat Connection, j'ai même pas eu besoin de dire César que c'était une clé digitale, il me l'a dit lui-même : "ce n'est pas un bloc normal, c'est une clé digitale, comme celles qu'on a pu faire sur les jeux rainbow arts et ariolasoft".

Je précise aussi que je suis la seule personne de la communauté CPC capable de dumper ce genre de cassette protégée (hélas....), c'est la raison pour laquelle jusqu'ici ces cassettes là n'avaient jamais été dumpées.

Je fais équipe avec César pour 2 raisons :

1) je suis le meilleur dumpeur de K7 sur CPC. J'ai vu tout les systèmes de protections, blocs à la con, timings plombés, clés digitales et autres.

2) être le meilleur dumpeur ne suffit pas. N'étant pas programmeur, j'ai besoin de l'appui du meilleur, et le meilleur pour cette tâche c'est César aka CNGSOFT. Personne ne lui arrive à la cheville pour les cassettes.

Le jour ou il dira j'arrête, je prendrais ma retraite ! Mais avant que ça n'arrive, on aura rendu éternel 98% de la logithèque de l'Amstrad CPC



Les blocs DRB ne permettent pas de voir ce qu'on fait, ou de voir si il y a une connerie dans le dump.

Verboten Verstehen !

Laissez moi gérer l'aspect CDT et occupez-vous de la partie programmation, chacun son domaine !



Si le CDT déconnait, le WAV déconnerait pareil, et mon 464 le jetterait aussi, hors ça n'est pas le cas.

Le problème n'est pas coté CDT mais côté émulateur. Posez-vous la question, les émus plantent sur le loader encrypté ! Et vous m'enquiquinez avec la clé alors que ça crashe et ça reset bien avant !



Le format CDT a été crée pour faire du mastering, contrairement au format DSK. Le format SCP est une cochonnerie dans le sens ou il permet la copie de disquettes originales, sans aucun contrôle sur les données.

La preuve, quand je convertis via HxC un dump SCP en dump Kryoflux, et qu'ensuite j'en fais un CT-raw pour créer un IPF, je vois par le biais de l'outil de génération d'IPF que le dump d'origine est dégueulasse.

Pour les dumps Kryoflux, si déjà le fichier CT-raw ne fonctionne pas ou déconne, la génération d'IPF sera impossible.

Et j'ajouterais ceci :

Le SCP et le kryoflux n'ont absolument pas le même but.

Le SCP est un système de copie bit à bit, le système kryoflux est un système de préservation.

Le premier sert à arracher le contenu d'une disquette, le second permet la création de masters propre et 100% fonctionnels, la ou le SCP c'est la surprise à l'arrivée, si y avait de la crasse sur la disquette originale on ne le verra pas forcément tout de suite.

Le système kryoflux interdit lui la génération d'IPF si on utilise un matériau d'origine pourri. Le SCP lui laisse faire.

Je peux en parler, j'ai fais des tonnes d'images disquettes avec le SCP, et j'ai crée plus de 500 ipfs tout format (Amiga, ST, CPC, et PC).

_________________
SPS Community Expert (SPS CE) / SPS France

En fait, une pause, c'est un 0 sur la pin du PPI, qui dure pendant les xx millisecondes spécifiées dans le fichier.


Sans doute, mais ça ne ressemble pas au wav original sur le coup....



Ca n'est pas illogique, mais si l'on ne peut faire autrement, il faut l'utiliser.... Non ?
C'est d'ailleurs ce qu'ils préconisent :
"Please use this block only if you cannot use any other block."
Ce qui semble être notre cas...



Malheureusement (pour avoir enfin pu tester), le seul wav qui passe reste celui qui passe aussi sur émulateur... On revient donc à notre premier problème : Faire marcher un CDT correct, vu que ce wav ne provient entièrement d'un cdt.




Ca ne plante pas pour des causes d'émulations : Le wav fonctionnel ne marcherait pas sur émulateur, sinon.


Le CDT pour du mastering ? Je le voyais plus comme un dsk pour cassette : Avoir le contenu d'un média dans un fichier lisible et petit (ce qui est un énorme avantage, je te le concède volontier)
Pour du mastering, il parait vraiment manquer de précision et être trop approximatif ?



Là, c'est potentiellement l'étape HxC qui pose problème : Il me semble me souvenir de mon implémentation, que le SCP est plus précis que le Kryoflux (les formats sont très, très proches - Forcément, ils décrivent des inversions de flux).

C'est sans doute la suite de logiciels lié au Kryoflux qui ajoute la plus value.

Là merci, je comprends mieux ce que tu voulais dire. Donc un 0 sur la pin du PPI pendant 3033ms donc si je suis ton raisonnement sur Marmelade par exemple, sur la première pause à la fin du 4ème bloc du chargeur encrypté.

Tu parlais en fait de ton implémentation WAV - PPI dans sugarbox, ok

C'est plus clair.



Et c'est pas de bol, mais en utilisant un bloc DRB, ça n'y ressemblerait pas non plus. Sinon César aurait choisi ce type de bloc.

Et je le redis, on ne peut rien faire avec un bloc DRB, pas corriger si il y a le moindre problème.

Les blocs DRB sont utilisés uniquement dans le cas de jeux sur cassettes qui nécessitent un bloc de donnée, mais auquel les blocs de données classiques (turbo bloc, pure data ou encore Standard) ne correspondent pas.

Exemple : Knight Force, Dick Tracy, Wild street, Frank bruno Boxing.

Ces softs utilisent soit des blocs de flux de bits, soit de la donnée MFM. Les blocs de données classiques ne peuvent pas contenir ce type d'information.

Les blocs DRB sont uniquement utilisables dans des cas spéciaux, dans lesquels les blocs ne contiennent PAS de données de quelque type que ce soit. Et j'ajouterais utilisables seulement par des experts qui savent ce qu'ils font et quelles données ils mettent dedans.

Dans ton cas, tu y mettrais des données simplement parce que c'est facile et peu couteux. Mais ce n'est pas le but recherché.



Parce que chaque type de bloc a été crée dans un but particulier.

Les blocs standard et turbo bloc servent à encoder les blocs basic ou binaire standard, encodés avec la ROM de l'amstrad.

Les blocs pure data servent pour les jeux qui ont des blocs principaux n'utilisant pas de timing (aucun pilot tone, et consorts).

On détermine son usage si le loader se met simplement en écoute. En gros, le loader s'apprête à avaler ce qu'on va lui présenter venant de la bande en terme de 0 et 1.

Les blocs pure tone servent à encoder les clés de protections de certains logiciels comme indiqué plus haut.

L'utilisation de ce type de bloc se justifie à partir du moment ou la clé ou le bloc spécial ne contient pas de données.



Ce n'est pas notre cas. Le bloc pure tone a été choisi parce qu'il est le seul correspondant à la description :
1) ne contient pas de données
2) Parce que le bloc DRB ne doit être utilisé que pour stocker de la donnée spéciale (flux de bit ou MFM).
La clé qui nous concerne ici n'est PAS composée de données en flux de bit ni MFM. C'est un son audio digital.
3) le loader de la clé n'attend pas de données, mais d'une longueur de pulses et d'un nombre de pulses dans une durée de temps fixe dans le temps.



votre implémentation pour le format WAV est bonne. Pas de problème de ce côté là, j'ai pu le tester moi-même.



Votre implémentation a un problème. C'est pas normal que votre z80 émulé plante sur le chargeur binaire encrypté alors que la détection FDC passe, que le test de la multiface passe, et que le test de la rom passe.

quelque chose ne se fait pas correctement, pourquoi en CDT le dit chargeur plante, qu'est-ce que ton débugger indique si tu breakpointes le truc ?



C'est un syllogisme. Ton implémentation WAV est bonne, pas celle du CDT. La translation que vous en faites est erronée, et je ne comprends pas pourquoi le chargeur binaire encrypté planté.

Ce chargeur n'est pas protégé côté timing, ça aurait pu être ça, mais c'est pas le cas. Le problème vient des données soit remontées soit translatées du CDT vers le z80 ou tout autre partie.

Mais quoi ? Tu n'as pas le choix, il faut y aller au débugger.



absolument, c'est pour cette raison que ce format a été crée. Le format CSW ou même WAV sont des formats de travail, mais pas des formats définitifs.

Le problème du format DSK est que pendant longtemps l'émulation du FDC sur CPC était proprement pourrie, limitée au strict minimum, ce qui a donc amené à simuler certaines protections, car les auteurs d'émulateurs rechignaient à émuler cette puce correctement, j'invente pas le truc, c'est Simon Owen qui me l'a dit le jour ou je lui ai dis que je ne comprenais pas pourquoi un certain nombre de protection étaient simulées.

Le format Cassette, est beaucoup plus simple en terme de protection. On peut varier les plaisirs, mais ça reste quand même très cadré par rapport à ce qu'on peut faire. Il a donc été très facile de créer le système tournant autour du CDT. Le truc c'est que ça nécessite une implémentation forte et plus complexe que celle visant à implémenter la lecture sur la pin du PPI, c'est la contrepartie du système. Tout les systèmes de protection peuvent être supportés, mais voilà, l'émulation à côté doit tenir la route.

A la grande époque, les masters n'étaient pas des fichiers CSW ou WAV, ça pesait trop lourd. Les duplicateurs utilisaient un format compact comme celui du CDT, bien plus simple à transporter sur une seule disquette et à passer ensuite dans un utilitaire spécial via un PC qui envoyait directement le contenu sur bande.



ça ne pose aucun problème, j'ai pu généré sans souci des IPFs tirés de conversion de fichiers SCP. L'auteur du HxC n'aurait pas mis ça en place si ça ne pouvait pas marcher.

J'ai testé et c'est fonctionnel. Non le vrai souci c'est les gens qui dumpent des disquettes pourries, avec de la crasse dessus. Avec le SCP, ça passe quoi qu'il arrive, il ne stoppe pas en indiquant que le dump est merdeux.

Même Drew est d'accord sur ce sujet, une disquette pourrie donnera un dump pourri. C'est pas parce que c'est le SCP que ça change quoi que ce soit au problème.

Et l'histoire de la précision, entre nous soit dit, ça n'apporte rien de particulier en plus. C'est juste mieux que moins et ça s'arrête là.



Ben y a pas vraiment de plus value en soit. Le système de génération d'IPF est carré. C'est soit tu lui fournis un dump niquel, et tu peux générer un IPF, soit tu lui mets un dump pourri ou miteux, et là il t'envoie simplement chier, et tu n'es pas autorisé à générer de la merde. Il y a un garde fou

_________________
SPS Community Expert (SPS CE) / SPS France

Bon, j'ai pu mettre en place la sauvegarde en wave sur mon ému après lecture wave ou cdt et donc depuis les données PPI (longueur de pulse/0 ou 1).

Si je compare le wave avec la clé digitale rajoutée par César et le wave généré à partir du cdt :

-> La différence notable est l'interprétation de la clé digitale !

En effet, la clé digitale est traduit en plusieurs pulses de longueurs différentes...
alors que lors de l’interprétation du cdt, on a des pulses de même longueur...c'est normal, c'est ce qu'on a fait avec le pulse tone !

L'erreur également, c'est de penser que le loader de Rat et le même que Marmelade et attends la même chose... je n'en suis pas persuadé du tout !!!

-> Un test intéressant à faire serait de générer le wave depuis le CDT, et de copier/coller la clé digitale (du wave avec la clé digitale rajoutée par César) à la place de l'autre et voir si le wave obtenu fonctionne !?
Je ne sais pas si quelqu'un peut le faire ? car avec Audacity, je peux pas générer de wave 8 bit !