| ★ CODING ★ FDC ★ À LA DÉCOUVERTE DU FDC – ÉPISODE 3 ★ |
| A la découverte du FDC épisode 3 (Roudoudou) |
Dans l'épisode 2, je vous racontais que Discology essayait de rater la lecture d'un secteur pour trouver le début de la piste, afin de récupérer les secteurs lisibles dans le bon ordre. En effet, la fonction GetID renvoie le premier secteur trouvé et on ne peut jamais savoir où on va démarrer sur la piste.L'analyse de piste Il faut savoir que Discology joue avec le feu en utilisant cette méthode car le premier appel à l'instruction GetID ne déroge pas à la règle de lenteur des instructions de lecture/écriture du FDC : elle est lente, entre 1980 et 3900 nops soit le temps que le FDC survole jusqu'à 120 octets de données sur la piste. Heureusement pour Discology, l'entête d'une piste écrite par un FDC fait presque toujours 146 octets. La raison est assez simple, un FDC standard qui formate une piste écrira 80 octets de GAP, 16 octets de synchro+identification et enfin une nouvelle GAP avant l'entête du premier secteur. Ainsi il n'y avait plus qu'à dérouler des GetID et compter les nops en fonction de la longueur de piste configurée pour lire tous les secteurs dans l'ordre. Sur la capture ci dessous le réglage maximum de longueur de piste.
Quand la fiction devient réalité Si les premières protections ont été créées sur CPC, les meilleurs système anti-copie viennent de créations industrielles sur des machines dédiées qui n'ont rien à voir avec le CPC. Les éditeurs envoyaient leur master qui était injecté dans la machine traceuse mais l'opérateur pouvait modifier certains paramètres comme augmenter la taille de GAP d'un seul secteur de la piste, modification anodine qui rendait la copie impossible.
Pour la création d'une protection plus évoluée, l'opérateur devait créer un script dans le format FreeForm, associé à un logiciel propriétaire qui permettait de définir bit à bit la piste. Un réglage fin sur la vitesse moteur permettait aussi de tasser les bits sur le tour de piste, pratique pour dépasser la capacité théorique de 6250 octets. Plus sale, on s'apercevait rapidement que l'entête piste ne servait à rien. On gagnait alors 146 octets à le supprimer. Enfin, les données du dernier secteur pouvaient même chevaucher le trou d'index (le secteur taille 6 de Fighter Bomber déborde de cette façon et rebique dans la GAP pré-sectorielle). Ci-dessous le début du dump IPF de la deuxième piste. Les données terminent sur 72 octets, suivie d'une énorme GAP de 76 octets. les 12 octets de synchronisation et le reste de l'entête surligné dans lequel on repère les informations secteur (piste 01/tête 00/ID C1/taille 06).
Au petit jeu de celui qui en mettra le plus, il est possible de s'amuser à dépasser les spécifications du FDC et mettre un peu plus de 64 secteurs (32 max théorique, 25 max réel) dépourvus de données. Une telle protection existe depuis 1986 que l'on retrouve sur les jeux 2112 AD , N.E.X.O.R. , Time and Motion, Working Backwards ainsi qu'une compilation. En recréant cette protection, j'ai découvert un amusant message dans Discology (peut-être uniquement le fruit de la traduction ?), et aussi vu qu'il ne plantait pas ! Attention, trop de secteurs sur Disc+Ultra vous amènera directement au reset !
Si Discology ne peut pas tout copier, on remarque quand même qu'il ne rate aucun secteur malgré que ma protection soit une suite continue d'entêtes. Je vous disais en préambule que seul le premier appel de GetID était lent. Mais le premier, ça veut tout dire et rien dire non ? L'optimisation interne du GetID Lors de mes tests de l'instruction GetID, mon programme envoyait deux instructions à la suite. J'ai rapidement remarqué que le premier appel était toujours lent, suivi d'un second rapide. => #4A [#10,#10,#10,#10,#10,#10,#10,#10,#10,#90] |
|
