C64C mit verschwindendem Cursor

    Guten Abend zusammen,


    ich melde mich hier mit einem Problem, das natürlich (wie so oft) dann auftrat, als ich meinen C64C gereinigt und ohne großartige Reparaturen als fertiggestellt betrachten wollte.


    Es handelt sich um eine Assy 250469.


    Im Grunde funktionierte er mit einem polnischen Neubaunetzteil auf Anhieb, lud Programme von Datasette, startete ein Spiel vom Modul, zeigte einen normal aussehenden Startbildschirm an,

    keine ICs wurden übermäßig warm, die Spannungen waren unauffällig, lediglich einige Tasten reagierten nicht.

    Ursache waren die abkorrodierten Federkontakte des Tastatursteckers, die beim ersten Abziehen brachen.

    Ersatz habe ich durch Zufall gefunden, die Molex-Serie KK 254 passt (davon gibt es auch eine Version mit bereits angecrimpten Leitungen).

    Vier der neuen Federkontakte habe ich angestückelt, danach bleibt ein flaues Gefühl beim Abziehen des Steckers, bislang halten die übrigen Kontakte aber.

    Einzelne Tasten reagierten sporadisch, weshalb ich die Tastatur öffnete und reinigte, nach dem Zusammenbau: Einwandfreie Funktion.


    Nur die shift lock-Taste hatte keine Auswirkung, natürlich sollte man den Taster auch wieder anlöten...

    Erst nach dem Anlöten des Schalters verschwand der Cursor nach dem Betätigen der shift lock-Taste, Tastatureingaben waren auch nicht mehr möglich.

    Also ausgeschaltet, mich gewundert, nach einigen Minuten den C64 nochmal eingeschaltet, Cursor ist wieder da, Tastatur reagiert.

    Shift lock betätigt: Cursor weg, Tastatur reagiert nicht mehr.


    Meine Vermutung ist nach dem Lesen einiger Beiträge, dass die CIA 1 defekt sein könnte (zumal ich in Unkenntnis den Joystick bei eingeschaltetem Rechner eingesteckt habe).


    Eine Testcartridge, test harness o.ä. besitze ich (noch) nicht.


    !IRQ sieht in meinen unerfahrenen Augen gut aus.


    Wo könnte ich bei der Fehlersuche ansetzen?


    Viele Grüße,

    K.

    Zitat von Entmagnetisierspule

    Meine Vermutung ist nach dem Lesen einiger Beiträge, dass die CIA 1 defekt sein könnte

    zumindest ist diese schonmal für die Tastatur zuständig und ohne sie gibts auch keinen blinkenden Cursor

    ..ich gehe mal davon aus, dass deine Annahme richtig ist


    es könnte aber natürlich auch sein, dass beim wiederanlöten vom Schift-Lock-Schalter eine Brücke zu Masse gebildet wurde - und bei dessen Betätigung wird dann das Signal komplett auf GND gelegt, was die CIA damit quittiert, dass sie sicherheitshalber in einen "Hold"-Zustand geht?


    das Board ist jedenfalls das robusteste, was das an- und abstecken von Joysticks während des Betriebs angeht - vor den Joystick-Ports sind extra nochmal Durchführungskondensatoren - das haben alle anderen Boards nicht

    ich bin signifikant genug:razz:

    Guten Tag Tom,


    die linke Shift-Taste erzeugt den selben Effekt, die rechte Shift-Taste nicht.


    So ist es, nach dem Drücken der shift lock-Taste verschwindet der Cursor und die Tastatur reagiert nicht mehr, das ist reproduzierbar.

    Beim letzten Test war nach einigen Minuten ein Brummen im Lautsprecher des Fernsehers zu vernehmen (unabhängig von shift lock etc.),

    bevor die Probleme mit der shift lock-Taste auftraten, war kein Brummen zu hören.


    Grüße,

    K.

    Zitat von Entmagnetisierspule

    die linke Shift-Taste erzeugt den selben Effekt, die rechte Shift-Taste nicht.

    naja - das relativiert meine Idee von oben aber ...wenn die "normale" Shift-Taste den gleichen Fehler auslöst, dann würde ich jetzt tatsächlich auf die CIA tippen ...

    du hast 6526B verbaut ... - eine einzelne 6526A hätte ich noch ..aber für die Tastatur und für die Joysticks würde das passen ..es sei denn, du möchtest gern gleiche Bestückung?


    falls es dir aber nur um die reine Funktion geht, darfst du dich gern bei mir per PN melden, dann schick ich dir die "-A" zu;)

    ich bin signifikant genug:razz:

    Gefällt mir 2

    Was mich irritiert ist, dass die anderen Tasten ja funktionieren...

    wenn eines der beiden für Left-SHIFT notwendigen Portbits defekt wäre sollten doch auch andere Buchstaben nicht funktionieren- oder?

    PB7: Cursor UP/DOWN, SHIFT LEFT,X,V,N,",",/,STOP

    PA1: 3,W,A,4,Z,S,E, SHIFT LEFT


    TOM:0)

    Zitat von Shadow-aSc

    wenn die "normale" Shift-Taste den gleichen Fehler auslöst

    Naja, sowohl Shift-Lock als auch die linke Shift-Taste gehen auf die gleichen Pads, sind also faktisch die gleiche Taste. Das einzige, was man hieraus schonmal ableiten kann, ist, dass es nicht am Schalter in der Shift-Lock-Taste hängt.


    Die Tastatur "an sich" ist eigentlich - man möge es mir verzeihen - dumm wie ein Stück Brot. Technisch wird dort nichts anderes getan, als die Verbindung zwischen 2 Pads mechanisch und damit auch elektrisch zu schließen. Die Pads sind jeweils in verschiedenen Reihungen an die Pins Richtung internem Keyboard-Connector angeschlossen, und diese Pins gehen wiederum quasi unmodifiziert an die beiden Ports A (PA0-PA7) und B (PB0-PB7). Ohne zu sehr ins Detail zu gehen, ein paar Grundlagen zur Tastaturabfrage beim C64:

    - Unter jeder Taste sitzen 2 Pads, wovon eines mit einem Pin / Bit an CIA Port A, das andere mit einem Pin / Bit an CIA Port B verbunden ist.

    - Die Pins / Bits beider Ports werden durch einen internen Pullup auf High gezogen, solange der Pin keine Verbindung zu irgendwas Definiertem hat, also "floatet".

    - Die Datenrichtung kann über die beiden Ports DDRA und DDRB bitweise zwischen Eingang (nur Lesen) und Ausgang (Lesen und Schreiben) umgeschaltet werden.

    - Das Keyboard wird per Interrupt 60x pro Sekunde abgefragt, egal, ob was gedrückt wurde oder nicht (also: Polling).


    Grundsätzlich läuft bei einem Tastendruck etwa Folgendes ab:

    - Ein Pin von Port A wird mit einem Pin von Port B kurzgeschlossen. Erstmal passiert da nix Dramatisches, weil erst im Interrupt geprüft wird, welche Taste das auslöst. Das Folgende passiert im Interrupt:

    - DDRA steht komplett (PA0-7) auf Ausgang. DDRB bleibt auf Eingang.

    - Port A wird mit #%00000000 initialisiert, damit sind alle Pins auf Low.

    - Port B wird gelesen. Kommt als Ergebnis #%11111111, dann ist zum Abfragezeitpunkt keine Taste gedrückt, keine Decodierung nötig. Warum? Weil die in Port A geschriebenen Nullen wie GND wirken. Tastendruck würde dann zumindest einen der Pins an Port B mit irgendeinem dieser Pins an Port A kurzschließen und damit diesen Pin an Port B ebenfalls auf "0" / Low ziehen. Ist beim Lesen von Port B nach obiger Vorbereitung von Port A also alles auf "1", dann ist kein Kurzschluss vorhanden -> keine Taste gedrückt. -> Abbruch der Tasturabfrage.

    - Wurde eine Taste gedrückt, ist ein Bit des gelesenen Port B -Bytes "0". Die Decodierung startet.

    - Bit / Pin #0 von Port A wird auf "0" gesetzt, der Rest auf "1". Damit wird quasi zuerstmal NUR alles in "Spalte 0" geprüft.

    - Port B wird erneut ausgelesen. Dann werden alle 8 Bits dieses Ergebnisses auf "0" oder "1" nacheinander getestet. Ist ein Bit ="0", ist der Kurzschluss und damit die gedrückte Taste gefunden: Nummer dieses Bits ist die "Zeile" in der Decodiermatrix, die Spalte ist über den in Port A geschriebenen Wert bekannt, wo im Loop immer nur EIN Bit auf "0" gesetzt wird. -> Taste erkannt, raus aus der Prüfung, zur Auswertung.

    - Sind alle Bits im Port B auf "1", dann war die gedrückte Taste nicht in Spalte 0 der Matrix.

    - Durch Bitrotation (SEC, ROL A) wird das "0"-Bit in die nächste zu prüfende "Spalte" der Matrix verschoben, das resultierende Byte in Port A geschrieben, und erneut wird Port B auf eine Reaktion (ein Pin / Bit statt "1" nun "0") geprüft. -> Loop

    - Spätestens mit "Spalte" #7 und "Zeile" #7 sollte dann nach max. 64 Durchläufen (8 Zeilen x 8 Spalten) die "0"-Reaktion gefunden sein. Ein Zähler innerhalb der Schleifenkonstruktion liefert dann den Matrixcode der gedrückten Taste.


    Klingt kompliziert - isses auch, zumindest beim Erklärversuch... ;)


    Das heißt aber auch:

    Ist die CIA defekt, dann müssten *mehrere* Tasten (da an jedem Pin 8 Tasten hängen) einen Fehler / ein Problem erzeugen. "Shift links" verbindet (genau wie "Shift lock") die Pads "B" und "3" der Tastatur miteinander, also "B" -> Port B Bit 1 ("row1" = Pin 11 an CIA #1) mit "3" -> Port A Bit 7 ("column7" = Pin 8 an CIA #1). Auf Reihe "B" liegen nun auch noch E, S, Z, 4, A, W und 3, auf Spalte "3" liegen noch N, V, X, "run/stop", "/", das Komma und "Cursor hoch/ runter". Deshalb sollte bei CIA-Defekt je nach Portbit auch jede der anderen Tasten der genannten Tastengruppen zum gleichen Ergebnis führen. Ist dagegen wirklich NUR Links-Shift / Shift-lock betroffen, müsste der Fehler im Bereich des Keys selbst liegen, denke ich.


    Durch die simple Natur dieser elektrischen Verbindung (nur Kurzschluss der Port-Pins; die Tastatur bekommt nichtmal 5V vom Rechner, der Pin ist nicht genutzt) kann ich mir kaum vorstellen, dass der Rechner "elektrisch" abstürzt, wenn die anderen Tasten nicht Gleiches auslösen. Und im ROM-Listing zur Tastaturabfrage hab ich auf die Schnelle nur einen "No-Return-Loop" gesehen - wenn der gelesene Wert von Port B sich beim Vergleich mit einem direkt danach per CMP erneut ausgelesenen Wert unterscheidet, wird unendlich geloopt, bis der Wert konstant bleibt. Kippelt also ein Portbit in rasender Geschwindigkeit, kann das zu einem Lockout innerhalb der Interrupt-Routine führen. Unwahrscheinlich...


    Ich würde Shift-lock nochmal ablöten und schauen, ob ohne den Lock-Schalter auch bei "Shift links" wieder der Cursor verschwindet.


    Mal weiter analysieren, was mir noch so einfällt... ;)


    Just my 2 cents, again...

    Guten Abend zusammen,


    ich konnte heute noch ein wenig am C64 herumprobieren, aber zunächst Shadow-aSc vielen Dank für das freundliche Angebot, ich komme darauf zurück, wenn ich keine "-B"-Variante finde (obwohl der C64 mit den angestückelten Tastaturkontakten nun schon verbastelt ist, würde ich mich doch auf die Suche nach der B-CIA machen).


    Ralph, diese Erklärung ist wirklich gut, ich danke dafür ganz herzlich.

    Ohne den Shift Lock-Schalter bleibt der Cursor sichtbar.


    Und Tom, exakt das ist das Problem (PB7 und PA1), dazu komme ich jetzt.


    Nach dem heutigen Einschalten des C64 funktionierten sämtliche Tasten an PB7 nicht.

    Alle anderen Tasten funktionierten, Cursor right/left jedoch brachte einen invertierten senkrechten Balken (den ich durch Drücken von - und Shift right reproduzieren konnte) und beim Betätigen mit Shift right zusammen eine invertierte geschlossene Klammer (durch Drücken von ; und Shift right zu reproduzieren), vorher hat Cursor right/left immer ohne dieses Phänomen funktioniert.


    Leicht erstaunt habe ich den C64 ausgeschaltet, ca. 10s gewartet, ihn wieder eingeschaltet-und zumindest Cursor right/left verzichtete auf seine Zusatzfunktion.

    Also gut, Tasten an PB7 immer noch tot, der Rest funktioniert.

    Shift left gedrückt und sämtliche Tasten an PA1 geben auf, der Rest funktioniert.

    Shift lock gedrückt, der Cursor friert ein (sichtbar oder nicht sichtbar, je nachdem, wann man drückt), nichts geht mehr.


    Also den C64 wieder ausgeschaltet, nach 10s eingeschaltet, normaler Startbildschirm ohne Cursor erscheint.

    Nach weiteren 10s eingeschaltet: kein Cursor.

    Nach einer Minute eingeschaltet: Cursor vorhanden, das ganze Spiel lässt sich nun mit entsprechenden Pausen wiederholen.

    Nur Cursor right/left zeigte nicht mehr seine ungewollte Zusatzfunktion mit invertierten Zeichen.


    Mir ist noch aufgefallen, dass der Cursor unregelmäßig blinkt, und dass der Startvorgang des C64 in den Fällen, in denen kein Cursor erschien, schneller ablief als ein Start, bei dem ein Cursor erschien (gefühlsmäßig eine Sekunde).

    Bei einem Start mit Cursor war ganz kurz "Zeichensalat" auf dem Bildschirm zu sehen, danach erschien sofort der normale Startbildschirm.


    Gedrückthalten der linken Shift-Taste lässt den Cursor ca. doppelt so schnell blinken, die rechte Shift-Taste hat diesen Effekt nicht.


    Die Tastaturkontakte liegen im betätigten Zustand (gemessen am Tastaturstecker) bei ca. 80 bis 170 Ohm, sind das übliche Werte?


    Grüße,

    K.

    Zitat von Entmagnetisierspule

    Die Tastaturkontakte liegen im betätigten Zustand (gemessen am Tastaturstecker) bei ca. 80 bis 170 Ohm, sind das übliche Werte?

    Sind (denke ich) übliche Werte... wären sie zu hoch, würde die Taste ganz einfach nicht funktionieren...


    Ich tippe jetzt auch schon sehr auf eine defekte CIA...


    PS: Eine der beiden CIAs kann man doch auch gegen eine aus einem Amiga austauschen, die soll dann so halbwegs funktionieren oder? Hab ich zumindest mal wo gelesen...


    Cheers, TOM:0)

    Zitat von Ralph_Ffm

    - Port A wird mit #%00000000 initialisiert, damit sind alle Pins auf Low.

    - Port B wird gelesen. Kommt als Ergebnis #%11111111, dann ist zum Abfragezeitpunkt keine Taste gedrückt, keine Decodierung nötig. Warum? Weil die in Port A geschriebenen Nullen wie GND wirken. Tastendruck würde dann zumindest einen der Pins an Port B mit irgendeinem dieser Pins an Port A kurzschließen und damit diesen Pin an Port B ebenfalls auf "0" / Low ziehen. Ist beim Lesen von Port B nach obiger Vorbereitung von Port A also alles auf "1", dann ist kein Kurzschluss vorhanden -> keine Taste gedrückt. -> Abbruch der Tasturabfrage.

    Ah, man versucht also Aufwand zu sparen, indem man einen kleinen Mehraufwand vorher macht. Das wusste ich so auch nicht nicht, sondern dachte dass die Routine "stur" immer alle Bits von PortA testet. D.h. es wurde wahrscheinlich auch hier und da nur eine bestimmte Anzahl Bit von PortA getestet, wenn man beispielsweise gezielt nur auf (eine) bestimmte Taste(n) wartet?

    Zitat von zitruskeks

    Ah, man versucht also Aufwand zu sparen, indem man einen kleinen Mehraufwand vorher macht. Das wusste ich so auch nicht nicht, sondern dachte dass die Routine "stur" immer alle Bits von PortA testet.

    Ja, der "kleine Mehraufwand" ist ja wirklich minimalst, in Relation zum kompletten Durchlaufen der Tastaturabfrage / -decodierung, denn die müsste sonst eben komplett alle Kombinationen durchgehen, nur um im besagten Fall festzustellen, dass eben *keine* Taste gedrückt wurde. Durch den einen simplen Vergleich kann die Zeit, die so im Interrupt verweilt werden muss, ggf. erheblich reduziert werden, und das kostet nur wenige Bytes / Opcodes und ein paar Taktzyklen. Ist halt eigentlich brachial gelöst, aber dadurch auch wieder bestechend effizient. Man kriegt halt nur raus, *dass* irgendeine Taste gedrückt ist, aber erstmal nicht, welche das ist.


    Zum Identifizieren der Taste muss dann halt eben wirklich jedes einzelne Bit von Port A getrennt und nacheinander als "Spalte" gewählt (also gelöscht und damit auf GND gelegt) werden, um die Reaktion der 8 "Zeilen" (also Bits von Port B) DARAUF zu testen. Nur so kriegt man dann den passenden Index in die Matrix. Wobei der Testloop natürlich bei Finden der ersten "reagierenden" Kombination von "Zeile" und "Spalte" abgebrochen und verlassen wird, und über den gefundenen Matrixzeiger wird dann der zugehörige Tastencode geliefert. Ein sturer Test aller 8x8 Kombinationen bis zum bitteren Ende findet also nur in Ausnahmefällen statt...


    Zitat von zitruskeks

    D.h. es wurde wahrscheinlich auch hier und da nur eine bestimmte Anzahl Bit von PortA getestet, wenn man beispielsweise gezielt nur auf (eine) bestimmte Taste(n) wartet?

    Die Tastaturdecodierung im Interrupt (also im ROM) wartet ja nicht auf eine bestimmte Taste, sondern pollt die Tastaturmatrix und liefert bei gedrückter Taste deren Code zurück ans System bzw. legt den in der Zeropage bzw. im Tastaturpuffer ab, wo ihn dann ein Programm auslesen kann. Da die Abfrage im IRQ arbeitet, muss ein Programm deshalb auch nicht selbst die Matrix auswerten, sondern kann bequem auf das vom Kernal gelieferte und regelmäßig aktualisierte "Ergebnis" warten.


    Wie oben geschrieben: bis die erste gedrückte Taste erkannt wird (1 Bit in Port A auf 0 gesetzt UND 1 Bit in Port B als Reaktion darauf auch 0) wird stur bitweise weitergeprüft, ob eine "0 -> 0"-Kombination gefunden wird.


    Ich formuliere das mal als logischen Pseudo-Programmcode:


    FOR X=0 TO 7

    ... Setze Bit X in Port A auf logisch "0", alle anderen auf logisch "1"

    ... FOR Y=0 TO 7

    ....... Teste Bit Y in Port B auf logisch "0"

    ....... IF Bit Y in Port B = "0" THEN Matrixpointer = (X * 8 ) + Y ; gedrückte Taste gefunden, Code dafür ist besagter Pointer in die Matrix - > Loops verlassen!

    ... NEXT Y

    NEXT X

    Falls die Schleifen bis hierhin kommen, war doch keine Taste erkennbar gedrückt, da alle 64 Kombinationen erfolglos durchgeprüft wurden.


    Man muss das halt immer bewusst trennen: Tastaturdecodierung auf Kernal-Ebene (IRQ) ist NICHT gleich der Tastaturabfrage innerhalb eines Programms.

    :)

    Einmal editiert, zuletzt von Ralph_Ffm () aus folgendem Grund: *grrrrr* Aus "8 )" wird ein Smiley - so funktioniert nichtmal Pseudocode, wenn einen mitten in der Formel ein Emoticon angrinst...

    Zitat von Ralph_Ffm

    Wobei der Testloop natürlich bei Finden der ersten "reagierenden" Kombination von "Zeile" und "Spalte" abgebrochen und verlassen wird, und über den gefundenen Matrixzeiger wird dann der zugehörige Tastencode geliefert

    Naja so "natürlich" hätte ich das auch nicht gedacht, da man so kein Rollover hat. (ich muss gestehen das war mir bis grade nicht mal so wirklich aufgefallen am c64)


    Mit "D.h. es wurde wahrscheinlich auch hier und da nur eine bestimmte Anzahl Bit von PortA getestet, wenn man beispielsweise gezielt nur auf (eine) bestimmte Taste(n) wartet?" meinte ich schon alternative Ansätze zur Kernalroutine SCNKEY - immerhin scheint es (nach etwas herumgooglen) viele andere Routinen zu haben, z.T. mit Key-Rollover. Wenn man in einem Game voll auf speed optimiert wäre es ja sinnvoll, gezielt nur die Leitungskombinationen zu testen, auf denen die erwarteten Keys auch liegen.

    Zitat von zitruskeks

    Wenn man in einem Game voll auf speed optimiert wäre es ja sinnvoll, gezielt nur die Leitungskombinationen zu testen, auf denen die erwarteten Keys auch liegen.

    Damit hast Du natürlich recht. Ich ging jetzt erstmal von der Standard-Kernalabfrage aus. Wenn man programmseitig aber das gesamte ROM ausblendet und sich selbst um die Funktionen kümmert, kann man selbstverständlich auch maßgeschneiderte Tastaturroutinen basteln. Das kann man dann auch flexibler mit gleichzeitiger Abfrage der Joystickports kombinieren, damit nur noch die zugelassenen Inputvarianten überhaupt geprüft und verwendet werden.


    Bei Erkennen von Sonder- / Kombinationstasten (Shift, Control, C= ) wird übrigens die Tastaturdecodierung NICHT unbedingt abgebrochen und als "erledigt" gemeldet, sondern es wird in einige Sonderroutinen verzweigt, um dort z.B. das Shift-Flag zu setzen, den Zeiger auf die Zeichensatztabelle im Rom umzustellen (Shift + C= ) etc., und dann ggf. die Tastaturabfrage fortzusetzen - sonst würde gleichzeitiges Drücken von Shift und einer anderen Taste ja keine Großbuchstaben erzeugen, sondern nur immer Shift erkannt. Und Letzteres wäre irgendwie "brotlose Kunst"... ;)


    Für den exakten Umgang der Kernal-IRQ-Routine mit der Tastaturdecodierung müsste ich nochmal ins ROM-Listing schauen. Ich meine mich zu erinnern, dass die gedrückte Taste über einen inkrementierenden Zähler als Index in die Matrix im X-Register gehalten / hochgezählt wird. Wenn mich meine Erinnerung nicht trügt, wurde nach Erkennen einer Taste (sofern keine obige "Zusatz-Taste" wie Shift) der Index abgelegt, der zwischenzeitlich auf dem Stack (mit PHA) gesicherte Spaltenzähler gepullt (mit PLA) und dann die Routine verlassen... Damit wäre dann seitens des Kernal maximal eine Taste plus Zusatztaste gleichzeitig erkannt worden, aber keine multiplen Tastenbetätigungen identifizierbar.


    Ist schon verdammt lang her, aber so langsam kommt es wieder zurück in den Kopf-Speicher... ;)

    Guten Abend zusammen,


    ich danke euch für die interessanten Einblicke, die ich hier gewinnen konnte und gebe die kurze Rückmeldung:

    Es war die CIA 1 (Danke für den Anstoß, Tom, ich hätte sonst eher gezögert, sie auszutauschen).

    Ich konnte sie heute auslöten (das war wirklich eine spezielle Erfahrung, es ging aber ohne Leiterbahn- und Lötaugenabriss), habe dann eine "low cost"-Fassung eingebaut (für den Fall, dass ich in hoffentlich ferner Zukunft ein entlötetes Bauteil einsetzen muss, diese vertragen sich aufgrund anhaftender Lotreste in der Regel nicht mit "Präzisions"fassungen),

    die Leiterbahnen ohne Befund durchgepiepst, die Ersatz-CIA eingesetzt, eingeschaltet...sämtliche Tasten funktionieren, sogar die Shift-Tasten mit ihrer einrastenden Abart.


    Ursprünglich verbaut war eine 6526B aus der 43. Woche 1987, nun werkelt dort eine 6526 aus der 25. Woche 1983.

    Nicht ganz, was ich mir vorgestellt habe, aber es funktioniert und ich bin zufrieden mit meiner ersten C64-Reparatur.


    Ein Nachtrag noch: Die CIA stammt von einer großen Online-Verkaufsplattform, sie war in ihrem früheren Dasein ebenfalls gesockelt (auf welche Platinenversionen lässt das schließen, interessehalber?).

    Da ich die Fledderei solch alter Elektronik nicht gutheiße, rede ich mir nun ein, dass meine CIA kein Teil einer Schlachtplatte war...


    Grüße,

    K.