Hallo, Jim K. schrieb: > @Michael U. Das Auslesen hat ja mit dem externen Modul und einem 27256 > als Einstellung funktioniert. Ein Beitragsspender hat angeboten sich die > zwei U2364 anzusehen bzw. auszulesen. Die zwei Speicherbausteine sind > auf dem Postweg . Es ist aber mit an Sicherheit grenzender > Wahrscheinlichkeit davon auszugehen, dass beide Speicherbausteine > tatsächlich defekt sind. ok. Möglich ist es natürlich. Dann kommt aber die Frage auf, ob das Ursache oder Folge ist. Wenn es auf dem Datenbus Konflikte gab oder Adressleitungen von außen festgenagelt waren/sind kann es natürlich auch CPZ/PIOs/Rams mitgenommen haben. Wenn die oberen Adressen wirklich so seltsame H-Pegel haben, auch ohne Roms, würde ich jetzt wohl eine der Adressen dicht am Z80 auftrennen (man kann den Pin auch flach am Z80 trennen und später wieder verlöten) und direkt am Z80 Pin messen, on H dann auf sinnvolle Werte geht. Wenn nicht ist die CPU angeschossen, wenn ja dann darf man sich wohl durchhangeln... Gruß aus Berlin Michael
Axel R. schrieb: > Wie programmiert man denn die CS-Eingänge? Bei Masken-ROM steckt das Programm in den Alu-Leiterbahnen, welche die einzelnen Transistorzellen miteinander verdrahten. Da werden quasi die beiden obersten Lagen des Chips kundenspezifisch für Dich gefertigt. Die interne CS-Logik hat mehr Eingänge als von aussen erreichbar sind. Über die Verdrahtungsebene wählst Du aus welche auf die beiden Pins des Gehäuses gelegt werden und welche einen festen Pegel bekommen und somit daueraktiv sind.
https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=10199 Hier war es der RAM ( wurde schon drauf verlinkt? bin mir gerade nicht sicher...)
Jim K. schrieb: > Es ist aber mit an Sicherheit grenzender > Wahrscheinlichkeit davon auszugehen, dass beide Speicherbausteine > tatsächlich defekt sind. eher nicht! die wahrscheinlichkeit, dass zwei prom's in gleicher art und weise defekt sind, ist gering. hier ist das nichtverstehen des simplen cs-thema offensichtlich nur die ursache. es ist verstörend, wie hilflos/sinnlos hier die amateure rumtanzen ohne belastbare ergebnisse zu erreichen.
Axel R. schrieb: > https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=10199 > Hier war es der RAM ( wurde schon drauf verlinkt? bin mir gerade nicht > sicher...) Ja, dort war ich bereits. Dort hatte ich auch den Tipp mit den 27256er statt 2764er gelesen. RAM Bausteine und 2 PIOs habe ich inzwischen hier. Ich möchte aber vor dem bloßen Tauschen weiterer Komponenten, den zahlreichen Hinweisen von euch nachgehen und über mögliche Diagnosen den Fehler eingrenzen. Dauert halt ein bischen weil ich mit der Materie nicht so vertraut bin.
Hallo, Apollo M. schrieb: > die wahrscheinlichkeit, dass zwei prom's in gleicher art und weise > defekt sind, ist gering. Ich habe mit der Ausfallrate von U2364 keine Erfahrung, ich kann dem TO nur glauben, daß er mit einem Eprommer die Roms als 27256 ausgelesen hat und nur komplett 0xFF bekommen hat. Es werden so alle Möglichkeiten für CS1 und CS2 genutzt, hätte also was rauskommen müssen. > > hier ist das nichtverstehen des simplen cs-thema offensichtlich nur die > ursache. Ist hier auch egal, weil als 27256 mit A13/A14 alle möglichen CS-Kombinationen angesprochen werden. Gruß aus Berlin Michael
Jim K. schrieb: > michael_ schrieb: > ... >> Kann sein. >> Geht aber nur in die Dekodierung des RAM ein. >> Hast du den 8205 schon getauscht? > > Ja, den habe ich getauscht. Wenn die Spannung an A11 immer noch niedrig ist, bleibt ja nur noch ein RAM-Chip, der Pullup-R oder die CPU übrig. Die ROM sind ja raus.
Michael U. schrieb: >> die wahrscheinlichkeit, dass zwei prom's in gleicher art und weise >> defekt sind, ist gering. Da müsste jetzt ein gelernte Ossi was zu sagen. Wie bekannt ist, werden bei Masken-ROMs die Verdrahtungsebenen kundenspezifisch ausgeführt. D.h. die beiden obersten Lagen kommen in einem späteren Arbeitsgang auf den vorprozessierten Wafer. Danach kommt üblicherweise noch eine Oxidschicht zur Passivierung oben drauf. Damit sind Masken-ROMs relativ unsterblich, zumindest verglichen mit anderen Speichertechnologien. Aber: die Kunst der Passivierung hat nicht jeder Halbleiterhersteller gleichermaßen beherrscht, bzw die Notwendigkeit derselben nicht immer gesehen. Wenn das Alu unter dem Epoxygehäuse frei liegt, dann gammelt das wenn der Chip Feuchtigkeit zieht. Und das sind Serienfehler, die ganze Gerätefamilien lahmlegen können. Das kennt man z.B. von den allerersten Baujahren der 74C und 4000er Logik von National Semiconductor.
Jim K. schrieb: > Axel R. schrieb: >> https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=10199 >> Hier war es der RAM ( wurde schon drauf verlinkt? bin mir gerade nicht >> sicher...) > > Ja, dort war ich bereits. Dort hatte ich auch den Tipp mit den 27256er > statt 2764er gelesen. RAM Bausteine und 2 PIOs habe ich inzwischen hier. Vielleicht bestätigt sich mein am Anfang gemachter Verdacht zu den C-MOS RAM U224. Bei denen hatte ich damals schon Ausfälle, bei ROM gleich welcher Art nie. Lass erst mal die PIO. Die Anzeige ist unabhängig davon, die sollte zuerst gehen.
Angehängte Dateien:
-
U2364-brd.png
7,7 KB -
U2364-sch.png
20 KB
Die ROMs zeigen beide das gleiche Fehlerbild. Stromaufnahme im aktiven Zustand: Datenblatt < 140mA, IST: 220mA Stromaufnahme im inaktiven Zustand: Datenblatt < 40mA, IST: 220mA Es lassen sich keine Daten lesen, auch nicht sehr langsam oder mit leichten Veränderungen der Betriebsspannung. Die Ausgänge sind alle permanent auf 0. Falls jemand sich einen Adapter für 27C64 bauen möchte, hänge ich einen Vorschlag für eine Platine an, die universell für alle 4 Varianten einsetzbar ist. Falls die Eagle Dateien gewünscht werden (4.16), bitte PN.
Axel R. schrieb: > Das finde ich spannend! > Wie programmiert man denn die CS-Eingänge? Der Speicherbereich ist 8K x > 8. Gibt es da noch einen weiteren Speicherbreich für die Konfiguration > oder sind die Chips bereits ab Werk vorkonfiguriert und man hätte da > seine Wünsche vorab mit angeben müssen? /Ist ja jetzt eh' zu spät/ (Im > Datenblatt steht leider nix zur Vorgehensweise, nur dass die CS-Eingänge > programmierbar seien) Programmierbar ..ja. Allerdings für den Auftraggeber des ROM Bitmusters beim Hersteller, die Dinger sind maskenprogrammiert. Pille
Georg G. schrieb: > Die ROMs zeigen beide das gleiche Fehlerbild. > > Stromaufnahme im aktiven Zustand: Datenblatt < 140mA, IST: 220mA > Stromaufnahme im inaktiven Zustand: Datenblatt < 40mA, IST: 220mA Tja also muss er erst mal die Sache mit dem EPROMs lösen und die Sache muss passen... Die Codierung der ROMS könnte so sein 00b ROM1 01b ROM2 10b PM10 Modul 10b PM11 Modul ROM1 11b PM11 Modul ROM2 Ohne die CS Codierung um zu basteln wird es nicht gehen... Die Logik muss dafür sorgen das bei anderen CS Zuständen der EPROM nichts auf den Datenbus ausgibt. Das geht nur rein mit Adressverschiebung nicht.
:
Bearbeitet durch User
@Georg G. Vielen Dank für den Test.
Das oben genannte hast du verstanden? Deine Versuche den Inhalt in EPROM zu brennen wird aufgrund der CS Codierung scheitern. Du brauchst die ROMS oder musst die CS Codierung mit Logik so gestalten das die tristate Ausgänge hochohmig sind wenn dieser nicht eingesprochen wird. So wird Murks geladen... Der Code im Grundgerät schaut welche Module vorhanden sind in dem er die CS anspricht und schaut ob was auf dem Datenbus erscheint. Dann lädt der Z80 von dieser Adresse alles andere nach. Dort findet auch die Initialisierung der PIO statt.
Hallo, Marco H. schrieb: > Das oben genannte hast du verstanden? Deine Versuche den Inhalt in EPROM > zu brennen wird aufgrund der CS Codierung scheitern. Du brauchst die > ROMS oder musst die CS Codierung mit Logik so gestalten das die tristate > Ausgänge hochohmig sind wenn dieser nicht eingesprochen wird. Stimme ich nur teilweise zu. Ohne Erweiterungsmodul muß ein 27256 gehen daß Adresse 0x0000 beim Ansprechen von 0x4000 (Modul) reagiert, stört da nicht, weil die gelesenen 0x00 keine Modulkennung ergeben und dann im Oroginal-Rom weitergemacht wird. Die Spannungswerte sind laut TO auch ohne Roms fragwürdig. Den Fehler darf er also auch gut ohne Roms suchen gehen. Die Frage wäre jetzt auch noch, ob die Roms 0V am Ausgang anzeigen oder ob das Low niederohmig gegen GND ist. Dann kann es eben noch was mitgenommen haben. Gruß aus Berlin Michael
Michael U. schrieb: > ob die Roms 0V am Ausgang anzeigen oder ob das Low niederohmig > gegen GND ist. Ohne Betriebsspannung sind die Ausgänge hochohmig.
Schaut man sich die Logik an bemerkt man das Signal 33 u. 35 ROM(Selekt1) und ROM(Selekt2) ich habe nicht gefunden wo sie erzeugt werden ? Sie werden aber auf 5V gezogen. Was bedeutet das man das Modul steckt die ROMs Im Grundgerät blockiert werden können. Womit alles komplett aus dem Modulen kommt. Theorie -> wenn die Module ok sind wird das Gerät mit dem Externen PM11 Modul funktionieren.. Beim PM10 wird wohl ein Teil mit benutzt... Die Umschaltung der ROMs Erfolgt über A15(Signal 16) über die Logik D212 D216. Das laden von Adresse 0x4000 wird aber schwer werden.. Denn im Programm wird der CE nicht aktiv das es die Daten im zweiten ROM versucht zu lesen. Die CS Signale sind das eine CE das andere. Der erste ROM ist schlicht weg Inaktiv. Vielleicht wenn man zwei mit um 01b(CS) versetzen ROM1 und ROM2 Inhalt einbaut.. Muss man sich eben nochmal genau anschauen..
:
Bearbeitet durch User
Lies mal alles. Wurde schon geklärt, dass es in der Maskenprogrammierung der ROM erfolgt. Marco H. schrieb: > Das laden von Adresse 0x4000 wird aber schwer werden.. Denn im Programm > wird der CE nicht aktiv das es die Daten im zweiten ROM versucht zu > lesen. Wenn die Module ab 4000H liegen, brauchen die ROM im Grundgerät nicht deaktiviert werden. Der Bereich wird auch abgefragt vom Grundprogramm. 4544 2000 C3 4B 25 L0022: JP L0618 4545 2003 C3 18 20 L0092: JP L0619 4546 2006 C3 26 20 L0089: JP L0620 4547 2009 C3 E8 24 L0413: JP L0621 4548 200C C3 34 20 L0421: JP L0622 4549 200F C3 67 24 L0422: JP L0588 4550 2012 C3 CB 1E L0419: JP L0623 4551 2015 C3 C6 3E L0039: JP L0587 4552 2018 3A 00 40 L0619: LD A,(4000H) 4553 201B FE 50 CP 50H 4554 201D CA 01 40 JP Z,L0091 4555 2020 CD 76 26 CALL L0624 4556 2023 C3 04 00 JP L0625 4557 2026 3A 00 40 L0620: LD A,(4000H) 4558 2029 FE 53 CP 53H 4559 202B CA 01 40 JP Z,L0091 4560 202E CD 41 31 CALL L0626 4561 2031 C3 04 00 JP L0625
Hallo, ROM1 kann mit L an B2 (ROMSEL1) am Steckverbinder mit D215 abgeschaltet werden. An A3 (ROMSEL2) liegt das invertierte A15 (mit D212), das kann aber nur ein Ausgang zum Modul sein. Gruß aus Berlin Michael
Soll das Gerät denn originalgetreu restauriert werden, oder einfach nur wieder funktionieren? Falls letzteres würde ich die ROM-Decodierung massiv abspecken und alle Daten inklusive der externen ROM-Module in einen 27256 oder 27512 packen. So wie sich das oben liest liegt doch alles in einem linearen Adressraum, ohne Bankswitching?
Es lassen sich beide abschalten... Beide Leitungen (ROMSEL1) und (ROMSEL2) werden auf 5V gelegt. Signal 33 u. 35 Die Umschaltung erfolgt mit Signal 16 und D212
Hallo, Marco H. schrieb: > Es lassen sich beide abschalten... Beide Leitungen (ROMSEL1) und > (ROMSEL2) werden auf 5V gelegt. Signal 33 u. 35 Die Umschaltung erfolgt > mit Signal 16 und D212 Signal 16 ist A15. A15 auf H (Adresse ab 0x8000) wäre L am Ausgang von D212. Der ist push-pull, da H von außen raufzulegen wäre mehr als seltsam. Gruß aus Berlin Michael
Soul E. schrieb: > Soll das Gerät denn originalgetreu restauriert werden, oder einfach nur > wieder funktionieren? Falls letzteres würde ich die ROM-Decodierung > massiv abspecken und alle Daten inklusive der externen ROM-Module in > einen 27256 oder 27512 packen. So wie sich das oben liest liegt doch > alles in einem linearen Adressraum, ohne Bankswitching? @Soul E. Das Gerät soll nach Möglichkeit nur wieder funktionieren.
Marco H. schrieb: > Die Umschaltung erfolgt > mit Signal 16 und D212 Nein. Nur die Selektierung auf die unteren 32KB. Michael U. schrieb: > Signal 16 ist A15. A15 auf H (Adresse ab 0x8000) wäre L am Ausgang von > D212. > Der ist push-pull, da H von außen raufzulegen wäre mehr als seltsam. D212 gilt als die Negierung der A15 für beide ROM. Also L ergibt am DL010 jeweils H. Zweimal H am NAND ergibt L. Damit wird /CE für beide ROM freigegeben. Die restliche Selektierung der 8k Blöcke erfolgt über die programmierten CS1/2.
Vielleicht bin ich blind... Beachte das Gatter D216 am D224 ! D216 Pin4 ist auf 5 gezogen -> Signal 35 = ROMSEL1 Gatter D216 am D225 D216 Pin2 ist auf 5 gezogen -> Signal 33 = ROMSEL2 Beide Roms lassen sich offenbar über das Modul deaktivieren. @michael_(Gast) das ist wohl korrekt...
Hallo, Marco H. schrieb: > Vielleicht bin ich blind... Nein, ich war blind, Signal 33 und 34 verwechselt... Gruß aus Berlin Michael
Im Grunde ist ja die Codierung über die CS Eingänge ja nichts anderes wie ein ROM mit größeren Adressraum. Man hat sich das einfach so gedacht das diese als Array zusammenschalten lassen ohne externe Decodierlogik. Das Problem besteht hier nur das der Austausch EPROM den Datenbus nicht blockieren darf wenn dieser im nicht verwendeten Adressraum angesprochen wird. Man kann sich jetzt mit dem Code beschäftigen und diesen ewt. anpassen. Oder man versucht mit externe Logik es so zu lösen das sich die Angelegenheit wie im Original verhält. Das Gerät würde wenn es gut anstellt nicht groß verunstaltet und zum guten Stil legt man die Dokumention im Gerät bei. Zumal wir ja schon zwei Kunden haben für eine Lösung des ROM Problems...
:
Bearbeitet durch User
Marco H. schrieb: > Beide Roms lassen sich offenbar über das Modul deaktivieren. Ja, jedes ROM einzeln. Bingo! D216 würde sonst nicht gebraucht. Man könnte auch ROM1 und ROM2 komplett in ein ext. Modul packen. Zu beachten ist auch, dass die CS1 und CS2 echte Chipselekt-Eingänge sind. Nicht wie eine Adressumschaltung an einem 27256.
Marco H. schrieb: > Im Grunde ist ja die Codierung über die CS Eingänge ja nichts anderes > wie ein ROM mit größeren Adressraum. Ich war zu spät. Wie schon gesagt, ist es nicht so. Echte CS Eingänge, der Ausgangstreiber der ROM geht auf Tristate.
Soul E. schrieb: > So wie sich das oben liest liegt doch > alles in einem linearen Adressraum, ohne Bankswitching? Dann sieh dir das Schaltbild noch einmal an. Das ROM der Eröffnungsbibliothek und das erste ROM des Endspielmoduls liegen beide auf 0x4000. Das Gerät erkennt was es vor sich hat am Byte bei 0x4000 (ein "S" oder ein "A"). Die einfachste Lösung ist imho ein Stück Lochrasterplatte mit einem Adapter für einen 27c64 und einem 74hc138. Das ist an einem Abend gelötet. Schaltbild siehe oben...
Also ohne Externe Logik nicht lösbar.. Was war das für eine schwere Geburt..
:
Bearbeitet durch User
Georg G. schrieb: > Das Gerät erkennt was es vor sich hat am Byte bei 0x4000 > (ein "S" oder ein "A"). Oder 50H bzw. 53H :-) Georg G. schrieb: > Die einfachste Lösung ist imho ein Stück Lochrasterplatte mit einem > Adapter für einen 27c64 und einem 74hc138. Das ist an einem Abend > gelötet. Schaltbild siehe oben... Mehr wird auf den Erweiterungsmodulen nicht drauf sein. Gibt es da einen Plan? Ich würde da die D216 umbasteln. Idee ist da.
Ist das Dingen nach einem Monat noch nicht repariert! Ich meine nach der Zeit und unzähligen Kommentaren müsste doch endlich mal ein konkretes Ergebnis in Sicht sein.
https://www.mikrocontroller.net/attachment/496240/IMG_20210310_165054.jpg https://www.mikrocontroller.net/attachment/496241/IMG_20210310_165110.jpg Kann nicht viel oben sein.. K555A3 -> DL000D/S -> NAND-Gatter mit 2 Eingängen
Ja, aber genau die komischen 2364. Wo man erst mal nicht weiß, wie die CS programmiert sind.
10b PM10 Modul 10b PM11 Modul ROM1 11b PM11 Modul ROM2 Daher kommt vielleicht auch der Name... http://www.robotrontechnik.de/bilder/Upload_Forum/2g_3he.gif Da sieht man sogar die Adressen 0x4000 u. 0x6000 Naja da haben wir es, doch... Beim Laden von der Adresse 0x4000 wird mit Modul ein ROM blockiert. So erkennt das Programm was gesteckt wurde...
:
Bearbeitet durch User
Angehängte Dateien:
-
Fertig.jpg
240 KB -
Buzzer.png
15 KB -
Uebersicht-Amps.png
32 KB
Der CMD läuft wieder. Vielen Dank für Eure Hilfe. Nachdem ich beide PIOs getauscht habe und nochmal verschiedene ROM-Kombinationen mit der ROM-File aus dem Internet durchprobiert habe, hat es mit dem M27256 in der Kombination BM1 (0000-1FFF), leer (2000-3FFF), BM2 (4000-5FFF) funktioniert. An Pin 26,27,28 des M27256 hatte ich keinen Widerstand eingesetzt. Allerdings hat er Probleme gemacht wenn das PM10-Modul eingesteckt war. Er hat damit nicht gestartet. Ich habe zwischen Pin 26 und 28 einen 10kOhm Widerstand angelötet. Damit startet er mit und ohne PM10 Modul. Ob das ganze auch mit Spielfiguren tut kann ich noch nicht sagen. Die Figuren habe ich nicht hier. Das Bild vom Oszi zeigt den Buzzer beim Start. Ein kurzes Signal, dann verstummt er. Die Übersicht vom DMM zeigt 4 Einschaltvorgänge und die zugehörigen Ampere die das Gerät zieht. 1. Mit Brett, mit PM-10 Modul 2. Mit Brett, ohne PM-10 Modul 3. Ohne Brett, mit PM-10 Modul 4. Ohne Brett, ohne PM-10 Modul Mein anfängliches Bauchgefühl, dass das Gerät mit mehr als 1,1 Ampere deutlich zuviel verbraucht, hat sich bestätigt. Ich hatte vor den beiden PIOs alle Elkos, 3 von 5 Widerstands-Netzwerke und den RAM ausgetauscht. Das hat aber nicht geholfen. Ich kann jetzt nicht genau sagen, ob mit den neuen PIOs und den anderen alten Bauteilen das Gerät auch funktioniert hätte. Es funktioniert jetzt jedenfalls. Insgesamt frage ich mich nach wie vor, was diesen Fehler verursacht haben könnte. @Axel R. Den ausgebauten UCY 74S405 habe ich mit einem TL866II+ und dem Selbstbau-Arduino Projekt https://www.instructables.com/Arduino-IC-Tester/ getestet. Die Logikfunktion zeigt keine Fehler.
:
Bearbeitet durch User
Jim K. schrieb: > Der CMD läuft wieder. Prima! Defekte PIOs hat ich auch schon ein paar mal bei älteren Geräten. Das scheint wohl häufiger ein Problem zu sein...
Beide PIO? Die haben aber nichts mit dem Adressbereich zu tun. Jim K. schrieb: > 3 von 5 Widerstands-Netzwerke > und den RAM ausgetauscht. Widerstände kann man doch einfach messen. RAM? Vermutlich hat ein Datenkämpfen stattgefunden. Der Schwächere hat nachgegeben.
Hallo, erstmal schön daß er wieder startet. Ich hätte da wohl weniger getauscht, ich hätte wohl eine der Leitungen mit dem fragwürdigen Pegel an den ICs der Reihe nach aufgetrennt und den Übeltäter eingegrenzt. Ob Deine Geschichte mit dem Widerstand wegen des Zusatzmoduls da eine mögliche Lösunf ist, kann ich jetzt nicht einschätzen, da müßte ich mir die ganze Decodierung genauer anschauen. Irgendwem muß ja der Pegel an A13 nicht wirklich gefallen, wenn da ein zusätzlicher 10k PullUp die Verhältnisse ändern kann? Gruß aus Berlin Michael
Das Problem ist nicht gelöst... Spätestens wenn im weiteren Programm nachgeladen wird wird es Probleme geben. Mit dem PM11 Modul um so wahrscheinlicher. Zumal auch nicht sicher aus welchen ROM die Daten nun kamen. Die Lösung ist ja oben beschrieben worden!
:
Bearbeitet durch User
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.