[Zx81] Buffer de BUS pour Zx81.
Modérateurs : Papy.G, fneck, Carl
Re: [Zx81] Buffer de BUS pour Zx81.
C'est la French Touch et la Deutsche Qualität
Re: [Zx81] Buffer de BUS pour Zx81.
J'ai le temps pour tout numériser...justement sur le fil "[ZX81] Donne plein de documentation ZX81" il y a des livres qui correspondraient.
Re: [Zx81] Buffer de BUS pour Zx81.
Salut,
Siggi confirme la complexité de l'activation de U4, Bus de donnée.
Siggi confirme la complexité de l'activation de U4, Bus de donnée.
Au niveau de la carte, j'ai encore de la place, mais ça va être "rock n'roll"..Hi Xav
your data bus buffer U4 is only activated (/CE = low), while /RFSH is low. Thus you are not able to acces data in external ram, rom or i/o-cards during normal READ/WRITE cycles.
You will need a more complex logic to activate the data bus buffer when needed and when allowed!
I think, this will by a solution:
the data bus buffer should be activated (/CE=LOW) all the time, except during that phases:
- while internal ram or rom is accessed (onboard the Zeddy, before the data bus buffer). Thus /MREQ is LOW and either /RAMCS or /ROMCS is LOW (external ram cards push /ROMCS or /RAMCS to high, if they use that address range itself)
- while internal i/o devices (ULA) are accessed.Thus /IORQ is LOW and either A0 or A1 are low (or A2, if the printer is used)
HTH
Siggi
Re: [Zx81] Buffer de BUS pour Zx81.
Il te reste aussi la solution d'utiliser un 16V8 ou de simplement supprimer U4.
Re: [Zx81] Buffer de BUS pour Zx81.
Salut Fred,
Le GAL d"Atmel est une solution plaisante, mais un peu compliquée à metre en oeuvre.
La suppression du buffer DATA est une régression inenvisageable car on perd l'avantage de normaliser les tensions en entrée du BUS.
Par contre, en sortie de BUS, pas besoin de faire de buffer!
On envoie tout en direct (diodes signals, et on bufferise l'entée…
Il faudrait un suiveur octal entant… ça doit exister.
J'attends de voir les montages proposés sur les docs mises à disposition par dgillou.
Dans le cas contraire, je place la logique sur la carte.
[edit:
Pourquoi ne pas prendre le LS244 sur le \RD et le \WR pour le BUS data…
]
Le GAL d"Atmel est une solution plaisante, mais un peu compliquée à metre en oeuvre.
La suppression du buffer DATA est une régression inenvisageable car on perd l'avantage de normaliser les tensions en entrée du BUS.
Par contre, en sortie de BUS, pas besoin de faire de buffer!
On envoie tout en direct (diodes signals, et on bufferise l'entée…
Il faudrait un suiveur octal entant… ça doit exister.
J'attends de voir les montages proposés sur les docs mises à disposition par dgillou.
Dans le cas contraire, je place la logique sur la carte.
[edit:
Pourquoi ne pas prendre le LS244 sur le \RD et le \WR pour le BUS data…
]
Re: [Zx81] Buffer de BUS pour Zx81.
Bonjour,
@Xavier,
Je ne sais pas ce que tu entends par :
Mais le Z80 ne supportera pas d'avoir trop de charge (de CI) sur son bus de donnée et le fait de ne buffériser qu'en entrée n'aidera pas si il y a plusieurs cartes.
A moins que je n'ai pas compris ce que tu envisage.
Je pense que la solution va résider, comme l'a suggéré Fred_72, en une PAL ou une GAL ou plus antique ... une EPROM!
Bonne journée
Jean-François
@Xavier,
Je ne sais pas ce que tu entends par :
Par contre, en sortie de BUS, pas besoin de faire de buffer!
On envoie tout en direct (diodes signals, et on bufferise l'entée
Mais le Z80 ne supportera pas d'avoir trop de charge (de CI) sur son bus de donnée et le fait de ne buffériser qu'en entrée n'aidera pas si il y a plusieurs cartes.
A moins que je n'ai pas compris ce que tu envisage.
Je pense que la solution va résider, comme l'a suggéré Fred_72, en une PAL ou une GAL ou plus antique ... une EPROM!
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: [Zx81] Buffer de BUS pour Zx81.
On revient au même problème: le bus est complètement bloqué en lecture.
Je sais que c'est très énervant et frustrant mais on se trouve sur un bus bidirectionnel donc il faut penser à tout en même temps. Je me suis fait avoir plus d'une fois et après il faut charcuter le circuit ce qui serait dommage vu la beauté de l'ouvrage.
Le fait d'utiliser 2 moitiés de 244 revient à utiliser un 245 (mais la logique de commande est séparée ce qui peu la rendre plus simple).
Pour la sortie, aucun problème, il est possible d'utiliser le 244 piloté par /WR (/OE=/WR) (il faut peut être aussi ajouté /RFSH ??) car les données sortent du ZX donc pas de problème de conflit avec le bus. En écriture les données sortent du CPU.
Pour l'entrée c'est toujours le même problème, tu ne résonnes qu'avec les cartes d'extensions. Mais le Z80 peut lire n'importe quoi: sa RAM, sa ROM, le clavier, ... Si le 244 est simplement activé par /RD alors on court-circuite les données présentes sur le bus.
Il faut donc limiter l'activation du 244 (pour le RD) aux seuls cas qui correspondent aux périphériques placés après le buffer.
Il faut donc commencer par regarder les domaines d'I/O des différentes cartes et voir ce qu'elles utilisent.
Ensuite, il sera possible de faire une "carte" et de déterminer les zones d'activation du bus de données en entrée.
Le choix d'une GAL permet de modifier la programmation et donc cette "carte" de manière très souple sans avoir à placer des tonnes de cavaliers ou de charcuter les pistes. Mais il faut d'abord faire un état des lieux des cartes et de leurs besoins et ensuite on pourra envisager une solution LS ou GAL.
Je sais que c'est très énervant et frustrant mais on se trouve sur un bus bidirectionnel donc il faut penser à tout en même temps. Je me suis fait avoir plus d'une fois et après il faut charcuter le circuit ce qui serait dommage vu la beauté de l'ouvrage.
Le fait d'utiliser 2 moitiés de 244 revient à utiliser un 245 (mais la logique de commande est séparée ce qui peu la rendre plus simple).
Pour la sortie, aucun problème, il est possible d'utiliser le 244 piloté par /WR (/OE=/WR) (il faut peut être aussi ajouté /RFSH ??) car les données sortent du ZX donc pas de problème de conflit avec le bus. En écriture les données sortent du CPU.
Pour l'entrée c'est toujours le même problème, tu ne résonnes qu'avec les cartes d'extensions. Mais le Z80 peut lire n'importe quoi: sa RAM, sa ROM, le clavier, ... Si le 244 est simplement activé par /RD alors on court-circuite les données présentes sur le bus.
Il faut donc limiter l'activation du 244 (pour le RD) aux seuls cas qui correspondent aux périphériques placés après le buffer.
Il faut donc commencer par regarder les domaines d'I/O des différentes cartes et voir ce qu'elles utilisent.
Ensuite, il sera possible de faire une "carte" et de déterminer les zones d'activation du bus de données en entrée.
Le choix d'une GAL permet de modifier la programmation et donc cette "carte" de manière très souple sans avoir à placer des tonnes de cavaliers ou de charcuter les pistes. Mais il faut d'abord faire un état des lieux des cartes et de leurs besoins et ensuite on pourra envisager une solution LS ou GAL.
Re: [Zx81] Buffer de BUS pour Zx81.
Salut,
@Jean-françois.
J'ai demandé à Siggi le nombre de cartes avec et sans buffer… c'est donc 5 sans et 10 à 20 cartes avec.
Par contre, un PAL ou un GAL me semble luxueux pour un répéteur de signal, mais si cela est nécessaire…
Par plus ancien… tu veux dire… relais 5 volts ? … c'est pas con.. mais à force de blaguer plus personne ne va plus rien comprendre… ou l'inverse.
Et personnellement, un contrôle sur RD et WR est largement suffisant pour des cartes simples. [nan, cf Fred]
Au pire, si certaines fonctions direct sur le bus posent problème, ont les mets en amont du buffer pour éviter l'isolation galvanique des infos en buffer.
Je prends l'exemple de la fonction IN et OUT normalement activé avec \RD et \WR... sur la Memotech IF, un IN envoie l'info à la carte… le RD sera activé et non en WR du dus DATA, donc IF Centronics avant la carte buffer…
[Fred à posté en même temps, et…]
@Fred, donc selon toi la sortie vers l'extension est sur : (\RFSH+ \WR)
Et on utilise l'entrée par défaut, si aucune info d'écriture n'est envoyée avec \RFSH+NOT \WR...
Sortie conditionnée par le \WR et libre en lecture si rien n'est envoyé.
Là on est d'accord, \RD n'est donc pas utile pour lire une adresse en mode direct sans \RD.
Donc c'est tout simple…
@Jean-françois.
J'ai demandé à Siggi le nombre de cartes avec et sans buffer… c'est donc 5 sans et 10 à 20 cartes avec.
Par contre, un PAL ou un GAL me semble luxueux pour un répéteur de signal, mais si cela est nécessaire…
Par plus ancien… tu veux dire… relais 5 volts ? … c'est pas con.. mais à force de blaguer plus personne ne va plus rien comprendre… ou l'inverse.
Et personnellement, un contrôle sur RD et WR est largement suffisant pour des cartes simples. [nan, cf Fred]
Au pire, si certaines fonctions direct sur le bus posent problème, ont les mets en amont du buffer pour éviter l'isolation galvanique des infos en buffer.
Je prends l'exemple de la fonction IN et OUT normalement activé avec \RD et \WR... sur la Memotech IF, un IN envoie l'info à la carte… le RD sera activé et non en WR du dus DATA, donc IF Centronics avant la carte buffer…
[Fred à posté en même temps, et…]
@Fred, donc selon toi la sortie vers l'extension est sur : (\RFSH+ \WR)
Et on utilise l'entrée par défaut, si aucune info d'écriture n'est envoyée avec \RFSH+NOT \WR...
Sortie conditionnée par le \WR et libre en lecture si rien n'est envoyé.
Là on est d'accord, \RD n'est donc pas utile pour lire une adresse en mode direct sans \RD.
Donc c'est tout simple…
Re: [Zx81] Buffer de BUS pour Zx81.
Oui pour l'écriture c'est tout simple c'est /WR qui pilote. Pour RFSH je ne suis pas sûr (à voir avec la gestion de l'affichage si c'est utile ?? mes connaissances ZX sont trop limitées. J'étais jeune à l'époque ).
Je ne comprend pas ce que tu entends par libre en lecture.
Le buffer doit être présent en écriture et en lecture soit 2 buffers, sinon ça revient à shunter le buffer par un fil. La seule parade pour n'utiliser qu'un buffer c'est de faire appel à un buffer à collecteurs ouverts et des résistances de pull-up mais pas sûr que la sortance soit au top.
NB: La GAL n'est pas compliquée à utiliser car elle se programme en CUPL (un langage tout simple avec des ET et des OU) et un simple TL866 peut la programmer.
Je ne comprend pas ce que tu entends par libre en lecture.
Le buffer doit être présent en écriture et en lecture soit 2 buffers, sinon ça revient à shunter le buffer par un fil. La seule parade pour n'utiliser qu'un buffer c'est de faire appel à un buffer à collecteurs ouverts et des résistances de pull-up mais pas sûr que la sortance soit au top.
NB: La GAL n'est pas compliquée à utiliser car elle se programme en CUPL (un langage tout simple avec des ET et des OU) et un simple TL866 peut la programmer.
Re: [Zx81] Buffer de BUS pour Zx81.
Je ne comprends pas trop pourquoi le /RFSH vous préoccupe. Un Z80 ne mixe pas un /RD ou /WR avec /RFSH et le bus de donnée n'est pas sollicité durant un /RFSH (ce bus devrait être en haute-impédance). Certes, le ZX81 s'en sert pour le jeu de caractères mais c'est sur le bus d'adresse que les choses se passent. Et même si le bus de donnée serait mis à contribution pour la tambouille interne d'affichage, ce n'est pas quelque chose à externaliser.
Pour ce qui est du GAL ou PAL, le source est un fichier texte qui décrit assez simplement une équation logique pour chaque sortie et avec WinCUPL, il y a aussi un simulateur qui permet de voir comment se comporte le GAL/PAL sur la présentation des signaux en entrée. Et on peut se servir des broches supplémentaires sur un piano pour obtenir des sorties programmables (supposons que vous ayez 4 cas, le GAL/PAL pourrait embarquer la personnalisation via un piano à 2 bits branché sur deux broches en entrée du GAL/PAL).
Pour ce qui est du GAL ou PAL, le source est un fichier texte qui décrit assez simplement une équation logique pour chaque sortie et avec WinCUPL, il y a aussi un simulateur qui permet de voir comment se comporte le GAL/PAL sur la présentation des signaux en entrée. Et on peut se servir des broches supplémentaires sur un piano pour obtenir des sorties programmables (supposons que vous ayez 4 cas, le GAL/PAL pourrait embarquer la personnalisation via un piano à 2 bits branché sur deux broches en entrée du GAL/PAL).
Re: [Zx81] Buffer de BUS pour Zx81.
Un exemple pour mieux comprendre:
Soit 3 extensions I/O:
Une carte son AY: 2 adresses en écriture $DF et $0F
Une carte vocale SP0256: 1 adresse en écriture $3F et une adresse en lecture $3F
Une carte 8 entrées AN: 1 adresse en écriture $1F et une adresse en lecture $1F
Je garde une config à 2 LS244 pour faire plus simple.
Pour l'écriture pas de soucis, le buffer est commandé par /WR (Ok hlide, merci pour RSFH).
Pour la lecture, le buffer ne doit être activé que pour RD aux adresses $1F et $3F
Soit le schéma suivant: J'ai choisi un 16V8 mais des LS feraient tout à fait l'affaire dans cet exemple simple.
Les équations sont donc :
Soit 3 extensions I/O:
Une carte son AY: 2 adresses en écriture $DF et $0F
Une carte vocale SP0256: 1 adresse en écriture $3F et une adresse en lecture $3F
Une carte 8 entrées AN: 1 adresse en écriture $1F et une adresse en lecture $1F
Je garde une config à 2 LS244 pour faire plus simple.
Pour l'écriture pas de soucis, le buffer est commandé par /WR (Ok hlide, merci pour RSFH).
Pour la lecture, le buffer ne doit être activé que pour RD aux adresses $1F et $3F
Soit le schéma suivant: J'ai choisi un 16V8 mais des LS feraient tout à fait l'affaire dans cet exemple simple.
Les équations sont donc :
Code : Tout sélectionner
Name Example_buffer ;
Device g16v8a ;
/* *************** INPUT PINS *********************/
PIN 1 = A0 ;
PIN 2 = A1 ;
PIN 3 = A2 ;
PIN 4 = A3 ;
PIN 5 = A4 ;
PIN 6 = A5 ;
PIN 7 = A6 ;
PIN 8 = A7 ;
PIN 9 = nIORQ ;
PIN 11 = nRD ;
/* *************** OUTPUT PINS *********************/
PIN 19 = nOERD ; /* Commande LS244 RD */
/* EQUATIONS */
!nOERD = (!nRD & !nIORQ & !A7 & !A6 & !A5 & A4 & A3 & A2 & A1 & A0) # (!nRD & !nIORQ & !A7 & !A6 & A5 & A4 & A3 & A2 & A1 & A0);
Re: [Zx81] Buffer de BUS pour Zx81.
En gardant le même schéma mais en utilisant un champ d'adresses, l'équation est plus simple à écrire :
Code : Tout sélectionner
Name Example_buffer ;
Device g16v8a ;
/* *************** INPUT PINS *********************/
PIN 1 = A0 ;
PIN 2 = A1 ;
PIN 3 = A2 ;
PIN 4 = A3 ;
PIN 5 = A4 ;
PIN 6 = A5 ;
PIN 7 = A6 ;
PIN 8 = A7 ;
PIN 9 = nIORQ ;
PIN 11 = nRD ;
/* *************** OUTPUT PINS *********************/
PIN 19 = nOERD ; /* Commande LS244 RD */
FIELD ADDRS = [A7..0];
/* EQUATIONS */
!nOERD = (!nRD & !nIORQ & ADDRS:[1F]) /* carte ANA */
# (!nRD & !nIORQ & ADDRS:[3F]); /* carte SP0 */
Re: [Zx81] Buffer de BUS pour Zx81.
Et enfin en utilisant un 245 à la place des 2 LS244 cela donne:
Voilà, c'est quand même plus simple que d'aligner des portes logiques, non ?
Et le code:
Code : Tout sélectionner
Name Example_buffer ;
Device g16v8a ;
/* *************** INPUT PINS *********************/
PIN 1 = A0 ;
PIN 2 = A1 ;
PIN 3 = A2 ;
PIN 4 = A3 ;
PIN 5 = A4 ;
PIN 6 = A5 ;
PIN 7 = A6 ;
PIN 8 = A7 ;
PIN 9 = nIORQ ;
PIN 11 = nRD ;
PIN 12 = nWR ;
/* *************** OUTPUT PINS *********************/
PIN 18 = DIR245; /* Commande direction 245 0:Z2>Z1 1:Z1>Z2 */
PIN 17 = nCE245; /* Commande activation 245 */
FIELD ADDRS = [A7..0];
/* EQUATIONS */
!nCE245 = !nWR /* Ecriture */
# (!nRD & !nIORQ & ADDRS:[1F]) /* carte ANA */
# (!nRD & !nIORQ & ADDRS:[3F]); /* carte SP0 */
DIR245 = !nWR;
Re: [Zx81] Buffer de BUS pour Zx81.
Salut à tous,
Merci Fred pour cet exemple, et le décodage d'adresse devient beaucoup plus simple avec ce merveilleux 16v8 !
Perso je suis resté sur du TTL de base pour éviter la programmation de micro-contrôleurs ou autre GAL/PAL reprogrammables.
Dans mon esprit, il fallait acheter des programmeurs d'Eprom cent fois plus chère que les boitiers.
Pour des projets collaboratifs, il est plutôt difficile de rentrer dans la spécialisation technique… même si un Arduino, une Eprom ou tout autre composant programmable, sont facilement programmables avec des outils qui ne serviront qu'une fois.
Je suis resté : on achète, on soude… ça marche.
L'élément: "Oui, mais j'ai pas le truc pour le programmer…" reste un frein à la fabrication.
Même si une personne se propose de les flasher, le projet ne restera plus indépendant et libre d'accès.
Mais, pour des projets personnels, ce type de composants est formidable.
Je me mets du côté de la personne qui va être confrontée au grain de sable qui va laisser le projet à l'abandon à cause d'un code, d'un matériel inadapté ou une erreur de montage.
Cette solution est pratique, séduisante et simple… Mais tous n'ont pas voué leur passion à l'électronique.
Souder des pattes reste simple, mais programmer un boîtier… reste et restera une énigme pour certains.
[edit: En même temps, j'ai trouvé des programmeurs USB a 10€, donc du coup, cette solution me parait pertinente…]
Merci Fred pour cet exemple, et le décodage d'adresse devient beaucoup plus simple avec ce merveilleux 16v8 !
Perso je suis resté sur du TTL de base pour éviter la programmation de micro-contrôleurs ou autre GAL/PAL reprogrammables.
Dans mon esprit, il fallait acheter des programmeurs d'Eprom cent fois plus chère que les boitiers.
Pour des projets collaboratifs, il est plutôt difficile de rentrer dans la spécialisation technique… même si un Arduino, une Eprom ou tout autre composant programmable, sont facilement programmables avec des outils qui ne serviront qu'une fois.
Je suis resté : on achète, on soude… ça marche.
L'élément: "Oui, mais j'ai pas le truc pour le programmer…" reste un frein à la fabrication.
Même si une personne se propose de les flasher, le projet ne restera plus indépendant et libre d'accès.
Mais, pour des projets personnels, ce type de composants est formidable.
Je me mets du côté de la personne qui va être confrontée au grain de sable qui va laisser le projet à l'abandon à cause d'un code, d'un matériel inadapté ou une erreur de montage.
Cette solution est pratique, séduisante et simple… Mais tous n'ont pas voué leur passion à l'électronique.
Souder des pattes reste simple, mais programmer un boîtier… reste et restera une énigme pour certains.
[edit: En même temps, j'ai trouvé des programmeurs USB a 10€, donc du coup, cette solution me parait pertinente…]