Die Frage hatte ich mir schon vor einem Jahr gestellt. Doch diesmal kündigt sich die Hobby & Elektronik 2012 in Stuttgart tatsächlich mit Paketen an. Wenn wir vom 22. – 25. November in Halle 5 (nicht mehr in Halle 4!) auf dem Stand der CCL vor die Massen treten, die den Stuttgarter MesseHerbst besuchen, dann wollen wir ja nicht mit leeren Händen dastehen. Im Vorfeld haben wir also schon mal die eine oder andere Bestellung aufgegeben und die ersten Exponate sind jetzt eingetroffen.
Hinweis (Nachtrag vom 21.02.2014): Wie sich anhand der Originaldateien (Download von zimmers.net) nachweisen läßt, wurde Pet Tetris nicht 2012 von Elmar Trojer sondern bereits 2010 von Tim Howe programmiert (bitte dazu auch die Kommentare lesen). Dieser Blogbeitrag ist diesbezüglich also als „historisch“ anzusehen. Ansonsten fehlen mir hier erstmal die Worte.
Bereits im Mai diesen Jahres wurde Pet Tetris (Petris), ein Tetris-Clone für den Commodore CBM 3032, veröffentlicht. Autor, Elmar Trojer, hat das Programm mit CC65 erstellt {nachträgliche Anmerkung: erstellt hat es Tim Howe siehe Kommentare}, nachdem er einen CBM 3032 geschenkt bekommen hatte. Wie die nachfolgenden Abbildungen zeigen, ist die Umsetzung grafisch ansprechend gelungen. Warum Tetris nicht bereits zuvor in angemessener Qualität für die PETs dieser Welt verfügbar war, wird wohl ewig ein Rätsel bleiben. Dass zum Zeitpunkt des Erscheinens von Tetris die CBMs bereits ihren Zenit überschritten hatten, kann wohl kaum als ausreichende Erklärung dienen.
Titelbildschirm von Pet Tetris
Wer keinen CBM 3032 sein eigen nennt und Emulatoren nicht mag oder einfach mal sehen will, wie andere Petris spielen, kann sich ein Video dazu anschauen. Wer lieber selber spielt, kann das Programm aus dem Blog des Autors herunterladen (Deeplink: Download) {nachträgliche Anmerkung: der Blog wurde inzwischen gelöscht; siehe Kommentare}.
Die fehlenden Farben wurden durch Raster und Grafikzeichen ersetzt
In der Vergangenheit veröffentlichte Tetris-Versionen für PET- und CBM-Rechner waren entweder einfache BASIC-Programme die allenfalls als Machbarkeitsstudien bezeichnet werden können oder es handelte sich um „Abfallprodukte“ anderer Projekte.
Bedauerlicherweise ist Pet Tetris nur auf einem CBM 3032 mit naturwissenschaftlich/technischer Tastatur lauffähig, die Businesstastatur wird nicht unterstützt. Dass es auf einem PET 2001 nicht funktioniert ist nachvollziehbar, zu groß sind hier die Unterschiede in der Speicherbelegung. Auf einem CBM 4032 startet das Spiel zwar, doch auch hier kommt es zu Problemen. Das Spiel läuft immer im Kleinschrift- anstatt im Grafikzeichensatz und zwischen den Zeilen werden Blankzeilen eingefügt (hier liegt eine Inkompatibilität mit dem CRTC-Chip vor, eventuell funktionieren daher Rechner mit alter 3000er-Platine und einem BASIC 4 Upgrade-ROM, dies konnte ich aber leider nicht testen). Auch die Steuerungstasten funktionieren auf einem 4000er nicht richtig. Das ist sehr bedauerlich, denn der Aufwand, diese Inkompatibilitäten zu beheben hält sich sicher im Rahmen und wäre die Mühe wert.
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:
| Computer | Screen-RAM | Color-RAM | Hintergrundfarbe | Rahmenfarbe |
| PET 2001 | 32768 | – | – | – |
| CBM 3/4/8001 Series | 32768 | – | – | – |
| P 500 / CBM 500 | 53248 | 54272 | 55329 | 55328 |
| C 64 / SX 64 | 1024 | 55296 | 53281 | 53280 |
| C16 / C116 / Plus 4 | 3072 | 2048 | 65301 | 65305 |
| C 128 / C 128 D | 1024 | 55296 | 53281 | 53280 |
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:
| Label | PET 2001 | CBM 3/4/8001 | P 500 | C 64 | Plus 4 | C 128 |
| FA | 241 | 212 | 159 | 186 | 174 | 186 |
| NDX | 525 | 158 | 209 | 198 | 239 | 208 |
| STKEY | 521 | 155 | 169 | 145 | 145 | 145 |
| KEYD | 527 | 623 | 939 | 631 | 1319 | 842 |
| SFDX | 515 | 151 | 205 | 203 | 198 | 212 |
| LSTX | 547 | 166 | 225 | 215 | 2038 | 213 |
| SHFLAG | 516 | 152 | (224) | 653 | 1347 | 211 |
| RPTFLG | – | (228) | – | 650 | 1344 | 2594 |
| PNT | 224/225 | 196/197 | 200/201 | 209/210 | 200/201 | 224/225 |
| PNTR | 226 | 198 | 203 | 211 | 202 | 236 |
| TBLX | 245 | 216 | 202 | 214 | 205 | 235 |
| IIRQ | 537/538 | 144/145 | 768/769 | 788/789 | 788/789 | 788/789 |
| TBUFFR | 634/826 | 634/826 | (1024) | 828 | 819 | 2816 |
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.
Von der gestrigen HomeCon habe ich leider nicht viel mitbekommen. Ich war zwar vor Ort und das auch rechtzeitig, bin zudem recht lang geblieben, aber dummerweise musste ich erst meinen Lieblingsrechner, der auf der Bunkerparty „abgeraucht“ war, reparieren und das hat gedauert. Sehr lange gedauert. Wie sich abschließend herausstellte, war es zudem vergebliche Liebesmüh!
Ich hatte vorsorglich einen ganzen Stapel Commodore 128 D zur HomeCon geschleppt, um für alle Fälle was funktionierendes zur Hand zu haben. Dann startete ich meine „Reparaturversuche“. Da meine Hardwarekenntnisse im Austausch von Sicherungen enden, hatte ich einfach einen Ersatzrechner mit defekter Floppy zum Ausschlachten freigegeben und schraubte daher die von mir als defekt deklarierte Platine aus dem Lieblingsrechner raus und setzte die Platine aus dem Ausschlachtgerät ein. Die prinzipielle Funktionsfähigkeit der Ersatzplatine hatte ich zuvor getestet. Es muss hier angemerkt werden, dass eine C128-Platine mit ziemlich viel Schrauben befestigt ist und man zuvor Laufwerk und Frontblende entfernen muss. Es war also eine mehrstündige Schrauborgie.
Nachdem ich alles wieder zusammengesteckt hatte, vor allem musste ich die spezielle MMU-Platine für die SuperCPU von der „defekten“ Platine abnehmen und in die Ersatzplatine einbauen, kam der Moment der bitteren Wahrheit. Auch mit neuer Platine wollte der Rechner nicht starten. Nach weiteren Stunden von hin- und hergefrickel, Austausch von Komponenten und diversen Tests, musste ich endlich der bitteren Wahrheit ins Gesicht sehen: Ich hätte mir den Platinentausch sparen können! Defekt war nicht die Hauptplatine sonden der MMU-Adapter für die SuperCPU. Ohne diesen (also nur mit MMU betrieben) arbeitete das Gerät tadellos. Dass dieser Adapter, der zweifelsohne das neueste Bauteil im Rechner darstellte, defekt sein könnte, hatte ich wohl nicht wahr haben wollen und daher zuvor einen Test ausgeschlossen. Leider ist die SuperCPU128 ohne MMU-Adapter nicht im C128-Modus funktionsfähig, ich stehe also vor einem echten Problem.
Den Rest der HomeCon habe ich bei all dem Frust nur wie durch einen Schleier mitbekommen. Wie man schon während der Veranstaltung der ausgehängten ersten HomeCon-Zeitung (erstellt auf einem Atari mit Nadeldrucker) entnehmen konnte, wurde wieder (bei nahezu unablässigem Regen) gegrillt. Getränke und Kuchen gab es ebenfalls reichlich.
Im Verlaufe des Tages habe ich gut 40 Teilnehmer aller Altersklassen gezählt. Nach verhaltenem Start wurde der Saal zunehmens voller und voller. In einer Ecke war ein Atari ST-Netzwerk aufgebaut. Wer wollte, konnte seine Mitspieler als Smilies in einem Irrgarten jagen. Die offizielle SpielCompo wurde mit „Castle Crisis“ auf einem Atari 800XL ausgefochten. Aus mir unerfindlichen Gründen habe ich Platz 2 belegt, wo ich bei sowas sonst doch in der ersten Runde ausscheide.
Zu guter Letzt habe ich dann noch meinen Megabit 128 Internal Function-ROM Adapter in den Sockel U36 eingebaut und getestet. Dieses schöne Stück Hardware schlummerte schon einige Zeit völlig zu unrecht ungenutzt in meiner Hardwarekiste und so war die HomeCon auch für mich letztlich nicht nur eine lehrreiche sondern auch eine erfolgreiche Veranstaltung.
Bilder von der HomeCon gibt es im Photoalbum auf C128.Net
Durch reinen Zufall bin ich die Tage über ein Ebay-Angebot für Commodore 128 Case Badge Sticker gestolpert. Verkäufer war Hardware-Shuttle, ein Ebay-Shop für „Commodore Amiga – C64 – Apple & more“.
Ich habe mir gleich mal zwei der Sticker zusenden lassen. Das hat auch problemlos funktioniert (wie man an der Abbildung sieht) . Auch wenn inzwischen (30. Oktober) von den bei Ebay angebotenen Stickern mehr als die Hälfte verkauft wurden, darf man wohl davon ausgehen, dass der Vorrat noch lange nicht erschöpft ist. Auf der Homepage findet man neben dem C128-Sticker auch noch den bekannten Commodore-Sticker (Chickenhead-Logo), mehr als nur eine Variante eines C64-Stickers und einen C128 D-Sticker. Zumindest von letzterem muss ich mir jetzt unbedingt gleich noch ein paar zusenden lassen …
Nachtrag 05.11.2012: Die C128 D-Sticker sind nun auch angekommen, wie man sieht:
Heute traf endlich die heißersehnte RETURN #12 ein. Der ursprünglichen Planung nach sollte sie im August erscheinen und wäre das Sommerheft gewesen. Doch widrige Umstände hatten zu diversen Verzögerungen geführt. Wenn sie letzte Woche eingetroffen wäre, hätte man sie fast noch als Spätsommerausgabe durchgehen lassen können, immerhin lagen die Temperaturen am Wochenende deutlich über 20°C und man trug kurzärmelige Hemden. Doch heute kamen mit der RETURN auch gleich der erste Schnee (nicht nur ein paar winzige Flöckchen) und eisige Temperaturen. Da waren Pullover, Schal und Mütze fast schon Pflicht.
War das letzte Heft dem 40-jährigen Jubiläum Ataris gewidmet, so steht diese Ausgabe ganz im Zeichen des C64. „30 Jahre Commodore 64“ ist auch die Headline der 10-seitigen Titelstory des leitenden Redakteurs Boris Kretzinger (allein dieser Artikel lohnt den Kauf des Magazins). Leider verläßt Boris die Redaktion, wie er im Editorial verlauten läßt, doch neue Kräfte rücken nach.
Mit Interesse gelesen habe ich auch den Bericht über die [connected], der richtig Laune macht, sich mal in den hohen Norden zu begeben. Gefallen hat mir das Artikel-LayOut (entfernt ähnlich den Partyberichten in der LOAD) mit den Bildschnipseln.
Die umfangreichen Artikel zu „Maniac Mansion“ (dazu gibt es auch ein Longplay) und dem neuen C64-Spiel „Soulless“ werde ich mir mal in einer ruhigeren Minute reinziehen, ebenso wie die Heftdisketten, die man wie immer über die Homepage des RETURN-Magazins runterladen kann. Fazit: Ein echtes must have!
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.
| Computer | IRQ | LB (hex) | LB (dez) | RESET | LB (hex) | LB (dez) |
| PET 2001 | $E66B | $6B | 107 | $FD38 | $38 | 056 |
| CBM 3001 | $E61B | $1B | 027 | $FCD1 | $D1 | 209 |
| CBM 4001/8001 | $E442 | $42 | 066 | $FD16 | $16 | 022 |
| P 500 / CBM 500 | $FBE5 | $E5 | 229 | $F99E | $9E | 158 |
| CBM 600 / 700 | $FBD6 | $D6 | 214 | $F997 | $97 | 151 |
| VC 20 | $FF71 | $72 | 114 | $FD22 | $22 | 034 |
| C 64 / C64 SX | $FF48 | $48 | 072 | $FCE2 | $E2 | 226 |
| C 16 / C 116 / Plus 4 | $FCB3 | $B3 | 179 | $FF6F | $F6 | 246 |
| C 128 / C 128 D | $FF17 | $17 | 023 | $FF3D | $3d | 061 |
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:
| 100 rem *** cbm checker a (wte) *** 110 : 120 cbm=peek(65534): pet=0: c$=“commodore “ 130 if peek(1177)=63 then poke1177,62: cbm=peek(65534): poke1177,63 140 rem 2001,3001,4001,p500,cbm600/700,vc20,c64,c16/p4,c128 150 restore:data 107, 27, 66, 229, 214, 114, 72, 179, 23 160 ix=0: for i=1 to 9: read a:if a=cbm then ix=i: i=9 170 next: on ix gosub 240, 260, 280, 340, 360, 380, 400, 420, 440 180 if ix then 460 190 print 200 print „not supported system!“ 210 print „dieser computer wird nicht unterstuetzt!“ 220 end 230 : 240 a$=“2″: goto300 250 : 260 a$=“3″: goto300 270 : 280 a$=chr$(52-(peek(224)=0)*4) 290 : 300 if a$<„4“ then poke59458,peek(59458) or 32:rem killer poke (fast poke) 310 a$=mid$(„pet cbm „,5+(a$=“2″)*4,4)+a$ 320 pet=59468: c$=c$+a$+“001 series“: return 330 : 340 c$=c$+“p500/cbm510″: return 350 : 360 c$=c$+“600/700 series“: return 370 : 380 c$=c$+“vic20/vc20″: return 390 : 400 c$=c$+“64″: return 410 : 420 c$=c$+“c16/c116/plus4″: return 430 : 440 c$=c$+“128″: graphic 0: slow: return 450 : 460 print chr$(147)chr$(142): if pet then poke pet,12 470 print „this program is running on a“ 480 print c$: print 490 print „dieses programm laeuft auf einem“ 500 print c$: print: end |
Variante A der Systemerkennung. Rechnerspezifische Details werden über ON / GOSUB definiert
| 100 rem *** cbm checker b (wte) *** 110 : 120 cbm=peek(65534): c$=“commodore “ 130 if peek(1177)=63 then poke1177,62: cbm=peek(65534): poke1177,63 140 restore 150 rem 2001,3001,4001,p500,cbm600/700,vc20,c64,c16/p4,c128 160 data 107, pet 2001 series, 1, 1, 0 170 data 27, cbm 3001 series, 1, 1, 0 180 data 66, cbm 4001 series, 1, 0, 0 190 data 229, p500/cbm510, 0, 0, 0 200 data 214, 600/700 series, 0, 0, 0 210 data 114, vic20/vc20, 0, 0, 0 220 data 72, 64, 0, 0, 0 230 data 179, c16/c116/plus4, 0, 0, 0 240 data 23, 128, 0, 0, 1 250 : 260 ix=0: for i=1 to 9 270 read a, a$, pet, kp, c128 280 if a=cbm then ix=i: i=9 290 next 300 if ix then 370 310 : 320 print 330 print „not supported system!“ 340 print „dieser computer wird nicht unterstuetzt!“ 350 end 360 : 370 if kp then poke59458,peek(59458) or 32:rem killer poke (fast poke) 380 if kp<>pet then if peek(224)=0 then a$=“cbm 8″+mid$(a$,6) 390 c$=c$+a$: if c128 then graphic 0: slow 400 : 410 print chr$(147)chr$(142): if pet then poke 59468,12 420 print „this program is running on a“ 430 print c$: print 440 print „dieses programm laeuft auf einem“ 450 print c$: print: end |
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.
Ich bin eigentlich kein Freund von „gemoddeten“ Commodore-Rechnern. Die meisten Versuche beleidigen entweder mein ästhetisches Empfinden oder erregen meinen Widerwillen gegen mutwillige Zerstörung von Originalhardware. Wenn jedoch ein umgebauter Rechner ordentlich verarbeitet und gestylt wurde, zolle ich dem gern Respekt.
Was allerdings unlängst im Forum64 der Öffentlichkeit präsentiert wurde, löste eine andere Reaktion aus. Ich musste schnell zum nächsten Spiegel rennen, um zu überprüfen, ob mein Gesicht nicht vielleicht wirklich gelb angelaufen war… aus purem Neid! DerSchatten hatte dort einen mit hoher Präzision gemoddeten Commodore 128 D präsentiert, der nicht nur mir solch starke Emotionen abrang.
Für den C128D SD2IEC/LCD Black Edition! wurde als Basis ein C128 D (kein DCR) verwendet, da dieser für den Einbau eines Parallelspeeders (hier ProfDOS) besser geeignet ist. Der Umbau enthält zusätzlich ein SD2IEC-Interface (Shadowolf-Variante) das an der Front montiert wurde. Dazu musste das Netzteil um einige Zentimeter nach hinten versetzen werden. Verbaut wurden außerdem noch eine DualSID-Platine mit 2x6581R5 und ein 64k VDC RAM Upgrade. Eine schwarze Lackierung (matt) und HIFI-Füße runden die edele Optik ab. Detailliertere Infos, auch zu den Elementen an der Frontseite, finden sich im Originalbeitrag im Forum64, auf dem auch dieser Text beruht.
 |
 |
 |
|
Alle Bilder sind aus dem Beitrag im Forum64. (c) 2012, DerSchatten |
||
Nachdem mit dem DATA-Bug und dem LOAD & PEEK-Problem hier zwei Fälle von unnützem Wissen diskutiert wurden, denen man zumindest noch eine klitzekleine Restnützlichkeit attestieren könnte, kann davon beim heutigen Beitrag keine Rede sein. Man muss hier zum besseren Verständnis vorausschicken, dass es das Commodore-BASIC erlaubt, die BASIC-Befehle bei der Eingabe abzukürzen. Dazu wird der Buchstabe (oft ist es der zweite oder dritte), der dem System eine eindeutige Identifizierung des Kommandos erlaubt, „geSHIFTet“ eingetippt. Im Groß-/Kleinschriftmodus sieht das dann z.B. so aus: lI entspricht LIST; renU entspricht RENUMBER und gO entspricht GOTO.
Angeregt durch die Diskussion um den DATA-Bug, hat Hydrophilic im C128-Forum auf Commodore128.org darauf hingewiesen, dass auch zur GETKEY-Anweisung unnützes Wissen existiert. Im C128 System Guide und auch im deutschen C128 Bedienungshandbuch ist für GETKEY getkE als Abkürzung aufgeführt. Das ist nicht die ganze Wahrheit. Hydrophilic offenbarte eine andere Abkürzung: auch gEkE entspricht GETKEY.
Wie die nebenstehende Abbildung zeigt, hat er recht. Damit gäbe es zwei mögliche Abkürzungen. Man kann aber genausogut behaupten, es gäbe gar keine. Denn für den BASIC-Interpreter existiert der BASIC-Befehl GETKEY überhaupt nicht!
Man kann GETKEY auch als GET KEY schreiben (was die Abkürzung gEkE bzw. gE kE erklärt). Damit besteht eine gewisse Parallele zu GOTO und GO TO; beide Schreibweisen für den Sprungbefehl sind zulässig. Während jedoch GOTO ein eigenständiger Befehl mit eigenem Token ist, für den es auch eine eigene Abkürzung gibt, gibt es kein Token für GETKEY. Für den Interpreter erscheint GETKEY daher als gespaltene Persönlichkeit mit den Namen GET und KEY und wird mit zwei Token codiert. Dabei ist GET eindeutig das dominante Ego, denn die entsprechende BASIC-ROM-Routine (im C128 ab $5612) behandelt KEY einfach als einen Parameter der GET-Anweisung.
Fast eine Woche nach Freigabe des Downloads, kam heute die aktuelle Lotek64 #42 ins Haus geflattert. Vermutlich war die Redaktion (zu Recht!) schwer mit Feiern des 10jährigen Jahrestags beschäftigt, denn das Heft entspricht zwar den allgemeinen (hochgesteckten) Erwartungen, aber für eine Jubiläumsausgabe hätte man sich vielleicht doch etwas mehr erhoffen dürfen.
Aber ich will nicht zuviel meckern, sonst heißt es gleich wieder: „Selber was beitragen!“ (und was sollte man dem entgegenen, außer einem zustimmenden Kopfnicken?). Daher: Happy Birthday Lotek!
 |
Aus dem Inhalt:
|
