CODINGFDC ★ À LA DÉCOUVERTE DU FDC – ÉPISODE 4 ★

A la découverte du FDC épisode 4 (Roudoudou)
Dans l'épisode précédent, je donnais le détail du début d'une piste formatée en double densité par le FDC du CPC. Comme nous allons aborder l'instruction de formatage, je vais donner plus de détails sur la structure d'une piste CPC standard (en MFM, on stocke 2 fois plus de données avec la même densité de support physique SD). Le détail se trouve dans la doc du FDC765A de Nec. Nous c'est surtout la deuxième ligne qui nous intéresse !

- 80 octets de GAP 4a (valeur #4E) => c'est la GAP du début de piste
- 12 octets de synchronisation (valeur #00)
- 4 octets d'index address mark (valeur #C2,#C2,#C2,#FC)
- 50 octets de GAP 1 (valeur #4E)

Dès la fin de l'entête piste suivront les secteurs complets (entête, données, CRC et GAP 3). Quand on formate une piste, la taille réelle des secteurs est unique et c'est celle renseignée lors de la demande de focrmatage. Le FDC ne sait formater qu'une seule taille de secteurs à la fois !

- 12 octets de synchronisation
- 4 octets d'index data address mark valeur (#A1,#A1,#A1,#FE)
- 1 octet pour le numéro de piste (pas obligatoirement la vraie piste)
- 1 octet pour le numéro de tête (pas obligatoirement la vraie tête)
- 1 octet pour l'ID du secteur (le bon !)
- 1 octet pour la taille du secteur (pas obligatoirement celle du formatage !)
- 2 octets de CRC des 8 derniers octets
- 22 octets de GAP 2 (valeur #4E)
- 12 octets de synchronisation (valeur #00)
- 4 octets de data address mark (valeur #A1,#A1,#A1,#FB)

La quantité de données du secteur dépend de la taille spécifiée lors de la commande et non la taille déclarée pour le secteur. La taille déclarée du secteur présente dans l'entête sera utilisée plus tard pour la lecture et l'écriture du secteur mais pas lors du formatage.

- 2 octets de CRC sur les données du secteur et les 4 octets précédents
- x octets de GAP 3 (valeur #4E) dont la taille dépend de la commande de formatage

Enfin, quand tous les secteurs demandés sont écrits, le FDC complète la piste avec une GAP 4b de fin de piste dont la valeur reste #4E jusqu'au trou d'index. Cela évite de se retrouver avec d'anciens secteurs si la piste qu'on formate est plus petite que celle existante. On peut aussi noter que si on déborde un peu de la piste, cette GAP 4b peut écraser un peu la GAP 4a. Sur un Gotek qui ne traite que des octets, ça passe crème mais sur un vrai lecteur, on a une chance sur 16 de tomber juste, mais ce n'est pas grave !

Les GAP 4a, 1, 2 ont TOUJOURS la même longueur. La GAP 3 est paramétrable, c'est celle qu'on retrouve comme information de piste quand Discology copie une disquette en mode intégral. La GAP 4b complète la fin de piste jusqu'au bout.

Concrètement, comment est la piste ?

Les lecteurs de disquette CPC ont une vitesse de rotation d'environ 300 tours/min soit 1 tour tous les 1/5 de seconde. Le FDC lisant/écrivant 1 octet tous les 32 microsecondes, la division est facile : 200.000 / 32 = 6250 octets bas niveau sur un tour de piste. Parfois plus, parfois moins selon la vitesse réelle du moteur de votre lecteur mais dans le respect de la tolérance du FDC qui est de 12% soit de 220bits/s à 283bits/s pour une référence de 250bits/s, ces valeurs ayant été mesurées par mes soins à l'aide d'un Gotek parfait et d'une série de HFE modifiés.

Mais surtout, comme on le voit sur cette magnifique photographie magnétique, il y a peu de chance que le dernier octet tombe juste ! La précision requise pour un tel exploit demande un positionnement à l'octet MFM soit au minimum la moitié de 0.001%, plus probablement le 1/3 pour éviter d'avoir un random bit au trou d'index. Il n'est pas sûr qu'aujourd'hui un Kryoflux ou équivalent puisse écrire une piste avec une telle précision au trou d'index.


crédit : Matesy GmbH de Wikicommons / pulses magnétiques représentant les données sur les pistes

DATAAAAAAAAAA

Les utilisateurs CPC sont habitués à avoir 178K par face de disquette quand elle est formatée en DATA. Nombreux sont ceux qui – avec Discology – ont vu défiler les secteurs numérotés de #C1 à #C9 et une fameuse GAP 3 de taille #50 (soit 80 en décimal). 9 secteurs par piste de 512 octets. Une addition de tous les entêtes, GAP et données nous donne 146+9x(512+62+80)=6032 octets

On voit qu'il n'est pas facile de faire tenir 10 secteurs comme dans Imperial Mahjong ou Can Robot Take Control qui utilisent le même formatage. Le DSK pose d'ailleurs problème à l'écriture physique car la GAP fait #30 (48) et si on applique le même calcul, on trouve 146+10x(512+62+48)=6366 octets, Rhaaaaaaaa!!! (c) Longshot

Patchez moi cette infamie !

Dans Imperial Mahjong, les secteurs sont lus en ligne alors que dans Can Robot Take Control les secteurs sont lus un par un. De plus, si dans Imperial Mahjong les deux derniers paramètres de la commande de lecture sont à #01 (ce qui se tient !) dans Can Robot Take Control ces deux derniers paramètres ont pour valeur l'ID du secteur (bouuuuuh !). Bref, des GAP 3 plus courtes sur Can Robot Take Control vont corriger les problèmes d'écriture sur support physique. On peut réduire la GAP 3 à 36 octets en respectant les spécifications. On se retrouve alors au plus proche du maximum, soit 6246 octets et le dernier secteur ne devrait pas déborder sur l'entête piste. Mais quid d'Imperial Mahjong qui lit ses secteurs en ligne ?

De l'influence de la GAP

Quand on analyse une piste après formatage et après écriture de ses secteurs, on s'aperçoit que l'ensemble du secteur n'est pas ré-écrit lors de l'écriture. Logique ? Oui, sinon on risquerait des décalages successifs et rien ne garantirait qu'au bout d'une centaine d'écritures, on n'ait pas bougé. Les données écrites commencent avec la deuxième série d'octets de synchro, suivi de l'IAM, les données et le CRC. Ainsi le secteur reste à quelques impulsions magnétiques près, toujours au même endroit.

Toujours au même endroit ? Le début du secteur, c'est certain ! Mais la position physique de la fin du secteur va dépendre de la vitesse de rotation du moteur ! Exemple avec un lecteur un peu plus rapide que celui qui a écrit la disquette, par exemple, 5 tours/minute sur une référence de 300 tours/min.

512 x 305 / 300 => 520,... => 8 octets de plus !


En respectant la tolérance de 12% du FDC, on peut imaginer une disquette écrite avec un lecteur à 285tr/min puis ré-écrite par un lecteur à 315tr/min

512 x 315 / 285 => 565,9 => 54 octets de plus !

L'utilité de la GAP 3 devient évidente, permettre l'écriture sur des disquettes qui ont été écrites sur une autre machine mais aussi conserver une sécurité sur sa propre machine, les lecteurs n'étant pas éternels ni même d'une vitesse de rotation stable sur l'instant. Par contre en lecture il ne devrait pas y avoir de souci de lecture tant que celle-ci a pu être écrite correctement. Et au petit jeu de la GAP la plus courte possible, si votre lecteur ne danse pas le flamenco quand il tourne, il est facile de formater, écrire et lire des disquettes avec des GAP très courtes, jusqu'à 1 en fait. Vous me voyez venir, patchez aussi Imperial Mahjong avec une GAP correcte (36 octets).

Zéro tracas, zéro blabla : évidemment, avec un lecteur simulé par un Gotek, la rotation est parfaite, vous ne serez jamais concernés par ces problèmes. Avec un lecteur type 3.5″ sans courroie, la stabilité est très bonne aussi. Dans l'attente de plus de données en provenance de personnes ayant eu des soucis avec Imperial Mahjong, considérez que vous pouvez bien faire ce que vous voulez de votre côté !



Antoine Taveneaux / CC BY-SA 3.0 / La tête en position de lecture sur une disquette 3.5″

Écrire des secteurs de différentes tailles sur la même piste

Comme je vous le disais au début de cet épisode, la taille réelle des secteurs est unique et c'est celle renseignée lors de la demande de formatage. Le FDC ne sait formater qu'une seule taille de secteurs à la fois ! Ce qui veut dire que si vous voulez mélanger les tailles de vos secteurs, il va falloir ruser !

La méthode la plus performante consiste à formater la piste en demandant comme taille unique la plus petite taille des secteurs dont vous avez besoin. Ensuite, pour chaque secteur plus gros que la taille de base, il faut insérer des secteurs (qui peuvent tous s'appeler pareil) qui seront écrasés par l'écriture du gros secteur.

Par exemple une piste avec un secteur taille 2, un secteur taille 1, un secteur taille 2 et un autre secteur taille 1. Nous écrirons réellement 4 secteurs de taille 1 lors du formatage, dont deux secteurs avec des informations de taille supérieures.

L'écriture du premier secteur déborde sur le deuxième (ID=#FF) qui se fait effacer. Le troisième secteur (ID=#02) est inchangé mais devient réellement le deuxième secteur. Le quatrième et dernier secteur se retrouve décalé lui aussi, en troisième position (ID=#03).

Pour aller plus loin sur les formats écrasés

Il existe une série d'articles dans les derniers Amstrad 100% à propos des protections logicielles, je vous conseille la lecture du n°44 sur les secteurs écrasés qui détaillera bien mieux que ce petit exemple. Il y a les sources d'un petit outil qui permet de formater des pistes avec des formats spéciaux, ainsi que des routines basiques de lecture/écriture de secteurs, cela permet de pas mal jouer avec les formats spéciaux.

À lire aussi dans CPC Info l'article de Yannick Gour sur les formatages (+outils).

Saint Graal du formatage : écrire des secteurs de taille 6 sur une piste

Même si le FDC est incapable de s'arrêter d'écrire ou de lire la quantité demandée quand il a commencé, il est possible d'écrire des secteurs de taille 6 en coupant le moteur ! Avec une bonne courroie la manipulation n'est pas compliquée et les lecteurs 3.5″ s'arrêtent quasi instantanément. Je vous en avais précédemment parlé avec la protection Hexagone. Sur le dump Kryoflux suivant, on peut voir de tels secteurs en orange. Comme le programme ne sait pas où les données s'arrêtent, la couleur s'arrête mais les données continuent bien.

En analysant sur plusieurs tours les données, on repère le moment (petit trait rouge) où le support physique reboucle car on tombe rarement pile au bon endroit. Sur cet exemple, je tente à chaque piste d'écrire un peu plus loin, jusqu'à ce que je m'approche trop (vert très clair) de l'entête du secteur. On voit que la zone de rebouclage continue de se décaler jusqu'au moment où, sans entête, les données sont perdues pour notre FDC : dommage !

J'ai besoin de vous !

J'espère que cet article n'aura pas été trop indigeste vu que je suis parti un peu dans tous les sens (GAP, taille, formats spéciaux, taille 6). N'hésitez pas à me contacter si vous avez des questions sur certains points plus précis, vos questions serviront à l'élaboration d'une meilleure documentation FDC à venir !

Roudoudou

★ ANNÉE: 2021
★ AUTEUR: Roudoudou

★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser...

Lien(s):
» Coding Src's » Roudoudou FDC Library
» Coding » A la découverte du FDC épisode 3 (Roudoudou)
» Coding Src's » Digitalised Sample Loader (Roudoudou)
» Coding » A la découverte du FDC épisode 5 (Roudoudou)
» Coding » A la découverte du FDC épisode 2 (Roudoudou)
» Coding » A la découverte du FDC épisode 1 (Roudoudou)
Je participe au site:

» Vous avez remarqué une erreur dans ce texte ?
» Aidez-nous à améliorer cette page : en nous contactant via le forum ou par email.

CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 305 millisecondes et consultée 90 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.