| ★ CODING ★ AMSTAR ★ ANALYSONS LES FICHIERS ★ |
| Initiation à L'Assembleur Amstar&CPC 30:- Header Analysons les Fichiers | Coding Amstar |
Nous n'allons pas étudier ici la gestion des fichiers mais plutôt leur implantation sur un disque. Comme pour les articles précédents (catalogue détourné) il est préférable d'avoir un éditeur de secteurs sous la main afin de pouvoir observer la moindre parcelle de notre disque. L'éditeur ici utilisé est celui de Discology qui offre la souplesse et la simplicité nécessaires. Mais rien ne vous empêche d'en utiliser un autre.Vous connaissez maintenant le système de repérage des fichiers sur la disquette grâce au catalogue ( voir numéro 26 d'Amstar & CPC ), il n'y a donc pas de problèmes pour retrouver le point de départ de notre fichier. Encore faut-il savoir le type de fichier utilisé. Il existe 3 possibilités : BASIC, binaire ou ASCII. Nous commencerons par observer la disposition de ces derniers sur notre disquette car il s'agit du cas le plus simple : les données sont directement Inscrites sur la disquette en code ASCII sans Header. C'est-à-dire que si nous nous plaçons directement au départ d'un fichier en ASCII, nous trouverons le texte du fichier qui est facilement lisible dans la partie «texte» présente sur tous les bons éditeurs de secteurs.
Nous avons parlé de Header. De quoi s'agit-il exactement ?. Eh bien, les fichiers (sauf ASCII) sont sauvés sur la disquette avec une zone de 128 octets en en-tête. Cette zone permet d'obtenir certains renseignements sur le fichier. Voici comment elle se décompose : Le premier octet est le numéro de User, Mais ce numéro est en fait assujetti à celui déjà présent dans le catalogue, vous pouvez en faire vous-même l'expérience : Il suffit de modifier le numéro de User présent dans le Header sans modifier celui du catalogue et il n'y aura rien de changé pour l'utilisateur. On peut même aller plus loin car si on change le nom d'un fichier avec la commande |ERA, la zone correspondant au nom dans le Header ne bouge pas. Justement la partie du Header comprenant le nom du fichier est constituée de 11 octets (8 octets pour le nom, 3 pour l'extension), elle est située juste après le User, Les 6 octets suivants sont à zéro, le 19ème indiquant le type de fichier selon les critères suivants : 0 pour le BASIC, 1 pour le BASIC protégé et 2 pour le binaire. Un listing en BASIC protégé est facilement obtenu par un SAVE "NOM DU PROGRAMME",P. A ce moment-là, il n'est plus possible de lister le programme ni de le modifier. Avec Discology , l'option «CODER» permet de retrouver un fichier normal ou plutôt compréhensible.
Continuons avec 2 octets nuls tout de suite suivis par l'adresse d'écriture du fichier. Eh oui car lorsque le CPC charge un programme en mémoire, il faut bien qu'il sache à quelle adresse il doit être placé. C'est donc sur les 22 et 23ème octets que l'on trouvera cette adresse disposée dans le sens poids faible/poids fort, c'est-à-dire que pour un programme BASIC, dont l'adresse de chargement est &170 les deux octets contiendront : 70 01. Le 24ème octet n'a pas de signification connue (ce qui est le cas de la majorité des octets du Header). Les 25 et 26èms octets renferment la longueur du fichier suivie de l'adresse de lancement sur deux octets également. Cette adresse de lancement est nulle pour les fichiers en BASIC puisque l'adresse est toujours constante (&170). En fait on trouve une valeur uniquement pour les fichiers binaires sauvés avec une adresse de lancement : par exemple SAVE "ESSAI",B,&4000,&1000,&5400Indiquera une adresse de chargement égale à &5400.
Les octets les plus importants se trouvent en position 68 et 69, ils contiennent une somme de contrôle des 67 octets précédents. Cette somme de contrôle permet de faire la différence entre les fichiers ASCII et les autres types de fichiers. En effet lors de l'ouverture d'un fichier l'ordinateur récupère la somme de contrôle et la compare à la somme des 67 octets précédents. Si l'on a affaire à un fichier ASCII, Il est très peu probable que les 2 octets réservés au contrôle contiennent la somme des autres octets, Cela est très Improbable mais cela peut arriver : dans ce cas les 128 premiers octets du fichier ASCII seraient perdus.
|
