Le conflit sur le bus de données se produit quand le bit de protection écriture est positionné dans $A7CB et qu'on cherche à écrire. L'écriture est transformée en lecture par la logique TTL.
En pratique ça arrive rarement, et peut-être jamais :
- Quand l'extension RAM est utilisée par le nanoréseau, elle n'est pas protégée en écriture
- Quand on utilise mon programme de simulation de cartouche la protection écriture est active, mais à priori les programmes sur cartouche ne cherchent jamais à écrire à ces adresses puisqu'à l'origine c'est de la ROM dans les MEMO5.
- L'extension RAM n'est utilisée par aucun autre programme à ma connaissance.
Il reste que ce n'est pas satisfaisant intellectuellement. Même si ça n'a pas de conséquence il serait plus propre d'éviter ce conflit. J'ai écrit un programme pour le provoquer artificiellement. Le MO5 et l'extension mémoire ont résisté. Par contre ils doivent souffrir si les conflits sont répétés longtemps.
La simplification du schéma en enlevant la ligne à retard est très intéressante. Si ce retard n'est pas nécessaire je me demande pourquoi les concepteurs se sont compliqué la vie. Dans ma réalisation avec les deux circuits imprimés je vais aussi la supprimer et contrôler qu'il n'y a pas de différence.
[MO5] Extension 64K ram interne jamais vue
Modérateurs : Papy.G, fneck, Carl
Re: [MO5] Extension 64K ram interne jamais vue
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: [MO5] Extension 64K ram interne jamais vue
Selon Didier, ça serait utile pour de la RAM dynamique pour laisser un délai, dans le cas d'une RAM statique, c'est inutile.Daniel a écrit : ↑31 janv. 2021 18:03 La simplification du schéma en enlevant la ligne à retard est très intéressante. Si ce retard n'est pas nécessaire je me demande pourquoi les concepteurs se sont compliqué la vie. Dans ma réalisation avec les deux circuits imprimés je vais aussi la supprimer et contrôler qu'il n'y a pas de différence.
Re: [MO5] Extension 64K ram interne jamais vue
Tu sous entends quoi par souffrir, la génération presque certaine d'un crash ? Et simplement solvable par une exctintion machine puis ré-allumage ?
Mais niveau raisonnement pour comprendre, pourquoi ça fonctionnerait correctement puis alors que le test est identique et fonctionne, un phénomène de répétition donnerait un soucis ?
Re: [MO5] Extension 64K ram interne jamais vue
Deux sorties TTL sont connectées. L'une est à l'état haut et l'autre à l'état bas. Celle à l'état haut débite donc le courant maximum possible.
Les deux portes supportent ce courant un court instant. Je ne sais pas si elles le supportent longtemps.
Les deux portes supportent ce courant un court instant. Je ne sais pas si elles le supportent longtemps.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: [MO5] Extension 64K ram interne jamais vue
Waouh ok, je comprends pourquoi je ne pouvais pas raisonner là dessus, j'en restais au stade de raisonnement sur de la connaissance très générale (grossière) au niveau de la RAM (je veux dire même si on comprends pas toujours tout sur ce très vaste sujet, on arrive a suivre au moins le raisonnement). Mais là en fait, il s'agit d'un problème qui devient électronique.
En théorie, il y aurait un composant intermédiaire qui pourrait s"insérer dans le circuit et résoudrait ce problème ? De forte chances que même en ayant la solution, je ne la comprenne pas non plus, mais c'est intéressant au moins de savoir si c'est solvable même si personne ne le fait réellement en correction.
En théorie, il y aurait un composant intermédiaire qui pourrait s"insérer dans le circuit et résoudrait ce problème ? De forte chances que même en ayant la solution, je ne la comprenne pas non plus, mais c'est intéressant au moins de savoir si c'est solvable même si personne ne le fait réellement en correction.
Re: [MO5] Extension 64K ram interne jamais vue
Le problème c'est que sur le bus de données, il ne doit y avoir qu'un seul composant qui "envoie" des valeurs.
Hors dans cette configuration, la mémoire est placée en lecture. Elle envoie donc des valeurs sur le bus alors que le CPU fait de même. Donc les données entre en collision. Si les états logiques sont identiques => pas de soucis, s'ils sont différents ça fait un petit court-circuit.
D'après les documentations constructeurs cela ne devrait pas avoir de conséquence avec des CI TTL bipolaires car le courant de sortie à l'état haut est très faible (<1mA) par rapport au courant de sortie à l'état bas (10mA). Donc c'est l'état bas qui gagne.
En pratique ce n'est pas vrai, je viens de faire le test. Un 74LS00 peut sortir un courant de 60mA (en CC) à l'état haut tandis qu'il peut absorber un courant de 32mA à l'état bas. Donc 2 portes de ce type en conflit au niveau de la sortie donne un courant circulant dans les 2 portes de 30mA. ça va chauffer et pas sûr que le CI supporte longtemps ce traitement.
Pour le délai, cela permet aussi de compenser des transitions pas très raides au niveau des signaux de commande (comme l'horloge).
Hors dans cette configuration, la mémoire est placée en lecture. Elle envoie donc des valeurs sur le bus alors que le CPU fait de même. Donc les données entre en collision. Si les états logiques sont identiques => pas de soucis, s'ils sont différents ça fait un petit court-circuit.
D'après les documentations constructeurs cela ne devrait pas avoir de conséquence avec des CI TTL bipolaires car le courant de sortie à l'état haut est très faible (<1mA) par rapport au courant de sortie à l'état bas (10mA). Donc c'est l'état bas qui gagne.
En pratique ce n'est pas vrai, je viens de faire le test. Un 74LS00 peut sortir un courant de 60mA (en CC) à l'état haut tandis qu'il peut absorber un courant de 32mA à l'état bas. Donc 2 portes de ce type en conflit au niveau de la sortie donne un courant circulant dans les 2 portes de 30mA. ça va chauffer et pas sûr que le CI supporte longtemps ce traitement.
Pour le délai, cela permet aussi de compenser des transitions pas très raides au niveau des signaux de commande (comme l'horloge).