Pour info, voici le schéma que j'ai de la X720:
Il n'est vraiment pas beau mais on y trouve des renseignements intéressants tel que l'adaptation des niveau en entrée et en sortie sur le bus.
On y vois (à peu près) comment sont démultiplxées les adresses et comment est faite la bufférisation!
Bonne journée
Jean-François
Canon X07 - The project
Modérateurs : Papy.G, fneck, Carl
Re: Canon X07 - The project
Il n'y a que 11 sortes de gens, ceux qui comprennent ceux qui ne comprennent pas et ceux qui me font répéter!
Jean-François
Jean-François
Re: Canon X07 - The project
Houlà ! c'est illisible :/
Bon, ma tentative d'utiliser un 745 dans le circuit principale s'est soldé par un échec car je ne sais pas si on peut et comment gérer des ports bidirectionnels pour les données. Quand je lance la simulation, j'ai toujours un cas où je me retrouve en court-circuit à cause de plusieurs sorties en confit. Du coup, j'ai viré la partie donnée du circuit principal.
Concernant le CPLD, je n'ai pas encore traité /MREQ et /IORQ. Le CPLD sort /M1 et /HALT. Il sort DW/R (/RD AND /INTA où /INTA est l'équivalent de /IORQ AND /M1 pour un Z80 lors du cycle Interrupt Acknowledge). Il sort aussi /ADOE et /SCOE (noms et usages non définitifs) pour tri-stater le bus d'adresse sur NOT(/BACK AND /RESET) alors que /SCOE c'est juste sur NOT(/BACK). Certains signaux en entrée ne sont pas définitifs non plus (/WR, /WAIT, etc.) et peuvent être retirés si non nécessaires.
Voici l'archive zip des fichiers pour Digital : Voici les images pour chaque composant :
Bon, ma tentative d'utiliser un 745 dans le circuit principale s'est soldé par un échec car je ne sais pas si on peut et comment gérer des ports bidirectionnels pour les données. Quand je lance la simulation, j'ai toujours un cas où je me retrouve en court-circuit à cause de plusieurs sorties en confit. Du coup, j'ai viré la partie donnée du circuit principal.
Concernant le CPLD, je n'ai pas encore traité /MREQ et /IORQ. Le CPLD sort /M1 et /HALT. Il sort DW/R (/RD AND /INTA où /INTA est l'équivalent de /IORQ AND /M1 pour un Z80 lors du cycle Interrupt Acknowledge). Il sort aussi /ADOE et /SCOE (noms et usages non définitifs) pour tri-stater le bus d'adresse sur NOT(/BACK AND /RESET) alors que /SCOE c'est juste sur NOT(/BACK). Certains signaux en entrée ne sont pas définitifs non plus (/WR, /WAIT, etc.) et peuvent être retirés si non nécessaires.
Voici l'archive zip des fichiers pour Digital : Voici les images pour chaque composant :
- Canon-X07.png (207.74 Kio) Consulté 929 fois
- CPLD.png (142.29 Kio) Consulté 929 fois
- NSC800_STATUS.png (17.88 Kio) Consulté 929 fois
- Z80_M1.png (9.12 Kio) Consulté 929 fois
Dernière modification par hlide le 10 déc. 2023 15:16, modifié 1 fois.
Re: Canon X07 - The project
Après analyse de ton document (il a fallut que je colorise les lignes qui m'intéressaient), j'ai déduis que le buffer de lecture de donnée 244 (223) se fait essentiellement avec (/RD AND /INTA). Le circuit est plus complexe mais c'est parce qu'il mixe la reconnaissance des adresses de certaines zones de mémoire spécifique au X720. Je savais qu'il fallait inclure /INTA car sur une autre machine, j'avais (/M1 OR /IORQ) AND /RD pour activer la direction B->A d'un 745 avec un Z80.
Quand à l'autre buffer d'écriture de donnée 244 (219) se fait essentiellement sur /WR.
Bon je suppose que l'on va utiliser deux 244 au lieu d'un 275.
EDIT: dans CPLD, j'ai fait une erreur sur le composant logique à utiliser pour créer le signal W/RD qui devient /ROE et qui est utilisé pour le buffer (223).
Quand à l'autre buffer d'écriture de donnée 244 (219) se fait essentiellement sur /WR.
Bon je suppose que l'on va utiliser deux 244 au lieu d'un 275.
EDIT: dans CPLD, j'ai fait une erreur sur le composant logique à utiliser pour créer le signal W/RD qui devient /ROE et qui est utilisé pour le buffer (223).
Dernière modification par hlide le 10 déc. 2023 16:28, modifié 1 fois.
Re: Canon X07 - The project
Bonjour Hlide,
Une question sur ce que tu as envoyé.
Tu liste les signaux /BACK et /BREQ du X07 dans la première image partie CPU CONTROL ainsi que dans la partie CPU/DMA BUS CONTROL et tu parle aussi de /RESIN et de /RFSH mais ceux-ci ne sont pas utilisés dans la simulation.
Faut-il absolument envisager de sortir ces signaux?
Pour le buffer des données je le voyait comme cela:
-si accès aux ressources interne du X07 (RAM, ROM et I/O) --> buffer placé en haute impédance (D'ou l'utilité d'avoir tout le bus d'adresse sur le CPLD entre autre.)
-Si accès à autre chose --> alors buffer actif en fonction de /RD ou /WR suivant le sens de câblage du buffer.
J'ai attaqué un récapitulatif des zones mémoires et entrées/sorties internes au X07 afin de déterminer le sens de ce buffer!
Je le posterai bientot.
Bonne journée
Jean-François
Une question sur ce que tu as envoyé.
Tu liste les signaux /BACK et /BREQ du X07 dans la première image partie CPU CONTROL ainsi que dans la partie CPU/DMA BUS CONTROL et tu parle aussi de /RESIN et de /RFSH mais ceux-ci ne sont pas utilisés dans la simulation.
Faut-il absolument envisager de sortir ces signaux?
Pour le buffer des données je le voyait comme cela:
-si accès aux ressources interne du X07 (RAM, ROM et I/O) --> buffer placé en haute impédance (D'ou l'utilité d'avoir tout le bus d'adresse sur le CPLD entre autre.)
-Si accès à autre chose --> alors buffer actif en fonction de /RD ou /WR suivant le sens de câblage du buffer.
J'ai attaqué un récapitulatif des zones mémoires et entrées/sorties internes au X07 afin de déterminer le sens de ce buffer!
Je le posterai bientot.
Bonne journée
Jean-François
Il n'y a que 11 sortes de gens, ceux qui comprennent ceux qui ne comprennent pas et ceux qui me font répéter!
Jean-François
Jean-François
Re: Canon X07 - The project
J'ai placé des signaux dans le CPLD en me basant sur le bus Z80. Il est probable qu'au fur à mesure, certains signaux ne s'avèreront pas nécessaires et on pourra les supprimer sûrement. D'après la documentation du Z80, /BACK (/SCOE du CPLD) est utilisé pour tri-stater les signaux du SYSTEM CONTROL, à savoir : /RD, /WR, /MREQ et /IORQ. Le bus d'adresse et de donnée est aussi impacté par /BACK mais aussi par /RESET. C'est pourquoi, je crée les signaux /ADOE pour le bus d'adresse du RC2014. Cependant, vu que /RD et /WR du NSC800 sont tri-staté quand on a /BACK = 0, je présume que ça revient mettre en haut impédance les sorties des buffer (223) et (219) pour le bus de données.
Dans le circuit principal :
1) /BREQx07 est transmis au RC2014 via un buffer.
2) /BACKx07 est transmis au NSC800 depuis RC2014 via un buffer mais aussi utilisé par le CPLD pour créer /ADOE et /SCOE.
3) /RESINx07 est transmis au NSC800 depuis RC2014 via un buffer mais aussi utilisé pour créer /ADOE.
4) /RFSHx07 est transmis au RC2014 via un buffer.
5) Je présume que les accès internes du X07 (RAM, ROM et I/O) sont déjà géré par X07 ? ou il passe quand même par le connecteur ? si tu veux couper l'accès aux bus d'adresse et de données au RC2014, il suffit de de placer /ADOE et /SCOE à 1 en incluant dans leur équation si on autorise un accès au RC2014, je pense, car le RC2014 ne pourra pas voir les tentative de lecture ou écriture avec les /MREQ, /IORQ, /RD et /WR en haute impédance de cette façon. Mais dans ce cas, il faut que /ROE et /WR incorporent /ADOE dans l'équation : /ROE = /ADOE OR /RD OR /INTA et /WOE = /ADOE OR /WR.
J'ai apporté des corrections :
Dans le circuit principal :
1) /BREQx07 est transmis au RC2014 via un buffer.
2) /BACKx07 est transmis au NSC800 depuis RC2014 via un buffer mais aussi utilisé par le CPLD pour créer /ADOE et /SCOE.
3) /RESINx07 est transmis au NSC800 depuis RC2014 via un buffer mais aussi utilisé pour créer /ADOE.
4) /RFSHx07 est transmis au RC2014 via un buffer.
5) Je présume que les accès internes du X07 (RAM, ROM et I/O) sont déjà géré par X07 ? ou il passe quand même par le connecteur ? si tu veux couper l'accès aux bus d'adresse et de données au RC2014, il suffit de de placer /ADOE et /SCOE à 1 en incluant dans leur équation si on autorise un accès au RC2014, je pense, car le RC2014 ne pourra pas voir les tentative de lecture ou écriture avec les /MREQ, /IORQ, /RD et /WR en haute impédance de cette façon. Mais dans ce cas, il faut que /ROE et /WR incorporent /ADOE dans l'équation : /ROE = /ADOE OR /RD OR /INTA et /WOE = /ADOE OR /WR.
J'ai apporté des corrections :
- Canon-X07.png (232.87 Kio) Consulté 891 fois
- CPLD.png (57.56 Kio) Consulté 891 fois
Dernière modification par hlide le 10 déc. 2023 21:09, modifié 1 fois.
Re: Canon X07 - The project
Bon, OK pour le fait que tu te soit basé sur le bus RC2014.
De mon côté j'ai exxayé de lister les diverses configuration d'état du buffer de donnée en fonction des zone ou accède le NSC800
Sur cette nouvelle version de la cartographie tu verra en rouge les accès fait en interne et en orange ceux fait soit en interne soit en externe en fonction d'une config par dip switch. les cartes programmes ne sont pas supportées dans cette version!
1 - La config idéale: X07 de base sans extention mémoire ni carte d'application.
2 - La config maximum : X07 + extention 8kO + X720 + carte d'application.
Un mix de cela peut être fait grace à des dip switch.
l'idéal, par la suite, sera de faire un dump des cartes d'applications et/ou des cartes programmes et d'en faire des cartouches, ce qui permettrai d'optimiser la configuration.
Ou de les mettre en ROM pour les avoir tout le temps sous la main sachant que l'insertion d'une cartouche est prioritaire sur la RAM et la ROM (2 contacts dans la cartouche, detect1 et 2, permettent cette identification.
La nouvelle version de la cartographie: Bonne soirée
Jean-François
De mon côté j'ai exxayé de lister les diverses configuration d'état du buffer de donnée en fonction des zone ou accède le NSC800
Sur cette nouvelle version de la cartographie tu verra en rouge les accès fait en interne et en orange ceux fait soit en interne soit en externe en fonction d'une config par dip switch. les cartes programmes ne sont pas supportées dans cette version!
1 - La config idéale: X07 de base sans extention mémoire ni carte d'application.
2 - La config maximum : X07 + extention 8kO + X720 + carte d'application.
Un mix de cela peut être fait grace à des dip switch.
l'idéal, par la suite, sera de faire un dump des cartes d'applications et/ou des cartes programmes et d'en faire des cartouches, ce qui permettrai d'optimiser la configuration.
Ou de les mettre en ROM pour les avoir tout le temps sous la main sachant que l'insertion d'une cartouche est prioritaire sur la RAM et la ROM (2 contacts dans la cartouche, detect1 et 2, permettent cette identification.
La nouvelle version de la cartographie: Bonne soirée
Jean-François
Il n'y a que 11 sortes de gens, ceux qui comprennent ceux qui ne comprennent pas et ceux qui me font répéter!
Jean-François
Jean-François
Re: Canon X07 - The project
Bonsoir,
J'ai oublié de signaler que la gestion de la mémoire paginée ROM ou RAM n'est pas implémentée ni prise en compte sur la dernière cartographie.
En effet avant d'aller si loin je préfère attendre d'avoir une base fonctionnelle.
Bonne soirée
Jean-François
J'ai oublié de signaler que la gestion de la mémoire paginée ROM ou RAM n'est pas implémentée ni prise en compte sur la dernière cartographie.
En effet avant d'aller si loin je préfère attendre d'avoir une base fonctionnelle.
Bonne soirée
Jean-François
Il n'y a que 11 sortes de gens, ceux qui comprennent ceux qui ne comprennent pas et ceux qui me font répéter!
Jean-François
Jean-François
Re: Canon X07 - The project
Je dois vous avouer que je sens de plus en plus mal ce projet. J'ai passé mon temps à revoir les signaux tant du côté du Z80 que du NSC800 pour me rendre compte que c'est probablement impossible de reproduire à l'exact parce que les signaux S0 et S1 restent flous sur la nature exacte du cycle-M pour pouvoir reproduire certains signaux dans les timings attendus du Z80 (je rappelle que le RC2014, c'est un bus Z80 à la base). Je vais donc tenter une approche un peu moins rigoriste sur la génération des signaux /MREQ et /IORQ mais en tenant compte au mieux les cas spéciaux. Je vous joins également un document qui détaille la gestion des interruptions entre le Z80 et les PIO/CTC/SIO/DMA (le KIO en somme) avec l'importance des signaux IEO/IEI/M1/IORQ.
Le cas du STATUS (S1, S0) :
Le cas de /MREQ et /IORQ :
On doit fournir /MREQ pour tout ce qui exige un accès mémoire via /RD ou /WR ou /RFSH. Je propose d'oublier /RFSH carrément (seulement utile pour de la DRAM externe). Je propose également de modifier l'état de /MREQ sur les fronts montant et descendant de ALE (le signal /MREQ à 0 pour ALE = 0 sera beaucoup long que l'attendu du Z80 mais ça reste mieux que de faire simplement /MREQ = IO/M qui sera toujours à 0 sauf sur les cycles port I/O et qui ne fonctionnera pas pour tous les cas spéciaux).
On doit fournir /IORQ pour tout ce qui exige un accès port I/O via /RD ou /WR ou mémoire via /INTA. Mêmes proposition et remarque que /MREQ concernant le signal ALE.
(a) Ici, on a le signal IO/M pour départager entre /MREQ et /IORQ mais il y a le cas inconnu (b).
(b) Je peine à trouver le diagramme correspondant à ce cas. Mais un des document indique que l'on n'aura pas de /RD à 0 et donc on peut penser qu'il n'y aura pas de conséquence fâcheuse à avoir /MREQ = 0.
(c) C'est le cas le plus attendu pour ce status (1, 1). Si on ignore /RFSH (toujours à 1 du côté du RC2014), on aura bien /MREQ à 0 sur le deuxième ALE mais pas de /RD à 0 donc on peut penser qu'il n'y aura pas de conséquence fâcheuse.
(d) Sur le Z80, on a /IORQ = 0 au lieu de /MREQ = 0 alors que le NSC800 a IO/M = 0 ! cependant, /INTA passe à 0 sur le front descendant de ALE. Et tant pis, si on a très brièvement un /MREQ = 0 entre le moment où ALE passe à 0 et l'instant d'après où /INTA passe à 0 car on ne devrait pas avoir de /RD, /WR ou /RSFH à 0 qui pourraient conduire à des conséquences fâcheuses.
(e) /RD reste à 1 alors que le Z80 veut que l'on produise /MREQ et /RD à 0. Après, on peut argumenter que le NMI a un cycle M1 qui ignore l'opcode fetch sur le Z80 donc je dirais que ce n'est pas un soucis de ne pas avoir /RD à 0.
Donc il nous faudrait :
Le cas du STATUS (S1, S0) :
- (0, 0) - OPCODE FETCH avec /HALT = 0
- (0, 1) - WRITE (mémoire ou port E/S selon le signal IO/M)
- (1, 0) - (a) READ (mémoire ou port E/S selon le signal IO/M) ou (b) INTERNAL OPERATION (aucun détail là-dessus !)
- (1, 1) - (c) OPCODE FETCH avec /HALT = 1 ou (d) INTERRUPT ACKNOWLEDGE (/INTA au lieu de /RD) ou (e) NMI AND RESTART INTERRUPT
Le cas de /MREQ et /IORQ :
On doit fournir /MREQ pour tout ce qui exige un accès mémoire via /RD ou /WR ou /RFSH. Je propose d'oublier /RFSH carrément (seulement utile pour de la DRAM externe). Je propose également de modifier l'état de /MREQ sur les fronts montant et descendant de ALE (le signal /MREQ à 0 pour ALE = 0 sera beaucoup long que l'attendu du Z80 mais ça reste mieux que de faire simplement /MREQ = IO/M qui sera toujours à 0 sauf sur les cycles port I/O et qui ne fonctionnera pas pour tous les cas spéciaux).
On doit fournir /IORQ pour tout ce qui exige un accès port I/O via /RD ou /WR ou mémoire via /INTA. Mêmes proposition et remarque que /MREQ concernant le signal ALE.
(a) Ici, on a le signal IO/M pour départager entre /MREQ et /IORQ mais il y a le cas inconnu (b).
(b) Je peine à trouver le diagramme correspondant à ce cas. Mais un des document indique que l'on n'aura pas de /RD à 0 et donc on peut penser qu'il n'y aura pas de conséquence fâcheuse à avoir /MREQ = 0.
(c) C'est le cas le plus attendu pour ce status (1, 1). Si on ignore /RFSH (toujours à 1 du côté du RC2014), on aura bien /MREQ à 0 sur le deuxième ALE mais pas de /RD à 0 donc on peut penser qu'il n'y aura pas de conséquence fâcheuse.
(d) Sur le Z80, on a /IORQ = 0 au lieu de /MREQ = 0 alors que le NSC800 a IO/M = 0 ! cependant, /INTA passe à 0 sur le front descendant de ALE. Et tant pis, si on a très brièvement un /MREQ = 0 entre le moment où ALE passe à 0 et l'instant d'après où /INTA passe à 0 car on ne devrait pas avoir de /RD, /WR ou /RSFH à 0 qui pourraient conduire à des conséquences fâcheuses.
(e) /RD reste à 1 alors que le Z80 veut que l'on produise /MREQ et /RD à 0. Après, on peut argumenter que le NMI a un cycle M1 qui ignore l'opcode fetch sur le Z80 donc je dirais que ce n'est pas un soucis de ne pas avoir /RD à 0.
Donc il nous faudrait :
- /MREQ = 0 si (ALE = 0) et (IO/M = 0) et (/INTA = 1), sinon 1.
- /IORQ = 0 si (ALE = 0) et (IO/M = 1 ou /INTA = 0), sinon 1.
Re: Canon X07 - The project
Bonjour Hlide,
Ton expertise va beaucoup plus loin que ne je saurais le faire.
Tu semble penser que ce ne sera pas réalisable, si c'est le cas on laissera tomber la partie RC2014 et je me concentrerai sur la partie mémoire, cartouche, et diverses extentions sur la carte de base.
Je comprend ce que tu explique mais je suis incappable de t'aider sur ce point, tu m'en vois désolé.
Dis moi ce que tu en pense et surtout ne perd pas plus de temps si tu sens que c'est une impasse.
Je vais, de mon côté, voir si je peux avoir de l'aide.
Bon weekend
Jean-François
Ton expertise va beaucoup plus loin que ne je saurais le faire.
Tu semble penser que ce ne sera pas réalisable, si c'est le cas on laissera tomber la partie RC2014 et je me concentrerai sur la partie mémoire, cartouche, et diverses extentions sur la carte de base.
Je comprend ce que tu explique mais je suis incappable de t'aider sur ce point, tu m'en vois désolé.
Dis moi ce que tu en pense et surtout ne perd pas plus de temps si tu sens que c'est une impasse.
Je vais, de mon côté, voir si je peux avoir de l'aide.
Bon weekend
Jean-François
Il n'y a que 11 sortes de gens, ceux qui comprennent ceux qui ne comprennent pas et ceux qui me font répéter!
Jean-François
Jean-François
Re: Canon X07 - The project
Petite mise à jour avec passage en version 1.0 et non en 0.3 à cause d'une refonte des signaux :
- Canon-X07.png (229.18 Kio) Consulté 718 fois
- CPLD.png (152.39 Kio) Consulté 718 fois
Re: Canon X07 - The project
Disons que je n'espère plus la reproduction exacte des timings pour une compatibilité à "99,9%" avec l'ensemble des cartes RC2014. J'espère juste qu'avec cette simplification sur /MREQ et /IORQ, on arrivera quand même à gérer les cas spéciaux sur le bus RC2014 et à être dans les clous avec KIO et ses semblables. Et puis ça libèrera autant de place dans le CPLD pour la gestion de tes mémoires/cartouches/extensions non RC2014.
Re: Canon X07 - The project
Bonjour Hlide,
OK pour tout, je vais continuer d'avancer doucement, la semaine prochaine je ne serais pas absent mais en ce moment c'est assez difficile.
De toute façon on se tiens au courant.
Bonne journée
Jean-François
OK pour tout, je vais continuer d'avancer doucement, la semaine prochaine je ne serais pas absent mais en ce moment c'est assez difficile.
De toute façon on se tiens au courant.
Bonne journée
Jean-François
Il n'y a que 11 sortes de gens, ceux qui comprennent ceux qui ne comprennent pas et ceux qui me font répéter!
Jean-François
Jean-François
Re: Canon X07 - The project
Bonjour à tous,
Bon malgré quelques soucis de santé me revoilà.
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 donc recherché si il avait été créé une carte 8085 pour le bus RC2014 et bingo.
Voici deux liens qui parlent de cette carte. Je sais que ce n'est pas du NSC800 mais cela peux donner des idées pour la génération des signaux manquants.(ou pas
).
https://feilipu.me/2021/08/15/8085-cpu-on-the-z80-bus/
https://groups.google.com/g/rc2014-z80/c/qo7nfDZmY-k
Attenton le schéma est donné à plusieurs endroits et il semblerait que la dernière version de la carte soit la v4!
Sinon, il y a aussi un japonais qui a fait un adaptateur NSC800 pour SBC Z80, mais on a très peu de renseignements!
http://haserin09.la.coocan.jp/board.html#BYHASERIN
Voilà mes trouvailles du moment, je continu à bosser sur le schéma pour dégrossir la carte.
Bonne journée
Jean-François
Bon malgré quelques soucis de santé me revoilà.
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 donc recherché si il avait été créé une carte 8085 pour le bus RC2014 et bingo.
Voici deux liens qui parlent de cette carte. Je sais que ce n'est pas du NSC800 mais cela peux donner des idées pour la génération des signaux manquants.(ou pas
).https://feilipu.me/2021/08/15/8085-cpu-on-the-z80-bus/
https://groups.google.com/g/rc2014-z80/c/qo7nfDZmY-k
Attenton le schéma est donné à plusieurs endroits et il semblerait que la dernière version de la carte soit la v4!
Sinon, il y a aussi un japonais qui a fait un adaptateur NSC800 pour SBC Z80, mais on a très peu de renseignements!
http://haserin09.la.coocan.jp/board.html#BYHASERIN
Voilà mes trouvailles du moment, je continu à bosser sur le schéma pour dégrossir la carte.
Bonne journée
Jean-François
Il n'y a que 11 sortes de gens, ceux qui comprennent ceux qui ne comprennent pas et ceux qui me font répéter!
Jean-François
Jean-François
Re: Canon X07 - The project
Re-bonjour à tous,
@Hlide - Un autre document trouvé à l'instant, contenant une carte RC2014 pour 8085 et une pour NSC800 en espèrant que cela puisse aider.
Pas sûr que cela apporte grand chose mais bon.
Bonne journée
Jean-François
@Hlide - Un autre document trouvé à l'instant, contenant une carte RC2014 pour 8085 et une pour NSC800 en espèrant que cela puisse aider.
Pas sûr que cela apporte grand chose mais bon.
Bonne journée
Jean-François
Il n'y a que 11 sortes de gens, ceux qui comprennent ceux qui ne comprennent pas et ceux qui me font répéter!
Jean-François
Jean-François
Re: Canon X07 - The project
Je viens de lire le premier lien qui donne un exemple de conversion des signaux /mreq et /iorq.
Deux problèmes :
- le signal /mreq descend presque en même temps que /rd mais pas /wr (le signal sera plus court). C'est pourquoi je n'ai pas voulu procéder ainsi. J'ai considéré que si le signal ale passe à 0, c'est que l'adresse est déjà stabilisée et que l'on pouvait initier un /mreq ou /iorq à 0 de sorte que le périphérique concerné sera déjà prêt à répondre sur /rd ou /wr. Et si ces signaux ne sont actifs, il n'y aura pas de réponse donc ce ne devrait pas être grave. Et à chaque ale à 1, les signaux /mreq et /iorq repassent à 1.
- le nsc800 est un z80, non un 8085, le signal /inta est donc à prendre en compte.
Il y en a un autre problème je crois mais je ne peux pas me replonger dans les détails (smartphone en montagne).
Le fonctionnement d'un 8085 sur un bus z80 n'est pas symétrique au celui d'un z80 sur un bus 8085 (cas du nsc800).
Deux problèmes :
- le signal /mreq descend presque en même temps que /rd mais pas /wr (le signal sera plus court). C'est pourquoi je n'ai pas voulu procéder ainsi. J'ai considéré que si le signal ale passe à 0, c'est que l'adresse est déjà stabilisée et que l'on pouvait initier un /mreq ou /iorq à 0 de sorte que le périphérique concerné sera déjà prêt à répondre sur /rd ou /wr. Et si ces signaux ne sont actifs, il n'y aura pas de réponse donc ce ne devrait pas être grave. Et à chaque ale à 1, les signaux /mreq et /iorq repassent à 1.
- le nsc800 est un z80, non un 8085, le signal /inta est donc à prendre en compte.
Il y en a un autre problème je crois mais je ne peux pas me replonger dans les détails (smartphone en montagne).
Le fonctionnement d'un 8085 sur un bus z80 n'est pas symétrique au celui d'un z80 sur un bus 8085 (cas du nsc800).