000
29.05.2023, 13:54 Uhr
Stefan
|
Hallo in die Runde!
Ich habe einen KC 87.11 mit "wirre Zeichen"-Problematik, den ich gern reparieren würde.
Direkt vorab: Ich vermute einen Defekt in D47, also das höchstwertige Bit des DRAMs. Bevor ich da irgendwas bestelle und löte, wollte ich hier mal fragen, ob meine Vermutung plausibel ist. Habe noch fast keine Erfahrung mit Reparaturen.
Symptome:
- Der Bildschirm zeigt nach dem Starten (stabil) entweder mal komplett wirre Zeichen aus dem Zeichensatz oder mal senkrechte Streifen (ausgefüllter Block, Zeichen 0xff) mit Semikolon oder (seltener, vereinzelt) anderen Zeichen dazwischen. Manchmal kommt das System nach einer Weile von dem erst komplett wirren Zustand in den Zustand mit den Streifen. Ich habe mir noch kein RGB-Kabel gebastelt, kann daher nichts über Farben sagen.
- Die Graphic-LED leuchtet bei Reset ganz kurz und bleibt dann aus. Das Klicken ist zu hören.
- Die Graphic-LED Lässt sich mit "Graphic"-Taste nicht einschalten.
- Kein Piepen bei CTRL+G.
- An den Ausgangsleitungen der PIO (zur Tastaturmatrix) sind mit Oszi keine Signale sichtbar.
- Spannungen an den Klemmen für Stromversorgung: -5,07 V, -12,23 V, +12,32 V, +5,09 V
- sowjetische Bauteile: D4-D6, D38, D39, D40-D47, D74, D59, D60, D61, D69, D64, D65, D22, D34; Rest größtenteils DDR und einige westliche
- Mir fällt nichts auf, was auffällig warm werden würde.
- Mit einem Analogoszilloskop (C1-118A) habe ich die Pins der CPU durchgeguckt. Das sah für mich im Groben plausibel aus. /IOREQ bleibt H. An /WR ist zu sehen, dass vier Paare von Schreibzugriffen mit längerer Pause danach passieren - das System scheint halbwegs deterministisch in einer Schleife zu stecken.
Mit einem billigen 8-Kanal-Logikanalyzer (und Pulseview) habe ich den Datenbus (an den Wickelbrücken neben der CPU) aufgezeichnet. Anhand der Daten (verglichen mit Listing "os11.lst") ist gut zu erkennen, welcher Bereich des ROMs gerade abgearbeitet wird:
- 0xf2bf: CALL CHEC (= 0xf26c); dabei wird die Rücksprungadresse 0xf2 0xc2 auf den Stack geschrieben
- 0xf26c: PUSH HL schreibt 0xfd, 0x48
- 0xf26d: PUSH DE schreibt 0x81, 0x81
später dann bei 0xF28B:
- 0xf28b: POP DE liest 0x81, 0x81
- 0xf28c: POP HL liest 0xc8, 0xfd
- 0xf28d: RET liest 0xc2, 0xf2
Es fällt auf, dass bei POP HL 0xc8 statt 0x48 gelesen wird. Das Bit 7 kippt also auf 1. Für die anderen Bits wird der erwartete Wert ausgelesen. Daher gehe ich von einem Defekt in D47 aus.
Der Rücksprung "funktioniert", da in 0xf2c2 das entsprechende Bit mit 1 dort sowieso passt.
Meine Theorie, warum er überhaupt im Bereich 0xf2c2 landet: Bei der Initialisierung wird in 0xf696 zuerst MOD in 0xf231 aufgerufen und dort dann in 0xf233 CHR0. Sofern ich es richtig überblicke, wird von dort bei RET das erste Mal der Stack gelesen. Die korrekte Rücksprungadresse wäre eigentlich 0xf236. Aufgrund des Bitfehlers wird das zu 0xf2b6. Das wäre sozusagen in der "Mitte" des Befehls "LD HL,LOGDV+2": 0x26 0xfc (LD H, 0xfc). Dann wird ab LOCK der Rest ausgeführt und er kommt in den Schleifenzustand mit CALL CHEC.
Da auf dem Datenbus in dem Zustand sonst hauptsächlich ROM-Zugriffe passieren, wäre auch plausibel, dass es mit dem Analog-Oszi bei Datenleitung 7 nicht direkt auffällt.
Ansonsten war mir noch aufgefallen, dass bei den quadratischen Kerkos C6 und C20 Ecken abgebrochen sind.
Ist meine Erklärung und Schlussfolgerung plausibel? Wäre (Sockelung und) ein Austausch von D47 der erste sinnvolle Schritt?
Soll ich noch etwas anderes überprüfen?
Gibt es für KR565RU6 auch Äquivalenztypen (scheint nicht so?)? Hat wer in Halle welche?
Fällt euch auf dem Foto noch etwas auf, was ich tun sollte? - Foto: https://imgur.com/a/DFsdvsQ
Bin gespannt auf Antworten.
Viele Grüße
Stefan
Dieser Beitrag wurde am 29.05.2023 um 14:00 Uhr von Stefan editiert. |
