Z80 - IORQ : besoin du support d'un connaisseur

[mchobby]

Bonjour,
En plein bricolage et apprentissage sur du Z80 (voir "Retro-ingénierie d'une carte Z80 : de la centrale DTMF vers des projets Z80") j'y ai ajouté une petite carte d'extension pour faciliter mon propre apprentissage qui se commande à l'aide d'un out()

Carte d'extension RCIO

minimal.jpg (259.41 Kio) Consulté 335 fois

C'est aussi simple que:

Code : Tout sélectionner

    ld a, $0f    ; Lit LED 0, 1, 2, 3
    out ($1d),a  ; LED port

J'ai fini par rencontrer un problème sur lequel je bloque depuis bientôt un mois... et j'aurais bien besoin du soutien de quelqu'un d'expérimenté.

Voici comment j'ai détecté mon problème...

• J'ai bien initialisé l'adresse de ma stack et j'obtiens un comportement bizarre quand je fais des call et des push et pop.
• Le programme semble ne plus répondre (plante)... et j'ai une modification de mon affichage de LED durant l'appel de ma routine sys_wait1s.
• La routine sys_wait1s mouline deux fois un décompte du registre HL afin d'avoir une pause totale de 1 seconde puis fait un RET.
• Si j'appelle la routine avec un call mon affichage LED est modifié sans aucun out() dans le compte !!!!

Si le contenu de la routine est intégrée dans mon code pour éviter le call mon programme fonctionne comme attendu (tout indique un problème de stack)... il y a cependant un MAIS!

Comme mon interface d'extension se comporte bizarrement durant un call, je me suis penché sur son fonctionnement pour m'assurer qu'il n'y avait pas de bug sur le décodage de l'IORQ.

Schéma de l'extension

Sélection_149.jpg (414.18 Kio) Consulté 335 fois

Pour modifier les LEDs (point 1), il faut une impulsion LOW sur le Signal CP (entre poins 1 & 2).
Cette impulsion n'est possible que pour la bonne combinaison de a0, a1, l'opération write (donc _wr LOW) et l'activation _RCIOce (point 2) enable de la carte d'extension).
Le signal RCIO provient du point 3, ligne Y7 du 74HC138 qui décode l'adresse de base de l'IORQ en provenance du Z80 (pour l'adresse 0x1C auquel on ajout a0 ==> 0x1D pour pouvoir contrôler les LEDs).

Tout cela me semble correct... je me demande donc pourquoi l'état de mes LEDs est modifié pendant un décompte du registre HL (lors d'un call uniquement)!

J'ai donc commencé à vérifier mes signaux sur la carte avec un oscilloscope.
J'en suis arrivé a tester un programme très simple:

Code : Tout sélectionner

    ld a, $0f    ; Lit LED 0, 1, 2, 3
    out ($1d),a  ; LED port
    halt

J'ai bien mes LEDs allumées comme attendu... par contre j'ai plusieurs activations de mon interface (voir capture ci-dessous) ...
et là je ne comprend pas pourquoi!

Capture des signaux

DS1Z_QuickPrint15.jpg (137.58 Kio) Consulté 335 fois

• JAUNE : Activation du module LED (signal CP sur U108)... donc envoi des données D0-D7 vers les LEDs.
• Bleu Foncé: Adresse A0 (pour vérification).
• Rose: IORQ du Z80
• Bleu ciel: signal _RCIOce (ligne Y7) donc un IORequest vers ma carte

Note: c'est parfois une, deux, trois activation des LEDs (module U108) et même parfois 4 activations)! J'ai aussi des séries d'une seule activation et rien de plus et parfois des séries multiples.

Edit 17/12 19:00

J'ai essayé de trouver une corrélation entre mon activation CP de U108 et quelques autres signaux:

• RESET n'est pas en cause.
• INT n'est pas en cause
• Les signaux MRQ, RD, WR sont bien comme attendu
• M1 est bien HIGH durant les mise-à-jour des LEDs (donc normal).
• Je n'ai pas le signal HALT après le premier IORQ (voir image ci-dessous).

Capture du HALT

DS1Z_QuickPrint16.jpg (142.04 Kio) Consulté 332 fois

Edit 17/12 19:15

Je me suis assuré que la 2ieme ROM n'est jamais activée.
Donc pas de problème avec les ROM.

Les signaux sur ma première ROM sont OK.
Toute suggestion est la bienvenue.
Dominique

[hlide]

A première vue, ton signal /RCIOce sera positionné à 0 tant que :
- /IORQ = 0 via /E1,
- /M1 = 1 via /E2,
- E3 forcé à 0 car A[5..7] = 000b,
- A[4..2] = 111b.

Ça s'assure que l'on capture ce signal que sur un accès lecture/écriture du port I/O à l'adresse indiquée (0x1C). Jusque là, tout va bien.

La capture des données par les LED se fait à travers un buffer via un déclencheur sur le premier front montant de /RCIOce AND NOT(A[1]) AND A[0] AND NOT(/WR). Ça me chiffonne en fait. Sous Digital, j'ai reproduit l'équation "déclencheur" et le buffer simplifié. Il suffit de mettre (/RCIOce, A0, A1, /WR) à (1,1,0,0) initialement puis de permuter /WR plusieurs fois pour voir que la LED change à chaque fois que /WR passe à 1. Je pense que je viens de te reproduire ce qui se passe quand tu écris dans la pile (PUSH ou CALL).

passe_1.png (161.5 Kio) Consulté 301 fois

passe_2.png (161.95 Kio) Consulté 301 fois

La LED n'aurait jamais dû basculer sur ce cas !

Sans titre.png (111.38 Kio) Consulté 305 fois

Si tu as Digital et que tu veux tester :

nRCIOce.zip

(931 octets) Téléchargé 9 fois

[hlide]

Pour conclure, je n'aurais pas utilisé un 74LS374 (positive edge triggered FF) mais un 74LS373 (transparent latches) pour ne capturer le bus de donnée que sur /RC14ce = 0, A1 = 0, A0 = 1 et /WR = 0. De cette façon, on ne prendra en compte que ce cas. Les "edge triggers" sont à double tranchant avec des équations complexes.

[mchobby]

@hilde ,

Diandre, comment ai-je pu rater cette énormité sur le signal cp ? ... c'est pourtant bien logique.

Si je pouvais, je m’enverrai des coups de pied dans le fondement. Cela serait bien mérité.

Sélection_151.png (82.02 Kio) Consulté 272 fois

Un tout grand merci pour ton aide (et l'investissement en temps).
Je vais suivre ta suggestion et opter pour le 74LS373 (transparent latches). Je vais encore pouvoir avancer d'un nouveau pas dans mon projet.
Je corrige cela puis je reviens sur mes soucis de pile.

Pour le logiciel Digital, je ne pratique plus Windows depuis une dizaine d'années.
Je chercherais un équivalent Linux.

Encore un Grand Merci!

[hlide]

Digital, c'est du Java donc pas intrinsèquement lié à Windows.