Décodage d'adresses... je m'y intéresse enfin !

[Falkor]

Bonjour à tous,

Je profite de ces moments de confinement hélas sans mon matériel pour faire un peu de théorie et consacrer du temps à des notions sur lesquelles j'aimerai monter en compétences.

J'avais un petit projet pratique qui me trottait en tête depuis quelques temps, projet impliquant de manipuler des notions de décodage d'adresse et d'étude de "memory-maps", j'ai donc décidé de m'y plonger plus sérieusement.

Il y a quelque temps j'avais récupéré de grosses quantités d'uvproms 2716 et un programmateur. Mais quoi faire avec ? 2 ko c'est vraiment pas grand chose... J'avais des cartouches de VCS2600 qui trainaient par là, et je savais que leur capacité native était de 4 ko. Je me suis donc dit pourquoi ne pas tenter de concevoir un circuit associant deux mémoires 2716 pour obtenir un total de 4 ko ? Ok ça semble lourd pour une simple cartouche de 4 ko mais c'est l'occasion de réfléchir un peu...

Je me suis donc lancé en fonction de mes connaissances actuelles... J'enfonce surement des portes ouvertes mais j'espère que ma méthode et mes conclusions sont justes !

Je commence donc par la memory map de la machine :

Code : Tout sélectionner

registres TIA   $0000 à $007F
RAM		$0080 à $00FF
registres RIOT	$0200 à $02FF
ROM		$1000 à $1FFF

Parler en hexa me dérange un peu, je passe donc en décimal :

Code : Tout sélectionner

registres TIA   0 à 127
RAM		128 à 255
registres RIOT	512 à 767
ROM		4096 à 8191

On a bien nos 128 octets de RAM (!) et nos 4096 octets de ROM en cartouche. Il y a plein de "trous", je ne sais pas trop pourquoi on ne cherche pas à tout rassembler. Ça simplifie certainement l'électronique de décodage ?

Bref, je calcule le milieu de la zone mémoire pour la couper en deux, j'en déduit que la première moitié se situe entre 4096 et 6143 (décimal) soit $1000 à $17FF et la seconde entre 6144 à 8191, soit $1800 à $1FFF

Je passe en binaire histoire d'avoir quelque chose de plus "visuel" :

tableau1.jpg (185.5 Kio) Consulté 1548 fois

J'observe que le µP accède à la cartouche si et seulement si A12=1. Ce signal peut donc être utilisé comme signal de "chip select" (via une porte inverseurse bien sûr) pour les chips de mémoire de la cartouche, observation confirmée par une recherche en ligne.

Pour différentier mes deux parties de ROM, je peux manifestement utiliser A11 :
A11=0 -> première moitié
A11=1 -> seconde moitié

J'en déduit ce petit tableau, avec !CE1 le chip select de ma 1ere moitié et !CE2 la 2ème :

tableau2.jpg (28.13 Kio) Consulté 1548 fois

Sachant ceci, je peux tenter de faire un peu de logique. J'aimerai utiliser des portes NAND pour construire mes deux "!chip select".

J'ai des souvenirs (trop) vagues du lycée où il fallait écrire de longues équations puis les simplifier avec divers formules (je me souviens de "DeMorgan").

J'ai préféré cogiter pour sortir ceci :

portes.jpg (23.61 Kio) Consulté 1548 fois

Que je vais tenter de simuler avant d'aller plus loin... (et surtout avant d'avoir vos avis !)

Bon encore une fois désolé si je répète des notions de bases (que j'espère justes ) ou des trucs évidents mais ce projet est une vraie occasion de me plonger dans ces notions de décodage qui m'ont parfois posé problème.

Que pensez-vous de mes observations/conclusions

Merci pour votre retour !

[Totor le Butor]

Jusque là... tout va bien !

[Falkor]

Vraiment ? Bon bah c'est plus simple que je pensais alors.

Même la partie décodage et mes portes NAND aussi ? J'ai pas encore simulé le résultat.

J'attaque le dessin du schéma...

[Xavier_AL]

Salut Falkor,

Si tu te souviens des tableaux de Karnaugh…

J'ai aussi besoin d'une piquouse de rappel, car les cours d'automatismes sont bien loin.

Et ça ne servirai aussi pour mes cartes.

Le poste un projet sur un autre fil, car il y a des "oublis" sur un schéma pour une carte Zx81...

[Je reste pour faire le bilan, moi aussi ]

[irios]

Le raisonnement est parfait et la logique aussi.
Il y a des composants tout fait pour réaliser du décodage simple comme les 74LS139 (2 vers 4) et 74LS138 (3 vers 8 )
Cependant, il faut bien prendre en considération que dans un plan d'adressage il y a les bits utilisés pour les adresses (connectés directement au boitier comme de la SRAM, EPROM, PIA, PPI, ACIA,etc) et les bits de sélection de la plage d'adresses (connectés sur le décodeur d'adresses). En règle général, ces bits sont les bits de poids fort du bus d'adresse (A15,A14,A13,...)

[Falkor]

Les tableaux de Karnaugh, c'est ça !

Bon dans un cas comme celui-ci je ne pense pas qu'utiliser un tel outil soit utile mais je vais quand même tenter histoire de voir si je retombe sur ce que vous m'avez validé.

@Irios : oui j'ai souvent vu ces références de CIs dans des schémas, je vais regarder comment ça fonctionne.

Merci pour vos retours !

[Totor le Butor]

Oops , il y a une minuscule toute petite pétouille, sur ton schéma tu as inversé /ce1 et /ce2 par rapport à ton tableau.
Dans un NAND, 1 et 1 = 0 , 1 et 0 = 1

Pour faire du décodage d'adresse un petit plus velu sans trop se prendre la tête tu peux aussi utiliser une Eprom pour faire le job. C'est beaucoup plus souple puisque modifiable par rapport à un circuit cablé et en plus on dispose de 8 bits de données pour adresser 8 boitiers différents ou un panachage des 8 .

Pour reprendre ton besoin, tu connectes A12 et A11 aux pattes A10 et A9 de la 2716, les autres pattes d'adresses de la 2716 à 0. Le /CS et le /OE de la 2716 à 0 en permanence.

Pour le /CE1 : (A12 à 1 et A11 à 0) -> (eprom A10 à 1, A9 à 0), tu remplis l'eprom de 0 sur le bit de données D0, tous les autres bits de données à 1 (soit FE), de l'adresse 1024 de l'eprom (Hex 400) à 1535 (hex 5FF), tu auras le /CE1 sur le bit D0.

Pour le /CE2 : (A12 à 1 et A11 à 1) -> (eprom A10 à 1, A9 à 1 ), tu remplis l'eprom de 0 sur le bit de données D1, tous les autres bits de données à 1 (soit FD), de l'adresse 1536 de l'eprom (Hex 600) à 2047 (Hex 7FF), tu auras le /CE2 sur le bit D1.

Ce type de technique est très utilisé avec des petites proms de type 74S387 ou similaire dans nos Sasfépu. Par exemple, dans un C64 il y a un PLA qui crame souvent et qui est remplaçable par une eprom rapide.
Le seul souci est la lenteur relative des eproms qui avoisine les 150 à 450 nS pour avoir la bonne info sur les pattes de données une fois l'adresse positionnée et stable. Ce délai peut être divisé par 2 à 3 si l'eprom est tout le temps sélectionnée.
Pour une vieille 2716 de 450 nS de temps d'accès et si elle sélectionnée en permanence (/CS et /OE à 0), l'accès à la donnée une fois l'adresse positionnée est d'environ 120 nS .

[Falkor]

@Totor : merci d'avoir relevé cette boulette, qui m'aurait sans doute posé pas mal de problèmes lors des tests.

J'ai utilisé un petit utilitaire "Logical circuit" qui m'a sorti direct la table de vérité :

table.jpg (121.29 Kio) Consulté 1425 fois

(Je vous rassure je l'avais aussi faite à la main ) et qui m'a permis de confirmer que je m'étais planté.

Malin ton astuce d'utiliser une mémoire en plus pour le décodage ! Tu fais en gros directement la saisie de ta table de vérité à l'intérieur, les adresses de ton UVPROM étant les entrées et les bits de data les sorties individuelles ? Je ne savais pas que le PLA du C64 fonctionnait de cette façon... ! J'imagine que pour décoder huit circuits différents d'un coup on gagne énormément en circuiterie !

Concernant la 2716 toujours, la datasheet me dit que pour la lecture:
-VPP est à 5V
-/OE et /CE à la masse (cf tes explications). En "standby", /CE = high et /OE "don't care". J'ai donc intérêt à laisser en permanence /OE à la masse et injecter mes /CE1 - /CE2 sur les /CE ?

Merci !

[Papy.G]

/CE1-/CE2 sur les /CE, et le signal de lecture (/R ?) sur /OE.

[Totor le Butor]

Oui, effectivement tu saisies la table de vérité dans l'eprom, une erreur... pas grave tu effaces et modifies . C'est quand même plus souple qu'une logique câblée et fixe !
C'est mieux de valider le circuit par le /CE car ça sort l'eprom du mode stand-bye et basse consommation mais tu peux aussi connecter les 2 entrées de validations ensemble.

Une petite observation, il est toujours bien de prévoir une petite résistance de pull-up (4,7 K relié au +5v) sur une entrée de validation comme ça tu ne risques pas d'avoir des phénomènes imprévisibles et c'est indispensable si la commande se fait par un circuit comportant des sorties susceptibles d'être en haute impédance.

[Falkor]

La console n'envoie pas de signal de lecture, seuls les bus d'adresse et de data sont présents sur le slot de connexion de la cartouche.

J'ai voulu regarder des schémas de cartouche existants, mais je ne retrouve pas les bons signaux sur celui-ci: https://www.atariage.com/2600/archives/ ... e_PAL.html

Sur cet autre, /OE est à la masse, /CE correspond à /A12 : http://www.grandideastudio.com/wp-conte ... ematic.pdf

Je reste donc là dessus, et en ajoutant une résistance de tirage pour la sécu ?

Tiens concernant cette dernière, faut-il comme pour les capas de découplage les positionner au plus près des broches concernées ou je peux la caler où il y a de la place

[Papy.G]

/CE vers /OE des chips sans passer par l'Eprom. Voir dans les spécifications pour voir si la chronologie des signaux est importante, s'il est nécessaire d'inverser le câblage du /CE et du /OE sur chaque chip.

[hlide]

Comme dit Papy.G, on trouve plutôt un /CS sur le /OE de la ROM, et le /CE de la ROM à la masse pour toujours.

[Falkor]

J'ai étudié 2 datasheets :

2716_1.jpg (176.94 Kio) Consulté 1350 fois

2716_2.jpg (143.54 Kio) Consulté 1350 fois

Dans les deux cas l'utilisation du /CE provoque les délais les plus longs (si j'interprète bien) par rapport à l'utilisation de /OE, donc j'ai effectivement intérêt à caler les /CE de mes roms à la masse et faire les activations direct avec /OE comme vous me le conseillez.

Après les chronogrammes montrent que les µC basculent d'abord le /CE avant /OE. C'est toujours le cas ?

[Papy.G]

Le bon sens en tout cas, veut que tu choisisse le chip (/CE) avant de lui demander de te causer (/OE).