CODING ★ AVEC THOR ★

Bidouilles ACPC n°47 - Les vecteurs system (5/6)

Qui ne connait pas ce dieu, si bien remis au goût du jour par les Marvels Comics?

Ce brave médecin, qui d'un coup de canne sur le sol se transforme en dieu arme d'un marteau aux pouvoirs foudroyants. Mais j'y songe, nous aussi nous avons des vecteurs qui nous rendent marteau...

La dernière fois, nous en étions restes aux vecteurs permettant la gestion des RSX. Malheureusement. il nous manquait encore quelques-uns de ces fantastiques outils pour mener à bien notre inquisition au sein du système. Cela n'est plus, car, dans ces pages, vous trouverez quelques informations complémentaires qui vont vous éclairer les points encore obscurs. Les RSX, c'est bien pratique, mais c'est mieux si on peut aussi utiliser les interruptions qui nous permettent de faire tant de jolies choses. Vous savez bien, ces trucs qui sont appelés tout seul 50 ou 300 fois par seconde. De quoi faire de belles choses résidentes et indépendantes du programme principal.

L'AVENEMENT DES ÉVÉNEMENTS

Avant tout. nous devons savoir que les vecteurs qui vont suivre utilisent des blocs d'événement qui permettent au système de travailler avec diverses routines d'interruption fonctionnant a diverses vitesses. Prenons le cas d'un bloc d'événement comme vous en verrez de nombreux si vous utilisez cette forme de programmation. En voici la structure réduite a son plus simple effet :

  • octet 0 et 1 : pointeur système (il en faut)
  • octet 2 : compteur (simple comme compteur)
  • octet 3 : classe (priorité de l'évènement )
  • octet 4 et 5 : adresse de la routine de traitement (facile)
  • octet 6: adresse de sélection de la ROM (0 pour la Ram)

A ces blocs d'évènement viennent se souder des blocs de contra le qui permettent au système de partager le temps d'interruption entre toutes les routines installées, ceci sans trop ralentir le programme principal. Il en existe de deux sortes : une pour les interruptions rapides et l'autre pour les interruptions « lentes ».

LENT, TERNE ET CLAIR

Quoi que 300 ou 50 fois par seconde, on ne peut pas dire que ce soit franchement escargotesque, mais bon... Si vous avez a utiliser les interruptions rapides, soit celles émises par le CRT tous les 1/300' de seconde, il vous sera possible de retrouver un bloc de contrôle d'interruption dont la structure est simple. Les premiers composants en sont un pointeur système sur deux octets, suivis d'un bloc d'évènement de la même structure que celui que nous avons décompose dans le paragraphe precedent . Si vous vous posez les mêmes questions que moL vous verrez que deux pointeurs systèmes se suivent. Va savoir a quoi ((a sert tant de redondance. M'enfin, ils doivent bien savoir ce qu'ils en font
Pour ce qui est des interruptions lentes (pouf pouf !), ils ont un bloc de contrôle un peu plus fourni. En voici sa bête composition:

  • octet 0 et 1 : pointeur système (eh oui ! encore un)
  • octet 2 et 3 : compteur(lorsqu'il passe a zéro, l'interruption est exécutée)
  • octet 4 et 5 : recharge (valeur de recharge du compteur)

Puis suit le bloc d'événement dont nous n'avons cesse de parler df3puis le début

PRECAUTIONS D' UTI LISATION

Un conseil, ne perdez jamais l'adresse d'un bloc de contrôle, car vous pourrez en avoir besoin a maintes reprises. Il est aussi très intéressant de travailler sur les valeurs utilisées par ces blocs de manière a forcer la priorité de telle ou telle action. Il est de plus tellement pratique de savoir exactement ou se trouvent les trucs qui influencent nos programmes. Notez aussi que, parfois, la routine d'interruption n'est pas forcement sur le plan de ROM sélectionne. Dans ce cas, il arrive que le système décide de ne pas lancer votre petit programme en attendant de meilleures conditions pour le faire. Il vaut mieux, alors, déplacer la routine d'interruption dans les 32 Ko de mémoire centrale, ce qui permet de la voir lancée presque a tous les coups, si le niveau de priorité est bien entendu assez fort Analysez bien les blocs de contrôle. Dans la majeure partie des cas, il est possible de réinitialiser les valeurs de contrôle, ainsi que celles de priorité, pour permettre le lancement systématique de son programme. A vous de tripoter...

VECTORISEZ

Comme pour les mois précédents, nous vous donnons 4 indications par vecteur passe en revue:

  1. l'adresse d'appel (indispensable voire primordiale) ;
  2. un bref commentaire sur la raison d'être (ce qu'il fait) ;
  3. les conditions d'appel passées dans les registres ;
  4. les conditions finales, soit les résultats de l'action émise ainsi que les registres ou zones modifies.

En voiture Thor, et sans tarder.

. BCD7 : initialisation et déposé d'un bloc d'événement dans la liste de ceux a activer lors d'une interruption en provenance du CRT .
Lorsque vous appelez ce vecteur, il met tout en ordre pour que la routine citée soit appelée a chaque fois qu'il est possible.
CA: contient l'adresse du bloc d'événement ;
B contient la classe de l'événement;
C contient l'adresse de sélection de la Rom;
DE contient l'adresse de la routine a insérer dans la file des événements temporises.
CF: AF, DE et HL modifies.

. BCDA: déposé d'un bloc d'événement dans la liste de ceux a activer lors d'une interruption en provenance du CRT
Comme il est possible d enlever un bloc d'événement dans la file d'attente avec le vecteur suivant, il est possible de le remettre avec celui-ci.
CA : HL Contient l'adresse du bloc d'événement;
CF : AF, DE et HL modifies.

. BCDD : enlève un bloc d'événement de la liste de ceux a activer lors d'une interruption en provenance du CRT
Voir la légende du vecteur précédent
CA : HL contient l'adresse du bloc d'événement ;
CF : AF, DE et HL modifies.

. BCE0 : initialisation et dépose d'un bloc d'événement dans la liste de ceux a activer lors d'une interruption rapide (tous les 1/300' seconde)
S'il te plaît, monsieur le système, peux-tu me lancer cette routine 300 fois par seconde ? Pas de problème Batman, on y va...
CA: HL contient l'adresse du bloc d'événement;
B contient la classe de l'événement;
C contient l'adresse de sélection de la Rom;
DE contient l'adresse de la routine a insérer dans la file des événements temporises.
CF : AF, DE et HL modifies

. BCE3 : pose d'un bloc d'événement dans la liste de ceux a activer lors d'une interruption rapide
Le même vecteur que &BCDA mais pour les interruptions rapides.
CA: HL contient l'adresse du bloc d'événement
CF : AF, DE et HL modifies.

. BCE6 : enlevé un bloc d'événement de la liste de ceux à activer lors d'une interruption rapide
Comme &BCDD mais pour les interruptions au 1 /300'
CA: HL contient l'adresse du bloc d'événement
CF: AF, DE et HL modifies.

. BCE9 : dépose simple d'un bloc d'événement dans la liste de ceux il activer lors d'une interruption normale (tous les 1/50' seconde)
Attention! ici le bloc d'événement n'est pas initialise. Il faut utiliser le vecteur BCEF pour cela.
CA: HL contient l'adresse du bloc d'événement;
DE contient la valeur a installer dans le compteur ;
BC contient la valeur de recharge de ce compteur lorsqu'il atteint la valeur O.
CF : AF, BC, DE et HL modifies

. BCEC : enlevé un bloc d'événement dans la liste de ceux à activer lors d'une interruption normale.
Il est possible de suspendre le lancement de certaines routines lentes sans pour autant les enlever de la file d'attente.
CA: HL contient l'adresse du bloc d'événement
CF : si le bloc d'événement appartenait bien a la liste, la retenue est vraie et DE contient la valeur du compteur. Dans tous les cas, AF, DE et HL modifies.

. BCEF : initialise un bloc d'événement de manière à ce qu'il soit gérable par les deux vecteurs precedents
Installer un événement dans une liste, c'est bien mais encore faut-il que la zone de mémoire concernée soit réellement un bloc de contrôle. C'est ici que nous le créons.
CA: HL contient l'adresse du bloc d'événement;
B contient la classe de l'événement;
C contient l'adresse de sélection de la Rom;
DE contient l'adresse de la routine;
CF: AF et DE sont modifies et HL contient l'adresse du bloc d'événement augmentee de 7 octets.

. BCF2 : actionne un bloc d'événement
Des compteurs sont mis en action lors des appels des interruptions. Le fait de passer par ce vecteur permet le lancement conditionnel de la routine tout en modifiant les compteurs et les priorités mis en œuvre.
CA: HL contient l'adresse du bloc
d'événement
CF: les registres sauf IX et IY sont
modifies en fonction de la routine appelée.

.BCF5 : fait le ménage dans toutes les files d'attente d'événements temporises
CA : rien a configurer.
CF : AF et HL sont modifies.

. BCF8 : détruit un événement en l'enlevant physiquement de la file d'attente
CF : HL contient l'adresse du bloc d'événement.
CA : AF, BC, DE et HL modifies.

. BCFB: recherche de l'événement suivant a traiter
Cela permet de savoir si des taches restent a remplir ou non.
CA: rien à faire.
CF: si une routine est trouvée, la retenue est vraie et HL contient l'adresse du bloc d'événement. De toute manière, AF, DE et HL sont modifies.

. BCFE : traite un bloc d'événement
Dans ce cas, le lancement de la routine associée au bloc n'est pas force.
CA : HL contient l'adresse du bloc d'événement.
CF : AF, BC, DE et HL modifies.

. BD01 : termine le traitement d'un événement
Permet de modifier les niveaux de priorité des événements vises. Le système réalise cette opération en fonction des priorités de tous les événements.

. BD04 : interdiction des événements temporises normaux
Les files d'attente d'événements ne sont plus scannées.
CA: rien.
CF: HL est modifie.

. BD07 : réautorise les événements temporises conventionnels Quand on a utilise le vecteur précèdent. On peut inverser l'action avec celui-ci.
CA: aucune.
CF: HL est modifie.

. BD0A : interdit un événement
Ce vecteur permet de stopper l'action d'un événement sans pour autant perdre du temps avec la gestion de la file d'attente.
CA: HL contient l'adresse de l'événement.
CF: AF est modifie.

. BD0D : donne le temps écoule en 1/300' de seconde depuis l'allumage du CPC
CA: rien a prévoir.
CF: DEHL forme le nombre demande sur 32 bits.

Voila, il ne nous reste plus qu'a passer en revue l'interfaçage avec le matériel. Et c'en est fini des interruptions. Notez que pour posséder ces dernières, rien ne vaut le fait de les utiliser a fond et de les analyser au microscope. En attendant je m'interromps...

Sined le Barbare tabac, ACPC n°47, avril 93, p38, 39

Page précédente : Bidouilles ACPC n°46 - Les vecteurs system

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

Lien(s):
» Coding » Bidouilles ACPC n°32
» Coding » Bidouilles ACPC n°36 - Direct disk Access
» Coding » Assembleur ACPC n°25
» Coding » Bidouilles ACPC n 03 - Les Instructions supplemetaires du Z80
» Coding » Bidouilles ACPC n°37 - FDC en mode direct
» Coding » Assembleur ACPC n°45 - Le directeur rit ( Modification du catalogue AMSDOS )
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 337 millisecondes et consultée 2185 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.