Reparaturbericht: VIC20CR mit Black Screen

Ein kleiner Reparaturbericht

Vor kurzem habe ich einen VIC20CR-PAL mit offenbar deutscher Vergangenheit erstanden. Da er ohne Tastatur kam, könnte das eine mit orangenen F-Tasten gewesen sein, die der Verkäufer behalten oder getrennt verkauft hat. Die (verlöteten) Chips sind Ende 1982 bis Mitte 1983 hergestellt und die QC-Marke ist bei 36/83 markiert. Seriennummer Gehäuse und Board passen nicht zusammen, wobei ich auch nicht weiß, ob das überhaupt so sein sollte. Der VIC ist zwar von Anfang 1984, müsste also einer der letzten gewesen sein, kann aber später ersetzt worden sein, oder, wie auch alle anderen gesockelten Chips, aus einem oder mehreren anderen Geräten stammen könnten. Besonders die beiden großen RAMs sind unterschiedliche Marken, was nach Austausch und evtl. Reparaturversuchen (erstmal alles tauschen, was in Fassungen steckt) aussieht.

Das Board war als defekt angeboten und somit hatte ich auch keine großen Erwartungen. Es sollte je nach Zustand im schlimmsten Fall als Spenderboard oder als Grundlage für einen Neuaufbau mit Teilen aus den beiden anderen defekten Boards in meinem Fundus dienen. Der Preis war auch ok (ich hatte sogar mehr geboten), also ohne übertriebene Vorsicht ran an die Sache!

Erste Schritte

Erstmal alle gesockelten Custom-Chips (CPU, VIAs und ROMs) raus und nach erster Prüfung auf offensichtliche Kurzschlüsse mit dem Elektrizitätswerk verbunden. Kein Qualm, kein Knistern, stabile 5V. Also CPU und ROMs wieder rein und neuer Versuch. Die Spannung bleibt stabil. Auch die für die Datasette, die über CR2 aus den 9V~ vom Netzteil gewonnen wird, an die ich jetzt erst gedacht hatte, die aber erstmal nicht so wichtig sind. Datasette hab ich jetzt gar nicht zur Hand. Aber der dicke C39 drängt sich ja förmlich auf, wie er da so auffällig unauffällig in der Ecke lungert.

Nächster Schritt: Monitor anschließen. Schalter umgelegt - gar nichts. Ach ja, meinem Netzteil hatte ich ja einen Schalter verpasst. Nicht das erste und ganz sicher nicht das letzte Mal, dass ich kurz erschrecke.

Alle Unterbrechungen beseitigt, meldet sich der Monitor mit einem klassischen Black Screen. Bei einem Dell-Monitor mit angeschlossener Soundbar schaltet sich diese ein (leiser Knack) und die LED leuchtet, sobald ein Bildsignal anliegt. Sehr praktisch, denn man muss nicht auf den Monitor sehen und kann stattdessem z.B. das Multimeter im Auge behalten.

Fehlersuche

Die Liste mit möglichen Ursachen und Verursachern (Ray Carlsen - VIC20 Diagnostics and Repair) ist lang. Dass der VIC überhaupt reagiert, ist aber schon mal ein gutes Zeichen. Den hätte ich vermutlich nicht ersetzen wollen. Der letzte Preis, den ich gesehen habe aus vertrauenswürdiger Quelle überstieg den Gesamtpreis für das Board mit Gehäuse. Es soll günstig bleiben.

Warum also nicht besser erstmal mit einem möglichst kleinen Teil anfangen?

Der 555 (UB6) erzeugt beim Einschalten das Reset-Signal, in dem er über einen Inverter den RESET-Pin der CPU bzw. die gesamte RESET-Leitung kurz auf LOW zieht, danach auf HIGH und dort über den Pullup R26 lässt. Also müssten an Pin 40 der CPU nach dem Einschalten 0V (lt. Datenblatt jedenfalls unter 0.4V) und kurz danach 5V (resp. mind. 2.4V) anliegen. Spannungsmesser Pin 40 geklemmt und eingeschaltet. 0 Volt und dabei blieb es. Hmm.

Also direkt am 555 messen. Vor dem Inverter an Pin 3 müsste es genau umgekehrt zu sehen sein: erst 5V, dann 0V. Siehe da, der Kleine macht, was er soll. Auch der 7406 (UB4) erfüllt seine Aufgabe. Das Signal wird korrekt bei jedem Einschalten erzeugt. Ganz in der Nähe ist die SERIAL-Buchse:

An deren Pin 6 liegt RESET an und dieser Pin ist bei der Printbuchse hinten der freiliegende oder vielmehr freistehende Kontakt, so dass man nichts umständlich in die Buchse fummeln muss und die Messspitze einfach "von hinten" dranhalten kann. Auch da kommt RESET an - eine evtl. angeschlossene Floppy würde sich also wie erwartet bemerkbar machen, wenn man z.B. gerade nichts zum Messen zur Hand hat.

Den USERPORT (PIN 3, dritter von rechts) und den EXPANSIONSPORT (Pin X, hintere/untere Reihe, der dritte von links) noch überprüft,

auch da kommt alles an. Dem Schaltplan (251027-01, Link, ist zwar für das NTSC-Modell, bis auf Takterzeugung und ein paar Teilenummern aber identisch) lässt sich entnehmen, dass das RESET-Signal auch noch an den VIAs anliegt (UAB1 und UAB3, jeweils Pin 34). Fast schon enttäuschend war auch da alles, wo es ein soll.

Warum also nicht an der CPU? Nochmal gemessen und nochmal, schon um Messfehler meinerseits auszuschließen, aber ohne Änderung. Dabei fiel mir auf, dass - egal wo sonst gemessen - der LOW-Pegel 0.1V, nur an der CPU 0.0xV, teilweise sogar 0.00xV betrug, was ja auch bedeuten könnte, dass ich gar nicht richtig am Pin dran bin. Oder auch am falschen. Alles schon passiert. Aber nachdem ich das ausgeschlossen habe, konnte es nurmehr eins bedeuten: Da ist eine Unterbrechung irgendwo!

Von der CPU lässt sich auf der Oberseite der Weg der Leiterbahn Richtung 555 ganz gut verfolgen. Erster Wechsel zur Unterseite ist die Durchkontaktierung zwischen U13 und UC4.

Da die blank ist, kann man dort erstmal ohne die Lötstoppmaske irgendwo abkratzen zu müssen, einfach messen. Auch an der Stelle liegt das RESET-Signal ordnungsgemäß an. Die Unterbrechung muss also zwischen diesem Punkt und Pin 40 der CPU sein. Ist ja nur ein relativ kurzes Stück. Bisher war ich zu faul, das Board aus dem Gehäuse zu nehmen, auch weil es im Gehäuseunterteil verschraubt einfach stabiler liegt. Aber vielleicht war es ja tatsächlich nur so ein simpler Fehler. Also lohnt sich der "Aufwand", die Schrauben zu lösen.

Nach dem Umdrehen war erkennbar, dass es bereits mal Kontakte mit Lötwerkzeug gegeben haben muss. Flussmittelreste um ein paar Fassungen, wo offenbar (nach)gelötet wurde, aber sonst nichts offensichtlich Vermurkstes. Pin 40 der CPU (Pfeil) sieht allerdings recht gut aus, jedenfalls keine kalte Lötstelle oder fehlendes Lötzinn. Da wirken Pins auf den Bildern (und auch in natura) wie gar nicht verlötet. Das ist aber nur das Licht.

Allerding besteht von diesem Pin kein Kontakt zum Rest der Schaltung. Von unten nach oben schon, also der Kontakt der Fassung an sich ist ganz, aber auch von unten gibt es keinen Kontakt zur Durchkontaktierung oder sonst irgendwo hin. Die Fassung löte ich nicht aus, nöö! Aber es kann eigentlich nur das Lötpad direkt unter der Fassung bzw. die Durchkontaktierung, in der der Pin steckt irgendwie getrennt worden sein.

Provisorische Lösung: Jumperkabel anklipsen. Direkt von der Quelle (FB17 bietet sich an, im Schaltplanfälschlich als FB7 bezeichnet) zum Reset-Pin der CPU.

Nun kommt RESET auch dort an. Überall sonst auch noch. Sehr schön. Aber: weiterhin Black Screen.

Teiletausch

Weil die CPU nicht eingelötet ist, war das Einfachste, sie in einem anderen, funktionierenden Board auf (grundsätzliche) Funktion zu überprüfen. Das ist zwar ein NTSC-Modell, die CPU ist aber gleich. Bild, Cursor, Farben, Tastatureingaben - alles da, alles funktioniert. Es kann natürlich trotzdem ein bizarrer Teildefekt vorliegen. Aber ohne Wärmebildkamera und 'awesome scope skillz' (und vor allem ohne Scope) mache ich mich gar nicht erst auf die Suche danach. Die Messbilder sieht sich eh niemand an.

Nicht lang grübeln, Einschaltmeldung ist (erstmal) das Ziel!

Wenn die Fassung der CPU evtl. nachgerüstet und beim Auslöten vielleicht das Pad beschädigt oder sogar komplett abgerissen wurde, ist das vielleicht auch bei den anderen Pins mit Lötspuren passiert? Am naheliegendsten (auch im wörtlichen Sinne) ist die KERNAL-Fassung. Ohne KERNAL kein Bild. Also alle 24 Pins "durchklingeln", ob alles noch so verbunden ist, wie es die Entwickler der Schaltung vorgesehen haben. Dabei am besten mit eingesetztem Chip dessen Beinchen als Messpunkt nutzen und dabei so wenig Druck wie möglich ausüben, um eventuelle Kontaktschwierigkeiten durch Oxidation der Fassungskontakte und/oder Haarrisse in Fassungsnähe gleich "mitzumessen". Vergoldete Messspitzen sind dafür nicht verkehrt.

Wo man anfängt, ist fast egal, es ist sowieso der letzte Pin, den man prüft, wenn überhaupt einer. Praktikabel erscheint natürlich mit der 1 anzufangen und eine Runde rumzugehen. Da ich aber den VIC20 überhaupt nicht (den C64 auch nicht auswendig) kenne, gehe ich nach Plan, in dem Fall nach Schaltplan vor.

KERNAL (UE12) beginnt links oben mit CA0 an Pin 8 und geht schön durcheinander weiter. Da ich aber die andere Seite, also die Stelle(n), bis wohin der jeweilige KERNAL-Pin verbunden sein sollte, auch bloß suchen muss, ist das halb so wild. CA0 bis CA15 sind die 16 Adressleitungen A0-A15, die von der CPU kommen (daher das C davor). Also Pin für Pin im "soft touch" die Verbindung zur CPU gemessen und weil es so schön war auch gleich zu allen anderen Chips, die mit am CAx-Bus hängen (UC5, UC6, UD8, UE8, UE10, UAB1, UAB2) und zum Expansionsport, und für den Datenbus CD0-CD7 entsprechend (zzgl. UF8) das gleiche Prozedere. Alles da, soweit, so gut.

Chip Select (/CS) hat zumindest elektrisch Verbindung zu den dazugehörigen Stellen, jedenfalls fällt nichts durch Unterbrechung auf. Da das BASIC-ROM direkt parallel an beiden Bussen hängt, kann man bei der Gelegenheit auch dort alles auf Durchgang messen, wobei dann einfach Pin 1 mit Pin 1, Pin 2 mit Pin 2 usw. (bis auf /CS an Pin 20) mit der benachbarten Fassung "klingeln" muss. Das geht schön schnell und ohne nochmal die anderen Stellen suchen zu müssen. Ich hab es später gemacht, sei hier aber für Nachahmer erwähnt. Ist ein Abwasch.

Masse ist auch vorhanden, bleibt nur noch Vcc an Pin 24 und wer ahnt es schon? Natürlich ist dort die Unterbrechung! Also tatsächlich egal, wie ich angefangen hätte, es war der letzte.

(wegen Beschränkung der Bilder weiter im nächsten Teil)

KERNAL bekommt also keinen Saft. Die Ursache ist vermutlich die gleiche, wie bei der CPU und genauso schnell behoben, wenn auch erstmal nur provisorisch.

Jumperkabel +5V (von irgendwo, hier von einem RAM) an Pin 24, einschalten und schon leuchtet der Bildschirm in den tollsten 80er-Jahre-Farben - natürlich NICHT!

Da ich das natürlich erwartet hatte und auch beim VIC20 ein defektes KERNAL ROM ein häufiger Grund ist, warum der Bildschirm dunkel bleibt, hatte ich schon den EPROP+ bereit gelegt (ein meiner besten Retro-Anschaffungen in jüngster Vergangenheit) und ein paar 2364-2764-Adapter vorbereitet. MS-DOS 7.1 (ja, tatsächlich!) gestartet, gleich alle drei ROMs gebrannt, aber nur KERNAL und BASIC eingesetzt (weil bei CHAR der Adapter wegen dem VIC-Kasten nicht wirklich reinpasst) und siehe da - ES LEBT!

Buntes Gewirr, aber immerhin ein Bild.

VC20 Diagnostics

Diagnose-Modul rausgekramt und rein und an. Ein richtiges Bild! Mit Buchstaben und Farben. Miese Qualität, aber das liegt am Kabel und Composite und überhaupt. Aber der VIC funktioniert, die CPU, scheiß doch auf die ROMs und ...

... hä? Der erste ROMCHECK FF ist das CHAR ROM und offenbar ok. Das ist gut, weil ja Adapter und so. Aber warum der zweite ROMCHECK BAD?

Zur Erläuterung: Das zweite ROM, was getestet wird, ist das KERNAL ROM. Die Überprüfung erfolgt per Checksumme. CHAR muss FF ergeben, KERNAL E0 und BASIC sollte C0 sein. Nach welchem Algorhitmus ist erstmal egal, es werden wohl verschiedene (alle?) Adressen ausgelesen, irgendwie zusammen gezählt und ergeben eben die Prüfsummen. So ist sichergestellt, dass der Inhalt der ROMs in Ordnung ist, ohne den Inhalt tatsächlich auf Funktion prüfen zu müssen.

Dass nun ausgerechnet KERNAL fehlerhaft sein soll, ist verwunderlich, schließlich steckt ja ein frisch gebranntes EPROM in der Fassung und das Binary ist aus dem INTERNET!!1!elf! Voller Selbstzweifel nochmal das Original ROM rein, angeschaltet - Black Screen. EPROM wieder rein, Modul startet, alles schön bis zur gleichen Stelle - ROMCHECK BAD.

Ok, vielleicht liegt es ja nicht am EPROM oder Adapter. Ach was, ganz bestimmt liegt es nicht daran! Sonst würde das Programm vermutlich gar nicht erst laufen.

Komm, noch einen Versuch. Aus und An - selbes Ergebnis. Funktioniert der Rest-Knopf am Modul überhaupt? Ja. Auch zweimal? Ja. Nanu? Jetzt steht da KEYBOARD BAD! (leider kein Bild gemacht) Was war passiert?

Da steht doch tatsächlich Checksumme vom KERNAL E0, na bitte! BASIC OK und nächster Test sind die VIAs, wo auch die Tastatur dranhängt. Die VIAs waren aber noch gar nicht wieder drin und ich hatte den Test Harness auch noch nicht angeschlossen, weswegen der Test natürlich nicht weiter lief. Dummerweise bricht die Software nämlich beim ersten gefundenen Fehler ab. Das schreit geradezu nach einem Custom-Patch! (zwinkerzwinker kinzi )

Also alle Fassungen und alle Ports bestückt, angeschaltet - ROMCHECK BAD *Fuuuaaaaarrrrgggg!*

(Kurze Unterbrechung. Zen-Garten umgraben.)

Mir schwante es unterbewusst schon, ich meine (jetzt hinterher) auch, das irgendwann mal irgendwo gelesen zu haben, jedenfalls stellte ich nach erneutem mehrfachem Ein- und Ausschalten bzw. resetten fest, dass sich die Checksumme jedes Mal ändert. Das war mit Sicherheit auch vorher schon so, ich hatte nur nicht darauf geachtet. Und wohl nur durch reinen Zufall ergab sich das eine Mal die benötigte "E0" und der Test lief daraufhin weiter, natürlich nur bis zum nächsten Fehler.

Es war schon spät und der Lötkolben sollte an dem Abend definitiv nicht nochmal heiß werden. Was tun? Rein überschlagsmäßig grob geschätzt gibt es nur 256 mögliche Checksummen. Eine davon ist es. Wie oft kann also die "falsche" kommen?

Ich weiß nicht, ob ich mehr oder weniger als 256 mal den Test gestartet habe, es kam mir sehr viel öfter vor, es war aber sehr wahrscheinlich viel weniger. Ich hatte zwischendurch auch weitere Pausen gemacht.

Irgendwann hatte ich jedenfalls wieder Glück und der Test lief komplett und ohne Fehler(!) durch. Das heißt, CHAR und BASIC (ich hatte irgendwann das Original wieder eingesetzt, nachdem ich die Fassung durchgeklingelt hatte, s.o.) sind i.O., die VIAs testen zumindest o.k. (der Test ist nicht ganz so gründlich wie beim C64-Diag), die Buffer für SERIAL scheinen i.O. zu sein und da das RAM schon vor den ROMs komplett getestet wird (war mir anfangs gar nicht so bewusst), ist auch dort alles gut, also die beiden gemischten Großen (U14, U15) und die verlöteten 2114er. Ob auch Ton kommt, ist mir an der Stelle schon fast egal. Ich gehe erstmal davon aus, da der VIC auch sonst zu funktionieren scheint. Das Kabel hat nämlich nur Video und ich bin zu faul, ein anderes rauszusuchen oder gar zu löten. Da kauf ich mir eher ein Oszi und überprüfe, ob man die Testöne "sehen" kann.

Der Test läuft eine Runde rum und bleibt - wenig überraschend - wieder beim ROMCHECK für's KERNAL stehen.

Soweit aber erstmal ein Erfolgserlebnis!

Ursachenforschung

Da der Lötkolben immer noch parkt, erstmal wieder den Schaltplan zur Hand genommen. Zwischendurch, beim Reset-Marathon ist der Test auch mal beim CHAR ROM mit BAD stehen geblieben. Einmal nur, was vielleicht Zufall und kein Zeichen für einen Defekt war, aber vielleicht spielt das ja noch ein Rolle. Der Test-Harness kann jedenfalls erstmal wieder ab.

Was passiert eigentlich inzwischen ohne Modul? Ausprobieren.

Es gab auch noch andere Fehlermeldungen oder nur Ready mit Cursor (wie nach STOP + RESTORE) und wie man sieht hin und wieder auch die normale Einschaltmeldung. Aber nichts davon war reproduzierbar. Bei jedem Bootvorgang gab es ein mehr oder weniger anderes Bild. Ist logisch, wenn ein ROM nicht oder nicht richtig angesprochen wird. Was diese Bilder nun tatsächlich im Einzelnen bedeuten, bleibt erstmal außen vor.

Manchmal friert beim RESET der Bildschirm ein und an einigen Stellen rollen dann ein paar Zeichen durch bis man nochmal (richtig) resettet. Aber das ist beim C64 auch ab und an der Fall. Da fehlt mir natürlich jegliche Erfahrung mit funktionierenden und erst recht mit defekten VIC20. Und bevor ich die Diag-Software disassembliert und "reverse engineered" habe, um zu sehen, welche KERNAL-Routinen wie genutzt werden und welche nicht, habe ich alle TTLs und RAMs aus- und wieder eingelötet. Denn vielmehr kommt ja als Fehlerquelle eigentlich nicht mehr in Frage. (Oder?)

Der Schaltplan zeigt, das KERNAL im Wesentlichen mit 8 Bausteinen kommuniziert. Zum Einen natürlich mit der CPU. Die Verbindungen und die CPU selbst nehmen wir mal als i.O. an (behalten aber bizarre Teildefekte im Hinterkopf!). Chip Select kommt als /BLK7 von UC5. Die Busse (CAx und CDx) hängen zudem noch an UD8, UE8 und UF8. Diese drei Brüder sind schnell ausgetauscht, da sie dankenswerterweise auch mit Fassungen versehen sind. Zudem sind es MOS 62245. Man erzählt sich, die hätten gern mal Einen weg. Ein Tausch gegen neue LS245 bringt aber keine Änderungen und geklingelt hatte ich sie schon zuvor bei der KERNAL-Analyse. Die VIAs sind auch beteiligt, bleiben aber ebenfalls erstmal außen vor, da sie ja die meiste Zeit daneben lagen und mit und ohne einem oder beiden (auch quergetauscht) das Fehlerbild gleich bleibt. An /BLK7 hängt zudem noch UD9. Der Verdacht liegt also nahe, dass UC5 und/oder UD9 nicht oder nicht so richtig will.

Kurzer Prozess

Nach drei Tagen Bedenkzeit (böse Zungen sagen Prokrastination dazu) und nochmaliger Konsultation des Schaltplans, jedoch ohne zu neuen Erkenntnissen zu gelangen, entschloss ich mich zur Radikalkur. Vermutlich wäre mir das so oder ähnlich auch bloß empfohlen worden, hätte ich vorher hier gefragt, was ich als nächste unternehmen könnte.

Schnell nochmal eingeschaltet:

Keine mysteriöse Selbstheilung. Also raus mit den beiden!

Um keine Schäden an der Platine zu riskieren, kommt die Seitenschneider-Methode zur Anwendung. Das erleichtert auch ungemein das Entlöten ohne Entlötstation.

Zuerst mal UC5. Das ist ein LS138. Der LS133 auf UD9 ist irgendwie nicht mehr so gut erhältlich, auch wenn dort notfalls sicher auch ein HC133 funktionieren sollte. Andererseits habe ich eigentlich genug auf Halde. Also rausgesucht und sogar einen "NOS" von 1989 gefunden. Fast authentisch.

Nach dem Wechsel von UC5 passierte: nichts. Das heißt, nichts neues oder anderes, alles blieb unverändert. Egal, der Lötkolben war einmal angeheizt, also auch UD9 raus. Natürlich nicht ohne ein Lötpad abzureißen, weil der Geduldsfaden zu kurz, der Unterdruck der Handpumpe zu groß und/oder das Lötpad selbst viel zu klein war. Zum Glück ist der Kontakt auf der Oberseite entscheidend und den konnte ich (wieder)herstellen.

Ohne viel Hoffnung, dass es das schon gewesen sein sollte, der nächste Einschalttest. Unfassbar! Die Checksumme für's KERNAL stimmt! Aber ich lass mich ja nicht dreimal reinlegen. Das war doch bestimmt wieder nur Zufall! Aber auch nach dem 22. Reset checksummte es wieder und wieder "E0".

Erledigt!

So sah es dann nach knapp 200 Durchläufen aus:

Stabil!

Beim ständigen Rein und Raus der Chips habe ich übrigens meinen Anfangsverdacht bestätigen können, dass wohl alle aus entweder anderen Boards stammen oder zumindest einige der oder alle Fassungen nachträglich installiert wurden. Die meisten Pins haben nämlich Lötzinnreste dran, die, obwohl sie wirklich nur minimal sind, beim Rausziehen den ein oder anderen Federkontakt mit nach oben biegen. Sehr nervig, aber zum Glück zurückbiegbar. Sehr viel öfter würde ich das den Fassungen bzw, Kontakten aber nicht zutrauen wollen!

Nun werde ich wahrscheinlich die nächsten 12 Monate vor mir her schieben gründlich überlegen, wie ich die bisher nur provisorischen Verbindungen endgültig verkabele.

----

Nur als abschließenden Hinweis: Immer wenn ich "einschalten" schreibe, habe ich natürlich vorher ausgeschaltet (duh! ). Meistens auch das Netzteil. Vor jeder Änderung im Aufbau (Chip rein, raus, Jumperkabel dran und ab usw.) und vor jeder Messung habe ich das Gerät stromlos gemacht. Gar nicht so sehr aus Angst vor den anliegenden Spannungen oder irgendwelcher statischer Entladungen o.ä., sondern einfach nur - in Kenntnis meiner Ungeschicklichkeit -, um sicher zu gehen, dass ich nicht irgendwo einen Kurzschluss verursache, wenn ich ein Kabel vom Multimeter oder ein Patchkabel fallen lasse oder beim Umdrehen der Platine selbige auf den Schraubendreher lege oder ähnluiches. Das Netzteil ist zwar kurzschlussfest (jedenfalls die 5V, die 9V sind zumindest abgesichert), aber je weniger zusätzliche Fehlerquellen ich einbaue, desto besser.

Und Sorry [sic!] für das Denglisch. Ich hab das so gelernt und gerade im Elektronik- und IT-Bereich [Ei-Tih-Bereich] ist es nicht immer einfach, sinnvolle deutsche Begriffe zu finden und falsche (auch englische) zu vermeiden. Ich bemühe mich, wo es geht, und beim Bemühen bleibt es meist. Es fällt mir nur bei längeren Texten besonders stark auf. Lötpad und Checksumme sind da schöne Beispiele.

Zitat von kinzi

eher als Type denn als "Uxy" (oder besser gleich beides der Art "74LS138 (Uxy)

Das kann ich gut nachvollziehen, geht mir genau so! Das hatte ich tatsächlich auch so vor. Es war mir am Ende aber zuviel Nicht-Text, wenn du weißt, was ich meine. Da litt ein wenig der Lesefluss. Weil ich aber tatsächlich mit dem Schaltplan hantiert habe, erschien es mir so eindeutiger. Es sind ja ingesamt drei 74LS138 verbaut.

Ach, und danke für die Blumen! Ich wollte mich nach Jahren des Profitierens vom hier versammelten Wissensschatz auch mal ein wenig einbringen. Vielleicht stolpert ja jemand über genau das selbe oder eine ähnliches Problem und wird inspiriert, einfach mal anzufangen.

Und ein bis zwölf (größere) Reparaturen liegen auch noch an...