000
09.12.2012, 09:41 Uhr
thasti
|
Hallo zusammen!
Da ich nun endlich alle Dokumentation zum EC1834 habe (dank des Wikis von felge1966, dankeschön!), konnte ich mich wieder meinem gestorben geglaubten EC1834 widmen, und bin schon ein ganzes Stück weiter.
Nun zum aktuellen Problem:
Nach den ersten Tests (Clock-Frequenzen, Reset-Schaltung, Spannungskontrolle) habe ich mich versucht, in der Selbst-Test-Routine vorzuhangeln, um zu sehen, an welcher Stelle der EC1834 stecken bleibt.
Es ist auf jeden Fall VOR Punkt 1.5, ab diesem Schritt würde es für Fehlersignale immer eine Meldung via Bildschirm oder akkustisch geben. Vorher, wie bei mir, nur System Halts, die ich selbst auf dem Oszi diagnostizieren kann.
Leider habe ich als Logic-Analyzer nur ein 8-Kanal, 24MHz-Modell zur Verfügung, aber das reichte bisher für folgendes:
Schritt 1.2, ROM-Test: konnte ich nur indirekt nachvollziehen, es ist für eine ganze Zeit viel Verkehr auf dem Adress-Bus, aber in dieser Zeit ist noch kein Speicherrefresh vorhanden.
Schritt 1.3, Init und Start des DMA sowie Timer1 für Speicherrefresh:
Kann ich nachvollziehen, 416ms nach inaktiv-werden des Reset am 8086 sind die Timer initialisiert (Frequenzen stimmen mit Handbuch überein, Timer 1 etwa alle 15µS) und auf /RAS0 und /RAS1 sind ab diesem Zeitpunkt die Refresh-Zyklen aller 15µs zu sehen.
Das Problem wird also in Schritt 1.4 liegen, dieser besteht aus:
1. Speicherplätze definieren
2. Aufruf eines Unterprogrammes zum Testen von 32k-Worten RAM [im Fehlerfall System halt!]
3. INT-Controller re-initialisieren
4. Konfiguration feststellen (DIP-Schalter werden via PPI abgefragt) [im Fehlerfall wieder System Halt]
Dazu folgendes:
- Wie könnte ich die re-initialisierung der Interruptcontroller feststellen, nur um auszuschließen, dass er nicht wirklich beim einlesen der DIP-Schalter (sind korrekt eingestellt) stecken bleibt.
Und: Ich kann feststellen, dass das /PCK-Signal, was mit einem Low-Pegel einen Paritätsfehler im RAM anzeigt, quasi dauerhaft LOW ist. Ich nehme also an, dass ich defekten RAM habe.
Das Rücksetzen dieses Signals macht /ENBRAMPCK. (setzt das Flip-Flop zurück). Das passiert nur ein einziges mal, 20ms nach Einsetzen des RAM-Refreshs, dann wird PCK nach 10µs wieder low, also wird wieder ein Paritätsfehler erkannt.
Ein Bild dieses Verhaltens (also etwa 430ms nach dem Reset) hänge ich an.
Ist hier zu finden: http://i.imgur.com/k7nGX.png
Folgende 2 Fragen sind für mich offen geblieben:
1. Wann wird /ENBRAMPCK aktiv, um PCK zurückzusetzen? Am Anfang des RAM-Tests? Würde für mich Sinn ergeben, das so zu machen, ist aber aus der Doku nicht ersichtlich.
2. Wie könnte ich mit den gegebenen Mitteln herausfinden, welcher RAM defekt ist? Keine Adressleitung und kein Data-Out ist auf irgendeinem Level fest (weder stuck-at-low noch stuck-at-high), daher tippe ich auf einfach eine kaputte Zelle, kein kaputter Ausgangstreiber).
EDIT: Siehe unten
RAMs sind alle U2164D, ich will aber nicht alle "auf Verdacht" wechseln. Die Paritätserzeugung mit D114 und D115 sieht für mich gut aus, soweit ich das erkennen kann sind die ausgegebenen Paritäten in Ordnung.
Vielen Dank für eure Hilfe, ich hoffe wir können den EC wieder zum Leben erwecken.
Stefan
EDIT: Bei D103 und D118 ist mir doch etwas komisch aufgefallen, was für die ganze misere Verantwortlich sein könnte:
Es sieht zwar so aus, als wöllte ein RAM den Ausgang auf Low ziehen, doch der andere scheint es auf High-Pegel halten zu wollen, es liegen dort immer 5V an (auf dem Oszi ist nur zu erkennen, dass die Spannung um etwa 0,1V einbricht, sobald das andere RAM eine 0 ausgeben möchte). Eins der beiden ist also Defekt. Ich konnte schon durch mechanische Belastung von D103 ein Piepen herausbringen, sicherlich ist er dann mal kurz weitergelaufen, ich kann dann auch auf dem Oszi sehen, dass die Spannungen dann OK aussehen. Ich werde mir also 2164 besorgen und wechseln und danach berichten.
Dieser Beitrag wurde am 09.12.2012 um 11:24 Uhr von thasti editiert. |
mich von meiner alten Rechentechnik trennen,
