[MZ-700] Recréation sur un CPLD du LSI, un GATE ARRAY en charge de la vidéo et du décodage des adresses.

[hlide]

Je suis parti sur un VHDL déjà existant fait pour dépanner un MZ-1500 dont le LSI était mort (entre lui et le MZ-700, c'est le même LSI). Le problème, c'est que cette version a simplifié la gestion des signaux d'horloge et vidéo en ne gérant que le NTSC. J'ai donc essayé de rajouter la gestion PAL pour que le LSI soit le plus complet par rapport à l'original.

1) Le fréquence principale sur la carte-mère est de ~14 MHz pour les versions japonaises qui sortent en NTSC et de ~17 MHz pour les versions occidentales qui sortent en PAL.
2) Une broche appelée NTPL sert à indiquer au LSI si on souhaite du NTSC ou du PAL et donc de générer l'horloge Z80 en conséquence. Une division par 4 de la fréquence principale en NTSC et une division par 5 pour PAL.

J'utilise Quartus II 13.0.1 et le CPLD est un MAX V 5M160ZE64C5. J'ai gardé ce CPLD pour pouvoir réutiliser le PCB existant quite à faire une retouche mineure je l'espère (remplacer la fonction ABC qui sort toujours un 0 et ne sert à rien, par NTPL pour enfin avoir la possibilité de gérer aussi bien du NTSC que du PAL).

Initialement, j'avais ça :

original_cpld.png (5.76 Kio) Consulté 839 fois

Après mes changements, notamment pour rajouter le mode PAL, je parviens à tout caser dans ce CPLD :

ntpl_cpld.png (13.93 Kio) Consulté 839 fois

Je vais créer une archive du source que je vais poster ici.

La problématique que j'ai eu, c'est de faire en sorte que le générateur vidéo contiennent des valeurs limites pour les compteurs de cycles horizontaux et verticaux qui ne soient plus des constantes mais des signaux pour pouvoir les initialiser selon l'état de la broche NTPL (et quand le /RESET est actif).

Mais le plus gros problème auquel j'ai dû faire face, c'est la division par 5 d'une fréquence tout en maintenant avec un "duty 50%". J'ai dû me farcir tout Google pour trouver quelque chose d'exploitable.

Bref, ça compile mais est-ce correct ? des experts en VHDL et CPLD ici pour jeter un coup d'œil sur mon source que je vais préparer bientôt ?

[hlide]

Ah oui, j'avais aussi des doutes sur le source original. Mais bon, je ne vais pas entrer dans les détails car je ne me souviens plus des détails après les avoir adresser (enfin, surtout correction des warnings).

[hlide]

Voici le projet sous Quartus II :

MZ-700 LSI (M60719).zip

(7.8 Kio) Téléchargé 13 fois

[6502man]

Beau projet que de remplacer un Gate Array

Donc tu est parti d'un projet existant pour une machine NTSC et tu veux la rendre compatible avec une machine PAL.

Est tu sur de la division par 5 de 17 Mhz pour le PAL ?
Tu à vérifier les signaux d'horloge en entrées et sorties sur une machine fonctionnel ?

La je peux pas ouvrir ton projet mais je verrais dès que j'aurais accès à une de mes machines de devs ...

[hlide]

Plus que sûr. La documentation est plus qu'explicite sur la fréquence exacte pour le PAL : LPHI (horloge principale) = 17.734475 MHz.

Ensuite PHIO (horloge Z80 dérivée de l'horloge principale) = 17.734475 / 5 = 3,546895 MHz. dans la doc, elle est donnée à 3.546875 MHz à un chiffre près.

Malheureusement les schémas simplifiés du LSI n'ont l'air valide que pour le NTSC où je sais que COLR et PHIO ont la même fréquence.

Sans titre.png (19.45 Kio) Consulté 648 fois

Or avec une fréquence PAL, ça donnerait COLR = 4.43361875 MHz ! et mon multimètre qui sait lire les fréquences m'a donné un nombre très proche de la division par 5 de la fréquence PAL. Donc je pense que c'est un [1/5] et non [1/4] que l'on devrait avoir et du coup utiliser COLR en NTSC pour faire l'horloge Z80 prend alors tout son sens.

J'avais fait un autre projet dont j'ai déjà fait fabriquer le PCB qui me permettrait de remplacer l'horloge d'origine et de choisir la fréquence PAL ou NTSC sur le même LSI d'origine. Et tu combines ça avec deux autres projets qui me permettaient d'avoir la rom MONITOR et le CGROM en fonction de la version japonaise ou occidentale.

IMG_20201128_194437.jpg (721.7 Kio) Consulté 647 fois

Petite remarque sur le MZ-700 : le MZ-700 sur lequel je fais mes expérimentations merdouille depuis un an (défilement des caractères et couleurs sur l'écran). Je sais que ce n'est pas le Z80, ni les ROM (MONITOR et CGROM) qui sont en cause. Je pressens que ce doit être les tampons entre le Z80 et le reste qui merdouillent. Donc, pour le moment je ne peux pas vraiment faire de l'expérimentation hardware :/. Je suis très mal équipé pour déterminer de façon plus rationnelle les causes.

[hlide]

Ah dernier point, l'archive ne contient que mon projet Quartus II et c'est un source en VHDL - pas de schémas car je n'arrive pas en faire avec Quartus car trop compliqué comparé à Digital ou EasyEDA (j'ai toujours autant du mal avec KiCAD). Je me sens plus à l'aise avec VHDL (voire Verilog) qu'avec un schéma. Mais après de là à être sûr à 100% que ce qui est écrit correspond bien au fonctionnement attendu, je n'en ferais pas le pas. Ça compile, j'ai traité les warnings qu'il y avait d'origine dans le source. Il reste des timings à consolider sur le PAL. Si j'avais un peu plus de place dans mon studio et plus de temps, j'aurais pu tenter de capturer les signaux pour retrouver les seuils des compteurs et quel est le décalage entre la /VSYNC et la /HSYNC sur le MZ-700 (il affiche quand même quelque chose) mais là c'est trop le bordel pour le faire bien.

Le PCB d'origine est un format EAGLE. Il n'est pas dans l'archive. Il faut le retoucher parce que j'ai modifié la signification d'une broche (ABC) qui ne servait en fait à rien (a priori toujours à 0 et pas utilisé par la carte mère) pour lui affecter le rôle de NTPL (le sélecteur NTSC/PAL). Donc un reroutage de ce signal pour qu'il aille sur la bonne broche externe (celle qui correspond au LSI). Et je crois aussi que j'ai renommé un certain nombre de broche du CPLD pour que cela colle avec les noms donnés dans la doc, donc, euh, un petit boulot là encore.

[6502man]

Si tu à trouvé l'info sur une doc originale dans ce cas pas de soucis pour ces valeurs.

J'ai parcouru le source VHDL mais pas encore simuler sous Quartus (pas installé sur cette machine).
Et je vois que tu n'à pas initialisé la variable 'CLKCNT5R' dans la partie Raising de ton diviseur par 5 est ce volontaire ?

Sinon pour la partie schématique sous Quartus ca fonctionne très bien, j'en ai fait pas mal au début que j'utilisé Quartus
et je le trouve assez simple à utiliser une fois que l'on à compris les bases
Mais maintenant je ne fait plus que de VHDL je trouve ca plus rapide à mettre en œuvre .

[hlide]

Alors même si ce code n'est pas totalement de moi (trouvé sur Google en faisant moult recherche sur la division par 5 avec conservation du duty-50%), c'est effectivement quelque chose qui m'a fait gratter la tête :

Code : Tout sélectionner

	-- Counting 5 rising edges of LPHI to toggle CLKDIV5R
	LPHIDIV5R: process(LPHI,RSTN)
	begin
		if (RSTN = '0') then
			CLKDIV5R <= '0';
		elsif rising_edge(LPHI) then
			if (CLKCNT5R = 5) then
				CLKDIV5R <= '1';
				CLKCNT5R <= "0001";
			elsif (CLKCNT5R > 2) then
				CLKDIV5R <= '0';
				CLKCNT5R <= CLKCNT5R + 1;
			else
				CLKDIV5R <= '1';
				CLKCNT5R <= CLKCNT5R + 1;
			end if;
		end if;
	end process;

Est-ce un oubli de la part de l'auteur ?
Le plus bizarre, c'est que je n'ai pas de warning à ce sujet. Mais comme je vois qu'il y a quand même un (CLKCNT5R = 5) avant l'affectation CLKCNT5R <= "0001". Alors je me dis que ça doit sans doute fonctionner parce que le CPLD l'initialise très certainement à 0 par défaut, mais je suis d'accord pour dire que ce n'est très propre en fait. Donc oui, je vais ajouter cette initialisation manquante.

Voici l'original GDG1500 sur lequel je me suis basé :

GDG1500vhdl.zip

(19.58 Kio) Téléchargé 8 fois

[6502man]

Je viens de lancer une simulation et voici ce que cela donne :

On voit que sans l'initialisation de CLKCNT5R la simulation ne démarre pas le compteur, ce qui est normal

Simulation1.jpg (259.12 Kio) Consulté 590 fois

En forçant le compteur à zéro voila ce que cela donne :

Simulation2.jpg (286.66 Kio) Consulté 590 fois

Evidement il faut forcer le compteur à zéro au début de la simulation car sinon c'est tout désynchronisé


Pour l'exemple j'ai fixé l'horloge arbitrairement et les pas de la simulation à 1000ps

En mode debugger j'exécute ton code pas à pas et vérifie l'état des signaux :

Simulation3.jpg (518.94 Kio) Consulté 590 fois

Pour le test je n'ai pris que les signaux servants à la division par 5 de l'horloge,
mais on peut intégrer tous les signaux si nécessaires et évidemment chaque signal
peut être configurer/modifier à volonté ...

[hlide]

Alors, je me dis que c'est une très mauvaise idée de RESET-er l'horloge PAL sur /RESET, d'autant qu'il faut 3 cycles minimum de prise en compte du /RESET à 0 pour le Z80. Et je ne sais pas trop comment faire une initialisation sans RESET pour un CPLD.

[hlide]

Bon j'obtiens quelque chose d'assez pourri au final qui ne ressemble même pas à ça :

Qa4BV.png (13.32 Kio) Consulté 546 fois

Visiblement son code n'est pas en adéquation avec l'image qu'il a produit...

@6502man, sais-tu comment faire pour recompiler les changements effectués sur le VHDL, sans devoir relancer la SIMU RTL et donc se refarcir les paramétrages ?

[hlide]

Donc, après modification du générateur de fréquence PLCLK :

lsi700_plclk.png (83.81 Kio) Consulté 535 fois

Et ça me donne :

Sans titre.png (65.87 Kio) Consulté 535 fois

J'ai bien ma fréquence divisée par 5. Mais ça m'ennuie toujours de devoir réinitialiser sur /RESET = 0.
De plus, je devrais m'assurer de recaler correctement le PLCLK comme on a pour le NTSC :

clocks.gif (3.36 Kio) Consulté 535 fois

[6502man]

Pour l'initialisation sans Reset tu peux faire comme ca
pour l'exemple je n'ai initialisé que la partie Raising :

Code : Tout sélectionner

signal CLKDIV5R		: std_logic   :='0';
signal CLKDIV5F		: std_logic   ;
signal CLKCNT5R		: unsigned(3 DOWNTO 0) :="0001";
signal CLKCNT5F		: unsigned(3 DOWNTO 0);

Comme tu peux le voir sans utiliser le signal Reset il n'y à que la partie Raising qui démarre

avec init.jpg (42.44 Kio) Consulté 491 fois

Pour caler ton signal il suffirait que tu rajoute dans la condition rising_edge(LPHI) et/ou falling_edge(LPHI)
A moins que cela soit par rapport à un autre signal ?

parceque la ca c'est déjà caler sur LPHI en ayant initialisé les signaux

[hlide]

Alors ce type d'initialisation que je souhaiterais si ardemment fonctionnel, il est dit que ce n'est pas toujours synthétisable et que l'on ne peut pas compter dessus pour n'importe quel device en dehors des FPGA et pour peu que le compilateur n'en fasse rien et le passe sous silence. En clair, il est dissuadé de le faire.

Mais bon, si ça fonctionne pour ce type de CPLD et que le compilateur peut en prendre compte, je vais aller dans cette direction. Pas comme si j'avais un grand choix pour le moment. D''ailleurs, si on prend le HCLK, je vois nulle part une initialisation et pourtant c'est bien un compteur qui démarre de 0.

[6502man]

Alors oui il peut y avoir des cas ou ce type d'initialisation ne soit pas pris en compte il n'y à qu'une fois insitu que tu seras fixé,
après les compteurs fonctionnent dans tous les cas avec ou sans initialisation mais leurs états de départ n'est pas forcement
'0000' mais peut être n'importe quel état !!!
Mais je ne vois pas d'autres solution sans passer par un signal type reset .
Je ne suis loin d'être un expert, peut être que d'autres personnes plus calé auront une autre piste.
Après c'est au démarrage et sur une période très courte donc à mon avis c'est négligeable.
par contre le caler sur un des signaux est impératif pour que les fronts coïncide bien à ce que tu attend.