Hallo Besucher, der Thread wurde 75k mal aufgerufen und enthält 551 Antworten

letzter Beitrag von root42 am

Blank Screen Marathon

    Blank Screen Marathon S22E12 - Noch ein 250407 Rev.B und keine Überraschung


    Dieses Board macht einen interessanten Eindruck, schon auf den ersten Blick gibt es viel zusehen.



    Handschriftliche Notizen weisen auf ein fehlendes Bild sowie zwei möglicher Weise defekte RAM-Bausteine U11 und U21 hin. Diverse ICs stecken in sauber eingelöteten Sockeln: Der CIA in U1, die drei ROMs, PLA und SID, U15, U26, die beiden 4066 in U16 und U28. An Stelle des Basic-ROMs findet sich ein EPROM, welches auf einem Turm von IC-Sockeln thront. Und dann sind da natürlich noch die allseits beliebten MT-RAM Bausteine.



    Der Schalter funktioniert einwandfrei, und bei der ersten Inbetriebnahme zeigt sich der erwartete Blank Screen mit einem Sync-Signal auf dem Monitor. Die gemessenen Werte sind eher unverdächtig:

    • 12,11V an VR1 und 5,02V an VR2
    • 4,85V DC und 9.86V AC am Userport


    Weil es schnell gemacht ist, entferne ich im nächsten Schritt alle gesockelten ICs, die für einen Dead-Test nicht gebraucht werden, um die Zahl der Verdächtigen möglichst weit zu reduzieren: Einen CIA, die drei ROMs, SID und PLA. Leztere wird natürlich durch ein bekannter Maßen funktionierendes Exemplar ersetzt.


    Der anschließende Dead-Test signalisiert durch 8 aufeinander folgende Blinksignale tatsächlich ein defektes RAM in U21. Da die RAM-Bausteine eh alle verdächtig sind, wird U21 ausgelötet, selbst durch einen einfachen RAM-Tester als fehlerhaft erkannt, und durch einen neuen IC ersetzt. Anschließend blinkt der Dead-Test 3x und weist auf U11, welcher sich auch als defekt entpuppt. Schließlich noch ein drittes Mal die gleiche Prozedur mit U9, und schon haben wir ein Bild! Der Dead-Test hat dann auch nichts weiter zu beanstanden.



    Im nächsten Schritt kommen dann die gezogenen ICs zurück auf das Board, und das Diagnose-Modul wird gestartet. Dieses beschwert sich zuerst noch über vermeintlich defekte CIAs, was sich jedoch durch gründliches säubern der Kontakte am User- und Tape-Port behben lässt. Danach erkennt dann auch das Diag-Modul keine weiteren Fehler!



    Das ging tatsächlich mal wieder schneller, als anfangs erwartet. Einige von Euch werden vermutlich einwenden, dass man auch die restlichen MT-RAM-Module prophylaktisch noch tauschen sollte. Mal schauen...

    Zitat von bigby

    Einige von Euch werden vermutlich einwenden, dass man auch die restlichen MT-RAM-Module prophylaktisch noch tauschen sollte.

    Auch wenn es da duraus andere Meinungen geht, mein "Arbeits-C64" ein 250425 hat auch

    komplett µT-RAMs, ich warte schon seit Jahren das die endlich mal kaputt gehen...


    Ist ein 84er Baujahr, soweit ich weiss... 38 Jahre Lebensdauer sind schonmal nicht schlecht!


    Mfg Jood

    8o Klar.


    Meine funktionieren ja auch noch. So schlecht können die nicht sein.:thumbup:


    kennt jemand den film "2022 die überleben wollen", als man den letzten Baum New Yorks vor der Außenwelt abgeschirmt hat? Das werde ich eines Tages sein. Der Hüter des letzten, funktionierenden, MT RAMs :thumbsup:

    Ja, ich habe auch in 2 Boardy noch diese µT Rams drinnen.

    Ich spreche jeden Tag mit denen und sage, dass sie durchhalten sollen :)


    Ich drohe auch mit Ersatz, den ich noch liegen habe.

    Ich sollte kucken, ob ich auch 16 Stück habe. Hmmm.... :)

    Zitat von fepo

    Ja, ich habe auch in 2 Boardy noch diese µT Rams drinnen.

    Ich spreche jeden Tag mit denen und sage, dass sie durchhalten sollen :)


    Ich drohe auch mit Ersatz, den ich noch liegen habe.

    Ich sollte kucken, ob ich auch 16 Stück habe. Hmmm.... :)

    Wenigstens einer, der die armen Jungs versteht.:thumbsup:


    <Fantasien>

    Irgendwann wird es auf Ebay heißen "C64 exklusiv mit 100% funkt. MT RAMs. Diese wurden bereits überall unberechtigt entsorgt und sind daher ultra rar. Alleine die RAMs erzielen unter Sammlern C65-Preise..."

    </Fantasien>


    :P

    Naja, das ist so eine Art erweiterte QA. Alle MT RAMs, die jetzt noch leben, werden vermutlich wirklich gute Qualität haben. Das sind sozusagen die Gold-Samples.

    Zitat von root42

    Naja, das ist so eine Art erweiterte QA. Alle MT RAMs, die jetzt noch leben, werden vermutlich wirklich gute Qualität haben. Das sind sozusagen die Gold-Samples.


    Nun, es gibt mehrere Ausfall-Mechanismen und je nach Historie können da auch ganz unterschiedliche überwiegen.


    Extrembeispiel:


    Ein C64, der seit damals im 24/7 Einsatz läuft


    (es gab mal ne Story über einen C64, der als Eigenbau-Diagnose-System in ner KFZ-Werkstatt angeblich über 25 Jahre mehr oder minder durchlief, mir persönlich sind C64 bekannt, die mehrere Jahre lang 24/7 in Schaufensterwerbungen (mit CRT-TV als Ausgabemedium!) und "embedded" als Teil einer Steuerung liefen, bei Letzteren wurde aber der VIC-II über SW aufs reine refresh der DRAMs reduziert (sprich der Schirm abgeschaltet...)


    wird andere Ausfallerscheinungen zeigen, als


    ein C64, der im Zustand "NOS", also immer noch in OVP und ohne wirkliche Betriebsstunden vor sich hin lagert, dabei vielleicht noch thermischem Stress und unterschiedlichen Luftfeuchten ausgesetzt ist, oder Temperaturen unterhalb 12°C, wo Zinnfraß auftritt.


    Die Rams scheinen -durch ungenügende Passivierung- eher durch Typ2 zu leiden, als denn durch Dauerbetrieb, es sei denn sie werden sehr warm dabei, d.h. hohe Umgebungstemperatur, kaum Luftaustausch etc., aber diese Ausfallmechanismen sind dann unvermeidbar, folgen physikalischen Gesetzen...



    Meine persönliche Erfahrung ist, dass die RAM-Bausteine als Erstes "spontan" sterben, wenn die Spannung vom Netzteil zu hoch oder auch nur stark wellig ist.

    Sie opfern sich also für den Rest, kommt einem das österlich bekannt vor?

    Blank Screen Marathon S22E13E14 - Zwei 250403: Das ist ja gar kein C64...


    Nach etwas längerer Wartezeit folgt nun eine Doppelfolge, in der zwei Assy 250403 ihren Auftritt haben. Hierbei handelt es sich, wie mancher wohl wissen wird, um Motherboards für den VC-20. Die Ursache für die lange Wartzeit waren allerdings nicht komplizierte oder schwer zu lokalisierende Schäden an der Hardware. Neben privaten und beruflichen Ursachen liegt der Grund vielmehr darin, dass dies die ersten VC-20 Boards sind, die ich repariert habe, was im Verlauf zu einigen Exkursen geführt hat. :-)


    Die Boards sind von der "neueren" Art, deren Stromanschluss kompatibel zu dem des C64 ist. Die erste Platine ist etwas schmutzig, macht aber auf den flüchtigen Blick einen gut erhaltenen Eindruck. Erfreulich viele Chips stecken in Sockeln. Das ist, soweit ich weiß, nicht ungewöhnlich beim VC-20, und es sollte die Fehlersuche erleichtern.



    Noch bevor ich jedoch in die Fehlersuche einsteigen kann, zwingt mich das Billig-TFT, das ich auf der Werkbank nutze, zu einem ersten Nebenprojekt. Schon als ich vor längerem meinen ersten (funktionierenden) VC-20 bekommen habe, musste ich feststellen, dass das TFT trotz SyncFix64 hier kein Bild zeigt. Das erschwert die Behebung eines Blank Screens natürlich ungemein... Also musste ich das TFT um einen Videoverstärker erweitern, den ich einige Zeit später in ein neues Gehäuse verfrachtet habe.


    Dann war es endlich an der Zeit, das Board anzuschließen. Es zeigte den erwarteten schwarzen Bildschirm, ließ aber ein Sync-Signal erkennen. Am Userport habe ich 4,66V DC und 10,64V AC gemessen, also etwas zu wenig auf der 5V-Schiene.


    Wie vom C64 gewohnt, habe ich mir als nächstes die Pins der CPU mit dem Oszi genauer angeschaut. Hier gab es (für mich) überraschend wenig zu sehen: Reset- und Takt-Signale sehen gut aus, aber auf Daten- und Adressbus tat sich überhaupt nichts. Also habe ich die CPU aus dem Sockel gezogen und in meinem funktionieren VC-20 getestet, wo sie problemlos funktionierte.


    Da ich nun schon dabei war, wollte ich mit dem Quer-Testen der gesockelten ICs weitermachen. Logischer nächster Kandidat wäre das Kernal-ROM direkt neben der CPU. Leider musste ich da zunächst feststellen, dass auch in meinem funktionierenden VC-20 bereits ein Ersatz steckt. Und dieser auch noch in einer handverdrahteten Adapter-Platine mit den eckigen, breiten Pin-Headern, die den Sockel auf dem Board bereits komplett ruiniert haben.



    Also musste ich zunächst dort Kernal-Sockel tauschen, um dann feststellen zu können, dass das ROM des aktuellen Kandidaten tatsächlich defekt ist. Und für die Gegenprobe musste ich erst noch eine neue Adapter-Platine mit schlanken Pins bauen. Das führte dann übrigens auch zu meinem zweiten Exkurs, aus dem der bereits vorgestellte KERNALquattro resultierte.


    Nachdem schließlich das defekte Kernal-ROM ersetzt war, zeigte der Patient aber bereits ein erstes Bild!



    Um das Board nun in gewohnter Weise weiter analysieren zu können, brauchte es jedoch weitere Werkzeuge. Platinen und Bauteile hatte ich rechtzeitig bestellt, und nach einiger Wartezeit konnte ich das fehlende Diagnose-Modul samt Test-Harness für den VC-20 zusammenbauen.



    Dieses lieferte dann bereits im ersten Testlauf die Erkenntnis: Abgesehen vom defekten Kernal-ROM scheint dem Board nichts weiter zu fehlen!



    Nach all der Vorbereitung also gleich weiter zum nächsten Kandidaten.



    Auch dieses Board optisch unauffällig, wieder mit vielen gesockelten ICs und wieder mit einem Blank Screen beim Einschalten.


    Dies ist nun das dritte VC-20 Board, das ich je in Händen hatte, meinen oben erwähnten, funktionierenden VC-20 mit gerechnet. Bei den ersten beiden war anscheinend jeweils das Kernal-ROM defekt. Daher entschied ich mich spontan, eine Abkürzung zu probieren, und habe gleich den Kernal testweise durch einen KERNALquattro ersetzt. Und was soll ich sagen? Auch dieses Board zeigt wieder ein Bild, und auch dieses Board zeigt beim Diagnose-Lauf keine weiteren Auffälligkeiten.



    Zugegeben, n=3 ist keine sehr aussagekräftige Stichprobe. Aber mein momentaner, subjektiver Eindruck: Was dem C64 seine PLA, ist dem VC-20 sein Kernal-ROM.

    Blank Screen Marathon S22E15 - Nun ein 310163 aus einem Plus/4


    Erneut ein Board, das mit allen vorangegangenen neben einer ordentlichen Schmutzschicht vor allem eines gemein hat: Es liefert kein Bild mehr.



    Dies Assy. 310163 stammt aus einem Commodore Plus/4 und zeigt ansonsten keine optischen Auffälligkeiten. Auch nicht unter dem als erstes entfernten Abschirmblech.



    Das erste Einschalten liefert den erwarteten schwarzen Bildschirm mit einem erkennbaren Sync-Signal, und an Userport sind 5,20V DC sowie 10,60V AC zu messen.


    Rasch wird mir bewusst, dass ich mich hier noch weniger auskenne als beim VC-20. Immerhin scheinen beim Plus/4 üblicher Weise die meisten großen Chips gesockelt zu sein und ich habe ein funktionierendes Gerät zur Hand. Also liegt es nahe, die ICs aus dem defekten Board so zu testen. Dem Bauchgefühl nach beginne ich mit dem Kernal ROM aus U24 - das ist in Ordnung.


    Als zweites folgt die 8501 CPU, die sich dann auch gleich als defekt erweist! Leider muss ich feststellen, dass auch die beiden Reserve-CPUs, die ich zur Hand habe, nicht funktionsfähig sind. Also kommt zunächst eine bekanntermaßen funktionierende CPU aus einem anderen Board leihweise zum Einsatz. Am Fehlerbild ändert sich jedoch zunächst leider nichts: noch immer ein schwarzer Bildschirm.


    Als nächstes also den Blechkäfig geöffnet, den TED Chip inspiziert, gezogen und auf einem anderen Board getestet: Dort liefert dieser ein Bild!



    Der TED kommt also zurück auf das Board, und ich untersuche die wichtigen Signale an seinen Pins mit dem Oszi. Viele wirken unauffällig, CAS, CS0 und RW jedoch zeigen keine relevante Aktivität, die drei Signal sind dauerhaft high. CAS und RW gehen vom TED direkt zu den RAM-Bausteinen; wenn der TED funktioniert, müsste dort eigentlich der nächste Defekt liegen. Um nicht gleich alle RAM-Bausteine auszulöten, schaue ich mir zunächst noch den Datenbus an, um hoffentlich eine Vorauswahl zu treffen zu können. Und tatsächlich sehen D0 und D1 an U11 bzw. U12 nicht sauber aus:



    Also habe ich die beiden ICs ausgelötet und mit Sockeln versehen. Letztendlich hat hat es dann genügt, U11 zu tauschen, und ich wurde mit einem Basic-Screen belohnt!



    Anschließend ging dann einige Zeit ins Land, bis ich ein Diag264 Modul samt Test-Harness komplett beisammen hatte:



    Im Gegensatz zum Diagnose-Modul für den C64 finde ich es hier schwieriger, saubere Ergebnisse abzulesen, und ich sah mich gezwungen, diese gleich in Video-Form aufzunehmen.


    [Externes Medium: https://www.youtube.com/watch?v=x1fYBZHu6vw]



    Leider moniert das Diag264 konstant "TED LATCH BAD", zu Deutsch also ein defektes Auffangregister im TED, anscheinend ein häufig auftretender Teildefekt. :( Eine angeschlossene Tastatur funktioniert jedoch (leidlich), und wenn ich beim Testlauf den Joystick-Dongle weglasse, bestätigt auch das Modul, dass der Tastaturanschluss funktioniert:


    [Externes Medium: https://www.youtube.com/watch?v=zV1mzLSDKH8]



    Derzeit habe ich hier 3 Motherboards für den Plus/4 mit insgesamt 4 grundsätzlich funktionierenden TED ICs. Allen vieren bescheinigt das Diag264 jedoch ein defektes Latch. Entweder gibt es also noch ein Problem mit meinem Test-Harness (oder dem Diag264 selbst), oder die 4 ICs haben tatsächlich alle den selben Teildefekt. :gruebel


    Vielleicht hat von Euch ja noch jemand einen Hinweis dazu. Wie äußert sich dieser Defekt üblicher Weise im Betrieb? Wie teste ich das am besten unabhängig vom Diag264? Und hat hier schon jemand einen Plus/4 mit vollständigem Harness fehlerfrei durch getestet?


    Ich freue mich auf sachdienliche Hinweise!

    Das von Togzip beschriebene manuelle Testen wird hier auch angesprochen:

    Zitat von https://www.inchocks.co.uk/commodore/Diag264/

    To use this diagnostic tool in its most effective form, it requires replacing the kernel ROM in the machine and attaching loop-back connectors to the interface ports. [...]


    Although I describe how to build such connectors that I have successfully used myself, they are not required to test the keyboard and joysticks if you don’t need to run the tests unattended. Diag264 does provide features to manually test the keyboard and joysticks and to bypass them to allow the rest of the tests to run unattended. As keyboard and joystick problems are not usually intermittent in nature, this should not be an issue for most users.

    Etwas in Formulierungen versteckt findet sich tatsächlich folgender Ratschlag: Entweder die Tests für Keyboard und Joysticks überspringen lassen, falls man dort ein Harness dranhat, oder mit den Händen die Keyboard- und Joystick-Tests durchführen. Hier könnte man in der Doku auch nochmal drauf hinweisen an der Stelle, wo die Fehlermeldung diskutiert wird.


    EDIT: Es fehlt aber in meinem Zitat der Hinweis, dass ein Test mit Harness fehlschlagen muss. :/

    Togzip Die Fehlermeldung sieht leicht anders aus, aber das liegt möglicher Weise an der älteren Diag264 Version. Vermutlich ist das tatsächlich das selbe Problem.


    Zitat von emulaThor

    EDIT: Es fehlt aber in meinem Zitat der Hinweis, dass ein Test mit Harness fehlschlagen muss. :/

    Ich kann mir auch nicht vorstellen, dass das so sein soll. Den von Dir zitierten Text habe ich auch gelesen. Aber ich interpretiere das eher so, dass beides gehen sollte, bzw. beliebige Kombinationen: Wenn man die beiden erwähnten Dongles nicht hat, aber Keyboard und Joysticks, kann man die Tests manuell durchführen. Man kann sie auch komplett überspringen, wenn man Shift-Lock eingerastet lässt. Aber wenn man beide Dongles dran hat, sollten die Tests eigentlich automatisch ausgeführt werden und auch die Chance haben, fehlerfrei zu bestehen. :nixwiss:


    Oder ist das vielleicht etwas, was mit diesen einfachen Loopback-Dongles am TED grundsätzlich nicht gehen kann, weil die sich gegenseitig stören?


    Zitat von emulaThor

    Zum manuellen Durchtesten des gesamten Keyboards am Plus/4 und aller möglicher Joystickverrenkungen eignet sich ja Anykey:

    Etwas vergleichbares hat das Diag264 sogar eingebaut. Das bekommt man angeboten, wenn man keinen Keyboard-Dongle aufsteckt.


    EDIT: Habe ich hier mal mitgeschnitten.


    [Externes Medium: https://www.youtube.com/watch?v=eqUtAntIKLg]

    Zitat von emulaThor

    Um sich noch tiefer in dieses "Problemfeld" zu vergraben, empfehle ich diese Lektüre (ich habe es nur überflogen):

    https://plus4world.powweb.com/forum/42748

    Klingt so, als müsste ich tatsächlich mal einen echten Joystick anschließen. :rolleyes: Dafür muss ich allerdings erst wieder einen Adapter bauen. Und dafür muss ich erst mal herausfinden, warum es da aktive und passive Varianten zu geben scheint. Verdammte Kaninchenlöcher...