Hallo, seit kurzem bringt mein EC184 immer wieder mal einen Paritätsfehler auf Adresse 28000. Nun ist aber mein Problem, dass ich aus dem Schaltplan und den sonstigen Unterlagen den defekten Chip nicht lokalisieren kann. Da fehlt mir einfach der passende Ansatz. Ich habe die Original-Diagnoseprogramme für DCP schon laufen lassen, aber auch das bringt mich nicht richtig weiter. Es kommt halt ein Fehler auf Adresse 28000 4 (siehe Bild). Aber welcher Chip ist es? Könnte mir bitte jemand auf die Sprünge helfen? Ich komme hier einfach nicht weiter und möchte nicht alle 40 auslöten müssen.
ohne aufschlüsselnde Bedienungsanleitung kann man das Tool den Entwicklern wohl um die Ohren hauen. Erst recht wenn die geschriebenen und rückgelesenen Datenworte nicht angezeigt werden. Denn jeder U2164D speichert nur ein Bit von 16 und für je 8Bit kommt noch ein Paritätsbit hinzu. Das macht 18 verdächtige ICs für ein und dieselbe Adresse.
Nehmen wir mal an es handelt sich um einen EC1834 (256kByte, bestückt mit U2164) und keinen EC1834.01 (640kByte, bestückt mit U61256) und nehmen wir ferner an, der wohl max. 5stellige Adressbereich ist dezimal angegeben und nehmen wir noch ferner an Modul 04 kennzeichnet den 5ten 64kByte-Block (ab 40000h). Dann liegt der defekte RAM auf der gesteckten Speichererweiterung und hat eigentlich die Adresse: 46D60h. Das beträfe dort dann Bank0 (Low-Byte) oder Bank1 (High-Byte).
Als Anfangstest würde ich die RAM-Erweiterung erstmal ziehen und das Diagnose-Tool erneut ausführen....
Weitere Vorgehensweise wäre dann z.B. mit dem DOS-Programm DEBUG Schreib-/Leseversuche auf die Adresse vorzunehmen.
Ich besitze keinen EC1834. Vielleicht kennt/hat hier jemand ein sinnvolleres Tool zum RAM-Test?
ich habe versucht, mich etwas näher an das Problem heranzuarbeiten. Auf der Erweiterungskarte 640k steckt der Fehler schon mal nicht. Den Test habe ich nur mit den 256MB on Board laufen lassen. Da das Diagnosetool diese mysteriöse „4“ mit ausgibt, habe ich im Schaltplan einfach mal die Datenleitung für das Bit 4 verfolgt, und bin beim IC D106 gelandet. Also ausgelötet und durch IC-Fassung+RAM ersetzt - der war es natürlich nicht. Stecke ich einen (bekannt defekten) IC dorthin erscheint der Paritätsfehler bei 3C000. Als nächstes seinen Nachbarn D121 gewechselt -> Paritätsfehler 20000. Ich kann hier irgendwie noch kein Schema erkennen. Vom Adressbereich 0-40000H ist es ja drin, aber halt nur wo? Gruß, Micha
--- -- 42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest" Aktuelle ProjektdokumentationenDieser Beitrag wurde am 10.01.2018 um 14:00 Uhr von PIC18F2550 editiert.
nach der zweiten IC-Fassung hatte ich dann erstmal keine Geduld mehr. Diese mehrlagige Platine geht echt schlecht beim (aus-)löten. Ich muss irgendwie die Lage der Speicherbänke bestimmen. Ich habe auch hier im Forum schon herumgesucht, aber bis jetzt nur die Lage der Bänke auf der Erweiterungskarte gefunden und die ist bei mir definitiv in Ordnung.
Vor dem Auslöten eventuel mit einem Oszi schauen ob da vernünftige signale anliegen. -- 42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest" Aktuelle Projektdokumentationen
Ich habe in den letzten Wochen einige alte Computer aufgearbeitet. Schneider Euro PC zwei RAM Bausteine in der Bank 0, IBM XT, acht Fehlerhafte RAM und in den letzten Tagen A5120 mit einem U256D Ausfall. Im Schneider und IBM die Ausfall RAM alle mit Infrarot Thermometer gefunden, der Temperaturunterschied der Fehlerhaften RAM Bausteine lag bei ca. 2°C von den anderen RAM IC, mit den Fingern nicht zu fühlen. Im A5120 konnte ich ohne BUS Verlängerung mit dem Thermometer nicht messen. Mit Widerstandsmessung von RAM zu RAM nach Abweichungen gesucht, drei Kandidaten gefunden aber nur einer war kaputt.
Einen ganzen RAM, Probeweise, huckepack von Baustein zu Baustein Stecken?, in einen IBM XT haben die auf jeden RAM noch einen aufgelötet. Kann also nicht Schaden.
Die Idee mit dem Thermometer ist genial! Auf die Idee wäre ich nie gekommen! -- Polyplay ESC2 Bauform4,K8924,EC1834,KC85/3-5,KC87,KC-Compact,Lada 21011,PC1715,PC1715W,A5105,CM1910,LC-80
werde wohl zuerst das mit dem Huckepack probieren. Dass IBM das serienmäßig gemacht hat, ist interessant...
Zumindest habe ich noch folgendes gefunden und weiß jetzt, dass mein Kandidat am RAS0 hängen muss. Das halbiert schon mal die Möglichkeiten.
Die Decodierung einer RAM-Spe 1 cheradr esse erfolgt mittels eines 1-aus- 8-Decoders [065], der in Abhängigkeit vom Pegel der Adressl ei tung Al 7 eine Speicherbank von 128 KByte auswählt.
AI? = 0 --> Adressberelch G...128K --> /RAS!
Al 7 = 1 --» Adressberelch 128K...256K --> /RASO
Ein 128-KByte-Bereich wiederum Ist ln zwei Bänke zu je 64 KByte unter- teilt, ln denen sich bei 16-81 t-Zugri ff jeweils L-Teil und H-Tell einer Adresse befinden, bei Byte-Zugriff in einer 64-K-Bank Bytes mit gerader Adresse und ln der anderen 64K-Bank Bytes mit ungerader Adres- se. Diese Zuordnung ist abhängig von den Signalen AO und /BHE und kann folgender Tabelle entnommen werden.
die Huckepack-RAMs im XT sind aber nicht identisch mit den darunterliegenden, die werden nicht gleichzeitig ausgewählt. Das Ganze dient der Verdopplung der Kapazität auf 128kbit. Außerdem macht(e) das nicht IBM, sondern die Chiphersteller, z.B. Siemens mit dem HYB42128 oder Samsung mit dem KM4128.
In einen IBM 5160 steckt das ganze Board mit 64K NEC übereinander gelötet (zwei IC), die 128K von Siemens habe ich auch da gehen aber nicht im 5160, wer das Zeug zusammengelötet hat weis ich nicht, gehen aber ohne Probleme, original IBM ist das aber sicher nicht.
Hallo, Huckepack hat leider auch nichts gebracht. Der Fehler ist ja leider nicht so, dass der RAM richtig defekt ist. Er zählt bis 256K problemlos durch, bootet dann auch meist problemlos. Der Fehler tritt halt in Form sporadischer Paritätsfehler auf. Richtig reproduzierbar ist es nur mit dem Diagnoseprogramm.
Obendrein scheint die Information dann doch nicht ganz stimmen. Laut meinem Stand der Forschung liegt der Adressbereich oberhalb 20000H bei den ICs D91-99 (L-Teil?) und D117-125 (H-Teil?). Gruß, Micha
der D108 war der Übeltäter. Hängt am Datenbit 2 (L-Teil der zweiten Bank). Wie das nun in Zusammenhang mit der Meldung des Diagnoseprogrammes steht, bleibt wohl ein Geheimnis der Entwickler. Ich hatte mich dann jedenfalls für die Brute Force Methode entschieden, nachdem der Fehler wenigstens Bankweise einzugrenzen war. Noch eine interessante Beobachtung: Das Hochzählen des Speichers beim Einschalten sagt nicht wirklich viel aus. Ich hatte versehentlich mal gar keinen Chip auf der Position von D105 stechen – gezählt hat er trotzdem bis 256k.
ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
