Messpunkte mit dem Oszi beim C64

Dieser Thread ist nicht als Einstieg bei der Fehlersuche gedacht. Es wird folgendes vorausgesetzt:

• Es wurde bereits getestet ob irgendwelche ICs ungebührlich heiss werden (= man verbrennt sich die Finger)
• Die Versorgungsspannungen wurden gemessen (Siehe dazu den passenden Thread in der Reparaturecke).
• Wenn möglich wurden alle gesockelten ICs in einem funktionierenden Board getestet.

Es wird ausserdem vorausgesetzt, dass Grundlagen des Umganges mit dem Oszi vorhanden sind (man sollte die Anleitung gelesen und zumindest teilweise verstanden haben) und bekannt ist wie man bei einem DIP-IC die Pins zählt. Idealerweise hat man ein funktionierendes Board an dem man Vergleichsmessungen machen kann.

Das von mir verwendete Oszi ist ein UNI-T UTD2102CEL, mehr als ausreichend für den Hobbybereich.

Für Messungen in alten Rechnern mit Takten unterhalb von 10MHz benutze ich meist folgende Einstellungen:

• Vertikal: 2V, damit ergeben 5V 2,5 Kästchen auf dem Bildschirm. Bei NMOS erreicht HIGH normalerweise nur Werte um ca. 4V.
• Horizontal: 100ns, damit hat man eine gute Auflösung von ca. je 5 Kästchen für HIGH und LOW bei PHI0 und sieht auch Störungen gut.
• Triggerung auf fallende Flanke in der Mitte des Bildschirms, damit ist der CPU-Teil eines PHI0-Zyklus auf der linken Seite des Bildschirms und der VIC-Zyklus auf der rechten Seite zu sehen.
• Das Oszi ist ein Zweikanal-Oszi und ich stelle die meisten Messungen im Verhätnis zu PHI0 dar wobei die Triggerung auf PHI0 passiert. Damit steht das Signal nicht leer im Raum sondern man sieht den Kontext zum Rest des Systems
• Manche Messungen brauchen für ein gutes Bild ein Speicheroszi, Einstellung auf 'one shot' oder 'single' (also nur die erste Triggerung auswerten und darstellen) und mehrfache Starts der Messungen bis das erwartete Bild zu sehen ist.

Die folgenden Einträge geben Hinweise welches Signal wo zu finden ist und wie es auf einem funktionierenden Board aussehen sollte, teilweise mit Bildern.

Als erstes verifizieren ob das RESET-Signal sauber erzeugt wird. Es ist an der CPU auf Pin 40 zu finden und muss beim Einschalten LOW (0V) sein und nach kurzer Zeit auf HIGH (4-5V) wechseln und dort bleiben. Passiert das nicht läuft die CPU nicht los. Mögliche Fehlerquellen sind hier der 556 und der 7406, bei einem 250469 auch der 74LS14.

Der nächste Check: Bekommt der VIC auch seine Takte? Diese liegen an Pin 21 (color clock, 17,73 MHz) und Pin 22 (dot clock, 7,88MHz) an. Das gesamte Systemtiming wird aus 'dot clock' abgeleitet, fehlt dieser Takt geht gar nichts. PHI0 (Pin 1 der CPU) ist genau 1/8 davon.

Angehängt ein Bild, PHI0 in Relation zur dot clock, aufgenommen auf einer 250466 mit 6569R5. PHI0 ist bei solchen Messungen hellblau dargestellt, das interessante Signal ist gelb

Als nächstes verifiziere ich AEC (Pin 5 der CPU) in Relation zu PHI0. Wenn man nicht gerade eine Badline erwischt sieht es aus als wenn AEC dasselbe ist wie PHI0, nur leicht verschoben. Bei einer Badline wäre AEC die ganze Zeit LOW.

Jetzt die Steuerung der RAMs. Die Schaltung im C64 routet _RAS vom VIC direkt zu den RAMs während _CAS durch die PLA muss. Ohne _CAS rückt das RAM keine Daten raus und macht nur einen Refreshzyklus mit der angelegten Zeilenadresse. Das Routing durch die PLA erlaubt es auf diese einfache Weise das RAM je nach Anforderung abzuschalten. Es verzögert aber auch _CAS etwas.

Der normale Ablauf ist das zuerst _RAS auf LOW geht und kurze Zeit später _CAS. Am Ende des Zyklus sind beide wieder HIGH und bleiben das auch eine Weile um die Precharge-Time einhalten zu können.

Die folgenden Bilder zeigen _RAS und _CAS im Verhältnis zu PHIO und je einmal im Verhältnis zueinander am VIC und am RAM. Bei den letzteren ist der Trigger auf _RAS welches hellblau dargestellt wird.

Die Pins sind:

• _RAS am VIC: 18
• _CAS am VIC: 19
• _RAS am 4164: 4
• _CAS am 4164: 15
• _RAS am 41464: 5
• _CAS am 41464: 16

Bis zum 250425 benutzt der C64 8 Stück 4164, ab dem 250466 dann 2 Stück 41464 DRAMs. Teilweise steht eine andere Nummer drauf, aber die Pinbelegung ist dieselbe.

Die nächste Check ist ob die ROMs überhaupt angesprochen werden. Dazu einfach das _CS-Signal an Pin 20 des ROMs testen. Es darf nicht dauernd HIGH sein sondern muss hin und wieder nach LOW wechseln. Bei LOW ist das ROM aktiv und liefert Daten. Hierzu habe ich nur ein Bild der Pinbelegung der im C64 verwendeten 2364 ROMs.

Oszi auf 'single' einstellen und auf HIGH -> LOW triggern lassen. Man sollte bei jedem Start der Messung sofort eine Flanke einfangen können.

Kommen wir zum R/_W-Signal (CPU Pin 38 ) . Damit zeigt die CPU an, daß sie Daten schreiben will. Der VIC kann nur lesen, bei ihm dient R/_W als reiner Eingang für den Zugriff auf seine Register.

Für das Bild brauchte ich wieder die Einstellung 'single' und ein paar Versuche bis ich einen Schreibzyklus erwischt habe.

Wie man sehen kann steigt R/_W am Ende des Zyklus erst schnell an und dann deutlich langsamer. Der Knick kommt vom AEC-Signal welches die CPU vom Bus nimmt wenn der VIC dran ist. Ab dort wird das Signal nur noch vom Pullupwiderstand der R/_W-Leitung (1.5KOhm) langsam hochgezogen. Das ist nicht wirklich optimal weil die R/_W-Leitung direkt an den RAMs hängt und bei zu starker Belastung der Leitung der Anstieg zu langsam sein könnte und damit die RAMs den VIC-Zyklus als Schreibzyklus sehen könnten. Es funktioniert offensichtlich, aber schon beim 250466 hat Commodore mit U11 und J3 einen Workaround vorgesehen (aber nicht implementiert) und beim 250469 das R/_W-Signal für die RAMs durch die PLA geschickt.

Jetzt der Datenbus (Pin 37/D0 - 30/D7 an der CPU)

Es sollte Aktivität zu sehen sein und zwar auf allen 8 Leitungen. Eine oder mehrere Leitungen die sich nie ändern deuten auf ein Problem mit irgendeinem Chip der mit dieser Leitung verbunden ist hin. z.B. ein defektes RAM, CIA, SID, VIC oder ROM welches eine Leitung dauerhaft nach LOW zieht. Meist (nicht immer) erkennt man solche Defekte an großer Hitzeentwicklung des betroffenen ICs.

Hier ein Bild von D0 in Relation zu PHI0. Der kleine Überschwinger auf D0 kurz nachdem PHI0 nach LOW wechselt war bei meinem Board problemlos reproduzierbar, beeinflusste den Betrieb aber nicht.

Zum _IRQ-Signal. Damit wird der CPU angezeigt, daß ein andere Gerät etwas will. Das Signal ist inaktiv solange es HIGH ist. Bei einem C64 passieren schon im Leerlauf (nur eingeschaltet) 60 IRQs pro Sekunde vom Systemtimer über den auch die Software-Uhr (TI und TI$) geführt werden. Dieser Timer ist in CIA1 zu finden an dem auch die Tastatur hängt. Auch das Blinken des Cursors wird damit über Software realisiert.

Man sollte also bei eingeschaltetem C64 an Pin 3 der CPU Aktivität feststellen können. Die LOW-Zeiten sind in Relation ziemlich kurz, also die horizontale Ablenkung auf 5ms pro Feld einstellen, damit kann man 3 IRQs sehen.

Hier noch ein Hinweis zu den Messungen.

Ich benutze ungerne den Tastkopf am Oszi wenn ich es vermeiden kann, man rutscht zu schnell ab und verursacht Kurzschlüsse womit man den Rechner noch weiter beschädigen kann. Der Klemmaufsatz ist aber etwas zu grob für DIP, der taugt bei meinem Oszi eigentlich nur für die Pins an den Ecken der ICs.

Also habe ich mir aus Pollin Best. Nr. 830 262 und einem Stück Litze einen kleinen Adapter gebastelt. Damit kann man sauber messen, das Signal wird bei den im C64 üblichen Frequenzen gegenüber der direkten Anwendung das Tastkopfes nicht sichtbar verzerrt. Die Klemme nur bei ausgeschaltetem C64 an das zu messende Signal anklemmen, verifizieren das kein Kurzschluss entsteht und dann erst einschalten und auf den Bildschirm des Oszi schauen.

GND für die Messungen hole ich mir meist vom Modulator, da findet sich immer ein Platz den dem die Krokoklemme hält.

Oszi und Tastkopf sind bei mir beide auf 'x10' eingestellt.

Das Bild zeigt die Messung von _IRQ an meinem Testboard. Wurde beim Vorbesitzer über Jahre offen im Keller gelagert. Funktioniert trotz des Aussehens aber einwandfrei nachdem ich einige defekte ICs gewechselt habe.

Nachtrag zur Messung von _CS an den ROMs: Im Leerlauf wird das BASIC-ROM (901226-01) nicht angesprochen, man kann aber einfach über das Drücken der RETURN-Taste Zugriffe produzieren.

Es kam noch ein Vorschlag den Ausgang des VIC mal aufzunehmen. Der Video-Ausgang des VIC wird durch den Modulator geroutet und dort im Pegel noch angepasst. Sollte dort ein Schaden sein sieht man auch am Videoausgang nichts obwohl das System sonst OK ist.

Hier zwei Bilder, aufgenommen am VIC Pin 15 (Sync/Luma) mit 10µs pro Feld. Einmal mit einem Teil der Einschaltmeldung und einmal ohne. Jeweils aufgenommen mit 'single'. Man kann die Synchronsignale recht gut erkennen.

Fehlendes Chroma (Pin 14 am VIC) ergibt ein Graustufenbild bei sonst einwandfreier Funktion.

Der sehr kurze, hohe Peak am Anfang der dargestellten Zeile müsste die weisse senkrechte Linie am linken Bildrand sein.

Hier noch ein wichtiges Signal. Damit der VIC ungestört seine Zugriffe machen kann müssen die Multiplexer (2 x 74LS257) ihre Ausgänge abschalten, Dieses wird bei den älteren Boards über das AEC-Signal und ein Gatter des 7406 mit einen sehr kleinen Pullupwiderstand (180Ohm) gesteuert, Diese Schaltung ergibt ein invertiertes AEC-Signal. Das Freigabesignal ist an den 74LS257 an Pin 15 zu finden und muss LOW sein wenn die CPU auf das RAM zugreifen darf. Ist der 7406 defekt und zieht das Signal dauerhaft auf LOW kämpfen die 74LS257 und der VIC um die Hoheit auf dem DRAM-Adressbus was garantiert Müll auf dem Monitor ergibt. Ist das Signal dauerhaft HIGH bekommt die CPU gar keinen Zugriff auf das DRAM und der Rechner startet nicht.

Das Bild zeigt PHI0 in blau und _OE (Pin 15) der Multiplexer in gelb. Wie die meisten Bilder in 'single' während einer normalen Bildschirmzeile mit abwechselnden CPU- und VIC-Zugriffen aufgenommen. Bei einer Badline wäre es für die Dauer der Badline durchgehend HIGH.

Hier noch 4 Bilder. Sie stellen das _CS Signal des Char-ROM (Pin 20) relativ zu Phi0 (CPU Pin 1) dar. Der Rechner funktioniert einwandfrei und die PLA ist ein Original von MOS. Die Bilder lassen vermuten, dass die Logik innerhalb der Original-PLA auch nicht wirklich 100% sauber ist. Manche Merkwürdigkeiten scheinen aber nicht zu stören.

Nicht jeder hat ein Oszi, aber in letzter Zeit gibt es immer mehr sehr preiswerte Multimeter mit eingebautem Frequenzzähler. Sowas kann beim Debugging eines defekten C64 durchaus hilfreich sein (Wenn die 60Hz auf _IRQ zu finden sind hat der KERNAL den CIA-Timer programmieren können) und ist für so ziemlich jeden erschwinglich. Ich hab keine 15 Euro incl. Porto für ein 'Victor VC921' auf Ebay hingelegt. Mit dem habe ich auf einer funktionierenden 250466-Platine folgende Signale gemessen und war von der Genauigkeit angenehm überrascht. Die Messung war einfach, schwarze Messleitung an GND und mit der roten das Signal abnehmen.

Duty Cycle = Verhältnis HIGH zu LOW wobei die Zahl angibt wieviel % der Periode das Signal HIGH ist.

Mit nicht gleichförmigen Signalen (AEC, _CS-Signale, Daten- und Adressbus) hat es so seine Probleme, die angezeigte Frequenz ändert sich andauernd, aber immerhin sagt einem das, daß sich auf der Leitung was tut. Bei statischen Leitungen wird hingegen 0 Hz angezeigt.

Durch Streuungen beim C64 und dem verwendeten Multimeter können obige Zahlen variieren, speziell der Duty-Cycle. Man sollte aber trotzdem abschätzen können ob das gemessene Signal im richtigen Bereich liegt, Der Duty-Cycle von _CAS muss z.B. höher sein als der von _RAS damit das DRAM funktioniert.

Bei einer PAL-Platine gilt folgendes:

(*) Auf den alten Platinen mit 74LS629/MC4044P wird dieser Faktor per diskret aufgebauter PLL erzeugt. Im 8701 hingegen über Verdopplung und Teilung durch 4.5.