Elle est pas jolie la piste de 32ko ? Et les secteurs anormaux même sur la piste 0 ? Winape renvoie un message d'erreur, winCPC aussi, y a que CPCE qui affiche correctement le catalogue.
Avant de lacher le dump sur le net, je vais le soumettre à Simon Owen, le papa de SAMDISK. Il va l'examiner et ensuite, dira si je dois le redumper ou si les émulateurs doivent être mis à jour.
PS : Je vais le redumper, je sais pas pourquoi, mais on dirait qu'il y a du GAP DATA MARKING dans les inter-secteurs.
Je vous tiens au courant !
_________________ SPS Community Expert (SPS CE) / SPS France
Est-ce que tu veux dire que SAMDISK nous donne toutes les infos sur la disquette, alors qu'avec Hercule (désolé j'utilise pas Discologie) il faudrait associer les infos du copieur (organisation et taille des secteurs) avec les infos de l'analyseur de disquette pour obtenir les 3 flags de retour FDC, voire même lancer l'instruction LirePiste pour voir le contenu des Gaps ?
C'est ca ? Si oui, ça peut être bien pratique quand on veut cracker une protection...et ça tourne sur CPC...ou que sur PC (où malheureusement la protection a pu en partie sauter à cause du DSK) ?
Et on peut le trouver où ce SAMDISK, avec le dico pour pouvoir comprendre ses logs ?
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Voici le commentaire de Kevin Thacker sur la protection du necromancien :
J'ai regardé le 'Necromancien'.
Pour supporter cette protection disc j'aurais besoin de ré-écrire mon émulation FDC, de façon à ce que les données des pistes au format RAW (MFM brut pour chaque piste). La piste 28 a plein de petits secteurs d'une taille de 256 octets. Les ID des secteurs sont en fait du code encrypté. Alors en premier lieu ceux-ci doivent être lu dans l'ordre (arnold le fait maintenant). puis les secteurs sont lus en utilisant la fonction read track, mais cette fois ci il lit les secteurs et les gaps et les autres données brutes MFM.
Je n'émule pas encore ça. Les dumps sont-ils bons? Je ne sais pas encore.
Après coup, au vu de ce que je lui ai dis, les zone GAPS sont dans le dump, donc c'est bon, reste le problème FDC.
En tout cas voici un exemple concret ou on voit bien que le CPC a des jeux qui utilisent des pistes MFM brutes ! Ici Rubi le roublard a rusé en faisant lire la piste 28 de 2 façon différentes, celle par Readtrack, et l'autre en lisant secteurs + gaps dans l'ordre. Les émulateurs ne supportent pas encore celà, mais ouf, kévin donnera les infos pour que les auteurs d'émus puisse l'incorporer
_________________ SPS Community Expert (SPS CE) / SPS France
Merci mais je n'y ai pas trouvé réponse à mes questions sur SAMdisk.
Il a l'air de tourner sur PC, mais sur PC il est déjà trop tard pour pouvoir gérer les disquettes originales (et même avec un lecteur d'Amstrad connecté directement sur le PC ce que je n'ai pas, comment garder le FDC original ?). Ou alors c'est qu'on est vendredi soir tard et que je suis trop fatigué pour comprendre Simon.
Quoiqu'il en soit ce que dit dlfrsilver est très pertinent, et je milite pour çà depuis longtemps: un format qui stocke les disquettes CPC dans les deux modes de lecture possibles: lire secteurs, et lire piste. Ensuite il faudra adapter les émulateurs, car si l'exécution d'un jeu lance la fonction lire secteur alors il faudra aller piocher dans le secteur, et si le programme lance la fonction lire piste (par ex pour récupérer des octets inter gaps ou n'importe quoi d'autre) il suffira d'aller piocher dans la zone du format qui contient le résultat du lire_la piste lu sur le CPC (donc forcément original par définition).
C'est pourtant de conception très simple, et ça fait des décennies que personne ne le fait... Bon ils font quoi tous ces gens pendant que moi je ne fous rien ?!?!!
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Citer :
Merci mais je n'y ai pas trouvé réponse à mes questions sur SAMdisk.
Il a l'air de tourner sur PC, mais sur PC il est déjà trop tard pour pouvoir gérer les disquettes originales (et même avec un lecteur 'Amstrad connecté directement sur le PC ce que je n'ai pas, comment garder le FDC original ?). Ou alors c'est qu'on est vendredi soir tard et que je suis trop fatigué pour comprendre Simon.
Si tu gardes le FDC d'origine, tu as les limitations d'origine...... Pour imager comme il faut les originaux, on a besoin d'une machine plus costaude qu'un simple CPC. Tu peux pas balayer une disquette en aveugle avec un CPC de base, sans compter qu'un CPC n'a pas assez de RAM pour contenir une disquette protégée entière (soit entre 250 et 500ko).
Citer :
Quoiqu'il en soit ce que dit dlfrsilver est très pertinent, et je milite pour çà depuis longtemps: un format qui stocke les disquettes CPC dans les deux modes de lecture possibles: lire secteurs, et lire piste. Ensuite il faudra adapter les émulateurs, car si l'exécution d'un jeu lance la fonction lire secteur alors il faudra aller piocher dans le secteur, et si le programme lance la fonction lire piste (par ex pour récupérer des octets inter gaps ou n'importe quoi d'autre) il suffira d'aller piocher dans la zone du format qui contient le résultat du lire_la piste lu sur le CPC (donc forcément original par définition).
Euh justement, tu n'as pas compris le système. On ne se heurte pas à un problème de stockage ou de données, on se heurte à un problème d'émulation : Le FDC est encore trop mal émulé, et mal implémenté dans les émulateurs, ensuite, l'émulation z80 est buggée, certaines instructions sont mal gérées en terme de timing, et les flags sont erronés.
Le souci rencontré sur le nécromancien vient du fait que les FDC actuellement ne savent lire en émulation que d'une manière. On en est encore à 'nann j'vous dis que le CPC ne fait QUE du sectoriel' ce qui est faux, résultat dans la pratique, c'est tout un mode de pensée qui est à revoir. le mode sectoriel ne s'applique principalement qu'aux jeux craqués ou non protégés, vous voyez ou je veux en venir ?
Avec l'émulation correcte du FDC, le contenu d'une piste du format DSK pourra enfin être lue telle que le FDC d'un CPC le ferait. En fait, et c'est subtil, on a d'un côté le format physique, avec les pistes composées de secteurs (qui peuvent être plombés au départ), et puis on a en face le FDC à qui on peut faire lire les données d'une manière différente de celle dont sont constistuées réellement les pistes.
Exemple :
Piste 40 Secteur 01 taille 256 zone GAP ...... Secteur 10 taille 256
J'ai fais au plus simple voilà le FORMAT de piste sur la disquette.
Maintenant je demande à mon FDC une lecture secteur pour vérifier les ID des secteurs pour les décoder, ainsi que les secteurs eux-même dans l'ordre :
et ainsi de suite. En mode secteur, ici dans notre cas du nécromancien, c'est le format physique tel quel qui est lu.
Par contre, une fois que cette premier lecture et vérification est effectuée, je demande à mon FDC de faire une lecture_piste (Read_track) en aveugle :
Kevin thacker m'a expliqué que cette piste, pourrait être annoncée et demandée en lecture au FDC comme étant composée de secteurs de taille 3 (2048 octets) alors que physiquement elle est composée de secteurs de taille 2.
Vous voyez le délire ? On peut faire faire au FDC une lecture physique du format, et aussi une lecture logique !
Ce qui veut dire qu'ici en admettant qu'il y ai des données en zone GAP entre tout les secteurs, la lecture physique marchera, secteurs par secteurs dans l'ordre, alors qu'avec un readtrack pour lire la piste de façon logique, et comme "utilisant" des secteurs de taille 3 logiques, si les données GAP sont absentes, alors il y a de la donnée absente, vous voyez le délire ? Et le jeu plante bien évidemment !!!
Citer :
C'est pourtant de conception très simple, et ça fait des décennies que personne ne le fait... Bon ils font quoi tous ces gens pendant que moi je ne fous rien ?!?!!
Kevin thacker travaille dessus.
_________________ SPS Community Expert (SPS CE) / SPS France
Oui, ça me rappelle des choses...cette ambivalence entre logique et physique.
1) Le cas standard: En général on formate physiquement 9 secteurs par piste en taille 2 (512Ko), et on les écrit en taille 2. Tout baigne. Une lecture logique d'un secteur renverra le contenu du secteur. Une lecture physique via un Lire_Piste renverra le contenu du 1er secteur, puis une zone de gaps entre le 1er et le 2ème secteur, puis le contenu du 2ème secteur, etc...
2) Cas non standard: Je n'y vois que 2 intérêts: créer une protection; ou arriver à stocker plus de données que les 9*512. Exemple: au lieu de 9 secteurs physiques de taille 512 avec une taille logique aussi de 512, on peut formater 18 secteurs de taille 256 avec une taille logique de 512: Secteur n°1, appelé &41, taille physique 256, taille logique 512 Secteur n°2, appelé &51, taille 256 Secteur n°3, appelé &42, taille 256, etc, etc
Rappel: on formate en taille 256 (dite "1"), et pour donner une taille logique de 512 (dite "2") il suffit de déclarer comme taille de secteur "2". Une simple déclaration, car la vérité de sa taille c'est 1. Simplement quand le FDC va lire le secteur déclaré en taille "2" il ne va pas aller vérifier si le secteur a été formaté en taille 1, mais va tout simplement aller lire 512 octets correspondant à une taille 2.
Poursuivons l'exemple: si je lis le secteur &41 formaté en 256 octets mais déclaré en 512, je vais récupérer des choses intéressantes: Octets de 1 à 256: je récupère le contenu (vide) du secteur. Octets de 257 à quelques dizaines d'octets après: je récupère la zone de GAP entre les secteurs &41 et &51 Ensuite: octets du contenu du secteur &51 Oui, en jouant sur les tailles déclarées des secteurs, en déclarant des grandes tailles, on peut récupérer les données des GAPs sans même avoir besoin de la fonction Lire_Piste !
Imaginons maintenant qu'au lieu de lire le secteur &41, je l'écris. L'ayant déclaré en taille "2" le FDC va écrire 512 octets. Cela va donc écrire les 256 octets du secteur &41, cela va écrire par dessus les GAPS séparant les deux secteurs &41 et &51, ce qui aura pour effet de faire disparaître le secteur &51 de la piste. Oui, on peut faire disparaître des secteurs en écrivant d'autres secteurs.
Il me semble que les résultats du FDC après une lecture (3 codes) permettent de détecter si la taille logique n'est pas en phase avec la taille physique.
3) Désynchronisation:Le fait d'écrire un secteur avec un banal lecteur d'Amstrad va "désynchroniser" la fonction Lire-Piste (défaut de magnétisation) qui renverra des octets qui ne sont pas les mêmes octets que ceux qui seront renvoyés par un lire_secteur. Donc toute protection élaborée sur Lire_Piste avec des secteurs écrits ne pourra pas être dupliquée avec un Amstrad, mais avec une machine plus précise. En fait, la grande majorité des protections Lire_piste travaillaient (probablement pour cette raison) avec des pistes dont on n'écrivait PAS les secteurs. Ou alors c'est mon lecteur qui déconnait ! Bon, voilà ce qu'il reste dans ma mémoire 20 ans après, j'imagine que la plupart d'entre vous se souviennent de tout çà, souvenirs, souvenirs...
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Beaucoup de protection CPC ont été ecrite sur Atari ST et PC. Ces machines ont la capacité d'écrire des pistes physiques infiniment plus longues qu'un CPC standard.
Exemple : La protection Alkatraz type 3 par exemple, utilisée sur la compilation les 12 jeux fantastiques de gremlin.
Il y a 8176 octets (1FF0$ en longueur) par piste. Pas besoin de préciser que ces pistes n'ont aucunes zones GAP. Y a juste 1 secteur plein à rabord dans la piste.
J'ai examiné le contenu par secteur avec SAMDISK, c'est un format PCW.
Sinon concernant Rubi, il avait je crois l'habitude d'utiliser un atari ST pour concevoir ses protections CPC.
Une protection comme celle du nécromancien ne peut être produite sur un lecteur de CPC.
Certaines protection sont bien logiques (vides de contenu pour certaines, mais pleines pour d'autres). dans le cas du nécromancien, tout les secteurs sont lus et contient de la donnée encryptée. Faire une piste de protection comme celle du nécromancien ça prend en taille 7000 octets.
D'autre protections sont vides, ne contiennent pas de données, mais contiennent un nombre impressionnant de secteurs. Nexor de design design utilise une piste de 32ko composée de 64 secteurs par exemple.
Citer :
3) Désynchronisation:Le fait d'écrire un secteur avec un banal lecteur d'Amstrad va "désynchroniser" la fonction Lire-Piste (défaut de magnétisation) qui renverra des octets qui ne sont pas les mêmes octets que ceux qui seront renvoyés par un lire_secteur.
Pas forcément, L'amstrad cpc est limité par la vitesse de rotation de son lecteur de disquette, certes, mais tant que les pistes ne sont pas trop longues, et pas trop trafiquées, ça pose pas de problème.
Y a pas de désynchro à proprement parler, la zone GAP est matériellement impossible à recopier sur un CPC. Ce qui veut dire que la copie secteur si la piste est d'une taille pas trop grosse tu pourras la copier, mais les données GAP n'était pas présentes sur la disquette copié, c'est baisé !
Citer :
Donc toute protection élaborée sur Lire_Piste avec des secteurs écrits ne pourra pas être dupliquée avec un Amstrad, mais avec une machine plus précise. En fait, la grande majorité des protections Lire_piste travaillaient (probablement pour cette raison) avec des pistes dont on n'écrivait PAS les secteurs. Ou alors c'est mon lecteur qui déconnait !
ça c'est pas vrai. Du tout. Tant que la protection n'utilise pas les zone GAP, pas de problème !
Tu mélanges le problème généré par les pistes qui sont trop longue, la protection par zone GAP, et la fonction de lecture du CPC. la plupart des protections qui utilisent la fonction lire_piste sont les jeux utilisant des pistes MFM, comme sur ST ou Amiga. En fait, comme dit plus haut, la protection Alkatraz type 3, utilise des secteurs gigantesques qui contiennent de la donnée. Mais la routine de lecture y accède via un trackloader qui fait forcément usage de la fonction brute Lire_Piste.
Le sectoriel n'est utilisé principalement que sur les disquette standard non plombées ou presque.
_________________ SPS Community Expert (SPS CE) / SPS France
Donc toute protection élaborée sur Lire_Piste avec des secteurs écrits ne pourra pas être dupliquée avec un Amstrad, mais avec une machine plus précise. En fait, la grande majorité des protections Lire_piste travaillaient (probablement pour cette raison) avec des pistes dont on n'écrivait PAS les secteurs. Ou alors c'est mon lecteur qui déconnait !
ça c'est pas vrai. Du tout. Tant que la protection n'utilise pas les zone GAP, pas de problème !
C'est peut-être que mon lecteur de disquette déconnait, mais je ne pense pas car je me souviens qu'un jour (sur ce forum ?) quelqu'un m'avait expliqué à quoi cela était dû (un "décalage électromagnétique").
Rappel des faits, et de cela j'en suis sûr, vous pouvez d'ailleurs faire un test si vous avez quelques minutes: 1) Formatter une piste avec octet de remplissage &E5 2) Lancer Lire_Piste (avec Hercule II, je sais pas si y'a la fonction Lire_Piste dans Discology?) 3) Regarder le résultat: on doit bien voir chaque secteur de contenu &E5, avec entre chaque secteur la zone de GAP 4) Ecrire le 1er secteur par exemple avec des zéros 5) Refaire un Lire_Piste 6) Regarder le résultat: je ne me souviens plus au sujet du contenu du 1er secteur et de la 1ère zone inter-secteur si elle est bien rendue par la fonction Lire_Piste ou non. Mais je suis sûr qu'au moins à partir du contenu du second secteur, l'on ne verra pas le contenu à &E5 (mais par exemple à &A3) et que les zones inter-secteurs auront elles aussi leurs valeurs perturbées (par exemple on ne retrouvera pas les fameux &4E des GAPs). Par contre la structure est maintenue: si on avait &4E &4E &4E 0 0 0, on aura bien 6 octets &51 &51 &51 &12 &12 &12, mais chaque octet est décalé. D'ailleurs, quelqu'un saurra peut-être nous dire s'il y a une règle précise de décalage par ex une rotation d'un bit sur la droite ou sur la gauche ?
En tous cas je vous encourage à faire le test, ça prendra 5 mn, si quelqu'un peut nous dire ce que cela donne! de mémoire le contenu du 1er secteur est bon (on voit des zéros
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 21 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
: 
