Archiv der Kategorie: C64

Unlängst habe ich über Möglichkeiten zur Unterscheidung verschiedener Commodore-Rechner geschrieben. Heute geht es darum, diese Informationen zu nutzen, um Programme entwickeln zu können, die sich unterschiedlicher Hardwarebasis anpassen können. Für die weiteren Beschreibungen beschränke ich mich auf die 8-Bit-Rechner mit 40-Zeichen-Darstellung (PET, CBM, P500, C64, Plus4, C128), da ansonsten der Aufwand für die Anpassung der Bildschirmdarstellung zu groß wäre bzw. die Darstellungsmöglichkeiten zu stark einschränken würden.

Unabhängig von später zu behandelnden Sonderfällen, die durch individuelle Eigenheiten oder spezifische Inkompatibilitäten einzelner Rechnertypen ausgelöst werden, gibt es einige Unterscheidungsmerkmale, die alle (oder zumindest mehrere) Rechner betreffen und die im Programm am Besten über das Vorbelegen einer Variable mit einem jeweils systemspezifischen Wert gelöst werden müssen. Ich nenne das jetzt hier einfach mal eine Systemvariable. Was sich hier kompliziert anhört, wirkt in einem Beispiel ganz simpel und verständlich: Anstatt mit POKE 1024,0 im linken oberen Bildschirmeck eines C64 einen Klammeraffen erscheinen zu lassen, verwendet man eine Variable: P=1024 und einen flexiblen POKE-Befehl: POKE P,0. Durch Anpassen des Werts der Variable P für verschiedene Systeme kann der POKE-Befehl auf allen Rechnern im linken oberen Eck den gewünschten Klammeraffen erzeugen.

Neben dem Basiswert des Bildschirmspeichers könnten auch Werte für I/O-Register als Systemvariable interessant sein, um zum Beispiel die Hintergrund- und Rahmenfarbe festlegen zu können:

Eine weitere Spielwiese ist die Belegung der „Zeropage“. Bei Commodore-Rechnern ist die Besonderheit zu beachten, dass mit dem Begriff Zeropage oft die „erweiterte Zeropage“, also der Bereich bis $03ff (beim C128 sogar bis $12ff), angesprochen wird und nicht nur die Zeropage, wie sie die CPU sieht. Und so soll der Begriff auch hier verstanden werden. Wobei klar sein muss, dass der Begriff „erweiterte Zeropage“ technisch gesehen Unsinn ist. Möglicherweise hat Commodore (oder eigentlich Microsoft) diesen Begriff dadurch provoziert, dass beim ROM-Update vom PET 2001 zu den Rechnern der CBM 3001 Series diverse Kernel- und BASIC-ROM-Variable und -Zeiger aus der Zeropage in den Bereich ab $0200 bis $033a verlegt wurden und umgekehrt. In jedem Fall war ein Begriff für den Gesamtbereich des von Kernel und BASIC benötigten RAM-Speichers erforderlich.

In der (erweiterten) Zeropage finden sich Daten zur zuletzt genutzten Peripherie (Gerätenummer für Nachladeoperationen), zu Tastatureingaben (Tastaturpuffer und Zeiger in den selben), Sprungektoren, z.B. für den IRQ, und vieles mehr. Die nachfolgende Tabelle listet einige dieser Daten in einer synoptischen Darstellung für die hier betrachteten Geräte auf:

FA: Aktuelle Gerätenummer – Diese Adresse ist relevant für alle Programme, die andere Programmteile nachladen. So können Kassetten- und Diskversionen unterschieden werden und das Nachladen erfolgt immer vom richtigen Laufwerk.

NDX: Anzahl der Zeichen im Tastaturpuffer (Warteschlange) – Durch Beschreiben mit dem Wert Null (0) wird der Tastaturpuffer „gelöscht“.

KEYD: Tastaturpuffer – In der Regel umfasst der Tastaturpuffer 10 Zeichen.

STKEY: Flag für STOP-Taste – Bei einigen Rechnern kann hier auch die RVS-Taste abgefragt werden. Prinzipiell stehen die 8 Bits für 8 Tasten. Welche das sind, ist jedoch systemspezifisch (abhängig von der Verdrahtung der Tastaturmatrix); nur die STOP-Taste ist immer dabei.

SFDX: Nummer der augenblicklich gedrückten Taste – In der Regel systemspezifische Indexnummer in die Tastaturdekodiertabelle. Bei CBM-Rechnern mit neuen ROMs, neuem Board und CRTC-Chip (40xx/80xx) ist es allerdings der dekodierte PETSCII-Code. Wer es in VICE testen will, kann dazu den 4032 (neue ROMs) mit dem 4032B (alte ROMs) vergeichen.

LSTX: Nummer der zuletzt gedrückten Taste – Analog zu SFDX.

SHFLAG: Flag für SHIFT-Taste – Neben der SHIFT-Taste werden hier (sofern vorhanden) auch die Tasten CONTROL und COMMODORE durch ein Bit repräsentiert. Beim P 500 beeinflussen auch andere Tasten den Inhalt dieser Speicherzelle.

RPTFLG: Ermöglicht Tastenwiederholung – Dieses Flag bestimmt die Art der Repeatfunktion: $80 = aktiv für alle Tasten, $40 = keine Tasten, $00 nur für Cursorsteuerung. Bei den CBM-Rechnern hat nur der CBM 80xx eine Repeatfunktion. Beim P 500 konnte ich das Flag nicht zweifelsfrei identifizieren.

PNT: Zeiger auf aktuelle Zeile (Text) – Pointer auf den Zeilenanfang.

PNTR: Aktuelle Cursor-Spalte

TBLX: Aktuelle Cursor-Zeile

IIRQ: IRQ-RAM-Vektor – Über diesen Vektor werden eigene Interruptgesteuerte Routinen eingebunden.

TBUFFR: Kassettenpuffer – Immer wieder beliebt für kleine, unterstützende Assemblerroutinen.

Üblicherweise werden nur wenige der hier aufgeführten Systemvariablen in die Systemerkennungsroutine integriert werden. Dafür kommen noch ein paar systemspezifische Systemadressen hinzu, die jeweils nur für ein Rechnersystem relevant sind, um dort Sonderfunktionen auslösen bzw. steuern zu können. Darüber wird allerdings erst im nächsten Teil berichtet.

Der Erste Schritt bei der Multiplattform-Programmierung besteht im Erkennen des Computersystems. Denn bei aller Ähnlichkeit zwischen den Commodore 8-Bit-Rechnern, gibt es doch genügend Unterschiede, die es zu beachten gilt. Zur Unterscheidung sind spezifische und unverwechselbare Kriterien heranzuziehen. Ein Beispiel für eine automatische Rechnererkennung ist die Routine die sauhund im Forum64 gepostet hat.

Wenn man auf Details, wie den RAM-Ausbau beim VC20 oder die Unterscheidung zwischen C16 und Plus4 verzichten kann, geht es aber auch einfacher. Statt diverse Adressen zu prüfen, genügt es, sich auf eine zu beschränken, die bei allen Rechnern unterschiedlich ausfällt aber bei allen ROM-Varianten identisch ist. Eine vertiefende Analyse läßt sich dann in den erforderlichen Fällen noch nachträglich durchführen.

Am Ende des ROMs finden sich gleich zwei geeignete Kandidaten für einen Rechnercheck. Nach meinen bisherigen Recherchen sind IRQ- (Puls) und RESET-Vektor bei jedem Commodore-Rechner unterschiedlich jedoch für verschiedene ROM-Versionen eines Rechners immer identisch. Zur Identifizierung genügt es, das Low-Byte des Vektors zu prüfen. Ich persönlich bevorzuge dabei den IRQ-Vektor, für irgendetwas muss man sich ja mal entscheiden.

Tabelle der Systemvektoren IRQ und RESET für alle Commodore-8-Bit-Rechner

Der IRQ-Vektor liegt bei $FFFE/FFFF, der RESET-Vektor bei $FFFC/FFFD im ROM; wie bei der CPU 6502 üblich im Format LSB/MSB (Low-Byte/High-Byte bzw. LB/HB). Mittels PEEK lässt sich der gewünschte Wert auslesen. PEEK(65534) liefert das Low-Byte des IRQ-Vektors, PEEK(65532) den des RESET-Vektors. Beim Commodore Plus 4 (und C16 / C116) muss zuvor allerdings noch das ROM eingeblendet werden, was einen kleinen schmutzigen Trick erfordert. Man kann ihn in Zeile 130 des nachfolgenden Listings finden:

Variante A der Systemerkennung. Rechnerspezifische Details werden über ON / GOSUB definiert

Variante B der Systemerkennung. Rechnerspezifische Details werden über DATA-Statements definiert

Wer den Quellcode genau studiert, wird feststellen, dass für die Rechner der CBM 8000er Reihe, die den gleichen IRQ-Vektor haben wie die 4000er, eine zusätzliche Detailprüfung implementiert wurde. Über die Speicherstelle $E0 (224) in der Zeropage kann man leicht erkennen, welchen Rechner (8001 Series: 0 / 4001 Series: 128) man vor sich hat.

Beide Varianten der Rechnererkennung haben ihre Vor- und Nachteile und stehen hier nur beispielhaft für zwei Möglichkeiten das Problem anzugehen [die Programme können als Text- und PRG-Dateien (gezippt) für Testzwecke heruntergeladen werden]. Da sich meine Multiplattform-Programme in der Regel auf die Rechner mit 40-Zeichen-Darstellung beschränken, lasse ich in der Praxis die Erkennung von CBM 600/700 und VC 20 „unter den Tisch fallen“ und erkläre sie zu „nicht unterstützten Systemen“. Und natürlich muss der Identifizierung auch eine ausgefeilte Differenzierung folgen (hier angedeutet durch den „Killer-POKE“ und die BASIC 7-Befehle GRAPHIC und SLOW). Doch dazu berichte ich später mehr.

Als der C64 im Jahr 1982 auf den Markt kam, hatte er ein Problem nicht: fehlende Software. Zwei ganz wesentliche Eigenschaften waren dafür verantwortlich: zum einen das Commodore BASIC 2.0, das die sprachbarrierenfreie Übernahme der bereits für ältere Commodore-Rechner (PET 2001, CBM und VC20) geschriebene Programme ermöglichte und zum anderen der über POKE-Befehle direkt beschreibbare Bildschirm mit 25 Zeilen zu 40 Zeichen (dem Format von PET 2001 und CBM 3001/4001 Series). Nahm man von beidem die Schnittmenge, so ergab sich, dass alles was als BASIC-Programm auf einem CBM-Rechner mit 40-Zeichen-Bildschirm lief, mit wenig Aufwand auf einen C64 übertragbar war.

Zwar bot der C64 mit Farbe, Grafik und Sound viele zusätzliche Möglichkeiten und natürlich lagen der Bildschirmspeicher und auch die für BASIC wichtigen Zeropage-Adressen an anderen Stellen im RAM, aber insgesamt war die Umstellung vom CBM auf den C64 nicht problematischer als die vom PET 2001 auf CBM 3001 Series. [Die stellte für Commodore sicher auch keine große Herausvorderung dar, aber ich erinnere mich noch mit Grausen an meine Probleme, denn mir fehlte damals jede Dokumentation.]

Eines der bekanntesten Beipiele für ein umgestelltes Programm ist sicher „FROSCH“ (Original Titel: „Back to Nature„) von der deutschen 1541-Demodiskette [Inhalt und Download]. Wie man an der Spielanleitung noch erkennt, wurde das Spiel ursprünglich für einen CBM-Rechner mit 40-Zeichen-Bildschirm und separatem Ziffernblock geschrieben (Autor: Bob Carr; veröffentlicht im CURSOR Magazine). Außer ein bißchen Farbe hat die C64-Version auch noch ein paar Geräusche bekommen. Doch allein durch einfaches Ändern der in Zeile 0 definierten Bildschirmadresse kann man, mit einigen Abstrichen, das Programm jederzeit auf einem CBM-Rechner ausführen.

Die Portierung von CBM-Programmen auf die Nachfolgegeräte (C64 /C128) hat also eine lange Tradition. Auch von mir gibt es dazu einige vor langer Zeit programmierte Beipiele (Wumpus, Wator). Im Zuge einer 4k BASIC Compo im Forum64 hatte ich mich (im Jahr 2009) des Themas mal wieder angenommen, besaß ich doch noch ein paar simple auf einem CBM 4008 programmierte BASIC-Spielchen auf Diskette, die außer mir noch kein Mensch gespielt hatte. Was lag da also näher, als sich an fertigen Programmen zu bedienen, anstatt sich neue Ideen abzuquälen.

Ich entschied mich damals für die Portierung von „Distichon„. Da noch genügend Bytes verfügbar waren, konnte ich allerdings gleich Nägel mit Köpfen machen und baute das Programm als Multiplattform-Game auf. Neben dem C64 wurden so auch CBM-Rechner (2001, 3001/4001 Series), der CBM 510 (aka P 500) aus der CBM2-Serie und der Plus 4 (C16/C116) bedient. Die bei der Compo noch bestehenden Limitierungen wurden jetzt mit einer Aktualisierung behoben (so dass nun auch die CBM 8001 Serie unterstützt wird).

Ein weiteres BASIC-Spiel (Isola) mit vergleichbarem „Migrationshintergrund“, habe ich für die letztjährigen C128 4kGame Coding Compo erstellt. Vermutlich mangels Teilnehmer ist es aber irgendwie nie zu einer Veröffentlichung der eingereichten Beiträge gekommen. Auch „Isola“ wird zu einem Multiplattform-Game weiterentwickelt. Ähnliches ist auch für das Spiel Canyon-Bomber geplant, das ich für die Compo auf der Bunkerparty 2012 vom CBM 4008 auf C64 portiert hatte (wobei hier zusätzlich einige Assemblerroutinen umzustellen waren).

Langer Rede kurzer Sinn: Im Laufe der Zeit hat sich so einiges an Informationen angesammelt, die es verdienen, hier dokumentiert zu werden. Es soll beleuchtet werden, wie man die einzelnen Rechner identifiziert und welche Besonderheiten zu berücksichtigen sind, wie kompatibel BASIC 2.0 mit sich selber ist, wie zickig sich 40-Zeichen-Bildschirme verhalten können und welche Gemeinheiten sonst noch so lauern. Wenn man all das beachtet, ist es jedoch keine große Kunst mehr ein Programm so aufzusetzen, dass es auf allen 40-Zeichen-Rechnern lauffähig ist.

Teil 1: Identifizieren Sie sich! – Auf welchem Computer läuft mein Programm?
Teil 2: Zeropage, oh, Zeropage – Synopse wichtiger Adressen im RAM
Teil 3: Jedem seine Extrawurst – Das Individuum fordert sein Recht
Teil 4: Immer im Takt – Die CPU (und BASIC): mal schnell, mal langsam
Teil 5: Abwärtskompatibel (zu BASIC 2.0) – Es ist gleich, doch nicht dasselbe
Teil 6: Das vierzigste Zeichen – Wie Fortschritt zum Problem wird

PS: Tokra hat mich darauf aufmerksam gemacht, dass es für den VC 20 einen PET-Simulator mit einer 40-Zeichen-Anzeige gibt. Und natürlich kann auch der VDC im C128 in einen 40-Zeichen-Modus geschaltet werden. Trotzdem werden beide Modi von meinen Multiplatformprogrammen nicht unterstützt. Diese Sonderfälle zu erfassen, würde sicher ein oder zwei Kilobyte zusätzlichen Programmcode erfordern. Da ich die Programme aber so klein halten will, dass sie auch auf einem CBM-Rechner mit nur 8K RAM lauffähig sind, ist das nicht umsetzbar. Was nicht heißen soll, dass es im Einzelfall nicht doch eine Spezialversion für den VDC im C128 geben wird.