Bus d'extension - accès à la RAM

Merci Jede, je vais regarder ça !

Mais comme je l'ai déjà dit, le gros souci que je vois avec le RPi c'est que tu te colles un Linux complet pour pas grand-chose en fait, et que du coup le boot est loin d'être immédiat, ça prend bien 30 sec minimum...

Bonjour Laurent,

Le 6502 ne peut pas faire de DMA car il ne peut pas libérer son bus d'adresse. Il faut ajouter des buffers pour çà. Le 65C02 peut le faire (certains modèles) car il dispose d'une patte BE (qui permet associée à RDY de mettre le bus d'adresse en HI-Z).

Pour récupérer les données de la RAM vidéo ça ne marche pas non plus car l'ULA adresse directement la mémoire sans passer par le bus du processeur. Il utilise directement les multiplexeurs des RAM.Donc pas d'activité sur le bus d'adresse concernant la RAM vidéo.
Par contre, tu peux avoir accès aux données écrites par le 6502 lors de la modification de la RAM. Il faut donc avoir un buffer image de la RAM.

Voilà, bon courage...

fred72 a écrit:Bonjour Laurent,

Le 6502 ne peut pas faire de DMA car il ne peut pas libérer son bus d'adresse. Il faut ajouter des buffers pour çà. Le 65C02 peut le faire (certains modèles) car il dispose d'une patte BE (qui permet associée à RDY de mettre le bus d'adresse en HI-Z).
.

Sur la feuille de donnees du uP il y a l info d'une DMA possible, mais apparemment en utilisant RDY pour stopper le 6502, mais si on a pas la haute impedance sur le bus d'adresse je ne vois pas l'interet de l'appellation DMA. C est juste pour l'acces a des mémoires lentes...Il s'agit peut être de Delayed Memory Access...
.

fred72 a écrit:Pour récupérer les données de la RAM vidéo ça ne marche pas non plus car l'ULA adresse directement la mémoire sans passer par le bus du processeur. Il utilise directement les multiplexeurs des RAM.Donc pas d'activité sur le bus d'adresse concernant la RAM vidéo..

J ai l'impression que les deux ont accès, dans un temps d'horloge, le uP envoie le poids faible de l'adresse a la RAM et le poids fort passe a travers l ula pour ressortir sur l autre branche du MUX, l'ULA s'occupe de la séquence ligne/trame. Ensuite dans un autre cycle d'horloge c'est l 'ULA qui crée la valeur du poids faible et du poids fort pour rafraichir la ram et récuperer l'octet dans l'adresse choisie par l'ULA pour l'afficher a l'écran.

kenneth a écrit:Sur la feuille de donnees du uP il y a l info d'une DMA possible, mais apparemment en utilisant RDY pour stopper le 6502, mais si on a pas la haute impedance sur le bus d'adresse je ne vois pas l'interet de l'appellation DMA. C est juste pour l'acces a des mémoires lentes...Il s'agit peut être de Delayed Memory Access... .

Oui en effet dans la doc ils parlent de RDY surtout pour accéder à des mémoires lentes en précisant qu'il peut aussi servir pour le DMA mais sans préciser qu'il faut ajouter 2 ls244 et quelques babioles. Disons qu'ils ont menti par omission.

Le 65c02 (wdc) peut le faire directement car il a une entrée BE pour libérer le bus d'adresse.
A ce propos, cela explique pourquoi certains 65c02 ne fonctionnent pas dans l'oric (il faut mettre BE à 1).

kenneth a écrit: ai l'impression que les deux ont accès, dans un temps d'horloge, le uP envoie le poids faible de l'adresse a la RAM et le poids fort passe a travers l ula pour ressortir sur l autre branche du MUX, l'ULA s'occupe de la séquence ligne/trame. Ensuite dans un autre cycle d'horloge c'est l 'ULA qui crée la valeur du poids faible et du poids fort pour rafraichir la ram et récuperer l'octet dans l'adresse choisie par l'ULA pour l'afficher a l'écran.

Non je ne crois pas, Pourquoi l'ULA qui galope à 12MHz devrait compter sur un mulet qui se traine à 1MHz.
C'est facile à vérifier, si tu lances un pgm en langage machine qui interdit les interruptions et boucle sur lui même tu devrait perdre la vidéo. Comme ce n'est pas le cas, c'est que l'ULA se charge seul de la génération du signal vidéo.
L'ULA a accès à la totalité de la RAM, puisqu'il fournit les 8 lignes d'adresse des RAM dynamiques. La seule raison pour laquelle l'ULA ne reçoit que A8-A15 du 6502 c'est le nombre de pattes disponibles sur l'ULA.

J'ai trouvé sur le site de Mike Brown le chronogramme de l'ULA.

Pendant la période basse de phi2 (CLK OUT), on a la RAM isolée au niveau du bus d'adresses par rapport au 6502, l'ULA envoie a la RAM par deux fois une adresse sur 16bits (2x8 avec ligne et trame), j'imagine que la première lecture est le rafraichissement, et la 2e la scrutation de la zone vidéo HIRES TEXT et fontes pour la gestion d'affichage. A ce moment là, le 6502 ne fait rien, (serait-ce une DMA déguisée?). Pendant la période haute de PHI2 on a un autre adressage (ligne, trame), mais avec MUX activé, donc l'ULA "passe la main" au 6502 pour choisir l'adresse à consulter, ou à écrire.
Pour les 8 lignes d'adresse manquantes, j imagine que l'ULA devient "transparent" et renvoie sur l'autre entrée du multiplexeur les 8 bits d'adresse manquants. Donc en fait, au début on a une sorte de DMA en lecture seulement et en interne seulement. Puis après, un adressage du 6502 par MUX et ULA interposés.
Donc, si on veut intervenir de l'extérieur, on ne peut pas piloter le bus d'adresse (le cpu ferait la tronche) et mème si on envoie une impulsion judicieuse sur MAP qui isolerait totalement le bus de données de la RAM et  le bus d'adresse de RAM (ligne, trame) la mémoire est inaccessible de l'extérieur.
Il faudrait une ULA modifiée, genre "signal long sur MAP, on met le compteur d'adresse de l'ULA a #400" puis "impulsion calibrée sur MAP pour incrémenter le compteur d'adresses, on envoie les donnees sur D0-D7 pendant la période ou le port de donnees du CPU est en mode lecture pour éviter les conflits, et l'ULA imposerait le mode écriture à la RAM même si le CPU ne l'indique pas.

PS
D'apres Mike Brown, le rafraichissement se ferait en même temps que la scrutation de la RAM pour la vidéo. Donc la deuxième scrutation reste mystérieuse...

Oui c'est tout à fait ça. Impossible d'acccéder à la RAM en écriture via le bus d'extension et lecture uniquement de ce qui passe par le CPU.
A la place de DMA interne déguisée, je dirais plutôt que l'ULA gère sa mémoire de 64K qu'il partage de temps en temps avec le 6502. En gros, dans le royaume ORIC, l'ULA est le roi et le 6502 le valet.  

Pour le rafraîchissement, c'est une pratique courante puisque la RAM doit être lue en permanence cela assure son rafraîchissement sans avoir à exécuter un cycle spécifique.

Sur CPC, c'est le même principe, pas de rafraîchissement spécifique de la RAM, mais la ram vidéo fait 16K et la répartition des lignes dans la mémoire n'est pas linéaire afin de balayer toute la RAM (enfin les 128 valeurs nécessaires au rafraîchissement)

Une ULA modifiée !!! C'est déjà la galère pour accèder à la ram overlay, alors un mode supplémentaire. la pauvre ula va exploser

Apparemment, la 1ère lecture permet de lire un offset d'affichage.

fred72 a écrit:Bonjour Laurent,

Le 6502 ne peut pas faire de DMA car il ne peut pas libérer son bus d'adresse. Il faut ajouter des buffers pour çà. Le 65C02 peut le faire (certains modèles) car il dispose d'une patte BE (qui permet associée à RDY de mettre le bus d'adresse en HI-Z).

Pour récupérer les données de la RAM vidéo ça ne marche pas non plus car l'ULA adresse directement la mémoire sans passer par le bus du processeur. Il utilise directement les multiplexeurs des RAM.Donc pas d'activité sur le bus d'adresse concernant la RAM vidéo.
Par contre, tu peux avoir accès aux données écrites par le 6502 lors de la modification de la RAM. Il faut donc avoir un buffer image de la RAM.

Voilà, bon courage...

Merci beaucoup Fred de venir apporter ton expertise sur le sujet, et désolé de ma réponse tardive j'ai eu une semaine chargée !

En fait, l'astuce proposée par Kennetth (et que tu suggères également) me va bien (juste "espionner" le bus d'adresses pour détecter les opérations d'écriture sur les adresses correspondant à la mémoire vidéo, ce qui me permettrait de "reconstruire" dans la RAM d'un Arduino ou d'un ESP le "framebuffer"  de l'Oric puis le convertir en signal VGA). Effectivement, le fait que l'ULA adresse la mémoire sans passer par le bus n'est pas gênant en soi pour cette application, puisque de toutes façons, à un moment donné l'écriture dans la mémoire vidéo par le 6502 passe forcément par le bus.

Les premières difficultés que je vois sont:
1) comment se synchroniser avec Phi2 pour lire le bus d'adresses et le bus de données au bon moment et  intervalles appropriés (j'ai vu que Kenneth avais posté des chronogrammes du site de Mike Brown, merci Kenneth   , mais je ne suis pas sûr de pouvoir les interpréter correctement. Je vois que dans l'état haut de Phi2 ("CLK OUT") on trouve les 2 phases d'écriture et de lecture sur le bus par le 6502, mais du coup je ne vois pas à quel moment lire le bus (il faudrait que ce soit juste pendant/après l'écriture).

Une fois ce "souci" réglé je pourrai déjà essayer un petit montage permettant de surveiller les adresses et les données écrites sur le bus et voir ainsi ce qui est écrit dans la "RAM vidéo" de l'Oric pour le copier.

2) Comment détecter le passage entre TEXT et HIRES. L'idée la plus simple que je vois est tout simplement, dans la surveillance du bus d'adresses, de regarder si je vois passer des adresses correspondant aux points d'entrée des routines TEXT et HIRES, ce qui m'indiquera quand de mon côté "switcher" l'affichage entre TEXT et HIRES (accessoirement, bien que non indispensable dans un premier temps, il faut bien sûr aussi détecter le passage en mode LORES0 ou LORES1, et gérer aussi le jeu de caractères alternatif...).

Mais bon, je n'en suis pas encore là, je serais déjà bien content d'arriver tout simplement à "espionner" le bus de l'Oric pour y détecter les écritures en RAM (et les appels en ROM donc..)

Après commenceront les vraies difficultés: générer un signal VGA (là pour le coup je compte "tricher" un peu et me faciliter la vie en m'inspirant de prototypes existants sur Arduino, ESP ou Teensy) et convertir un écran TEXT ou HIRES en VGA. Avec évidemment deux petites difficultés: convertir les caractères de l'écran TEXT en pixels à partir des jeux de caractères et en gérant aussi les attributs, et pour l'écran HIRES convertir la "pixel map" de l'Oric en "pixel map" VGA en gérant là aussi les attributs.

A ce stade-là, si jamais par miracle j'arrive à un truc qui marche, ce serait déjà fantastique car on aurait une sortie VGA pour l'Oric...

Après, j'aimerais bien pouvoir implémenter un mode graphique étendu (en HIRES et en TEXT) en gérant une "colormap" dans 8 Ko de RAM supplémentaires de l'Oric comme je l'ai expliqué, ce qui permettrait donc d'étendre les capacités graphiques sans altérer la compatibilité.

Et enfin, la cerise sur le gâteau serait de pouvoir combiner cette extension avec l'utilisation d'autres extensions, notamment un Microdisc ou un Cumulus... Je sais que la société TRAN avait commercialisé une carte Amplibus avec plusieurs connecteurs d'extension permettant de relier plusieurs extensions à l'Oric, j'aimerais savoir si ça marchait, et si c'est toujours envisageable de nos jours ? Car on voit beaucoup d'extensions arriver pour l'Oric (les cartes Twilighte et Sittler de Jede, et le lecteur SDCard de Kenneth entre autres...) et à un moment donné ce serait bien de pouvoir avoir 2 à 3 cartes d'extension connectées en même temps sur l'Oric, mais j'imagine que c'est chaud niveau timings / partage du bus et accessoirement conflits sur les plages d'E/S utilisées en page 3 (ça encore ça peut se régler assez facilement en se mettant d'accord sur les plages utilisées...).

L'écriture se fait lorsque phi2 est haut et devient effective au front descendant de phi2. Tout ceci fonctionne bien à condition d'utiliser un latch (type ls374) .

Le plus simple c'est d'utiliser les interruptions de l'arduino (s'il est assez rapide) puis de lire les 3 ports d'E/S raccordés aux bus d'adresses et de données (lecture directe des registres PIN). Regarde dans le mag 344, tu verras comment j'ai fait pour détecter l'impulsion STB.

Tu auras sûrement besoin d'un peu de logique entre R/W et phi2 pour arriver sur la patte d'interruption de l'arduino afin de ne l'activer que pour une écriture.

Maintenant à toi de jouer

Pour l'utilisation de plusieurs périphériques en même temps, ça dépend comment les cartes sont conçue. Par exemple pour le microdisc, les sorties de contrôle des I/O (MAP, ROMDIS, IO(CTRL)) sont de type collecteur ouvert permettant ainsi à d'autres périphériques de les utiliser. Mais bien entendu il reste le problème de la sortance de l'oric (c'est à dire le nb de portes que l'oric peut alimenter). En utilisant des composants de type HCMOS cela réduit un peu le soucis (entrance très faible vis à vis des LS).

Merci Fred pour ces infos ! Je savais que les composants 74HCT consommaient moins que les 74LS, dans mon cas je compte juste pour l'instant éventuellement utiliser si besoin des "level shifters" 74LVC244 ou 245, qui sont en CMOS donc j'imagine assimilables à des composants "HCT" ?
Etant une bille en électronique, j'avoue avoir du mal encore avec des notions comme "collecteur ouvert", est-ce que c'est le 3e état 'haute impédance" d'un composant "tristate" ?

Le collecteur ouvert est une sortie de porte logique dont le transistor interne a une patte 'dans le vide' ce qui a comme interet de ne pas "imposer" une sortie à un. Si on envoie un zero, on a zero volts en sortie, si on envoie un 1, on a une sortie dans un etat déterminé par l'entree qui sera connectée dessus, or une entree ttl dans le vide sera à un. C est pour ca que dans certains montages on voit deux sorties de portes logiques reliées ensemble sans risque de "forçage" pour faire une fonction AND, tant qu un des transistors de sortie a collecteur ouvert est activé, la sortie commune reste a zero.
Pour la haute impedance, la sortie "impose" autant un 1 qu un 0, sauf que la porte est equipee d' une entree speciale qui "coupe" la sortie de la porte et la rend inactive quelquesoit l'etat 0 ou 1 de sa sortie. La logique "trois état" désigne l'état haut, proche de 5v, l'état bas, proche de 0v, et l'état "roue libre" ou on impose aucun niveau de sortie.

fred72 a écrit:L'écriture se fait lorsque phi2 est haut et devient effective au front descendant de phi2. Tout ceci fonctionne bien à condition d'utiliser un latch (type ls374) .

Le plus simple c'est d'utiliser les interruptions de l'arduino (s'il est assez rapide) puis de lire les 3 ports d'E/S raccordés aux bus d'adresses et de données (lecture directe des registres PIN). Regarde dans le mag 344, tu verras comment j'ai fait pour détecter l'impulsion STB.

Tu auras sûrement besoin d'un peu de logique entre R/W et phi2 pour arriver sur la patte d'interruption de l'arduino afin de ne l'activer que pour une écriture.

Maintenant à toi de jouer

J'avais pas vu cette réponse Fred, super, merci beaucoup pour ces infos, je vais aller lire ton article dans le mag, et après comme tu dis, ce sera à moi de jouer !!  
(une fois que j'aurai reçu la nappe IDC 34 broches et le "breakout board" idoine que j'ai commandés sur eBay... Je vais d'abord essayer de me débrouiller pour prototyper avec un Arduino Mega 2560 car il est en logique TTL, et si j'arrive à qq chose mais que c'est pas assez rapide je passerai à l'Arduino Due que j'ai commandé aussi, ou alors au Teensy 3.x).

PS - Effectivement, j'y avais pas pensé mais le mieux est certainement ce que tu conseilles, d'utiliser la bonne configuration des signaux Phi2 et R/W pour déclencher une interruption, sur l'Arduino, ce qui se fait assez facilement via la fonction attachInterrupt()...)

fred72 a écrit:Regarde dans le mag 344, tu verras comment j'ai fait pour détecter l'impulsion STB.

Euh... en fait le mag n° 344 n'existe pas ?!
(Le dernier n° de 2018 (de novembre) est le 343, et le premier de 2019 porte le n° 345 ?!  )

En recherchant un peu dans ma collection de mags' sur mon disque dur, j'ai bien retrouvé un de tes articles sur ton contrôleur Microdisc (n° 324 d'avril 2017) mais je ne suis pas sûr que ce soit l'article auquel tu fais référence, car il n'y a aucune explication sur "STB", et pour moi "STB" fait référence au "Strobe" du port imprimante, et pas à un signal du bus, donc tu dois faire référence à un autre article ??

Pour le reste, en fait je n'ai pas trop compris:

fred72 a écrit:
Le plus simple c'est d'utiliser les interruptions de l'arduino (s'il est assez rapide) puis de lire les 3 ports d'E/S raccordés aux bus d'adresses et de données (lecture directe des registres PIN). Regarde dans le mag 344, tu verras comment j'ai fait pour détecter l'impulsion STB.

- De quels "ports d'E/S" et de quels "registres PIN" parles-tu ??

Merci Kenneth aussi pour la différence entre sortie à collecteur ouvert et logique 3 états, même si j'avoue que je n'ai pas encore tout à fait compris... Je vais potasser le sujet, car ce sont des notions qui reviennent hyper souvent, donc il faut que je maîtrise... J'avance petit à petit en électronique, j'étais content il y a 1 ou 2 ans lorsque j'ai tout à coup compris le principe (et l'utilité) des résistances de tirage, donc pour le reste je ne désespère pas d'y arriver un jour !!!

A ben oui, en effet, désolé, c'est le 343 (celui de décembre 2018). j'aurais mieux fait de préciser la date. Oui c'est bien Strobe dont il est question.

Sur arduino tu as des fonctions (digitalwrite, digitalread, pinmode) qui font du masquage et sont donc très lentes. Pour aller vite, il faut adresser directement les registres d'E/S de l'atmega pour lire les ports (registres PINx).

Par exemple si tu utilises le PortC (broches PC0 à PC7).
Après l'avoir définit en entrée ou en sortie (soit avec pinmode ou directement avec DDRC (registre de direction))
tu peux écrire sur le port en modifiant le registre PORTC. Par exemple PORTC=0x55
tu peux lire l'état des pattes du port en lisant le registre PINC. Par exemple a=PINC
Comme ça, tu fais une seule lecture/écriture (soit 1 seule instruction)

Super, merci Fred, j'avoue que j'ai complètement zappé cet article à l'époque, ce qui est étonnant car en général je "bookmarke" soigneusement ce genre d'articles hardware qui m'intéressent particulièrement !

A propos de cet article d'ailleurs, je vois que tu as monté le Nano sur une espèce de plaque d'essai (ou PCB que tu as fait graver ?), as-tu monté un connecteur IDC femelle  derrière, pourrais-tu à l'occasion poster qq photos supplémentaires ? J'ai bien envie d'essayer ce montage !

Merci également pour les infos sur les registres PIN, je n'avais pas compris de quoi tu parlais car bien qu'ayant déjà vu des programmes Arduino adresser directement les E/S de la bête, je ne me rappelais plus qu'il y avait des registres "PIN" et des registres "PORT", je n'ai jamais essayé ça moi-même

Et effectivement, s'il n'est pas nécessaire de recourir à ça pour des  comms série ou //, dans le cas qui m'intéresse j'imagine que je n'aurai pas le choix, voire même que ça ne suffira pas au niveau vitesse pour la partie génération VGA, mais bon je n'en suis pas encore là, bien que je pense tester les 2 parties séparément (lecture de la mémoire de l'Oric, et génération d'un signal vidéo à partir d'un "framebuffer" répliquant la mémoire "vidéo" de l'Oric)...

EDIT: j'avais pas bien regardé ta fonction "lecture_printer()" et j'avais pas tout à fait compris le principe au début... En fait, tu utilises les registres "PIN" pour lire (en 2 coups) les 8 pins de données du port // 6 pins sur PINC vu que 0x3F = b00111111, et les 2 autres bits sur PINB vu que 3 = b00000011, avec ensuite le décalage binaire pour que les 2 derniers bits lus servent de bits de poids le plus fort, 6 et 7) , et la donnée est ensuite écrite via  liaison série par l'Arduino... Donc est-ce que ça veut dire que lire les 8 pins avec digitalRead() puis convertir les valeurs lues en un seul octet  était trop lent pour la comm série à 19200 bauds ?

Oui j'ai gravé un petit PCB, ça fait plus propre
Il y a un petit connecteur 20 broches pour nappe soudé en bout de carte. Il faut juste forcer un peu pour le faire rentrer.



J'ai utilisé 2 ports car le nano ne dispose pas d'un port libre complet. les 2 lectures m'évitent de faire 8 lectures car digitalread est limité à 1 ligne (donc 1 bit). C'est plus simple à écrire et ça va beaucoup plus vite.
Il y a peut-être des fonctions arduino qui lisent le port complet, mais n'étant pas spécialiste arduino (je suis plutôt PIC) je préfère adresser directement les ports
une lecture via digitalread semble demander env 4µs. la lecture directe du port demande 0.13µs

la com série à 19200 bauds fait 0.5ms par caractère. Donc ça laisse un peu de temps.

Fred, il est vraiment nickel ton PCB, j'adore !!!

Je sais que malheureusement tu as indiqué dans un autre sujet que tu avais arrêté la fabrication de tes contrôleurs Microdisc, mais est-ce que tu accepterais de me vendre un exemplaire de ce PCB pour le port imprimante, avec le connecteur soudé ? Je suis vraiment très intéressé mais incapable de fabriquer ça moi-même, je suis trop nul encore en soudure...

PS - si ça t'embête, c'est pas grave hein, je me débrouillerai à l'ancienne avec un breadboard, j'ai aussi commandé une nappe IDC 20 connecteurs et le breakout board qui va bien lorsque j'ai fait mes emplettes pour le connecteur d'extension...

J'aurais dû te voir venir  

Bon je regarde demain ce que je peux faire...

fred72 a écrit:J'aurais dû te voir venir  

Héhé ! Mais c'est la rançon du succès et du talent ça Fred, forcément si tu crées de belles réalisations, ça intéresse du monde, comme Jede et Kenneth avec leurs cartes également !

Et de plus, je connais déjà la qualité de tes réalisations, puisque ça fait presque 3 ans je crois que j'utilise ton magnifique contrôleur Microdisc dont je suis super content, autant pour sa fiabilité que pour son design et sa compacité !!

Et c'est bien parce que je vois tant de superbes projets hardware dans notre communauté que j'ai envie de m'y mettre malgré mon niveau nul en électronique, je me dis qu'à force de persévérance et surtout grâce à votre aide bien sûr, je finirai peut-être par arriver à quelque chose !!!