CODINGLA BIBLE DU CPC 6128

La bible du CPC 6128 : 1.10.04 Le lecteur de cassette

Bien que votre CPC possède déjà un lecteur de disquette intégré, l'ordinateur dispose d'une connexion pour le travail avec un lecteur de cassette. Cela vous permet d'une part d'utiliser les logiciels disponibles pour le CPC 464, et d'autre part, la cassette est un moyen de stockage de données remarquable pour un prix très intéressant. Cette connexion permet également de préserver la compatibilité entre les différentes machines CPC.

Vous pouvez connecter n'importe quel modèle courant de lecteur de cassette. L'important est simplement qu'il y ait un niveau de signal suffisant sur la bague de l'écouteur et que le son du magnétophone ne soit pas trop "monotone". D'autre part, de trop grandes variations dans la vitesse d'écriture peuvent perturber le timing qui doit être respecté, surtout avec une vitesse de transmission élevée.

Mais venons-en au format d'écriture.

Le lecteur de cassette ne peut fondamentalement stocker les données, de même que le lecteur de disquette, que bit par bit.

Chaque octet à stocker doit donc être décomposé en ses différents bits et être transmis sous cette forme. Cette décomposition est réalisée par le processeur par logiciel, le bit supérieur étant à cet effet envoyé en premier au lecteur de cassette.

Le signal fourni par le 8255 pour le lecteur de cassette est un signal carré. Chaque bit est marqué par une vibration carrée, dans laquelle la phase low est exactement aussi longue que la phase high. On dit également que le signal carré a un rapport de 1:1. Un bit 0 nécessite moitié moins de temps qu'un bit 1.

C'est pourquoi les indications sur la vitesse d'écriture ne peuvent être que des indications imprécises. Il est évident qu'un bloc composé uniquement d'octets 0 sera sauvegardé en deux fois plus de temps qu'un bloc d'à peu près la même taille ne comportant que des &FF. Mais comme la répartition des bits 0 et 1 dans un bloc de données est à peu près égale, on peut s'en tenir aux indications de 1000baud( 1 baud= 1 bit par seconde) pour SUPER-SAVE (SPEED WRITE 0) et de 2000 baud pour SPEED-LOAD (SPEED WRITE).

Chaque fichier cassette, qu'il s'agisse d'un fichier programme ou d'un fichier de données, peut comporter au maximum 65536 octets. Les fichiers sont écrits par blocs comportant chacun au maximum 2048 octets. Chaque bloc comprend au maximum huit segments de données de 256 octets. Devant chaque bloc est écrit un header, c'est-à-dire une tête de bloc.
Bien qu'il n'y ait pas de liaison électrique avec l'amplificateur et le haut-parleur, il est possible, lorsque le volume est suffisant, de suivre à l'oreille le chargement et la sauvegarde de données et de programmes.

Le header de bloc est facile à identifier à l'oreille. On entend en effet un long ton égal suivi de quelques octets qu'il n'est toutefois pas possible de distinguer à l'oreille.
Le ton long et égal est une série de 2048 bits 1. Après ces bits vient un seul bit 0 puis un octet de synchronisation.
La longue suite de bits 1 est nécessaire à l'ordinateur pour déterminer la vitesse (baud-rate). Le bit 0 indique à l'ordinateur que cette tête est terminée et l'octet sync est nécessaire pour distinguer entre l'information du header et les données.
L'information du header figure dans une zone de données longue de 64 octets qui est transmise devant chaque bloc de 2K de données. Dans ce header de fichier figurent les informations sur le fichier lui-même, par exemple le nom, si le fichier est ou non protégé, s'il s'agit d'un programme Basic ou d'un fichier Ascii et quelle est la longueur du programme.

  • Octets 0-15 : Nom du fichier, si moins de 16 octets, rempli avec 00
  • Octet 16 : Numéro de bloc, dans cet octet figure le numéro qui sera affiché lors du chargement ou également avec Catalog.
  • Octet 17 : Si dans cet octet figure une autre valeur que 00, il s'agit du dernier bloc du fichier.
  • Octet 18 : Cet octet contient le type de fichier. L'information est codée dans les différents bits. La signification des bits vient à la suite de ce tableau.
  • Octets 19,20 : Ces octets contiennent la longueur des informations du fichier. Si le bloc, donc les 2 K, est entièrement écrit, ces octets contiennent la valeur &0800. Dans le dernier ou unique bloc, figure ici le nombre d'octets du bloc.
  • Octets 21,22 : Ces octets indiquent l'adresse de chargement, à partir de laquelle les données ont été écrites à l'origine. Pour les programmes Basic, c'est l'adresse décimale 368, pour les fichiers binaires, donc pour le langage-machine, c'est normalement l'adresse où tourne le programme en mémoire.
  • Octet 23 : Si le contenu de cet octet est différent de 0, il s'agit du premier bloc du fichier.
  • Octets 24,25 : Ces octets contiennent la longueur du fichier.
  • Octets 26,27 : Si un programme machine est lancé avec 'RUN "nom du fichier'", le contenu de ces octets du header sera interprété comme l'adresse de début d'un fichier en langage-machine. Le programme sera donc automatiquement lancé à l'adresse indiquée.

Les octets restants 28 à 63 du header ne sont pas utilisés par le système d'exploitation et sont à la disposition des programmeurs chevronnés.

Mais voici maintenant le décodage des bits de l'octet 18 du header:

  • Bit 0 : Si ce bit est mis, le fichier correspondant est déclaré protégé. Les programmes protégés peuvent être produits en Basic avec 'SAVE "NOM",p'
  • Bits 1-3 : Ces bits déterminent le type de fichier. Bien que trois bits permettent 8 différents types de fichier, seuls les types de fichier programme Basic (0), fichier binaire (1) et fichier de données ascii (3) sont utilisés.
  • Bits 4-7 : Ces bits comportent normalement un 0, seuls les fichiers Ascii ont un 1 dans le bit 4.

Comme nous l'avons déjà indiqué, les informations stockées dans les différents blocs sont encore subdivisées en différents segments.
Chaque segment se compose de 256 octets de données et d'octets de check sum (contrôle du total). La check sum de chaque segment est calculée d'après une formule spéciale et permet de vérifier lors de la lecture du fichier si les bits ont été correctement transmis. Dès lors que la checksum calculée ne correspond pas aux valeurs lues, le READ ERROR B est affiché.

Le READ ERROR A indique qu'un bit a été lu dont la durée était trop longue par rapport aux valeurs calculées pour les bits nuls ou 1. Cette erreur se produit souvent, lors de la lecture de programmes, lorsque la cassette, qui coinçait lors de la sauvegarde, est maintenant fluide.

La troisième erreur possible est le READ ERROR D. Cette erreur ne devrait se produire que rarement car elle signale que le bloc lu est plus long que les 2048 octets autorisés. Cela ne peut toutefois se produire que si l'utilisateur écrit dans les informations du header, lors de la sauvegarde, des valeurs plus grandes que celles autorisées.

Vous connaissez certainement l'instruction Basic 'SPEED WRITE par'. Suivant les paramètres utilisés, les données sont stockées sur la cassette à une vitesse moyenne de 1000 ou 2000 baud. Ceci n'atteint cependant pas encore la vitesse la plus grande possible. Par l'utilisation d'une routine du système d'exploitation, la vitesse (baud rate) peut être fixée à toute valeur comprise entre 700 et environ 3600 baud. La routine nécessaire est à l'adresse &BC68. Elle attend des paramètres dans deux registres et fixe la vitesse d'écriture en fonction de ces paramètres. Une valeur est transmise à la paire de registres HL qui détermine la vitesse (baud rate). La formule pour déterminer cette valeur est:
Baud rate=333333/moitié de la longueur d'un bit nul.

Cela donne pour 1000 baud une vitesse de 666 microsecondes pour un bit nul; un bit 1 dure exactement le double.

L'électronique utilisée dans le lecteur de cassette a cependant une particularité.

Si des bits nuls et des bits 1 sont lus tour à tour, l'électronique essaye de combler les différences de durée. Les bits 1 deviennent de ce fait plus courts, alors que les bits nuls apparaissent comme des impulsions plus longues qu'on ne l'aurait attendu après l'écriture. Pour cette raison, une compensation anticipée doit être exécutée et les bits nuls sont écrits plus brièvement, alors que les bits 1 sont écrits avec des durées légèrement plus longues. Ces durées nécessaires pour la compensation anticipée sont transmises à la routine dans l'accumulateur.

Pour des tentatives de fixer la vitesse d'écriture la plus rapide, qui est à moitié fiable, il suffit de transmettre dans l'accumulateur une valeur de 10. Pour écrire avec une vitesse de 3600 baud, il faut activer la routine suivante:

LD HL,93
LD A,10
CALL &BC68
RET

Ces quelques octets peuvent facilement être placés dans la mémoire avec les lignes suivantes:

10 MEMORY HIMEM - 10
20 FOR I = 1 TO 9
30 READ X : POKE HIMEM + I,X
40 NEXT I
50 CALL HIMEM + 1
60 DATA &21 &5D,&00,&3E,&0A,&CD,&68 ,&BC,&C9

Ne craignez pas de faire varier quelque peu les valeurs dans HL et dans l'accumulateur (les deuxième et cinquième valeurs de la ligne de Data), pour déterminer la plus haute fréquence d'écriture possible. Elle dépend des cassettes utilisées. Mais les propriétés de rotation régulière de votre lecteur de cassette jouent également un rôle non négligeable.

Si les valeurs sélectionnées sont trop petites, le CPC ne peut plus alors tenir les durées réclamées et vous obtenez comme résultat le message d'erreur WRITE ERROR A.
Encore un conseil pour finir:

Vous avez certainement remarqué que lorsque vous sauvegardez de très longs programmes avec de nombreuses variables, cela peut durer jusqu'à 15 minutes jusqu'à ce que les données ou le programme soient sauvegardés. Cela vient du fait que le CPC nécessite pour la sauvegarde une zone de 2K pour les blocs à transférer. Ce buffer est placé dans la limite supérieure de la mémoire. Si cette zone est toutefois occupée par des variables, ces variables sont recopiées dans une autre zone de la mémoire. Ce procédé est comparable à la redoutable garbage collection qui se produit toujours lorsqu'il n'y a plus de place suffisante en mémoire pour les chaînes de caractères et les tableaux.

Le délai d'attente provoqué par le transfert des variables peut cependant être notablement réduit si ce buffer de 2K est déjà installé et protégé au début de chaque programme. Un début de programme possible pourrait se présenter ainsi:

10 OPENOUT "DUMMY"
20 MEMORY HIMEM - 1
30 CLOSEOUT
40
50 'RESTE DU PROGRAMME

Ce procédé n'a bien sûr de sens que si vous travaillez dans le programme en question avec des fichiers. Si ce n'est pas le cas, vous pouvez renoncer à ces lignes de programme et entrer simplement l'instruction CLEAR avant la sauvegarde. Toutes les variables définies auparavant seront ainsi supprimées et l'installation du buffer de cassette se fera sans délai notable.

★ ANNÉE: ???

Page précédente : La bible du CPC 6128 : 1.10.03 La connexion du lecteur de disquette
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
Page créée en 058 millisecondes et consultée 1814 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.