Par Simon
Ou l’aventure des déboires avec les disquettes, partie 1 d’une possible longue série !
Quel est le besoin ?
Depuis quelques années me tourne en tête l’idée d’un outil de transfert de disquettes Oric vers PC. Readdsk est déjà très puissant sur PC, mais l’idée est d’utiliser le matériel Oric à la fois pour les non-bricoleurs qui ne voudraient pas désosser un drive 3 pouces et le brancher dans un PC, mais aussi parce que seuls les PC vieillissants sont encore capables de gérer un lecteur de disquettes. Savedisk, sorti en 2005 (cf. CEO-Mag n° 182, de juin 2005), répondait en partie à cette idée en permettant de lire, secteur par secteur, une disquette Sedoric, puis de la sauver sur PC par… Le port cassette ! Et ensuite de refaire un fichier .DSK pour émulateurs.
L’idée suivante était de rendre cet outil universel, en faisant en sorte qu’il ne se préoccupe pas du système de la disquette lue (Sedoric, Randos, Oric Dos, Stratsed, FTDos, XL-Dos, …). Il existe une commande au niveau du contrôleur de disquette du Microdisc (le FDC 1793), qui permet de lire une disquette piste entière par piste entière, indépendamment du format. Cela permet d’embarquer tous les secteurs et toutes les informations entre les secteurs, d’un seul coup, et donc a priori de gérer tous les DOS possibles tant que l’on trouve un moyen de gérer le nombre de pistes et de faces.
La galère commence
Las ! En testant cette commande (avec un gros coup de pouce de Fabrice), je me suis vite rendu compte d’un problème: a priori aléatoirement, des octets de valeur $C2 s’inséraient dans les données, voire les écrasaient. Cela ruinait la fiabilité. Pensant à un problème matériel (drive, disquette ?), j’ai varié les sources: drives 3″ ou 3.5″, test lors d’une visu sur du matériel de Thierry… Sans résultat probant: toujours des dizaines ou centaines de $C2 !
Pourtant, j’étais très intrigué car Nibble, l’éditeur de disquettes, est capable de lire et copier piste par piste, sans erreur. En regardant une piste dans Nibble et en comptant (un par un…), je pouvais voir beaucoup moins de $C2 que lorsque je faisais la lecteur moi-même… Quant à Euphoric, il rend une lecture parfaite de la piste.
Mais c’est quoi ce bazar ?
Passablement découragé, j’ai sollicité tranquillement les forums Oric, et au fil du temps et des d’échanges, a émergé une analyse d’un “bug” sur le contrôleur de disquette Atari ST (par Claus Brod), utilisé pour protéger des disquettes contre la copie. Il ressemble furieusement au problème sur Oric !
Schématiquement, lorsqu’il lit une disquette piste par piste, le contrôleur est en permanence à la recherche d’octets de synchronisation sur la disquette. Ces octets de synchro forment une suite de bits qui permet au contrôleur de caler le démarrage de sa lecture d’une piste. Comme il ignore la longueur d’une piste, le contrôleur sera en permanence ” à l’écoute” de cette séquence pour savoir si une nouvelle piste démarre.En détail, voici les différentes synchro qui existent sur une disquette:
- IAM – Index Access Mark (C2C2C2FC) marking the start of a track
- IDAM – ID Access Mark (A1A1A1FE) marking the start of a header field (Sector ID)
- DAM – Data Access Mark (A1A1A1F8 or A1A1A1FB) marking the start of a Data field (Sector)
Les C2 et A1 sont de plus, si j’ai bien compris, enregistrés sur la disquette avec une petite erreur volontaire, pour les démarquer d’octets de données.
Mais malgré cette précaution, une séquence de bits de synchro peut être présente au beau milieu des données d’un secteur, à partir d’une combinaison d’octets qui n’ont rien à voir. Et elle peut tromper la lecture qui va penser déceler un octet de synchro ! Sur Atari ST, c’est la séquence 000101001 qui serait en cause; je n’ai pas vérifié sur Oric.
Ce bug ne se produit pas avec les commandes de lecture par secteur (lesquelles ne recherchent pas de synchro piste !).
Voilà a priori l’origine des $C2 aléatoires ! Euphoric n’a pas ce problème car j’imagine que la lecture d’un fichier DSK sur le PC ne nécessite pas ce décodage bas niveau.
Magic Nibble
Et Nibble alors, pourquoi les $C2 sont moins visibles ?
Eh bien, Dominique m’a transmis il y a quelques mois une photocopie du manuel de Nibble. Ce dernier montre que ses auteurs ont bien rencontré des difficultés dans la lecture par piste, et explique le contournement du problème: la piste est lue, mémorisée, puis chaque secteur de la piste est relu individuellement. Cette lecture par secteur remplace celle faite en mode piste ! Ainsi les données des secteurs sont épargnées par les $C2 parasites.
Voilà la solution d’un mystère… Et une piste (sans jeu de mots !) pour poursuivre le copieur de disquettes universel sur Oric ? A noter que sur Jasmin, qui utilise un autre FDC (FDC 1770), le problème serait identique, mais je n’ai pas vérifié !
Documents expliquant le mystère de la commande Read Track sur Atari ST:
Leave a Reply