Table des matières

Retourner au sommaire

Catalogues et fichiers

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

Faites pas cette tête ! Je suis sûr que vous allez vous amuser ! 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.

Le catalogue

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  ».

Les formats

Le catalogue c'est un peu comme un bibliothécaire... 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ême1), seuls diffèrent le nombre de pistes, le nom des secteurs2), voire la taille des blocs et du catalogue.

Et après ?

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 2Ko3) et commence sur le premier secteur de la première piste, soit en piste &004) sur le secteur &C15) pour se terminer quatre secteurs plus loin, en &C46). 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 !

Catalogue
Octet Signification
0-31 1ère entrée de fichier
32-63 2ème entrée de fichier
64-95 3ème entrée de fichier
96-27 4ème entrée de fichier
2016-2047 64ème entrée de fichier

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 : bloc=((piste*9)+secteur)/2.
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 !

Un exemple s'il vous plait !

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

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.

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 :

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

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 !

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

&0000 00 52 65 73 65 72 76 65 64 4F 5F 6F 00 00 00 18  .  R  e  s  e  r  v  e  d  O  _  o  .  .  .  .
&0010 09 16 2B 00 00 00 00 00 00 00 00 00 00 00 00 00  .  .  +  .  .  .  .  .  .  .  .  .  .  .  .  .
&0020 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
&0030 Etc..

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.

Cas particuliers

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 :

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.

Exemple d'édition d'un catalogue d'un disc au format VENDOR

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

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.

Après la bibliothèque... voyons les livres eux-mêmes !

Les fichiers

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.

Fichiers binaires

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.

Fichiers ASCII

Les fichiers assis ? 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

L'en-tête système12), 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.

Comprendre les en-têtes système...

La structure de l'en-tête système

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 détail

En-tête système
Octet Signification
      0 « user » utilisé lors de la création du fichier (généralement à zéro).
1-8 Nom utilisé lors de la création du fichier.
9-11 Extension utilisée lors de la création du fichier.
12-17 Non utilisé.
18 Type de fichier.

Deux valeurs sont possibles : 0 ou 1. La valeur 0 indique que le fichier est tout à fait normal. En revanche, s'il est à 1 cela signifie que le fichier est crypté en mode système : il s'agit d'un fichier protégé13). La présence de cette valeur a deux rôles : celui d'avertir le système qu'il devra effectuer un décodage système avant de lancer le programme, mais aussi celui de provoquer l'effacement du programme s'il est interrompu durant son exécution14). Pour transformer un tel fichier en fichier normal, il faudrait donc mettre cet octet à 0 puis décoder tous les secteurs un à un grâce à l'option “Coder Système” de Disco. D'une part cela impliquerait une modification du CSH (voir ci-dessous) et de plus Disco peut faire cela automatiquement avec son copieur de fichiers donc passons ; mais vous savez au moins comment ça marche !
19-20 Non utilisé.
21-22 Adresse d'implantation du ficiher.

Attention, c'est une valeur sur 16 bits et comme pour toute valeur gérée par l'assembleur l'octet de poids fort est après l'octet de poids faible.
23 Non utilisé.
24-25 Longueur du fichier en octet.

Attention, il s'agit de la taille du fichier lui-même, sans prendre en compte les 128 octet de l'en-tête système.
26-27 Adresse d'exécution du fichier.
Si l'adresse d'exécution est à zéro c'est généralement qu'il s'agit d'un fichier de données et non d'un programme.
28-63 Non utilisé.
64-65 Longueur du fichier en octet, oui comme pour les octets 24 et 25.
66 Non utilisé (parfois utilisé comme octet de poids fort de la taille du fichier si elle est exprimée sur 24 bits au lieu de 16).
67-68 Somme de contrôle, le CSH.

Ces deux octets contiennent la somme sur 16 bits de tous les octets précédent et c'est grâce à cela que le système vérifie s'il a à faire à des données brutes (fichier ASCII) ou à un fichier binaire proprement dit. Si ces deux octets contiennent effectivement la somme de tous ceux qui précèdent, le système lit alors tous les renseignements de l'en-tête puis le lui-même fichier qui commence donc à partir du 128ème octet. Dans le cas contraire, le système considèrera qu'il a à faire à un fichier ASCII et lira les données bloc par bloc à partir du tout début du secteur.
69-127 Non utilisé.

À 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.

Voyager dans l'espace !

La fin des fichiers ASCII

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.

L'exemple

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é :

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 :

Et voilà !

Documentations externes

1) à l'exception notable du format RODOS qui est totalement différent
2) ce qui permet de détecter le format automatiquement
3) 4Ko dans certains formats Parados/Romdos
4) &02 en SYSTEM ou VENDOR
5) &41 en SYSTEM ou VENDOR
6) &44 en SYSTEM ou VENDOR
7) deux secteurs de 512 octets, ça fait bien 1Ko !
8) numérotées à l'aide de l'octet 12, le numéro de l'entrée
9) en pratique l'AMSDOS permet d'avoir plusieurs catalogues sur une même disquette, mais c'est une autre histoire…
10) Votre esprit subtil n'a-t-il rien remarqué ? Deux secteurs consécutifs ne sont pas forcément sur la même piste !
11) pour toutes les entrées si le fichier fait plus de 16Ko
12) ou header AMSDOS
13) soit un fichier BASIC sauvé avec l'option P, soit un fichier binaire protégé
14) ou si l'on tente de le charger sans l'exécuter