Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Megachur a écrit :
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 !
Citer :
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 !!!
Les deux sont pareils, à un détail près, la vitesse de chargement.
Si César avait vu une grosse différence, il me l'aurait dit. Ici la seule chose qu'il a remarqué, c'est que Rat utilise une vitesse de chargement plus élevée.
Citer :
-> 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 !?
1) j'ai déjà généré un wav depuis le CDT 2) César n'a pas rajouté de clé digitale, elle était là à l'origine sur la cassette.
Je n'ai plus le WAV brut non fonctionnel d'origine, car j'ai fait ce jeu morceau par morceau (la cassette étant en mauvais état).
Citer :
Je ne sais pas si quelqu'un peut le faire ? car avec Audacity, je peux pas générer de wave 8 bit !
Audacity n'est pas adapté à cet usage. Seul Goldwave donne le visuel voulu (et possède les options qui vont avec !).
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
@dlfrsilver :
j'ai l'impression qu'on parle toujours pas des mêmes fichiers !!!
je t'ai mis un zip avec :
le wav qui est ok (avec la clé digital copiée par César) le cdt qui est sur cpc-p0wer. le wav généré avec CDT2WAV 1.5 à partir du cdt sur cpc-p0wer !
en comparant c'est 2 waves... je ne trouve pas du tout la même chose :
dans le 1er wave la clé digitale est généré 31 ms avant par rapport au deuxième wave ! bon, c'est pas forcément bloquant mais... au lieu de 119ms, elle fait 347ms de long -> ça, ça l'est ! au lieu de 717ms entre la clé et les datas, on a 900ms (cela a été corrigé dans le deuxième CDT que tu as posté ici (cf ci-dessous) la dernière zone de data est beaucoup plus courte dans le deuxième wave (même durée de pulse ?) !?
si je prends le wave du dernier cdt que tu as fait new_Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].cdt que as posté !
la clé digitale est encore plus longue que l'original -> 440ms
donc ce que souhaiterait c'est un cdt qui correspond à l'original en terme de durée de clé = 119ms !? et idem pour les datas qui suivent (si c'est possible ?) !
-> après je pourrai regarder dans le code z80 pourquoi le wave passe mais pas la cdt -> qui donnera dans cas le même wave une fois converti avec CDT2WAV et ce qui n'est pas le cas pour l'instant avec le cdt !!!
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Lors de la conversion du WAVE en CDT de cette clé, je me demande donc comment un pulse de valeur 0x80 est traduit car s'il est traduit comme un "0" alors cela pourrait expliquer pourquoi le même loader plante à ce moment ?!
Lors de la conversion du WAVE en CDT de cette clé, je me demande donc comment un pulse de valeur 0x80 est traduit car s'il est traduit comme un "0" alors cela pourrait expliquer pourquoi le même loader plante à ce moment ?!
Ben le truc c'est qu'avec CPCemu ou Sugarbox, j'arrive même pas jusque là. Le chargement plante sur les premiers blocs
Je serais donc bien incapable de te répondre de ce fait.
_________________ SPS Community Expert (SPS CE) / SPS France
Lors de la conversion du WAVE en CDT de cette clé, je me demande donc comment un pulse de valeur 0x80 est traduit car s'il est traduit comme un "0" alors cela pourrait expliquer pourquoi le même loader plante à ce moment ?!
Ca ne me parait pas si illogique (que ça ne marche pas) : La valeur mid est bien 128 (0x80) sur un wav : On est en char non signés. Du coup, si tu mets 127 comme 0, à ce moment là toutes tes pauses vont devenir des "1", ce qui n'est sans doute pas prévue dans la protection. Pas gênant sur un bloc standard (vu qu'on parle de transitions), mais sur un calcul de pause, si.
@Denis : Note bien que ce fameux WAV fonctionne sur nos deux émulateurs, mets-y donc un peu du tiens !
Lors de la conversion du WAVE en CDT de cette clé, je me demande donc comment un pulse de valeur 0x80 est traduit car s'il est traduit comme un "0" alors cela pourrait expliquer pourquoi le même loader plante à ce moment ?!
Ca ne me parait pas si illogique (que ça ne marche pas) : La valeur mid est bien 128 (0x80) sur un wav : On est en char non signés. Du coup, si tu mets 127 comme 0, à ce moment là toutes tes pauses vont devenir des "1", ce qui n'est sans doute pas prévue dans la protection. Pas gênant sur un bloc standard (vu qu'on parle de transitions), mais sur un calcul de pause, si.
@Denis : Note bien que ce fameux WAV fonctionne sur nos deux émulateurs, mets-y donc un peu du tiens !
Je ne suis pas programmeur, la pour moi c'est du chinois.....
_________________ SPS Community Expert (SPS CE) / SPS France
--> le programme mesure la valeur exacte et il faut donc que hl soit = 048c si pas ok, reset !
donc avec wave ok, j'obtiens bien cette valeur donc ok on passe à la suite !
avec le CDT ( 1018 pulses pour le pure tone)
Rat Connection (version cpc-p0wer) hl(exde): 04B6 de(exhl): 0162 -> reset
ou dernière version de dlfrsilver avec pause=717 hl(exde): 04D1 de(exhl): 0162 -> reset
j'ai modifié par exemple la longueur du pure tone ou de la pause pour ces deux cdts, on passe le code quand hl=048c mais après on ne charge pas les data (border rouge ou vert)...il y a peut-être aussi ensuite un contrôle du contenu de la clé ou des datas ?!
@dlfrsilver : est-ce que César a pu analyser cela également ?
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Megachur a écrit :
Bon, histoire de ne pas s'endormir, j'ai fait une séance de débug ce matin...
et voilà en tout cas la différence que j'ai pu pister
voici le code qui est à la sortie de la séquence pure tone + pause (avant le dernier bloc pure data) !
Juste une question, tu as fait le débug à partir du CDT ou bien du WAV ?
Car le WAV fonctionne, pas de souci.
Mais il y a une incohérence ici :
Tu peux m'expliquer comment tu arrives à obtenir le code en sortie de la séquence pure tone alors que ton émulateur et celui de thomas plantent sur le premier loader crypté en début de cassette ?
Ces informations là tu n'es censé les avoir que si le dit loader s'est correctement chargé. Hors j'ai vu jusqu'ici que le CDT n'arrive pas jusqu'à ce point là.
--> le programme mesure la valeur exacte et il faut donc que hl soit = 048c si pas ok, reset !
donc avec wave ok, j'obtiens bien cette valeur donc ok on passe à la suite !
Le problème n'est pas côté WAV, mais côté CDT, il faut donc débugger à partir du CDT.
Citer :
avec le CDT ( 1018 pulses pour le pure tone)
Rat Connection (version cpc-p0wer) hl(exde): 04B6 de(exhl): 0162 -> reset
ou dernière version de dlfrsilver avec pause=717 hl(exde): 04D1 de(exhl): 0162 -> reset
j'ai modifié par exemple la longueur du pure tone ou de la pause pour ces deux cdts, on passe le code quand hl=048c mais après on ne charge pas les data (border rouge ou vert)...il y a peut-être aussi ensuite un contrôle du contenu de la clé ou des datas ?!
C'est parce que tu n'as pas pris le problème à la source.
Je vais te schématiser le fonctionnement et le suivi du programme par rapport à ce que César m'a expliqué :
- La cassette débute par 4 blocs, dont chaque header est "illégal", ou en anomalie. Le contenu des deux blocs est crypté.
- Quand le jeu se charge, les 4 blocs sont lus, puis le programme d'amorcage (boot loader) est décrypté après le passage des plusieurs routines anti-hacking.
- Le programme se sert de la pause située à la fin du quatrième bloc comme 'timer'. Ce temps de pause permet au z80 de procéder au décryptage du programme d'amorçage, ainsi que du premier loader protégé. le programme affiche alors "le programme est chargé".
- Le premier loader se met alors en mode écoute et attends la clé digitale avec les bons paramètres.
- Si la clé digitale est correcte, elle sert de clé de décryptage pour le second loader qui se trouvent après le premier loader (celui qui charge la clé), qui lui-même se trouve après le programme d'amorçage.
- Une fois la clé digitale lue, la pause qui est juste après sert de 'timer', le z80 prend de nouveau la main, et décrypte le second loader, qui lui va se mettre en écoute (le gros bloc n'a aucun timing ni pilot tone, c'est de la donnée pure), pour lire en mode brut le gros bloc de donnée.
En mode simple :
1) Chargement des 4 blocs de démarrage crypté et protégés 2) Passage et tests anti-hacking 3) Le z80 décrypte le programme d'amorçage et le premier loader pendant la 1ère pause 4) Le 1er loader est décrypté, et lit dès la fin de la pause la clé digitale 5) Si la clé digitale est bonne, le z80 procède au décryptage du second loader pendant la pause qui suit la clé. 6) Si la clé digitale est incorrect, ou si la pause qui la suit n'est pas de la bonne longueur, reset ! 7) Si tout s'est bien passé, le second loader est décrypté, et le border passe en couleur rouge ou rose suivant le jeu, et le chargement du gros bloc démarre.
Sous sugarbox, le chargement avec le CDT ne dépasse pas l'étape 1. L'émulateur plante à la fin de la lecture du 2ème bloc. CPCemu va un peu plus loin, mais plante à la fin de la lecture du 4ème bloc.
Tu comprends pourquoi je dis que tu prends le problème à l'envers ?
Ni Sugarbox ni CPCemu n'arrivent jusqu'à la clé quand on utilise le CDT.
Citer :
@dlfrsilver : est-ce que César a pu analyser cela également ?
Oui césar a analysé tout le loader de A à Z. Le problème est que le second loader c'est du code hyper long en spaghetti, et avec un entrelacement de code en clair et de code crypté.
Il n'a pu pour cette partie que "trapper" les accès à la cassette, qui indiquent simplement que le CPC se met en mode "écoute", et utilise une routine de chargement custom.
Pour info, c'est une méthode connue sur amiga (Frédéric Sol est en effet un Amigaiste avant tout).
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
@dlfrsilver: avant de te lire en détail... il y a juste un truc que je comprends pas : est-ce que tu as bien essayé la dernière version de CPCEmu que j'avais envoyée ?
Parce que moi, j'arrive sans problème à passer le pure tone/pause/pure data pour le wave qui marche. et pour la dernière cdt, le loader lit le pure tone/pause jusqu'au début du pure data !!!
C'est pour cela que je dis qu'en mode débug, j'ai bien vu que la valeur de HL calculé par le loader est &048c pour le wave qui marche et que pour les cdts, cette valeur est différente (plus grande exactement par exemple &04B6).
Avant ta réponse, cela va être compliqué d'aller plus loin...parce que j'ai l'impression qu'on a pas la même version de l'émulation ?!
Citer :
- Le programme se sert de la pause située à la fin du quatrième bloc comme 'timer'. Ce temps de pause permet au z80 de procéder au décryptage du programme d'amorçage, ainsi que du premier loader protégé. le programme affiche alors "le programme est chargé".
avec le wave de Rat Connection qui marche, je constate juste que le programme passe en couleur bleue puis en couleur noire (border et écran) et efface le message "le programme se charge veuillez patienter" par des espaces ! Ensuite on a plusieurs changements de couleurs (border rouge et fond gris) puis border jaune et bleu puis border vers et rose lors du chargement des données écran et programme
je n'ai pas vu de routine afficher "le programme est chargé" contrairement à Marmelade qui affiche "le code est chargé" !!!
cf image Rat_01.png avec le message, Rat_02.png avec le message efface et les autres jusqu'au début du loading du 5ième bloc de donnée (image d'écran + programme)
je mets le bout de trace de code que j'ai faite :
Code :
hl: 0000
1CA6:LD A,H 1CA7:OR L 1CA8:JP Z,&1CAE 1CAB:JP &2097
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
oui effectivement un des deux affiche le message mais pas l'autre, par contre, la mécanique interne est la même.
Je vais tester avec ton dernier CPCemu (je l'ai mis sur mon disque dur).
EDIT : j'ai un problème sur cette dernière version que tu m'as envoyé par mail. Le FDC n'est pas coché, par contre quand je lance l'émulation 464 en 64k, et que je fais RUN", il me répond BAD COMMAND, ce qui veut dire que le FDC est toujours actif !!! Et qu'il attend la commande |TAPE pour active la cassette.
_________________ SPS Community Expert (SPS CE) / SPS France
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 22 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
