CODING ★ CATALOGUE DETOURNE ★

Catalogue Détourné (Amstar&CPC)

Après une rapide introduction sur la structure des disquettes et une conclusion optimiste sur les possibilités de notre petite manipulation (voir CPC n°38) , nous voici à nouveau devant notre clavier avec un utilitaire pour disquette dans la main droite, la disquette exemple du mois précédent dans la main gauche et utilisons la troisième pour prendre notre courage à deux mains.

Nous en étions donc au charcurtage du catalogue afin d'égayer quelque peu la monotonie engendrée par l'emploi de CAT. Les résultats obtenus étaient encourageant mais la place occupée par les messages était encore trop Importante. Depuis le mois dernier vous avez certainement trouvé la solution ou plutôt une des solutions possibles : Il reste des octets disponibles après le code ASCII de la première ligne. En effet nous avons droit à 8 caractères pour le nom du fichier plus 3 caractères pour l'extension. Ce qui nous fait 11 octets. Mais il ne faut pas oublier le code d'autorisation d'écriture (&06), le code « locate » (&1F) et ses deux paramètres et enfin le code de fin d'écriture (&15). Une addition rapide nous donne 5 octets indispensables, Il ne reste que 6 octets. Cela semble amplement suffisant pour écrire un message conséquent. C'est vrai il est possible maintenant de taper des textes relativement importants. Par exemple si l'on utilise 32 entrées (sur les 64 disponibles) la taille du message pourra s'étendre jusqu'à 5 * 32 = 160 caractères I

Comment, comment ? Pourquoi seulement 5 octets alors que nous parlions tout à l'heure de 6 octets ? Il y a un petit détail que j'ai oublié de vous préciser : c'est l'installation des codes ASCII dans le catalogue. Si nous reprenons notre exemple en supprimant le dernier code 15, nous obtiendrons la ligne suivante :

00 06 1F 06 0C 54 00 00 00 00 00 00 00 00 00 00

Nous ajoutons alors la suite des codes ASCII : 41 50 45 08 5A 15, ce qui nous donne en clair : TAPE.Z Mais quel est donc ce code 08 qui se place Ici sous la forme d'un point ? Pourquoi ne pas le remplacer par un code ASCII "utile". Cela n'est pas impossible à faire mais la présentation du texte en souffre. Vous savez que le catalogue obtenu à l'écran par la fonction CAT dispose les fichiers dans un format spécial : Il y a un point entre le nom de fichier et l'extension (exemple : DISC.BIN),ce point n'est pas présent sur le catalogue "physique" de la disquette, il est donc nécessairement ajouté par l'Instruction CAT ( qui, par ailleurs, trie par ordre alphabétique les noms de fichiers ). Donc si vous Inscrivez le code 5A ( Z ) directement à la suite du code 45 ( E ) vous obtiendrez lors du CAT le texte suivant : TAPE.Z, ce qui est assez moche n'est-ce pas ? Le code 08 de l'exemple précédent est également un code de contrôle. Il agit sur le curseur en le déplaçant à gauche d'un caractère. Voici ce qui va se dérouler lors de l'utilisation de CAT : les codes vont être lus et affichés les uns à la suite des autres, arrivé au 9ème code le programme ajoute le point de séparation puis lit le 10 ème code, le retour en arrière du curseur. Ce retour permet ainsi d'effacer le point et de le remplacer par la lettre suivante. Ce petit tour de passe-passe n'est heureusement pas visible à l'écran. Ensuite le texte se poursuit normalement.

Il y une petite chose à ne pas perdre de vue : les « LOCATE » ( 1F ) ne doivent plus être décalés d'une unité en X ou en Y, mais bien du nombre de lettres affiché précédemment. Par exemple si on place la chaîne « TAPEZ » en 10,10 ( avec l'instruction 1F ) la suite du message devra être placée en 15,10 (d'ailleurs en agissant de cette manière vous gagnez un espace puisque c'est le LOCATE qui place correctement la chaîne aux bonnes coordonnées ). Les textes obtenus de cette manière seront sans doute plus longs mais il seront tous de la même couleur. SI l'on veut obtenir quelques effets dans les couleurs II faut sacrifier la place disponible pour les caractères. A vous de décider où vont vos préférences.

LA VENGEANCE DU CATALOGUE DETOURNE

Puisque nous sommes dans le catalogue, restons-y. Il y a encore un petit mystère à éclaircir : la signification des quatre octets qui sont pour l'instant encore mystérieux. Mais auparavant il faut connaître la signification des termes "enregistrements" et "blocs".

Un enregistrement est une subdivision d'un secteur, Cet enregistrement occupe 128 octets exactement. Un secteur standard sur une disquette CPC contient donc 512 / 128 = 4 enregistrements. Les blocs comprennent eux 1024 octets donc 2 secteurs. C'est clair, non ? Ces quelques subtilités ont pour origine les temps anciens de l'informatique : c'est par souci de compatibilité que l'on a conservé ces appellations et ces subdivisions. Maintenant que vous connaissez la signification de ces termes il est possible d'Indiquer le contenu normal des derniers octets d'une entrée du catalogue. Commençons parle 16ème octet de la première ligne d'une entrée. Il s'agit du nombre d'enregistrements occupés par le fichier. Ce nombre est bien sûr donné en hexadécimal comme tous les autres octets de la ligne.. Cela est intéressant : nous connaissons la taille du fichier. Il ne nous manque que la position du fichier sur la disquette. On trouve ces Indications dans la deuxième ligne d'une entrée de catalogue. Pour tout simplifier, la position est Indiquée elle en blocs, Ainsi pour un fichier de 1152 octets le nombre d'enregistrements sera de 9 ( 1152 / 128 = 9 ). La deuxième ligne pourra contenir par exemple les blocs 0C 0D. J'écris « pourra contenir » car les valeurs Inscrites ici dépendent étroitement du remplissage de la disquette. Il peut même arriver que les numéros de blocs ne se suivent pas. Cela s'explique par le fait que c'est le CPC qui choisit les blocs vides pour placer le contenu des fichiers, Je sens que l'attention se relâche un peu, je vous conseille donc de vous reporter à la figure 1 afin de vous remettre les idées en place.


Fig. 1

Ca y est, vous êtes totalement dans le bain, vous avez intégralement tout saisi ? En fait II est encore plus facile de prendre une disquette et d'essayer de manipuler un peu le contenu de ces sacrés secteurs, En se penchant un peu sur le contenu de cette fameuse deuxième ligne d'une entrée catalogue, on remarque que la place disponible est quelque peu réduite : les 16 valeurs représentant des blocs on ne peut donc décrire que des fichiers de 16 Ko, Mais alors comment se fait-il que l'on puisse en toute impunité enregistrer des fichiers beaucoup plus important ? Tout simplement l'ordinateur réserve autant d'entrées que nécessaires pour décrire le fichier.

Par exemple, un fichier de 40 Ko sera en fait représenté au catalogue par3 entrées (la dernière n'étant pas tout à fait complète). A ce niveau chaque entrée doit être "marquée" par un symbole quelconque afin que l'ordinateur sache repérer les différents morceaux. C'est pourquoi l'octet 15 de la première ligne est utilisé. Ce dernier indique en effet le nombre de blocs occupé par le fichier. Si ce nombre est égal à &80 cela signifie qu'une entrée supplémentaire a été ouverte pour le fichier. Chaque entrée d'un même fichier est composée de la même façon : le nom est identique, le numéro de user également, seul l'octet 12 (compteur des entrées) et les octets de la deuxième ligne sont différents,

LE FILS DU CATALOGUE DETOURNE

Un dernier petit truc qui concerne cette fols-ci la protection de vos programmes : en ajoutant la valeur &B0 au premier caractère de l'extension du fichier (BAS ou BIN le plus souvent), ce dernier sera alors "Read only" c'est à dire que vous ne pourrez plus modifier le nom ou supprimer le fichier en question. Si vous effectuez cette même opération sur le deuxième caractère de l'extension, le fichier sera alors Invisible aux regards indiscrets lors d'un CAT ou d'un DIR. Utilisez un moniteur de disque pour effectuer ces opérations.

Débordons un peu du cadre du catalogue maintenant. Si l'on connaît un peu mieux les points de repère utilisés par l'Amstrad pour positionner les fichiers, on ne sait pas encore comment sont Identifiés ces fichiers. Eh oui, il ne suffit pas de connaître la position du programme sur le disque, encore faut-ll connaître son genre (Basic, binaire, ASCII), sa longueur, son adresse d'entrée ou d'exécution pour les programmes binaires. Ces renseignements se trouvent sur le disque bien sûr aux coordonnées indiquées dans le catalogue, On trouve donc tout au début du fichier une zone de 128 octets appelée "header", ce qui signifie "tête". En décortiquant un peu ces données on connaîtra tout sur le fichier en question. Mais nous verrons cela plus en détail le mois prochain

AMSTAR&CPC n°30

★ ANNÉE: ???
★ AUTEUR: O. SAOLETTI

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

Lien(s):
» Coding » Assembleur ACPC n°45 - Le directeur rit ( Modification du catalogue AMSDOS )
» Coding » Catalogue Detourne (CPC Revue)
» Coding » Bidouilles ACPC n°03 - Catalogue décorés
» Coding » Bidouilles ACPC n°17 - Le catalogue AMSDOS
» Coding » Bidouilles ACPC n°30 - Catalogue et heresie
» Coding Src's » LIB Catalogue v1.0 (ANTOINE / POW)
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 402 millisecondes et consultée 1606 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.