Si je veux afficher une image il faut que je sois en mesure d’écrire dans la mémoire afin de vérifier que son affichage est conforme. C’est ce que j’entame d’abord pour la mise en place de l’adressage sur le CPLD correspondant puis les données sur le second CPLD.
Un moyen aisé de vérifier que cela se passe bien est de valider lorsque le TRS-80 affiche MEMSIZE ? en relisant la ROM décodé on peut remarque qu’il procède à un cycle d’écriture/relecture de toute la mémoire et s’arrête lorsqu’il constate une erreur.
Avant la mise en place de la mémoire supplémentaire un TRS-80 disposant de 16ko affiche 15570 octets disponibles. Un bon fonctionnement de la mémoire doit provoquer une mémoire disponible 48338 octets. Les premiers essais sont fastidieux, et j’ai du mal à obtenir quelques octets de plus et leur nombre n’est même régulier.
Fort heureusement mon oscilloscope me permet de mettre en évidence des ‘glitch‘ qui viennent interférer et provoquer des fronts non désirés qui perturbent le fonctionnement de la carte. Je retrouve ces pics sur l’alimentation sur les signaux du TRS, un peu partout quoi.
Je conclus que ceux-ci ont pour origine le CPLD et sont provoqués par une mauvaise gestion des signaux de commande des bascules. Il faut dire que c’est la première fois que j’utilise ces puces et les CPLD d’une manière générale.
Prenons un exemple pour expliquer ce phénomène.
MA0.d = A0 ;
MA0.ck = CLK & !MCY2 ;
MCY2 est un signal qui change d’état avec CLK, donc sur un front montant de CLK si MCY2 vaut ‘0’ la valeur passe à ‘1’. Elle repasse à ‘0’ 10ns après, puisque MCY2 qui dépend également de CLK peut changer d’état sur ce même front. Cela provoque un ‘glitch’ une activation parasite provoquée par une écriture de Noob.
Je prends donc soin de réécrire mes équations avec des horloges les plus simples et lorsque cela est possible en utilisant uniquement le signal issu de l’oscillateur 15 MHz, et le problème est résolu.
MA0.d = A0 & !MCY2 ;
MA0.ck = CLK ;
Afin de bien tester mes signaux, étant donné que je n’ai pensé à mettre de point tests sur ma carte, je retire une des deux mémoires afin de pouvoir y connecter mon oscilloscope. Et, en y regardant de plus près je m’aperçois que les données et certaines adresses ne matchent pas.
Je découvre quatre inversions sur le bus de données et deux inversions sur le bus d’adresse de la mémoire. Ce n’est pas grave, cela représente quelques coupures de pistes et six straps supplémentaires.
Ce ne seront pas les dernières car au fur et à mesure que j’avance dans la programmation, même si j’ai prévu huit signaux de communication entre les deux CPLD il va m’en falloir finalement plus. De file en aiguille ma jolie carte toute propre est devenue ce joyeux plat de spaghettis.
Le dernier problème important devant être réglé et le décalage des pixels avec les signaux de synchronisation. D’une part l’image était décalée de quelques pixels et d’autre part il y avait deux octets de décalage dans la mémorisation de l’image. Afin de régler ce problème il m’a fallu retarder le démarrage du compteur d’adresse de deux octets et le début d’échantillonnage de quelques pixels avec des compteurs donc des bascules supplémentaires.
Plus embêtant encore, dans l’impossibilité d’afficher les 12 derniers bits. Diagnostiquant, à tort, les effets du retard du compteur d’adresse, je me suis rendu compte que le signal issu de l’ordinateur supposé encadrer l’affichage d’une ligne n’était plus actif pour les douze derniers bits. Il m’a donc fallu recréer le même signal prolongé de ce délai.
A partir de ce moment le développement des fonctionnalités n’a plus trop posé de problèmes et le projet a avancé très rapidement. Le partage en deux CPLD adresses et données c’est avéré un bon choix, compte tenu de leurs capacités ; Le CPLD traitant des adresses a vu ses limites par le nombre d’entrées sorties utilisées alors que le CPLD traitant des données a été plus limité par l’utilisation de ses cellules et sa logique interne.
Dès lors il a fallu faire des compromis ; Faute de ressources j’ai abandonné quelques idées afin d’être en mesure d’implémenter d’autres qui me paraissaient plus utiles.
Maintenant la carte arrive à son fonctionnement nominal, en commençant à m’intéresser à l’écriture d’un jeu, je me rends compte qu’il est dommage de se limiter à 192 points de haut alors qu’il y a de la mémoire et que mon premier jeu en demande plus. En abandonnant à nouveau une ou deux idées et en optimisant mes équations, je parviens à finalement à afficher une résolution de 384x256 points avec la possibilité de positionner l’écran de vidéo native ave une décalage vertical réglable (puisqu’il reste, lui, avec ses 192 points de haut).
Et après, c’est fini ?
Le problème de ce type de projet, c’est qu’ils sont sans fin. Au cours de mes tests, notamment dans ma recherche de synchronisation, j’ai fait fonctionner la carte avec une horloge double soit 30MHz, divisée par deux dans les CPLD. Tout à fonctionné à merveille, cela grâce aux performances retenues pour les composants. Donc, en créant plus de cycles, il serait possible de raccorder un troisième CPLD qui pourrait lire et modifier des données dans la mémoire.
Ce pourrait être des fonctions de remplissage, tracés de droites, copie de blocs, etc…, mais c’est un autre projet…