— Basé sur les articles publiés dans Quasar CPC numéro 4 et numéro 5, Bidouilles, par OffseT.

L'objectif de cet article est de vous permettre de pouvoir bidouiller catalogues et fichiers à votre guise ! Je vois que le petit blond à lunettes a déjà son Disco en main ; il a raison, c'est l'outil idéal pour découvrir les entrailles de vos disquettes. Mais attention, utilisez impérativement une disquette de travail pour vos essais, nous ne saurions être tenus responsable de la perte de vos données ! Bref, commençons.

Au menu : comment créer des fichiers factices sur une disquette.

« Mais à quoi ça sert ? » s'écrie notre petit blond à lunettes. Eh bien, par exemple, pour marquer des secteurs endommagés (ce que des logiciels comme MarkError font automatiquement), pour protéger une zone dans un format personnalisé (pour votre trackloader ou autre), ou encore faire du « catalogue art  ».

Lorsque l'on veut manipuler le catalogue, la première chose à savoir, c'est où il se trouve sur la disquette. Sur CPC, l'AMSDOS nous propose deux formats principaux : le format DATA et le format SYSTEM (ou VENDOR, c'est pareil).

En format DATA, le catalogue est stocké en piste 0 et les secteurs sont numérotés de &C1 à &C9 (9 secteurs par piste), alors qu'en format SYSTEM ou VENDOR, celui-ci est stocké en piste 2 et les secteurs sont numérotés de &41 à &49 (toujours 9 secteurs par pistes). Dans ce dernier format, les piste 0 et 1 sont en effet réservées pour mettre des données bootables (qui sont chargées avec la RSX |CPM), la seule différence entre les formats VENDOR et SYSTEM étant que ce dernier contient l'amorce pour le CP/M (le système, CQFD). Ces formats sont tous en 40 pistes, numérotées de 0 à 39, et chaque secteur fait 512 octets ; on comprend ainsi pourquoi une disquette DATA offre 178Ko contre seulement 169Ko pour une disquette SYSTEM ou VENDOR qui a deux pistes en moins pour les données utilisateur.

Alors, bien sûr, il existe tout un tas d'autres formats, notamment pour gérer les disquettes 3”1/2, mais le principe reste généralement le même¹⁾, seuls diffèrent le nombre de pistes, le nom des secteurs²⁾, voire la taille des blocs et du catalogue.

Maintenant, imaginons que vous avez la liste des secteurs que vous voulez allouer. Nous allons donc voir comment se structure le catalogue afin de pouvoir créer un fichier factice (ou non) qui encapsulera ces petits secteurs. En effet, la présence d'un fichier utilisant nos secteurs implique que l'AMSDOS n'ira jamais les titiller lorsque vous ferez des manipulations sur votre disquettes (sauvegardes d'autres fichiers) ; c'est notamment très pratique pour verrouiller des secteur endommagés, empêchant ainsi l'AMSDOS de les utiliser pour vos précieuses données !

Le catalogue fait 2Ko³⁾ et commence sur le premier secteur de la première piste, soit en piste &00⁴⁾ sur le secteur &C1⁵⁾ pour se terminer quatre secteurs plus loin, en &C4⁶⁾. Pourquoi quatre secteurs plus loin ? Eh bien tout simplement car comme un secteur fait 512 octets, il en faut quatre pour couvrir les 2Ko de notre catalogue !

Or donc notre catalogue se compose d'entrées, chaque entrée référençant un fichier à l'aide d'une séquence de 32 octets dont la signification est la suivante :

Entrée de fichier
Octet	Signification
0	Numéro de “user” du fichier. Il s'agit tout bonnement du “user” correspondant à la commande |USER de l'AMSDOS pour lequel votre fichier sera visible, mettez 0 si vous voulez un fichier de base, une valeur entre 1 et 15 pour un autre user, une valeur supérieure à 15 pour un fichier “invisible” vu que les users supérieurs à 15 ne sont pas accessibles via la commande |USER (en bref, mettez ce que vous voulez sauf &E5 qui est réservé pour les fichiers effacés)
1-8	Nom du fichier.
9-11	Extension du fichier.
12	Numéro de l'entrée pour ce fichier. Un fichier de plus de 16Ko a plusieurs entrées dans le catalogue, elles sont numérotées à l'aide de ce champ.
13-14	Inutilisé.
15	Nombre d'enregistrements de ce fichier. Un enregistrement fait 128 octets. Cette valeur sert à la fois à savoir combien de blocs existent pour le fichier, mais également quelle taille maximale devra être chargée dans le cas d'un fichier ASCII (voir plus bas pour plus de détails sur les types de fichiers).
16-31	Liste des blocs alloués pour ce fichier. Un bloc fait 1ko, soit 8 enregistrements ou encore 2 secteurs. Sachant que seulement 16 blocs peuvent être référencés par entrée et qu'un bloc fait 1Ko7), vous en déduirez logiquement que les fichiers de plus de 16Ko utilisent plusieurs entrées8). Le numéro d'un bloc se calcule simplement à partir du numéro de piste et de secteur : . Attention : → “secteur” est le numéro de secteur et non son nom, c'est-à-dire que le secteur &C1 est le numéro 0, de même que le &41. → “piste” est le numéro de piste est relatif à la piste hébergeant le catalogue ; c'est-à-dire que sur un format DATA le numéro de piste 0 est effectivement la piste 0, alors que ça sera la piste 2 pour un format VENDOR ou SYSTEM. À noter : l'AMSDOS permet de déplacer un catalogue sur une disquette9), on pourrait parfaitement imaginer un catalogue en piste 23. Ici encore, le numéro de piste utilisé pour le calcul des blocs est relatif à la piste du catalogue, et le numéro de piste 0 correspondra à la piste 23 !

Du calme, ça arrive. Prenons un cas « complexe ». Imaginons une disquette sur laquelle on veut verrouiller les secteurs suivants :

• Piste 2 : secteurs &C1 et &C2,
• Piste 5 : secteur &C1,
• Piste 9 : secteur &C6.

Déjà, essayons de voir le nombre de blocs dont nous auront besoin. Comme notre disquette est au format DATA, la numérotation des pistes commence à 0.

• Pour le &C1 secteur piste 2 : soit le bloc 9 (&09).
• Pour le &C2 secteur piste 2 : soit le bloc 9 (&09).
• Pour le &C1 secteur piste 5 : soit le bloc 22 (&16).
• Pour le &C6 secteur piste 9 : soit le bloc 43 (&2B).

Argh, mais que sont ces chiffres entre quotes !? Eh bien il s'agit tout simplement du numéro du secteur sur la piste. En format DATA, '0' est donc le secteur &C1, '1' le secteur &C2 et '5' le secteur &C6.

Que constate-t-on ? Qu'il nous faut allouer non pas quatre mais trois blocs pour verrouiller ces quatre secteurs ! Car, en fait, un bloc ne définit pas un secteur mais deux secteurs consécutifs. Ici, les secteurs &C1 et &C2 de la piste 2 pourront donc être déclarés dans le même bloc. Par ailleurs, pour la même raison, le secteur précédant le secteur &C1 de la piste 5 se retrouvera également verrouillé (soit le secteur &C9 de la piste 4) ; il est perdu.

Pour mieux comprendre la chose, voici comment l'AMSDOS va retrouver les secteurs alloués à partir des numéros de blocs :

• où “piste” sera le nombre de piste à compter à partir de celle hébergeant le catalogue, soit 0 pour le format DATA et 2 pour le format SYSTEM ou VENDOR.
• où “masque” sera &C0 pour le format DATA et &41 pour le format VENDOR ou SYSTEM.
• et si “secteur2” dépasse la fin de piste, on prendra le premier secteur de la piste suivante¹⁰⁾.

Ceci étant fait, pour remplir notre entrée de fichier, nous avons également besoin de calculer le nombre d'enregistrements :

• (&18).

Voilà, on choisit à présent le nom que l'on va donner à son fichier : “Reserved” pour le nom et “O_o” pour l'extension par exemple. Et puis, pour le “user”, on va mettre un peu ce qu'on veut, mais vous éviterez tout de même la valeur 229 (&E5) qui est réservée aux fichiers effacés.

L'avantage d'utiliser un nom de fichier avec des minuscules (ou des caratères spéciaux) est que le BASIC et la plupart des outils standard ne seront pas capable de le manipuler ; impossible donc d'effacer notre fichier maison par erreur !

Voici ce que vous devriez finalement obtenir après introduction des données sous l'éditeur de Disco :

Ensuite, par mesure de sécurité, je vous conseille de charger l'explorateur de Disco, et de prendre “Exploration Fichier” afin de vérifier si votre fichier factice est bien là où vous le désiriez.

Mais il y a encore quelques petites précisions à donner sur le catalogue ; pour cela un petit écran de Disco commenté (c'est'y pas beau ça ?).

En effet, je ne vous ai pas parlé des fichiers cachés (dits “système”, ou “SYS”) qui sont invisibles dans le CAT du BASIC et du CP/M ainsi que des fichiers en lecture seule (dits “R/O”) qui apparaissent avec une étoile au CAT du BASIC. Le codage se fait très simplement au niveau du catalogue et plus précisément au niveau de l'extension du fichier. Vous aurez peut-être constaté lors de vos manipulations que certains noms de fichiers semblent “amochés” ; en fait c'est à cause de cet codage :

• Le fichier sera en lecture seule si vous mettez à 1 le bit 7 du premier caractère de l'extension du fichier¹¹⁾
• Le fichier sera caché si vous mettez le bit 7 du deuxième caractère à 1.

Comme vous le voyez, il n'y a rien de bien mystérieux à ces codages ! Et si j'avais oublié quelque chose n'hésitez pas à m'en parler.

Dans cet exemple d'édition d'un catalogue, on peut voir différents types de fichiers.

• MAXAM0.BIN qui est un fichier caché en lecture seule qui fait &34 enregistrements de long,
• MAXAM.BAS qui est un fichier en lecture seule de &0C enregistrements,
• DISC.BAS qui est un fichier standard.

Et vous comprenez maintenant pourquoi, du fait du système de codage des fichiers cachés et en lecture seule, certains noms de fichiers semblent amochés ! Si on ignore les bits 7, on se retrouve l'extension du fichier telle qu'elle apparaît avec CAT.

Sur CPC, nous avons deux grandes familles de fichiers : les fichiers binaires et les fichiers ASCII. La différence entre ces deux types est fondamentale.

Les fichiers binaires sont les seuls à disposer d'un en-tête système qui permet de les identifier clairements (adresse d'implantation, taille à l'octet près, exécutable ou non, crypté ou non, etc.), ils sont forcément sauvés et chargés en mémoire en seul bloc linéaire dont la taille maximale est limitée à 64Ko.

Les fichiers dits ASCII sont en fait des fichiers de données brutes. Ils n'ont donc pas d'en-tête système et leur structure est gérée directement par le programme les ayant générés. Leur principal avantage par rapport aux fichiers binaires est qu'ils sont de taille quelconque et que l'on y accède sous la forme d'un flux ; il est donc possible d'y stocker des données qui ne sont pas linéaires en mémoire et de le faire en plusieurs temps.

Ainsi, tous les fichiers n'ayant pas d'en-tête système sont considérés comme étant des fichiers dits ASCII. En fait, seuls les fichiers dits binaires en ont en fait un. Un fichier binaire est soit un programme BASIC, soit un exécutable (il contient alors directement le code machine), soit juste des données (fichiers binaires non-exécutables, comme une image sauvée avec OCP Art Studio par exemple).

L'en-tête système¹²⁾, quoi est-ce ? Eh bien ce sont les 128 premiers octets du premier secteur du premier bloc d'un fichier binaire. Simple non ? à quoi sert-ce ? Ce sont les quelques octets qui permettent au système de savoir qu'il s'agit effectivement d'un fichier binaire et comment il doit le traiter lors d'un LOAD ou d'un RUN.

Dans le grand chapitre précédent, nous avons vu en détail comment était codé le catalogue et vous aurez alors sûrement remarqué qu'il lui manque pas mal de renseignements concernant les fichiers. Heureusement, l'en-tête système est là !

Cet en-tête contient donc :

• le user et le nom de sauvegarde du fichier,
• le type du fichier (normal ou protégé),
• l'adresse d'implantation du fichier,
• l'adresse d'exécution du fichier,
• la taille du fichier,
• la somme de contrôle, le CSH (Check Sum of Header).

À noter que les « user », nom et extension de fichier stockés dans l'en-tête système peuvent être différents de ceux spécifié dans le catalogue si le fichier a été renommé depuis sa création.

Si vous avez bien suivi tout ce qui précède, vous en aurez dont subtilement déduit (Non ?! Mais si voyons) que les fichiers ASCII n'ont effectivement pas d'en-tête ! Mais comment qu'il fait alors le système pour savoir quand il devra arrêter de lire ? Eh bien c'est pas compliqué, ou plutôt si, c'est très compliqué ! En fait il y quasiment autant de types de détection de fin de fichiers différents que de programmes gérant des fichiers ASCII.

Toutefois, la plupart du temps c'est par la présence d'une séquence d'octets que la fin est détectée ; c'est le cas par exemple pour les sources Maxam ou Textomat. Il en est de même pour les fichiers ASCII créés depuis le BASIC. Dans tous les cas, la lecture d'un fichier ASCII s'arrêtera lorsque le nombre maximum d'enregistrements déclarés dans le catalogue aura été atteint et ce même si aucune fin de fichier n'a été détectée par l'application.

Voyons à présent en pratique à quoi cela ressemble avec un petit exemple à l'aide d'un grab d'un écran de Disco.

Exemple d'édition d'un en-tête système de fichier protégé :

J'ai ici édité le fichier SYStème “MAXAM.BAS”, on découvre alors grâce à l'en-tête que :

• il s'agit d'un fichier BASIC,
• le fichier est protégé,
• il s'implante en &0170,
• il fait &0537 octets de long,
• l'adresse d'exécution n'est pas spécifiée (normal pour un fichier BASIC),
• le fichier est effectivement codé en mode système
  • si vous faites “Lister → BASIC” : bug,
  • si vous faites “Coder → Système” puis “Lister → BASIC” : miracle.

• Tout savoir sur la création des CAT'arts par Les Sucres en Morceaux.