Kennen Sie Ihren C 64? (Teil II)

Haben Sie sich eigentlich schon mal Gedanken darüber gemacht, wie der C 64 funktioniert? Wir wollen Ihnen in dieser Reihe zeigen, wie man dem C 64 auf die Schliche kommt.

Keine Angst — wir fangen langsam mit den Grundlagen an, um uns Stück für Stück vorzuarbeiten, bis der C 64 wie ein gläserner Computer vor uns steht. Was ist dran an der »Hintertür«, die wir im ersten Teil beschrieben haben? Was kann man damit machen? Nun, die Antwort ist relativ einfach, denn die »Hintertür« ist die einzige Möglichkeit, auf preisgünstige Weise ein beliebiges Standard-Diskettenlaufwerk mit FDC (Floppy-Disk-Controller) an den C 64 anzuschließen (Bild 1). Dazu wäre es interessant, zu wissen, wie dieser Eingang (SO) in der 6510-CPU tatsächlich funktioniert. Doch das ist ein Geheimnis der CPU-Entwickler. Besitzer der (längst vergriffenen) Original-Dokumentation über diese CPU finden nur den lapidaren Hinweis: Das ist zur Zusammenarbeit mit einem künftigen Baustein vorgesehen und sollte normalerweise nicht benutzt werden. Der »künftige« Baustein istjedoch leider nie auf dem Markt erschienen.

Die Commodore-Entwickler haben beim C 64 diesen Signaleingang nicht mehr aus der 6510-CPU herausgeführt. Diese CPU ist übrigens nichts anderes als eine 6502-CPU mit einem Port und Steuereingängen für die Zusammenarbeit mit dem GDP (Grafik Display Prozessor oder Video-Chip). Nun gibt es eine unzählige Schar von Freaks und Hackern, die gerade beim C 64 auch den letzten POKE- oder PEEK-Befehl kennen. Doch wie sieht es mit der Sprache aus, die die 6510-CPU »spricht«? Assembler ist nicht nur Voraussetzung zum echten Messen, Steuern, Regeln und schnellen Spielen, sondern im Vergleich zum vorhandenen Basic (man könnte dem C 64 auch ein schnelleres Basic »einpflanzen«) fünf bis zehntausend mal schneller. Aufgrund jahrelanger Praxis in der Ausbildung kann behauptet werden, daß Assembler in der gleichen Zeit wie Basic erlernbar ist. Jede höhere Programmiersprache, und sei sie noch so komplex (zum Beispiel ADA oder C), muß am Ende von einer CPU ausgeführt werden. Und die »spricht« nur ihren speziellen Assembler.

Eine CPU kann man mit einem kompletten Computersystem vergleichen. Auch hier gibt es einen Interpreter (wie Basic ebenfalls interpretiert wird). Der Interpreter in der CPU bekommt über dem Datenbus ein Byte, und das wird in der CPU interpretiert. Das geschieht in dem Instruktionsregister des Prozessors. Ist das Byte nicht interpretierbar, »stürzt« der Computer ab und es hilft nur noch ein Reset.

Im Gegensatz zur Maschinensprache gibt es im Basic einen Notausgang. Wird ein Befehl nicht gefunden (weil er nicht in der Interpreterliste steht) oder kann er nicht ausgeführt werden (weil zum Beispiel keine Floppy angeschlossen ist oder per Befehl mathematisch nicht ausführbar ist, etc.), erzeugt das Betriebssystem (natürlich in Assembler geschrieben) eine Fehlermeldung. Die einfachste Fehlermeldung ist »SYNTAX ERROR«.

Wird ein Basic-Befehl eingegeben (oder im Programm abgearbeitet), sucht die CPU im Basic-Interpreter den Befehl und die entsprechende Routine dazu und führt sie aus. Die Routine ist natürlich wieder in Assembler geschrieben. Das alles braucht sehr viel Zeit.

Der eigentliche Chef

Doch das ist längst noch nicht alles. Nebenbei muß die CPU noch die Interrupt-Request-Routine (IRQ) bedienen. Sie wird ausgelöst durch den Timer eines Portbausteins (CIA 6526) des C 64. Die CPU unterbricht das Programm, rettet alle Register und führt die Routine aus. Diese Assembler-Routine wird 60mal pro Sekunde durchlaufen.

Dann ist da noch der Video-Chip VIC 6569 (GDP). Er sorgt für das Bild und die RAM-Auffrischung (Bild 2). Der GDP unterbricht dann die CPU, weil auf einem Bus ja nur einer arbeiten kann. Wenn der GDP auf dem Daten- und Adreßbus arbeitet, führt er direkte Speicherzugriffe (DMA) aus. Die Signalleitung dazu heißt »Bus available« (BA, Bus verfügbar) und geht zum CPU-Eingang »READY«. Das Signal »BA« müßte eigentlich »DMA (Direct Memory Access) oder »Halt« heißen, denn wenn diese Signalleitung auf Low geht, wird der CPU sozusagen die »rote Karte« gezeigt. Das heißt, die CPU hat ihre Aktivitäten einzustellen, und von Daten- und Adreßbus zu verschwinden. Da sie das meistens nicht sofort kann, gibt ihr der GDP noch drei Taktzyklen Zeit, um »die Beine hochzunehmen«. Der Zugriff auf den Leitungen regelt die Signalleitung »Adress-Enable-Control« (AEC). Der Zustand High dieser Leitung bedeutet, daß die CPU aktiv ist, Low gibt dem GDP Vorrang, geht also »BA« auf Low, wartet der GDP noch drei Taktzyklen. Danach geht AEC so lange auf Low, bis die Arbeit des GDP beendet ist. Es ist sehr wichtig, daß vor dem Zugriff (DMA) noch drei Taktzyklen gewartet wird, da sonst das System abstürzt. Dieses ganze Timing muß auch ein Baustein »wissen«, der eigentlich die gesamte Koordinierung im System durchführt: das PLA-IC 251 064-01. Dieser Baustein ist ein programmierbares Logic-Array, das heißt Signale, die hineingehen, erscheinen an den Ausgängen je nach vorheriger Programmierung in Abhängigkeit der gewünschten Verknüpfung.

Dieser Adreßmanager ist für Entwickler ein alter Bekannter, nämlich das IC 82 S 100 von Intel oder Signetics. Commodore hatte bei den ersten Prototypen des C 64 auch dieses IC benutzt. Aber warum sollte es in Serie von Intel oder Signetics kommen, schließlich hat Commodore einen eigenen Prozessorhersteller im Haus: MOS Technologies.

Ob der GDP die CPU anhält, bestimmt wiederum am Anfang die CPU, denn beim Hochlaufen des Systems (Reset oder Kaltstart) wird der GDP auf Zugriff programmiert. Und wenn die CPU das macht, kann das ein Programmierer natürlich ebenfalls. Da alle diese Aktivitäten durch Steuerregister ausgelöst werden, kann man sowohl den GDP als auch den IRQ der CPU abschalten. Das in Basic geschriebene Beispiel (Bild 3 und Bild 4) zeigt eine beachtliche Zeitersparnis. Hier greift der GDP nicht mehr in den Lauf der CPU ein und auch die Interruptroutine braucht die CPU nicht mehr zu durchlaufen. Beim Sortieren von großen Feldern oder Rechnen mit komplexen Formeln empfiehlt sich diese Methode. Da der GDP abgeschaltet wurde, erscheint jedoch kein Bild. Auch verhindert die gesperrte IRQ-Routine eine Tastaturabfrage.

Alle Vorgänge werden im System durch Signale (Low und High) gesteuert. Der Systemtakt beim C 64 beträgt zirka 980 kHz, das heißt 980 000mal pro Sekunde »passiert etwas« im System. Um verfolgen zu können, wer zu welchem Zeitpunkt was und wo macht, bleibt also wenig Zeit.

Nehmen wir einmal an, daß wir ein Programm im C 64 gestartet haben. Ist es ein Basic-Programm, so können wir im Problemfall ja mit einer Fehlermeldung rechnen, bei einem Assemblerprogramm bekanntlich nicht. Selbst die erfahrensten Assemblerprogrammierer verbringen Stunden mit einem Programmfehler, ohne ihn zu finden. Mit anderen Worten, wenn in diesem Artikel Schreibfehler sind, weiß der Leser meistens trotzdem, was gemeint ist — eine CPU aber verzeiht nicht den kleinsten Fehler. Fehlerbeseitigung in einem Pro gramm ist also eine Frage des Wissens, der Zeit und der Meßmittel. Datenanalyser oder Datenlogger liegen leider preislich ab 20000 Mark aufwärts. Außerdem gibt es für den C 64 keine.

Diese Geräte zeichnen einen Signalverlauf im System auf. Der Adreßbus besteht zum Beispiel aus 16 Leitungen. Will die CPU ein Byte von einer Adresse holen, muß sie auf den 16 Leitungen die entsprechende Binärkombination setzen, um das Byte auf dem Datenbus »serviert« zu bekommen. Dazu muß noch der Baustein selektiert (Chip select) und das Signal R/W gesetzt werden. Der C 64 arbeitet Low-Äktiv, das heißt wenn eine Leitung auf Low ist, ist das Bit gesetzt.

Um auf unser Problem zurückzukommen — wenn wir wissen wollen, was die CPU in Echtzeit bei welcher Adresse was macht, müssen wir diese Signale sichtbar machen. Man könnte ja auch die CPU nach jedem Schritt anhalten, um die Ausführung eines Programms zu überwachen, doch in Echtzeit (bei »echtem« Systemtakt) läuft es dann meistens doch nicht. Die Idee, durch Leuchtdioden die Signale sichtbar zu machen, scheint sehr abwegig. Das menschliche Auge hat ein Auflösungsvermögen von maximal 30 bis 40 Hz. Alle Leuchtdioden würden demnach auf einmal leuchten, und man würde keine Adresse oder Daten erkennen können.

Aber so unglaublich das klingt, genau diese menschliche Schwäche kann man sich beim Bau eines solchen Busmonitors zunutzemachen. Würde man diese Signale weiter ausdecodieren, und die Adresse auf einem Display dezimal oder hexadezimal anzeigen, könnte man in Echtzeit keine Adresse mehr erkennen. Doch zeigt man in Echtzeit den Wechsel zwischen Low und High mit einem Schaltungsstrick an, erkennt man klar, wo die CPU im System »herumläuft«.

Der Busmonitor arbeitet hier im Labor seit mehr als zwei Jahren problemlos. Er zeigt auf einen Blick, wo die CPU im Adreßraum »läuft« und welche Routinen sie benutzt. Außerdem kann er in erweiterter Form anzeigen, an welcher Adresse welches Byte verarbeitet wird.

Natürlich belegen diese Bus-Monitore weder Adreßraum noch sind sie auf Software angewiesen. Denn dadurch würden sie ja einen »normalen« C 64 verändern. Auch sogenannte Geheimbefehle im Assembler bereiten den Monitoren keine Probleme. Hier wird nur angezeigt, was eine CPU immer tun muß: Bei laufendem Systemtakt holt oder bringt die CPU ein Byte und dazu muß sie ja den Adreß- und Datenbus benutzen. Doch davon später mehr.
Der Monitor läßt sich auch gut benutzen zum Erlernen der Maschinensprache, da ein geschriebenes Programm jederzeit über den Monitor verfolgt werden kann. Wer einigermaßen mit dem Lötkolben umgehen kann und eine Investition von zirka 40 Mark nicht scheut, sollte seine Arbeitsmaterialien für unsere »Entdeckungsreisen« in den nächsten Folgen gleich bereitlegen.