Canon X07 - The project

[hlide]

@Hlide - Un autre document trouvé à l'instant, contenant une carte RC2014 pour 8085 et une pour NSC800 en espèrant que cela puisse aider.

Déjà vu sur github. Le schéma est incomplet avec des traces manquants. Le pcb ne m'inspire pas confiance. En gros, on a : /mreq = io/m et /iorq = not Io/m donc /mreq toujours actif, ce que je trouve très moyen.

[jeffounet]

Bonjour,

OK pour ces retours, je suppose que tu es en vacances donc laisse tomber pour l'instant, ce n'est pas urgent.
On verra l'année prochaine
J'ai mis les liens au cas ou...

Bonne soirée et passe de bonnes fêtes.

Jean-François

[Notator]

J'ai fait quelques recherches et, si le NSC800 est "compatible" Z80 pour les instructions, il est très proche de la structure du 8085.

J'ai beaucoup de mal à être d'accord avec cette affirmation ; je trouve que le NSC800 est beaucoup plus proche du Z80 que du 8085, déjà pour leur structure semblable.

Voici la structure interne du NSC800 :

NSC800 structure.png (63.47 Kio) Consulté 973 fois

Voici celle du Z80 :

Z80 structure.png (15.14 Kio) Consulté 973 fois

Et enfin celle du 8085 :

8085 structure.png (60.33 Kio) Consulté 973 fois

Du premier coup d’œil, on peut constater que le NSC800 a plus en commun avec le Z80 qu'avec le 8085, notamment sur les banques de registres disponibles, et le rafraîchissement automatique des mémoires dynamiques. Et puis les jeux des 158 instructions du NSC800 et Z80 sont identiques.

Par ailleurs, au sujet du tamponnage du µP, je comprends bien que Gleike est plus à l'aise avec un CPLD qu'avec des circuits logiques TTL, mais à mon avis, pourquoi réinventer la roue, alors qu'il suffirait de s'inspirer du tamponnage appliqué avec la valise Fox MZ80, qui pallie avec succès aux carences de tamponnage du Multitech MPF-1B.

[jeffounet]

Oui mais pour la valise Fox ils ont déplacer le processeur ce qui n'est pas possible ici.
Enfin, les documents transmis sont là pour référence.
Bon je retourne à mon apero

Bonne soirée à tous et bon apéro

Jean-François

[Notator]

Pour la valise Fox ils ont déplacé le processeur pour des raisons de commodité, pour améliorer le circuit de Reset et ajouter un circuit Break ; mais sur le fond, l'avoir déplacé ne change pas grand chose, puisque les pattes du Z80 sont d'origine aussi bien toutes présentes sur le Bus d'extension.
Subsidiairement, le déplacement du Z80 permit, au prix minime d'un support de circuit intégré, de faire bénéficier les circuits du MPF-1B du tamponnage du Z80.

Sinon, fondamentalement, tamponner le Z80 ou tamponner le bus, ça revient au même. Alors pour le Canon X07, il serait possible de la même manière de tamponner son bus ; c'est bien ce que vous envisagiez, non ?

[jeffounet]

Bonjour à tous,

Le problème, sur la carte FOX, s'ils n'avaient pas déplacé le processeur, c'est qu'ils n'auraient pas pu buffériser le bus de données sans compliquer le décodage d'adresse.
En effet la RAM et la ROM étant sur la carte principale, se seraient retrouvée avant le buffer et donc au moment de la lecture on aurait eu les données de la carte FOX qui entreraient en conflit avec celle de la RAM ou de la ROM.
J'en ai fait l'expérience sur le bus d'extension que j'avais fait pour le MPF-I.
Il faut faire un décodage complet de l'espace mémoire et des I/O utilisées sur la carte mère afin que le buffer soit à l'état haute impédance lorsque que l'on y accède! (séparation de l'extension et de la carte mère en quelque sorte!)
C'est ce qui est prévu pour le projet X07 et c'est pour cela que j'envoie la totalité du bus d'adresse et d'autre signaux à l'EPM7128 qui devra gérer ces fameux accès sans générer de conflit!
Je ne sais pas si j'ai été bien clair.

Bonne journée

Jean-François

[Notator]

Je crois qu'il ne faut pas tout mélanger : le tamponnage ou la bufferisation (moi je préfère les termes en français plutôt que des barbarismes franglais), c'est différent d'un conflit éventuel d'adresses.
Electrickery, dans un de ses articles, indique comment remédier au décodage d'adresses incomplet du MPF-1.

Quoi qu'il est soit, peu importe que la zone mémoire présente sur la carte MPF-1 soit ou non tamponnée (elle fonctionne correctement d'origine sans tamponnage, donc elle fonctionnera tout aussi bien si on la tamponne), et elle cohabitera tout aussi bien avec de la mémoire d'extension tamponnée, pour autant qu'il n'y ait pas de conflit d'adresses, ce qui est un autre problème bien spécifique.
Pour ce qui nous occupe dans ce sujet-ci, on n'a pas à se soucier des problèmes de décodage d'adresses du MPF-1, puisqu'il est question ici du X07.

Et pour ce qui est du tamponnage du X07, rien n'empêche de s'inspirer de la carte MZ80, et il n'est pas obligatoire de suivre à la lettre ce qui y est fait.
Après, chacun fait comme il veut, je suggère juste une autre possibilité de solution à un besoin.

[hlide]

Il a été entendu que le CPLD ne servirait pas au tamponnage (assuré par des tampons extérieurs du type 74xxx). Par exemple le bus d'adresse sera bien en entrée du CPLD pour la partie décodage des adresses en accès mémoire ET port I/O. C'est un tampon extérieur qui assurera la sortie d'adresse à partir de ce même bus vers le bus RC2014 avec la possibilité pour le CPLD de la forcer en haute-impédance sur certain décodage d'adresse. En somme, ce CPLD est un aiguilleur en plus de recréer quelques signaux du bus Z80 dont les périphériques RC2014 pourraient avoir besoin.

J'imagine que ce besoin existe parce que les cartes RC2014 ont leur propres décodeurs d'adresse qui écouteront le bus d'adresse et les signaux de contrôle. Si ces derniers sont envoyés inconditionnellement alors qu'un jeu d'interrupteur indique d'utiliser une extension non RC2014 dont l'adresse entre en conflit avec celle du bus RC2014, il y a fatalement conflit.

Bien sûr, avec le CPLD, on pourrait aussi conditionner la génération de /MREQ et /IORQ sur le décodage d'adresse et faire l'économie de deux tampons pour les adresses car le RC2014 ne fera rien avec cette adresse si il ne reçoit pas de /MREQ ou /IORQ. Encore que j'avais compris que ces tampons pouvaient servir à protéger les lignes et à amplifier leur force.

[Notator]

Oui, la fonction des tampons est d'améliorer la sortance des lignes du processeur, pour pouvoir plus les 'charger' en mémoires et circuits périphériques divers. Et vu tout ce que Jeffounet envisage de mettre en extensions, il ne seront pas superflus.

Ce que je comprends moins, c'est ce désir de pouvoir les mettre en haute impédance. Habituellement, le rôle des tampons est transparent, on n'est pas censé s'en servir comme sélection de circuits.

A moins d'avoir les bus et les lignes de commande partagés entre deux processeurs, d'un côté le NSC800 du X07, et de l'autre côté le Z80 du RC2014 ; là oui, il pourrait être nécessaire d'isoler tour à tour les ressources d'un côté ou de l'autre, pour ne pas que les deux processeurs puissent agir en même temps sur un même circuit, ce qui créerait conflit.
Mais même là, un circuit d'arbitrage permettrait d'empêcher un processeur de travailler quand son homologue est actif.

Alors dans une configuration à un seul processeur, il n'est pas nécessaire d'avoir besoin de porter les tampons en haute impédance ; même avec une cartographie chargée, même redondante, il suffit de valider juste les circuits à activer pour la tâche en cours par /CS ou un autre moyen.
Supposons par exemple que le processeur soit en train de travailler sur la mémoire interne du X07, peu importe qu'en parallèle derrière sur les même bus il y ait d'autres circuits présents, ils ne sont pas activés à ce moment-là.

[jeffounet]

Bonjour à tous,

Désolé je n'ai pu répondre avant.
Alors le premier point comme le dit Notator effectivement j'ai prévu plein de choses su la carte, dont le BUS RC2014, donc les tampons seront les bienvenus.
Ils ont une deuxième fonction qui sera l'adaptation de niveaux entre le bus X07 et l'interface, en effet l'interface sera alimentée par du 5V hors le bus du X07 est en 4,6V Je pense utiliser des circuits de la série 74HC ou HCT, vous me direz ce que vous en pensez.

Ensuite je me suis peut être mal expliqué dans mon dernier post. Je vais essayer de clarifier tout cela.

Sur la carte d'extension on va avoir un tampon pour les données qui changera de sens en fonction que le processeur se trouve en lecture ou en écriture.
Prenons le cas ou le processeur accède à la ROM interne, donc en lecture. Les données iront de la ROM vers le processeur.
A ce moment là, si le tampon est actif en lecture (je rappelle que le processeur est en lecture donc il est logique que le tampon soit configuré dans le sens extension vers processeur) même si tout les périphériques sont déselctionnés le tampon n'étant pas en mode haute impédance, interfèrera avec les données de la ROM!

Quand j'ai parlé du MPF1 c'était parce que j'avais fait cette erreur lors de la conception de mon bus RC2014 sur MPF1 et c'est uniquement pour cela que j'en avais parlé!
Je me trompe peut-être, et je m'en excuse par avance si c'est le cas, mais je pense que lorsque le X07 accèdera à ses ressources internes il faudra mettre le tampon de données en haute impédance afin de ne pas risquer de perturber le processeur.

J'espère avoir été un peu plus clair.
Merci pour vos retours.

Bonne fin de journée

Jean-François

[hlide]

Alors, techniquement, je ne pense pas que l'on aura un autre Z80 sur le bus RC2014. Ce devrait être le Z80 du NSC800 qui est à la manœuvre et lui seul. De plus, on n'a pas les signaux /BUSREQ et /BUSACK de disponible sur le bus d'extension (sauf à décider de mettre un PCB sur le processeur pour récupérer ces signaux et les faire parvenir à la carte contenant le CPLD). Certes, il peut y avoir les DMA des puces Zilog (SIO, PIO, CTC, KIO) mais je ne sais plus trop si ça se joue avec ces signaux - je pense que oui pour pouvoir arbitrer tout ce beau monde - ou avec le signal /WAIT.

D'une manière général, on s'attend qu'un certain nombre de signaux venant du "Z80" soient en haute impédance sous certaines conditions. Par exemple, quand /RESET ou /BUSACK sont actifs. En passant par les tampons, je n'ai pas l'impression que la sortie reproduira une sortie haute-impédance si une entrée est en haute-impédance (pas spécialement indiqué dans leur datasheet), donc je prévoyais de le reproduire sur le tampon en jouant sur le /CE ou /OE (les noms varient sur les tampons). Sur le MZ-700, les tampons connectés au Z80 sont placés en haut-impédance sur le signal /BUSACK par exemple.

Ce que Jean-François veut faire, si je ne me trompe pas, c'est isolé le bus RC2014 (via un système d'interrupteurs) dès lors que l'on veut piloter une extension de Casio sur un espace de mémoire ou port E/S *potentiellement* en conflit avec le RC2014. Car vu les possibilités d'extensions RC2014 offertes par les cartes existantes et futures dont le décodage d'adresse se passent toujours sur ces cartes et non pas par des lignes /CS, on a le risque d'activer plusieurs fonctions en même temps.

Le CPLD peut contrôler et dérouter les signaux à qui de droit sur les extensions connues du Casio que Jean-François a listées et donc décoder leurs adresses (système d'interrupteurs pour dire qui est prioritaire) pour créer leur ligne /CS mais ne peut pas décoder les adresses en destination du RC2014 (architecture ouverte à toutes les extensions RC2014 possibles) pour faire de même mais il peut "bloquer" un ensemble de signaux sur le bus RC2014 pour privilégier une extension Casio.

[hlide]

Alors concernant les DMA. En fait, ça semble plutôt concerner que la puce Zilog DMA (84[C]10) qui prend la place du Z80 pour les transferts directs entre mémoires et/ou ports E/S. Dans le cas du KIO, la référence DMA s'applique pour un transfert qui se passe entre lui et un contrôleur DMA. En revanche, on a bien les signaux /WAIT qui peuvent être utilisés pour permettre de faire patienter le Z80 sur la réception/émission d'un canal du KIO.

Donc bonne nouvelle pour le KIO.

[Notator]

Sur la carte d'extension on va avoir un tampon pour les données qui changera de sens en fonction que le processeur se trouve en lecture ou en écriture.

Oui, c'est le principe d'un tampon bidirectionnel, nous sommes bien d'accord.

Prenons le cas où le processeur accède à la ROM interne, donc en lecture. Les données iront de la ROM vers le processeur.
A ce moment là, si le tampon est actif en lecture (je rappelle que le processeur est en lecture donc il est logique que le tampon soit configuré dans le sens extension vers processeur) même si tous les périphériques sont désélectionnés le tampon n'étant pas en mode haute impédance, interfèrera avec les données de la ROM!

Ben non. quand (sans aucune extension branchée) ton processeur lit de la ROM, simultanément il y a sur le bus de données de la RAM et des circuits d'entrées/sorties ; et pourtant, il n'y a pas d'interférences, car tous ces circuits ne sont pas sélectionnés à ce moment-là.
C'est tout simplement comme si ils n'étaient pas là.

Je me trompe peut-être, et je m'en excuse par avance si c'est le cas, mais je pense que lorsque le X07 accèdera à ses ressources internes il faudra mettre le tampon de données en haute impédance afin de ne pas risquer de perturber le processeur.

Pas besoin de t'excuser c'est en discutant que les choses s'éclaircissent.

Même chose ici, quand le X07 accède à ses ressources internes, il a beau avoir 50 extensions sur son bus de données (à travers le tampon ouvert), ça ne va pas le perturber, car les extensions en question ne sont pas sélectionnées.

Par contre, il faudra prendre bien soin de loger le bout de programme qui effectue la logique de sélection de l'une ou l'autre extension dans un zone mémoire non utilisée en natif (ou sinon il faudrait modifier le Moniteur pour prendre ça en compte, ce qui ne serait pas évident).
Parce qu'il se pourrait (si cette logique était dans un champ mémoire déjà présent en natif) que lors de son usage un programme 'officiel' quelconque vienne écraser le processus de sélection des extensions.

Ce que je veux dire c'est que je suppose que toutes tes extensions seront branchées en permanence, prêtes à être utilisées par l'une ou l'autre application ; tu ne vas pas brancher et débrancher l'une ou l'autre extension selon le besoin du moment.
Alors, vu leur nombre, comme certaines des extensions seront inévitablement placées sur des mêmes adresses (j'ai vu ta cartographie), il y aura besoin d'une gestion globale des extensions, qui, en fonction des besoins, validera la, ou les extensions nécessaires à l'appli en cours d'exécution.

Donc, ce processus gestionnaire d'extension devra évidemment être activé dès qu'arrive le besoin de mobiliser une extension, et même en permanence ; car même dans le cas où tu travailles sur les ressources natives, si l'instant d'après tu dois enregistrer ton travail sur un carte SD, il faudra que l'extension SD (et l'appli qui va avec) soit 'réveillée'.

[Notator]

En passant par les tampons, je n'ai pas l'impression que la sortie reproduira une sortie haute-impédance si une entrée est en haute-impédance (pas spécialement indiqué dans leur datasheet), donc je prévoyais de le reproduire sur le tampon en jouant sur le /CE ou /OE (les noms varient sur les tampons). Sur le MZ-700, les tampons connectés au Z80 sont placés en haut-impédance sur le signal /BUSACK par exemple.

Il existe des tampons 3 états (ils sont transparents, ils répercutent en sorties exactement ce qu'ils reçoivent en entrées).
Le 74245, par exemple est un octuple tampon bidirectionnel (pour le data bus) 3 états.
Le 74244, par exemple est un octuple tampon monodirectionnel (pour le bus d'adresses) 3 états.

Le CPLD peut contrôler et dérouter les signaux à qui de droit sur les extensions connues du Casio que Jean-François a listées et donc décoder leurs adresses (système d'interrupteurs pour dire qui est prioritaire) pour créer leur ligne /CS mais ne peut pas décoder les adresses en destination du RC2014 (architecture ouverte à toutes les extensions RC2014 possibles) pour faire de même mais il peut "bloquer" un ensemble de signaux sur le bus RC2014 pour privilégier une extension Casio.

(C'est Canon, pas Casio ).
Oui, un jeu de sélecteurs pour valider les extensions nécessaires ; comme par exemple, s'il y a 16 extensions, envoyer sur un registre un mot de 4 bits ; avec par exemple le 74154, qui est un décodeur 4 vers 16, en fonction du code à 4 bits envoyé sur ses quatre entrées, il porte l'une de ses 16 sorties à un niveau bas, lequel valide l'extension voulue.

[hlide]

Prenons le tampon 244,

la doc me dit :

Code : Tout sélectionner

 INPUTS | OUTPUTS
----+---+---------
/OE | A |    Y
----+---+---------
 L  | H |    H  
----+---+---------
 L  | L |    L  
----+---+---------
 H  | X |    Z  

Ce que je voudrais :

Code : Tout sélectionner

 INPUTS | OUTPUTS
----+---+---------
/OE | A |    Y
----+---+---------
 L  | Z |    Z  
----+---+---------
 L  | H |    H  
----+---+---------
 L  | L |    L  
----+---+---------
 H  | X |    Z  

Or je n'ai pas l'impression que ce tampon soit en mesure de déterminer si une entrée est en haute-impédance (car sûrement lu comme un H à cause d'un pull-up par exemple) pour reproduire une haute-impédance en sortie. Je dois donc passer par une équation qui placera /OE = H pour forcer la haute-impédance en sortie là où je sais qu'en entrée j'ai haute-impédance (exemple, quand j'ai /BUSACK = 0).

Je n'utilise pas de 245 car dans les différents docs qui impliquent le NSC800, ils utilisent plutôt deux tampons monodirectionnels. En effet, le bus de données doit être en haute-impédance si aucun des signaux /RD ou /WR n'est actif. Je pense que c'est dû au fait que ADx est une sortie d'adresse durant ALE = 1 et qu'à ce moment-là le tampon 245 prendrait ADx pour une entrée de donnée à tort puisque /WR = 1.