Man kann einfach einen SST39SF010A verwenden. Der funktioniert prima als Decoder [1]. [1] Beitrag "Re: Nibbler 4 Bit CPU"
Ralf Nelle schrieb: > Thomas Z. schrieb: >> Nochmal es gibt genügend Beispiele auch hier im Forum wo Eproms als >> simple Decoder missbraucht werden. > > Das wird hier leider mantraartig wiederholt, ohne dass jemand ein > konkretes Beispiel liefert. Und es ist noch nicht einmal grundsätzlich > falsch: Mit einen 27C16 funktioniert es, weil die Ausgänge direkt am > Output Buffer hängen. > > Wenn man sich jedoch einmal die Mühe macht und in die Datenblätter > guckt, stellt man beim Vergleich der Blockdiagramme fest, dass es anders > als beim 27C16 beim 27C64 und 28C64 zusätzlich ein Data Latch gibt, dass > zwischen den Ausgängen und dem Output Buffer liegt. Dieses Data Latch > wird mit der fallenden Flanke von /OE getriggert. > > Maik hat die ursprünglich verwendeten vier 27C16 durch ein 28C64 > ersetzt, deshalb funktioniert die Schaltung jetzt auch nicht mehr. Eine > einfache Lösung wäre, /CE auf Masse zu legen und /OE an den > Adressdekoder oder - die sauberste Lösung, /OE mit /RD der CPU zu > verbinden. Mantraartig wiederholst Du mit Verweis auf eine Annahme von Dir die sich auf Zeiten im Datenblatt stützt. Bitte: Probiere es aus und melde Dich dann wieder, erst dann! Pille
Patrick L. schrieb: > Ja und da gibt es auch noch Unterschiede je nach Typ und > Hersteller. > > Ralf Nelle schrieb: >> Maik hat die ursprünglich verwendeten vier 27C16 durch ein 28C64 >> ersetzt, deshalb funktioniert die Schaltung jetzt auch nicht mehr. Eine >> einfache Lösung wäre, /CE auf Masse zu legen und /OE an den >> Adressdekoder oder - die sauberste Lösung, /OE mit /RD der CPU zu >> verbinden. > > Halte ich auch für Sinnvoll, den. > Microchip hat wohl welche mit transparentem Latch, da funktioniert ein > Decoder, wobei der Adresslatch bei Intel nicht transparent ist, somit > würde ein Decoder mit dem EPROM, nicht funktionieren. > > Habe jetzt leider nicht die Möglichkeit/Zeit dies in den Datenblätter > genau nachzulesen, aber ich mag mich an genau so ein Problem erinnern > als ich damals Apple][ Clones gebaut hatte, das Problem mit dem > Adresslatch im 27C64 machte Probleme, weil der CE/PE fest auf masse war. > die einten EPROMS gingen, die anderen eben nicht. An Deinem Bild steht 87C64 dran, wir können nun auch noch diskutieren wie sich der 42C4711 verhält. Worum geht es hier eigentlich, um Recht zu behalten? Um die Rolle der Bedeutung oder was eigentlich? Pille
Das klappt doch alles nicht, weil es sich um ollen DDR Krempel handelt .... ;D
Ralf Nelle schrieb: > Wenn man sich jedoch einmal die Mühe macht und in die Datenblätter > guckt, stellt man beim Vergleich der Blockdiagramme fest, dass es anders > als beim 27C16 beim 27C64 und 28C64 zusätzlich ein Data Latch gibt, dass > zwischen den Ausgängen und dem Output Buffer liegt. das ist richtig > Dieses Data Latch wird mit der fallenden Flanke von /OE getriggert. das ist falsch. Das Latch ist pegelgesteuert, genau wie bei einem 74HC573. Es gibt ja beide Varianten bei Latches. Patrik bezeichnet das als transparentes Latch. Dass die Schaltung von Maik nicht funktioniert liegt an anderen Dingen sicher nicht an der Verwendung eines 28C64 anstelle der Original 27(c)16. Alle üblichen parallel Speicher ob SRAM ROM EPROM EEPROM funktionieren was den Zugriff angeht gleich. Es gibt aber spezielle Speicher bei denen das anders ist. vgl auch Atmel 28C64 Datasheet 4.1 Read The AT28C64B is accessed like a Static RAM. When CE and OE are low and WE is high, the data stored at the memory location determined by the address pins is asserted on the outputs. The outputs are put in the high-impedance state when either CE or OE is high. This dual line control gives designers flexibility in preventing bus contention in their systems.
Wolfgang R. schrieb: > Pegelgesteuert und nicht flankengesteuert. Aber vielleicht ist dein "mit > den falling edges" auch missverständlich ausgedrückt... Nochmal: Zitat aus dem Microchip-Datenblatt des 28C64A, Seite 6, Chap. 2.1 Read Mode: "Data is available at the output [..] after the falling edge of /OE" Mit "falling edge" wird eindeutig die Zustandsänderung(!) von /OE von high nach low beschrieben. /CE sollte für die device selection verwendet werden, aber es ist kein Muss, deshalb kann er auch fest auf low gesetzt werden. Wenn /OE konstant low ist, werden die input/output buffers nicht vom data latch übernommen, weshalb immer 0 am Datenbus ausgegeben wird. Das ist genau der Fehler, den Maik beschrieben hat.
Angehängte Dateien:
Pille schrieb: > An Deinem Bild steht 87C64 dran, wir können nun auch noch diskutieren > wie sich der 42C4711 verhält. Worum geht es hier eigentlich, um Recht zu > behalten? Um die Rolle der Bedeutung oder was eigentlich? Genau das Meinte ich je nach Typ. Der Standard Microchip 27C64 hat kein Latch als beispiel, und würde als Decoder funktionieren. Dass meinte ich damit. Der eine Spricht von gelatchten xxC64 und der andere von ungelatchten xxC64. Beide haben recht, nur redet der eine von Äpfeln und der andere von Birnen. Und jeder will recht haben, (Haben sie ja eigentlich auch) nur reden sie aneinander vorbei, und keiner will es einsehen. ;-) Und der 28C64 hat ein Latch siehe Bild! Aber nicht nur für die Daten sondern auch für die Adressen! Und deshalb ist das Schema Neu vom TO somit ein Problem.
:
Bearbeitet durch User
Angehängte Dateien:
-
Gigatron.PNG
110 KB
Ralf Nelle schrieb: > Das wird hier leider mantraartig wiederholt, ohne dass jemand ein > konkretes Beispiel liefert. Und es ist noch nicht einmal grundsätzlich > falsch: Mit einen 27C16 funktioniert es, weil die Ausgänge direkt am > Output Buffer hängen. Im Anhang ein aktuelles Beispiel, ein Auszug aus dem Schaltplan des Gigatron TTL-Computers https://gigatron.io/ . Gezeigt ist ein 27C1024, das ist ein 16 bit-EPROM. In der von mir aufgebauten Version arbeiten zwei 27C512 (weil die gerade da waren), und mit 28F512 und 29C512 läuft das Ding auch. Eine weitere Anwendung für EPROMs mit dauerhaft aktivem /CE und /OE sind die Zeichengeneratoren in Textterminals, oder auch die klassischen Lichteffektgeräte aus den Bastlerzeitschriften der '80er. An den Datenbits hängen über Triacs aucht Lampen, an den Adressbits sitzt ein Zähler, /OE und /CE sind low.
Patrick L. schrieb: [..] > Und der 28C64 hat ein Latch siehe Bild! > Aber nicht nur für die Daten sondern auch für die Adressen! > > Und deshalb ist das Schema Neu vom TO somit ein Problem. Der 74LS373 ist ein transparent Latch. Ziehe Dir mal dessen Datenblatt und schaue Dir die Logiktabelle im Vergleich zum 74LS374 an. Danach kannst Du hier wieder auftauchen und erklären wer hier ein Problem hat. Pille
Pille schrieb: > Der 74LS373 ist ein transparent Latch. Was hat das mit dem 28C64 zu tun? der TO hat ja im Schema (Siehe https://www.mikrocontroller.net/attachment/523318/z80neu.png des TO) erwähnte 28C64 verwendet. Da ist es kein Transparentes Latch sondern ein Flanken-getriggertes im 28C64. Somit muss am ein [¯\_] stattfinden damit die Adresse/Daten übernommen werden.
:
Bearbeitet durch User
Patrick L. schrieb: > Da ist es kein Transparentes Latch sondern ein Flanken-getriggertes im > 28C64. Auch der AT28C64 ist vollständig kombinatorisch, zumindest im Lesebetrieb. /CE auf Low, /OE auf Low, /WE auf High, und dann nach Herzenslust Adressen anlegen und Daten abgreifen. Ohne eine einzige Flanke, exakt so wie unter "Operating Modes" im Datenblatt beschrieben. "The AT28C64 is accessed like a Static RAM. When CE and OE are low and WE is high, the data stored at the memory location determined by the address pins is asserted on the outputs." Und das funktioniert seit mindestens 20 Jahren.
Patrick L. schrieb: > Pille schrieb: >> Der 74LS373 ist ein transparent Latch. > Was hat das mit dem 28C64 zu tun? > > der TO hat ja im Schema > (Siehe https://www.mikrocontroller.net/attachment/523318/z80neu.png des > TO) erwähnte 28C64 verwendet. > Da ist es kein Transparentes Latch sondern ein Flanken-getriggertes im > 28C64. > > Somit muss am ein [¯\_] stattfinden damit die Adresse/Daten übernommen > werden. Hier: http://web.mit.edu/6.115/www/document/at28c64.pdf Seite 2 und 3 lesen, mehr mußt Du nicht machen. Pille
Angehängte Dateien:
-
27C64.jpg
220 KB
/CE liegt dauernd auf GND /OE wird durch die Taste, die ich oben drücke, auf GND gezogen DIP-Schalter = Adresse. Adresse rein, Daten raus. Nix Flanke. Meine Fresse. Gruß Jobst
Angehängte Dateien:
-
Bild_2021-11-11_082229.png
13 KB -
Bild_2021-11-11_082253.png
26 KB
Jobst M. schrieb: > Adresse rein, Daten raus. Nix Flanke. Meine Fresse. Patrick L. schrieb: > Der Standard Microchip 27C64 hat kein Latch als beispiel, und würde > als Decoder funktionieren. Dass meinte ich damit. Apfel = xxC64 (ohne oder transparentem Adresslatch) Birnen= xxC64 (mit adresslatch) Kernobst= alle 2XC64 scheinen wohl nach durchlesen einiger Datenblätter ein Transparentes oder gar kein Latch zu haben womit "Asche über mein Haupt" :-D Womit all die hier Aufgeführten xxC64 Device als Decoder funktionieren sollten. Somit muss ich auch meine Behauptung: Patrick L. schrieb: > Somit muss am ein [¯\_] stattfinden damit die Adresse/Daten übernommen > werden. Revidieren und halt zugeben dass ich wie gestern geschrieben keine Zeit hatte die Datenblätter durchzulesen, und nicht nur die ob geposteten Diagramme anschauen. Ich weis nur dass es da mal ein Problem gab in den APPLE ][ Clons das die ohne Latch nicht funktionierten, bis nach einem Upgrad TTL Adresslatch Chip's in der Schaltung waren. Es scheint aber tatsächlich auch welche zu geben die ein Flankengetriggertes Adresslatch haben, ob das jetzt xxx32 oder xxxx64 oder xxx128 waren müsste ich die Unterlagen im Archiv durchwühlen. Und dazu habe ich weder Lust noch Zeit, und ist jetzt auch Irrelevant. Somit auf den TO Zurückzukommen, Deine schaltung müsste laut schema Funktionieren, also liegt wohl ein anderer Fehler vor. Sache ist ich habe was Behauptet ohne die Zeit zu nehmen die Datenblätter zu Lesen und dafür ein dickes Sorry. Und damit ist es für mich gegessen, Kernobst ist Lecker ... :-)
:
Bearbeitet durch User
Patrick L. schrieb: > Kernobst= alle 2XC64 scheinen wohl nach durchlesen einiger Datenblätter > ein Transparentes oder gar kein Latch zu haben womit "Asche über mein > Haupt" :-D So ist es. Es gibt Sondertypen wie 27C65 oder 87C64, aber von denen war hier nicht die Rede. > Womit all die hier Aufgeführten xxC64 Device als Decoder funktionieren > sollten. Sie sollten nicht, sie tun es. Beispiele wurden genügend genannt. Ich nutze EPROMs von ca 1984 durchgehend bis heute, und mir ist noch kein Exemplar begegnet mit dem das nicht funktioniert. > Ich weis nur dass es da mal ein Problem gab in den APPLE ][ Clons das > die ohne Latch nicht funktionierten, bis nach einem Upgrad TTL > Adresslatch Chip's in der Schaltung waren. Das muss aber ein ziemlicher Spezialfall gewesen sein. Sowohl der echte Apple II als auch die klassischen Taiwan-Clones GTAC-1 (48k) und GTAC-2 (64k mit Z80) laufen mit stinknormalen EPROMs. Ebenso die IBS Space, die Bell&Howell, die Laser und der Basis 108. > Somit auf den TO Zurückzukommen, Deine schaltung müsste laut schema > Funktionieren, also liegt wohl ein anderer Fehler vor. Diese Erkenntnis hatte man schon vor Monaten. Bis dieser Spezi den Thread wieder hochholte und sein Halbwissen in die Welt spülte...
Also Leute, streitet hier lieber nicht um des Kaisers Bart. Ich würde dem TO ein paar kleine Änderungen an seiner Schaltung empfehlen: 1. schließe den Programmspeicher so an, wie es sich die Erfinder des Z80 gedacht haben: /CE an /MEMRQ * Adressdekoder und /OE an /RD und ggf. /RFSH zusätzlich an den Adressdekoder. 2. entferne all den hintereinander geschalteten Krempel vor dem Programmspeicher und ersetze das Zeugs durch eine quasi einstufige Logik. Zuerst der Dekoder-IC und dann ein 4xNAND, was 4 Ausgänge wieder zusammenfaßt und dann noch ein Inverter zum Umdrehen des Ergebnisses. Ich halte das für zuviel und zu lahm. OK, bei einem maximalen Takt von 4 MHz sind diese Bedenken vielleicht weniger interessant, aber trotzdem. Ob du nun 2 Stück TTL-IC's dafür ausgibst oder 1..2 andere Stück TTL-IC's, ist eigentlich vom Aufwand her schnurz. Allenfalls wäre zu überlegen, all diese Logik durch ein kleines CPLD zu ersetzen. Aber das nur am Rande, schließlich weiß ich nicht, ob dir das evtl. zu hoch ist. W.S.
Ralf Nelle schrieb: > Kennen wir uns nicht zufällig von einer After Hour? ;-) > > Grüße Ralf exakt :D Ich hätte das hier alles lesen sollen, bevor ich die Platine für den 28C64 wieder zerlegt habe. Aber ich werde wohl auch wieder auf moderneren Speicher gehen, wenn alles funktioniert. Ich habe jetzt eine Platine mit 2716ern gelayoutet (nicht 27C16) genau wie im original Schaltplan und der Klon startet. Die 7-Segmentanzeigen laufen und die Programme lassen sich mit der Bedienung aufrufen und verändern. Leider habe ich (wieder) dem 4007 einen falschen Footprint zugewiesen, weshalb ich ihn nicht verbauen kann und somit den Programmspeicher nicht mit richtigem Inhalt füllen kann. Ich habe aber einfach mal zum testen ein Programm per Hand eingegeben. So viele Parameter sind das ja nicht. Momentan erreiche ich aber weder per MIDI noch per Klaviatur eine Ansteuerung der Analogplatine. Ich werde also demnächst nochmal eine neue Platine Layouten - diesmal mit 2716 und 28C64. Bisher konnte ich aber auch bei den 2716ern ein seltsames verhalten mit diesem Computer feststellen. Nicht alle Kombinationen funktionieren miteinander. In meinem "ersten" Tiracon mit originalem Computer sind aktuell 4x Intel M2732 verbaut. Diese Computerplatine ist allerdings mittlerweile defekt, da diese nach einer gewissen Zeit Betrieb immer die 5V Spannung eines neuen Netzteils hat einbrechen lassen und deshalb abgestürzt ist. Ich habe von einem netten Herren eine originale Ersatzplatine spendiert bekommen und auf dieser laufen nun ebenfalls die 4x Intel 2732er wieder. Zwischenzeitlich hatte ich aber weitere 2716er auftreiben können und beschrieben: 4x KS573RF2 (russische 2716er) 4x U2716C35 (weiß, DDR) und aus dem originalen Tiracon mit anfänglich fehlerhaften EPROMs: 2x U2716C35 (lila, DDR) Diese habe ich dann auf dem originalen Computer getestet: 4x KS573RF2 - läuft nicht 4x U2716C35 weiß - läuft nicht 2x KS573RF2, 2x U2716C35 (lila) - läuft...?! 2x U2716C35 weiß, 2x U2716C35 lila - läuft nicht 2x U2716C35 weiß, 2x KS573RF2 - läuft nicht (zwischendurch wurde überprüft, ob der Inhalt noch richtig ist) Ich hatte also unter 5 Kombinationen nur eine funktionierende. Ein Wunder, dass dann 4x Intel 2732 laufen. Das gleiche verhalten hat sich auch auf der geklonten Computerplatine gezeigt. Ich werde jetzt noch die restlichen Fehler auf der neuen Computerplatine suchen und eine weitere erstellen. Wenn ich diese fertig habe melde ich mich wieder. PS: Ich konnte den UA880D gegen einen Z80 tauschen. Der Code läuft darauf offensichtlich auch. Grüße!
:
Bearbeitet durch User
Du kannst bei den Eproms weiter nach einer Ursache forschen aber Du kannst es auch lassen. Deine Probleme haben nichts mit den Epromvarianten zu tun, oder nur sekundär. Meine Meinung nach hast Du das Problem das Speicher gleichzeitig aktiviert werden und Datenlinien gegeneinander "kämpfen". Gruß, Pille
Wenn Datalines gegeneinander "kämpfen" sieht man das mit einem Scope, weil die Pegel "Treppenförmig" werden. Nach meinen alten Datenbüchern kann man den Zugriff auf die Eproms beschleunigen wenn man nur /OE verwendet. Mit /CS aktiv läuft der interne Adressdecoder weiter was einige ns spart aber mehr Strom kostet.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.