Emulation matérielle

J’ai un système basé sur le 6502 que je peux programmer librement. L’objectif maintenant est d’ajouter des LEDs et des boutons pour pouvoir écrire des programmes interactifs.

Le rôle du 6522

Le 6502 seul n’est pas en mesure de piloter directement des LEDs et des boutons, car les seules choses qu’il peut faire directement c’est lire et écrire sur les bus d’adresse et de données. Pour piloter une LED ou lire un bouton il faut un système intermédiaire qui s’interface avec la LED ou le bouton d’un côté, et communique avec le CPU via le bus de l’autre côté.

Le 6522 est une puce d’interfaçage conçue pour fonctionner avec le 6502. Son nom en anglais est Versatile Interface Adatper, je l’appelle donc “VIA” pour faire court. Le VIA propose plusieurs fonctions complémentaires, notamment des timers, mais ce qui nous intéresse ici ce sont les deux ports parallèles d’entrée-sortie. Il s’agit de 16 lignes qui peuvent être configurées individuellement en entrée ou en sortie, et qu’on va pouvoir lire ou écrire depuis le CPU.

Le VIA possède 16 registres de contrôle dans lesquel le CPU va lire ou écrire via le bus de données pour réaliser les fonctions souhaitées. Pour sélectionner le registre dans lequel on veut lire ou écrire, on utilise le bus d’adresse. Comme on a que 16 registres, 4 lignes d’adresse suffisent.

Chip Select et espace d’adressage

Jusqu’à maintenant on avait qu’un seul composant connecté aux bus d’adresse et de données : l’EEPROM. On va maintenant ajouter le VIA, et il faut donc s’assurer que le CPU puisse communiquer avec chaque composant sans perturber les autres ou être perturbé par leur présence sur le bus. Pour ça on utilise le Chip Select (aussi appelé Chip Enabled). C’est un signal qui permet d’activer le composant avec lequel le CPU cherche à communiquer à un instant donné. Chaque composant possède une ou plusieurs entrée pour ce signal, et ne prennent le contrôle du bus que lorsque le signal les y autorise. Le reste du temps les pins connectées au bus sont électroniquement déconnectées du bus (dans ce qu’on appelle un état de haute impédance).

Pour déterminer quel composant doit être actif on utilise le bus d’adresses. Avec 16 lignes d’adresse le CPU peut produire 65 536 adresses différentes. Ces 65 536 adresses constituent ce qu’on appelle “l’espace d’adressage”, et l’idée est de découper cet espace d’adressage en plusieurs plages et d’attribuer une plage à chaque composant. Pour ça on utilise des lignes d’adresse judicieusement choisies pour générer le signal Chip Select pour chaque composant.

Jusqu’à maintenant j’avais forcé le Chip Select (signal /CE) de l’EEPROM pour qu’elle soit toujours active. L’intégralité de l’espace d’adressage lui était par conséquent attribuée. La ROM possède seulement 15 lignes d’adresse (32k adressable), et on avait laissé la 16e ligne déconnectée. Par conséquent quand le CPU utilise une adresse dans la plage 0x0000-0x7FFF, ça correspond directement à une adresse dans la ROM. Mais c’est également le cas pour les adresses 0x8000-0xFFFF car si on ne prend en compte que les 15 premiers bits de l’adresses, les adresses sont identiques. Du point de vue du CPU le contenu de la ROM apparait dupliqué.

La 16e ligne d’adresse (A15) étant inutilisée pour adresser les données dans la ROM, on peut l’utiliser pour le Chip Select. Si on la connecte directement sur l’entrée /CE de la ROM, étant donné que la puce est activée si le signal est à 0, celle-ci ne répondra plus qu’aux adresse dans la plage 0x0000-0x7FFF. On a ainsi alloué la plage 0x0000-0x7FFF à l’EEPROM et libéré le reste pour d’autres composants. Cependant, rappelons-nous qu’au démarrage le CPU interroge les adresses 0xFFFC et 0xFFFD (vecteur reset), et dans cette configuration de la mémoire ça ne fonctionnerait pas. On pourrait rajouter un composant dont la tâche est de répondre spécifiquement à ces deux adresses, mais on devrait alors veiller à mettre à jour la valeur en fonction d’où on place le début du programme dans la ROM. Le plus simple est en fait d’allouer la plage 0x8000-0xFFFF à la ROM. On peut faire ça en inversant A15 (avec une porte logique NOT) avant de le connecter sur /CE. Ainsi l’adresse 0x7FFC dans la ROM correspondra à l’adresse 0xFFFC du point de vue du CPU. En revanche, l’adresse 0x0000 de la ROM se retrouve à l’adresse 0x8000 du point de vue du CPU. Il faudra donc être vigilant lors de l’écriture du programme.

On peut maintenant réfléchir à l’espace mémoire à allouer au VIA. On sait déjà que cette plage doit être comprise dans la plage 0x0000-0x7FFF. On pourrait allouer toute la plage, et tant qu’on ajoute pas d’autres composants sur le bus ça ne pose pas de problème. Mais je prévois d’ajouter au moins une puce de RAM par la suite, donc essayons de faire mieux que ça. Pour rappel le VIA n’a que 16 registres, la plage d’adresse n’a donc besoin de contenir au minimum que 16 adresses. Elle peut évidemment être plus grande que ça.

Je commence à être à court de breadboards, et celles déjà utilisées sont déjà bien chargées, je voudrais donc une solution qui utilise un minimum de connexions et un minimum de composants. Le VIA possède deux signaux Chip Select : CS1 et /CS2. La puce est activée lorsque CS1 est à 1 et /CS2 à 0. On sait déjà que le VIA doit être désactivé lorsque la 16e ligne d’adresse (A15) est à 1, puisque ça correspond à la plage allouée à la ROM. On peut donc connecter A15 sur /CS2. Si on s’arrête là on a effectivement alloué la plage 0x0000-0x7FFF au VIA. Imaginons maintenant qu’on branche A14 sur CS1. Le VIA ne serait alors actif que lorsque la 16e ligne d’adresse (A15) est à 0 et la 15e (A14) est à 1, ce qui correspond à la plage d’adresses 0x4000-0x7FFF. Si on ajoutait A13 avec un ET on réduirait à la plage 0x6000-0x7FFF. Et si on ajoutait encore A12 ça donnerait 0x7000-0x7FFF. Plus on réduit la plage mémoire allouée et plus on laisse de l’espace pour autre chose, mais plus ça demande de logique pour le Chip Select.

Je choisis de rester simple pour l’instant et de m’arrêter à A14. Ça permet de connecter CS1 et /CS2 diretement sans introduire de logique supplémentaire, et le compromis en terme d’allocation de l’espace d’adresse est ok pour l’instant.

Résumé des connexions à faire :

Montage de l’EEPROM avec Chip Select et test du programme

Je veux installer le VIA et la logique du Chip Select de manière semi permantente sur une grande breadboard que j’assemble avec celle du 6502, mais je n’ai plus de grande breadboard. J’en ai commandé des nouvelles, mais en attendant de les recevoir je fais un montage temporaire sur une petite breadboard, en faisant les connexion avec des lignes Dupont. Ça ne me laissera pas assez de Duponts pour monitorer les bus avec l’Arduino, mais tant pis.

Pour faire simple j’utilise une puce 74LS04 qui contient 6 inverseurs et je la place sur la breadboard du 6502 après l’espace réservé à la ROM. C’est temporaire car je prévoie de mettre la RAM à cet endroit par la suite. J’alimente le 74LS04, j’amène A15 sur l’entrée du premier inverseur, je retire le fil de connexion qui maintenait /CE de la ROM à la masse, et je branche la sortie de l’inverseur à la place.

Avant de passer à l’installation du VIA et immobiliser les fils de connexion, il faut reprogrammer la ROM. Pour éviter de reprogrammer si jamais ça ne fonctionne pas comme prévu du premier coup (ce qui demande pour l’instant de recâbler l’Arduino à chaque fois, ce n’est pas très pratique), j’essaie de faire un programme dont les effets sont reconnaissables sans ambiguité. J’imagine un programme qui allume 3 LED avec un motif alternatif 010-101. Il n’est pas nécessaire de faire appel à un compteur ou un timer, avec une horloge suffisamment lente on verra le motif clignoter sans soucis même si les instructions se suivent directement sans délai.

C’est le moment de se pencher plus en détails sur le fonctionnement du VIA. Pour configurer les pins du port A en sortie il faut écrire dans le registre 3. Un bit à 1 dans ce registre configure le pin correspondant en sortie. Ensuite pour définir la valeur sur le pin il faut écrire dans le registre 1. Vue le mapping mémoire que nous avons fait précédemment, l’adresse à utiliser pour les registres 1 et 3 sont respectivement 0x4001 et 0x4003.

Basiquement notre programme ressemble donc à ça :

1. écrire 1111 1111 (0xFF) à l’adresse 0x4003
2. écrire 0000 0010 (0x02) à l’adresse 0x4001
3. écrire 0000 0101 (0x05) à l’adresse 0x4001
4. recommencer à 2.

En pseudo code machine ça donne ça :

1. LDA #$FF
2. STA $4003
3. LDA #$02
4. STA $4001
5. LDA #$05
6. STA $4001
7. JMP $XXXX

Explications: Pour écrire une valeur donnée dans un registre du VIA, on charge d’abord la valeur dans l’accumulateur, puis on envoie la valeur de l’accumulateur à l’adresse du registre. L’instruction JMP permet de déplacer le pointeur d’exécution à l’adresse indiquée. Ici on veut revenir à l’instruction LDA #$02 pour former une boucle infinie. Pour définir l’adresse à donner à l’instruction JMP il faut connaître à quelle adresse exacte se situe l’instruction visée. Pour ça il faut :

• savoir à quelle adresse commence le programm dans la mémoire
• combien d’octets occupent les instructions qui précèdent
• prendre en compte l’allocation de l’espace d’adressage défini précédemment

Pour faire simple on peut placer le programme à l’adresse 0x0000 dans la mémoire, ce qui correspond à 0x8000 du point de vue du CPU. Il faudra donc penser à placer cette valeur dans le vecteur reset.

Nous avons déjà rencontré l’instruction STA précédemment. Le code correspondant est 0x8D, et l’adresse est passée dans les deux octets suivants, les poids faibles en premier. Nous avons également déjà rencontré l’instruction LDA, mais nous avions utilisé la version qui prend une adresse, alors qu’ici nous voulons lui passer la valeur directement. On aurait pu mettre la donnée en mémoire et utiliser LDA avec l’adresse correspondante, mais pourquoi faire compliqué. Dans la datasheet on trouve que le code pour LDA en mode d’adressage immédiat est 0xA9, et la valeur est indiquée dans l’octet qui suit. Regardons maintenant l’instruction JMP. Elle existe aussi dans plusieurs mode d’adressage, ici nous voulons le mode “adressage absolu” qui prend une adresse. Le code correspondant est 0x4C, et l’adresse est indiquée sur les deux octets suivants, poids faibles en premier comme d’habitude.

Voici le programme final :

On voit que l’instruction LDA #$02 si retrouve à l’adresse 0x8005, c’est donc cette valeur qu’on donne au JMP. Je programme la ROM avec le setup défini précédemment, et je la remet en place sur le circuit.

Avant d’installer le VIA je vérifie que le Chip Select fonctionne comme prévu et que le programme est bon. Je branche l’Arduino sur le bus et observe les données, toujours avec uniquement les 4 premières lignes d’adresse. Voici le résultat :

Tout est conforme.

Montage du VIA

Je peux maintenant enfin installer le VIA. Je place le 6522 sur une petite breadboard, et je connecte tout de suite VDD et VSS. J’ajoute 3 LEDs à côtés avec leur résistance et je connecte les LEDs aux 3 premières sorties du port A. Je passe en revue le reste des pins. Il faut connecter :

• les 8 lignes de données (D0 à D7)
• les 4 lignes adresses (A0 à A15)
• le signal d’écriture/lecture (/RW)
• la clock (PHI2)
• le reset (/RES)
• CS1 et /CS2

Nous n’utilisions pas le signal d’écriture/lecture (/RW) jusqu’à présent puisque la ROM n’est utilisée qu’en lecture. Mais le VIA peut-être utilisé en lecture et écriture, même si notre programme de test ne fait pour l’instant qu’écrire. Les signaux d’horloge et de reset peuvent être repris directement sur ceux du 6502. Je branche donc tout ça, l’Arduino fournit le signal d’horloge comme d’habitude.

Je lance, fait un reset, mais ça ne fonctionne pas, les diodes restent éteintes. Ça me laisse perplexe. Je teste d’abord les LEDs en amenant directement le 5V dessus et elles s’allument bien. J’observe ensuite les valeurs en sortie du VIA avec Arduino, et elles restent toutes à 0. De la même manière je vérifie les signaux CS1, /CS2, la clock, et /RW, et tout semble correcte. /RW est à 1 la plupart du temps pour indiquer une lecture, et passe à 0 de temps en temps pendant exactement un cycle. Idem pour CS1 et /CS2 qui prennent bien les valeurs attendues.

J’entreprends alors d’essayer de piloter le VIA directement avec l’Arduino pour vérifier que j’arrive à le faire fonctionner en envoyant manuellement des commandes et confirmer que le programme de test envoie bien les bonnes commandes. Sur la breadboard je force /CS1 à 1, /CS2 à 0, et /RW à 0. Avec le code je fais un reset en mettant à /RES à 0 et en faisant quelques cycles d’horloge, puis j’envoie les octets pour configurer le port A, mais toujours rien de visible. J’essaie avec le port B et toujours rien. À ce moment je commence à soupçonner mon VIA d’être défectueux.

Je tente de lire les entrées sur les ports. J’ajoute /RW dans le code pour pouvoir lire/écrire, et je connecte directement le 5V sur une des pins d’entrées. Là je réalise que les LEDs sont toujours connectées au port A alors que je teste le port B. Je corrige ça et relance le test précédent mais toujours rien. Je fais le teste de lecture et je lis 0. Ça me laisse vraiment perplexe.

Le code Arduino est disponible sur GitHub.

La suite

Je n’arrive pas à faire fonctionner le 6522, mais en revoyant la vidéo de Ben Eater consacrée à son installation j’ai l’idée de construire un latch comme il l’a montré dans cette vidéo, et d’essayer de l’interfacer avec le CPU. C’est un exercice intéressant. Si ça fonctionne ça permettra d’avoir déjà une sortie pilotable par le 6502, et donc d’avoir enfin des résultats observables directement et d’écrire des programmes qui font quelque chose.