Au sujet des IPFs : Nous parlons ici du container, bien sur (c'est le sujet). Le fait d'en faire un outil de préservation numéroté est un autre sujet (mais le format parait bien évidemment parfaitement adapté). Vu que le format présente tout ce que l'on souhaite, pourquoi ne pas le généraliser ?
Au sujet des read sector : Il faut bien comprendre comment se passe un read sector. Lorsque l'en-tête est lue et trouvée (elle correspond à la commande), la lecture début. Pour celle-ci, on se resynchronise à nouveau (12 série de 0x0, 3 fois 0x4489, plus le fameux F8/FB ) et on va lire autant d'octet que l'indique la taille. Soit 0x200 pour une taille 2, etc.... Et donc, potentiellement 0x2000 pour un secteur 6. Vu que 8192 octet, ça ne tiens pas sur une piste, on va passer le trou d'index et retourner les datas en début de piste, jusqu'à concurrence de ce qui est demandé.
Pour le read track, effectivement il y a un bug : Si le pattern du C2 (0x5224) est trouvé, le FDC se resynchronise dessus. Ce qui peut poser problème, vu que ce pattern peut exister en dehors de la synchro de début de secteur ! A priori, par contre je n'ai jamais vu cette protection sur CPC.
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Lone a écrit :
Au sujet des IPFs : Nous parlons ici du container, bien sur (c'est le sujet). Le fait d'en faire un outil de préservation numéroté est un autre sujet (mais le format parait bien évidemment parfaitement adapté). Vu que le format présente tout ce que l'on souhaite, pourquoi ne pas le généraliser ?
Au sujet des read sector : Il faut bien comprendre comment se passe un read sector. Lorsque l'en-tête est lue et trouvée (elle correspond à la commande), la lecture début. Pour celle-ci, on se resynchronise à nouveau (12 série de 0x0, 3 fois 0x4489, plus le fameux F8/FB ) et on va lire autant d'octet que l'indique la taille. Soit 0x200 pour une taille 2, etc.... Et donc, potentiellement 0x2000 pour un secteur 6. Vu que 8192 octet, ça ne tiens pas sur une piste, on va passer le trou d'index et retourner les datas en début de piste, jusqu'à concurrence de ce qui est demandé.
Pour le read track, effectivement il y a un bug : Si le pattern du C2 (0x5224) est trouvé, le FDC se resynchronise dessus. Ce qui peut poser problème, vu que ce pattern peut exister en dehors de la synchro de début de secteur ! A priori, par contre je n'ai jamais vu cette protection sur CPC.
ah mais pour sur, j'aurais aimé voir par exemple une piste de protection copylock sur un Amstrad CPC, le délire !
Mais c'est vrai qu'il y a aussi les pistes sans aucun secteurs, comme celles de maupiti islands, permettant de stocker un maximum de données par pistes. Sur Maupiti ST, y a 5842 octets de données sur 79 pistes, et surtout le jeu comporte un bios custom permettant de faire du read track en gestion de données
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Techniquement sur un FDC 765, je crois qu'il faut au moins un bloc secteur pour que le read track commence... sinon, on a une erreur 'Cylinder not found' sans cela !
du coup, je pense que c'est pour cela qu'on voit que des secteurs de 8192 (qui sont tronqués) mais qui permette de mettre un maximum de données par piste... mais il suffit alors de le lire en read secteur classique...
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Megachur a écrit :
Techniquement sur un FDC 765, je crois qu'il faut au moins un bloc secteur pour que le read track commence... sinon, on a une erreur 'Cylinder not found' sans cela !
C'est possible. Ce FDC qui est le même que celui du ST fait principalement du read track pour vérifier une piste de protection. Maintenant, pour faire de la gestion de données à la maupiti, j'ai encore jamais vu ça.
Citer :
du coup, je pense que c'est pour cela qu'on voit que des secteurs de 8192 (qui sont tronqués) mais qui permette de mettre un maximum de données par piste... mais il suffit alors de le lire en read secteur classique...
tu as à moitié raison et tort en même temps. les secteurs de 8192 octets n'existent pas en tant que tel.
Si tu fais allusion aux pistes speedlock, entre autre, ce sont des pistes écrites en mode write track. On a un bout de secteur de 512 octets, suivi de 5872 octets mis dans une énorme zone GAP. Si tu cherches à copier ça, comme le CPC sait pas gérer en écriture les zone GAP, dans le c*l lulu !
Samdisk stocke directement le contenu de ces pistes dans 1 seul secteur de 6k, mais c'est pas comme ça sur les disquettes originales. Tu peux pas stocker ce type de pistes en mode sectoriel à l'identique de ce que tu as dans une disquette originale.
_________________ SPS Community Expert (SPS CE) / SPS France
Le problème de la duplication des secteurs taille 6 n'a rien à voir avec la zone GAP. A priori, rien n'empêche l'écriture d'un secteur de taille 6.... Sauf que lors de l'écriture, on va venir écraser l'en tête de secteur après avoir fait le tour de la piste.
J'imagine qu'on doit pouvoir trouver des manips pour le faire (à base d'interruption volontaire de l'écriture au bon moment par exemple) mais ça ne semble pas trivial.
Tu as des infos (précises) sur Maupity ? J'avoue que je suis curieux de voir à quoi ça peut ressembler.
Le problème de la duplication des secteurs taille 6 n'a rien à voir avec la zone GAP. A priori, rien n'empêche l'écriture d'un secteur de taille 6.... Sauf que lors de l'écriture, on va venir écraser l'en tête de secteur après avoir fait le tour de la piste.
J'imagine qu'on doit pouvoir trouver des manips pour le faire (à base d'interruption volontaire de l'écriture au bon moment par exemple) mais ça ne semble pas trivial.
Tu as des infos (précises) sur Maupity ? J'avoue que je suis curieux de voir à quoi ça peut ressembler.
On peut les copier, non pas en arrêtant l'écriture, mais en arrêtant le moteur! C'est ce que fait disc+ultra depuis 1989, ça fonctionne plus ou moins bien, selon les lecteurs!
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Lone a écrit :
Le problème de la duplication des secteurs taille 6 n'a rien à voir avec la zone GAP.
L'amstrad ne peut pas écrire les infos stockées en zone GAP. Tu me parles des secteurs de taille 6 tel que Samdisk les stocke, moi je parle de leur stockage réel sur les vraies disquettes, pas de leur interprétation secteur faite par Samdisk.
Citer :
A priori, rien n'empêche l'écriture d'un secteur de taille 6.... Sauf que lors de l'écriture, on va venir écraser l'en tête de secteur après avoir fait le tour de la piste.
Ce que tu dis est uniquement vrai à partir d'une disquette originale. On peut copier sans aucun souci un secteur de taille 6 depuis un DSK, parce que ce n'est pas sauvé dedans comme c'est écrit sur une disquette originale.
Le stockage secteur dans les DSKs fait disparait complètement le principe de la protection speedlock, à savoir un secteur de 512 octets tronqué suivi directement du reste des données dans une immense zone GAP.
C'est à cause de ce principe que les disquettes originales ne sont pas (entre autres copiables) avec un CPC standard.
C'est simple : si un PC utilisant le même controleur disque qu'un CPC peut écrire un secteur de taille 6 provenant d'un DSK sans artifice, un CPC peut le faire de la même manière.
Citer :
J'imagine qu'on doit pouvoir trouver des manips pour le faire (à base d'interruption volontaire de l'écriture au bon moment par exemple) mais ça ne semble pas trivial.
tout dépend de quoi tu pars. Si tu pars d'une disquette originale, alors oui, comme les pistes sont celles originales speedlock, oui tu auras besoin d'un moyen hardware pour les copier.
Si tu pars d'un fichier DSK, que tu graves avec samdisk depuis un PC, les secteurs de taille 6 interprétés s'écriront sans aucun problème.
Citer :
Tu as des infos (précises) sur Maupity ? J'avoue que je suis curieux de voir à quoi ça peut ressembler.
tiens voilà comment une piste de Maupiti sur Atari ST est constituée :
Les deux disquettes font 80 pistes, double face.
Piste 1, Face 1: 9 Sectors, pas de système de fichier. Le secteur de boot charge les 8 secteurs restants de la piste, lesquels contiennent le “BIOS custom”. Le développeur a crée une erreur décalée de 1 et essaie de charger 9 secteurs en commençant au secteur 2. De ce fait l'appel Floprd() foire… Mais ça ne fait pas partie de la protection.
Piste 79, Face 2 sur le Disque B contient aussi 9 secteurs, qui sont utilisés pour sauver l'état en cours du jeu.
Le reste de ces disquette ne contient aucun secteur. Les pistes sont lues avec la commande read track et chaque piste utilise le format suivant:
24 * $4E 12 * $00 3 * $A1 $FE $07 numéro de piste $07 checksum octet de poids fort $07 checksum octet de poids faible $07 5842 octets de données $4E répété jusqu'à la marque d'index
Le programme ne cherche que deux $A1 en début de piste, suivi par $FE. Il teste également le numéro de piste (ça doit correspondre à la position de la tête, le bit 7 est parametré pour la face 2). Le checksum est un word non signé, qui est calculé en y ajoutant les 5842 (unsigned) octets de données. Le checksum est également testé.
Parce que les octets de données peuvent contenir n'importe quel octet de $00 à $FF ça ne peut pas etre écrit par un FDC standard, lequel ne peut pas écrire les octets comme $F5 ou $F7.
Cependant le FDC a un bug dans le read track, lequel essaie de se synchroniser en permanence et certains octets peuvent activer la synchro, laquelle ira détruire les octets qui suivent derrière. Pour éviter ça, une méthode très simple et très efficace a été utilisée: un octet $07 précède tout octet qui pourrait resynchroniser le FDC (Claus Brod a écrit un super article à ce sujet). C'est aussi la raison pour laquelle on a ces octets dans le header de la piste!
Et voilà. Efficace, une très grosse capacité de stockage par piste et impossible à copier.
(traduit de l'anglais)
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Coucou à tous !
Je voudrai signaler des .dsk non valides qui datent 1er août posté par notre ami dlfrsilver :
Birdie (F) (1987) [Original].dsk et Multicours 6e (F) (Face 1A) (1988) (1. Francais - Don Quichotte) (CPM) [Original] [COMPILATION].dsk
La protection KBI n'est pas conforme sur le .dsk...à l'originale = le .raw !
ci-joint deux fichiers qui le prouve : un dump des pistes en hexa du dsk reconstitué et l'autre idem du .raw (Birdie_Ere.raw).
Pièce jointe :
Birdie (F) (1987) [Original]_dump.dsk
Pièce jointe :
Birdie_Ere_dump.raw
il faut aller voir à la fin la dernière piste... secteur 73 octets de longs sur le .dsk qui manque les infos "KBI" dans les entêtes entre les 0x4e !!!
En effet, j'ai implémenté la lecture des CAPS .raws dans mon émulateur. J'ai pas encore finaliser la suppression des mauvaises données lues sur certaines révolutions mais sur birdie, pas de problème, on a le dump d'une piste complète de bonne et mon émulateur lit sans pb le .raw alors que le .dsk non ! comme j'ai pas l'ipf, je ne peux pas le comparer avec !?
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 108 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
!
