Documentation

Le bus système est défini comme étant l'ensemble de liens entre les composants permettant d'échanger données, adresses et signaux de contrôle. Ce système a plusieurs responsables de bus. Deux d'entre eux (Suzy et le CPU) réalisent des fonctions qui n'ont pas besoin du bus système mais qui utilisent des bus internes. Il a été défini que ces activités sur un bus interne seraient reflétées sur le bus système chaque fois que ce serait possible et sans utiliser les signaux pertinents (ni RAS ni CAS).

Pour permettre des opérations simulatanées de différents responsables de bus sur leur bus propre et des opérations génériques sur le bus système, le résultat est l'intercalage des adresses de responsables de bus. Ca élimine l'avantage de performance que représente le mode page. N'importe quel gain de performance grâce aux opérations simultanées est lié à la quantité d'activités requise autre que celles du bus système et reste limité par la bande passante du bus système. L'analyse de l'activité des deux responsables de bus indique qu'on aura de meilleurs performances avec des opérations classiques en utilisant le mode page qu'en utilisant des opérations simultanées avec une efficacité réduite du bus.

Il y a, en outre, une situation dans Suzy où le bus pourrait être réattribué à Mikey pendant que Suzy traite une fonction interne. Dans ce cas, la fonction interne à Suzy sera autorisée à continuer pendant que Mikey utilise le bus. A la fin de la fonction interne, Suzy s'arrêtera.

Nous allons autoriser uniquement un responsable à être opérationnel sur le bus système à un instant donné.

Les responsables de bus sont (par ordre de priorité) :
1) Vidéo
2) rafraichissement
3) CPU
4) Suzy

Vidéo et rafraichissement pourront être déclenchés simultanément chaque fois que c'est possible. Ca permettra de réduire la surcharge que représente la prise du bus à Suzy.

Il n'y a pas d'utilisateur par défaut du bus. Si personne ne le veut, il reste inutilisé. Quand il est dans cette condition, le système est "en veille".

NOTE IMPORTANTE : La veille est défectueuse dans Mikey. Voir la spec matérielle.

Il existe deux lignes de validation entre les composants, la demande de bus, et son octroi. La demande de bus vient de Mikey et est le résultat du "ou" logique des requêtes de bus du CPU, la vidéo et le rafraichissement. L'octroi de bus vient de Suzy et est généré par le contrôleur de bus de Suzy.

1) Contrôleurs de bus
Il y a deux contrôleurs de bus, l'un dans Mikey, l'autre dans Suzy. Le contrôleur de Mikey gère le CPU, la vidéo, le rafraichissement et l'octroi en provenance de Suzy. Le contrôleur dans Suzy gère les éléments internes à Suzy, la requête de bus de Mikey et l'octroi de bus à Mikey.

2) Contrôleur de bus de Suzy
Internes/Externes

Afin de maintenir une grande efficacité du bus dans Suzy, il n'est pas question de céder le bus sur n'importe quel cycle. Suzy aura donc des cycles dans lesquels il sera possible de donner le bus en réponse à une demande de Mikey. La connaissance de ces cycles est disponible pour les composants des lignes de confirmation du bus.

Confirmation de bus externe de Suzy

Suzy a une bascule d'activation du bus qui est contrôlée par le CPU. Si la bascule est réinitialisée, Suzy cèdera le bus lors de son prochain cycle approprié et ne tentera pas de le reprendre. La bascule est réinitialisée par le CPU et par le signal de réinitialisation du système. Quand la bascule est positionnée par le CPU, Suzy peut alors gérer la ligne de requête de bus de Mikey et quand il est désactivé, Suzy peut prendre le bus. Dès que Suzy commence à prendre le bus, la ligne d'octroi du bus sera mise à "0". Suzy ne le fera que si le besoin de bus est effectif. Après l'avoir récupéré, Suzy ne pourra le relâcher que pour deux raisons. La première est que Suzy a terminé avec la tâche en cours et qu'il n'y a plus besoin du bus. La deuxième est que le signal de requête de bus est survenu de la part de Mikey.

L'état éteint de la bascule d'activation de bus de Suzy ne modifie pas et ne réinitialiser pas le fonctionnement interne de Suzy. Ipeut être positionné ou éteint par le CPU à n'importe quel moment sans perturber les activités de Suzy en interne. La bascule contrôle seulement les accès au bus de Suzy. Quand Suzy effectue une fonction qui a besoin du bus, il va probablement se mettre en pause jusqu'à ce que le bus devienne disponible.

3) Contrôleur de bus de Mikey
Le contrôleur de bus de Mikey a 3 demandeurs pour son bus, le CPU, la vidéo et le rafraichissement. Après la réinitialisation du système, la vidéo et le raffraichissement sont désactivés et la requète du CPU est activée. Le CPU, quand c'est nécessaire, peut activer la vidéo et le raffraichissement pour qu'ils demandent le bus. Voyez la description des états de la machine (annexe 7) pour le détail cycle par cycle de l'aquisistion du bus.

1- Libération du bus par le CPU
Quand le CPU veut libérer le bus système (soit pour se mettre en veille, soit pour autoriser Suzy à le prendre), il réinitialise sa bascule de requête de bus. Cette bascule peut uniquement être réinitialisée par le CPU. Elle peut être positionnée par une réinitialisation système, n'importe quelle interuption non masquée et l'activation d'un octroi de bus de Suzy (oups !! Le retour d'un octroi de bus depuis une requête générée par un rafraichissement ou par la vidéo ressemble à un front de fin de tâche de Suzy. Je ne sait pas comment les identifier séparément !!!) (Peut être qu'on peut générer une impulsion sur la ligne d'octroi en faisant éteint allumé éteint allumé. Ce n'est pas un signal naturel et il pourra être détecté par la bascule du CPU.). Une attention particulière est nécessaire pour la conception matérielle pour ne jamais rater le front d'octroi de bus ou pour mal l'identifier. Quand le CPU réinitialise sa bascule de requête de bus et qu'aucun autre responsable de bus de Mikey demande le bus alors la ligne de demande bus repasse à l'état bas. Si Suzy veut le bus, il n'y a plus qu'à le prendre. Sinon, personne ne veut le bus et le système va alors passer en veille.

NOTE IMPORTANTE : La veille est défectueuse dans Mikey. Voir la spec matérielle.

2- Requête de bus CPU
Une fois que le CPU a libéré le bus, il ne le récupèrera que quand sa bascule de requête sera paramétrée comme décrit ci-dessus. Quand sa récupération est paramétrée, l'une des situations suivantes se produit :
¤ Réinitialisation Système. Cette condition est décrite ailleurs.
¤ Octroi de bus par Suzy. Suzy a fini sa tâche et le CPU peut désormais reprendre son traitement. Suzy a déjà positionné l'octroi de bus donc quand le CPU aura besoin du bus, il l'aura.
¤ Interruption. Si personne n'a le bus (cad que le système est en veille) le CPU va le prendre dès qu'il en aura besoin. Si Suzy a le bus, Suzy gère la ligne de demande de bus et l'octroie à Mikey dès que voulu.

3- Requête Vidéo ou Raffraichissement.
Les circuits de vidéo et de raffraichissement demandent régulièrement le bus sauf s'ils sont désactivés. Quand cette requète survient, l'un des cas suivants survient :
¤ Le CPU a le bus. Lors du cycle approprié dans les états de la machine, le contrôleur de bus va mettre en pause l'horloge du CPU et donner le contrôle au demandeur vidéo ou raffraichissement.
¤ Suzy a le bus. Mikey envoit la ligne de requête de bus à Suzy. Au moment approprié dans le cycle de Suzy la ligne d'octroi est activée. A ce moment, le contrôleur de bus de Mikey donne alors le contrôle au demandeur vidéo ou raffraichissement.
¤ Le système était en veille. Personne n'a le bus et le contrôleur de bus va le donner au demandeur.

4) Demandes/Autorisations du bus
En résumé, le fonctionnement de chaque acteur du bus peut être cantonné à son propre fonctionnement comme ceci :
1- Suzy a une bascule d'activation du bus. Si elle est active, Suzy peut participer au fonctionnement du bus. Si non, Suzy ignore les requête de bus et fournit systématiquement les octrois.
2- Quand la bascule d'activation du bus est activée et que Suzy veut le bus alors Suzy va gérer la ligne de requête de bus. Quand la ligne de requête de bus s'active, Suzy va (éventuellement) laisser le bus et activer la ligne d'octroi.
3- Quand Suzy en a fini avec le bus, il sera restitué par un positionnement (ou une impulsion) de la ligne d'octroi.
4- Quand la vidéo veut le bus, elle positionne sa ligne de requête de bus. Eventuellement, elle pourra voir que ça a fait de lui le détenteur du cycle et dans ce cas là, elle procèdera. Quand elle a fini, elle va réinitialiser sa ligne de requête de bus.
5- Quand le rafraichissement veut le bus, il positionne sa ligne de requête de bus. Eventuellement, il pourra voir que ça a fait de lui le détenteur du cycle et dans ce cas là, il procèdera. Quand il a fini, il va réinitialiser sa ligne de requête de bus.
6- Quand le CPU veut le bus, le décideur de ce besoin va positionner les lignes de requête de bus du CPU. Eventuellement, il pourra voir qu'il a été désigné détenteur du cycle et il procèdera. Quand il aura fini, il va réinitialiser sa ligne de requête de bus.
7- Le "OU" logique dues signaux de requête de bus du CPU, de la vidéo et du raffraichissement sont envoyés par Mikey à Suzy comme un signal inter-composants de requête de bus.