Monatsarchive: Januar 2013

Tuning-Tips für den C128

Prolog

Mein letzte Beitrag in der Reihe Multiplattform-Programmierung, beschäftigte sich mit der eigentlich simplen Aussage „verwende anstatt FOR…NEXT lieber zeitgesteuerte Schleifen“. Das ganze artete dann aber zu einer Abhandlung über Geschwindigkeitsunterschiede bei Commodores 8-Bittern aus. Um mich nicht noch weiter zu verzetten, klammerte ich das Thema C128 mit 1,3 MHz, also die Möglichkeit im 40-Zeichenmodus im oberen und unteren Rahmen den Prozessor in den 2 MHz-Modus zu schalten, aus. Das erschien mir dann doch als etwas zu spezifisch und sollte später kurz in einem separaten Beitrag, zusammen mit anderen Möglichkeiten des „Tunig“ beim C128, abgehandelt werden.

Wider erwarten hat sich dieses Thema als noch komplexer erwiesen als vermutet und hat mich die letzten 14 Tage mit Recherche, Programmierung und Austesten beschäftigt. Und noch immer ist kein Ende in Sicht. Heute gibt es daher erstmal nur Vergleichsdaten zu den immer mal wieder empfohlenen Tuning-Methoden. Eine tiefergehende Analyse zum Thema „1,3 MHz“ wird später folgen.

Das Herz des Commodore 128: die CPU MOS 8502
Das Herz des Commodore 128: die CPU MOS 8502 (hier mit Anschlüssen zur SuperCPU)

Speed me up Scotty!

Als Nutzer eines Commodore 128 muss man es zähneknirschend akzeptieren, dass dieser Rechner im 40-Zeichen-Modus unter BASIC geschwindigkeitsmäßig gegen jeden C64 „abstinkt“. Da, wenn der VIC für die Bildschirmanzeige zuständig ist, nur eine Taktrate von 1 MHz gefahren werden kann. Die Gründe sind bekannt: Speicherbankumschaltung, komplexeres BASIC und komplexerer Interrupt für Grafik-, Sprite- und Audiofunktionen. All das fordert seinen Tribut und der ist mit „Taktzyklen“ zu bezahlen.

Um ein paar Prozent Geschwindigkeitssteigerung herauszukitzeln (oder auch nur ein paar Promille), gibt es drei mehr oder weniger allseits bekannte Tricks. Es handelt sich um einen sehr massiven und zwei kleinere Eingriffe in das Interrupt-Geschehen.

Ein paar Promille

Einen Hauch von Geschwindigkeitssteigerung erhält man, wenn man das Grafik-Flag manipuliert. Über die Speicherstelle $D8 (216) wird der jeweilige Grafikmodus definiert. Im Grunde mach der Befehl GRAPHIC nichts anderes, als hier einen, dem jeweils gewählten Grafikmodus entsprechenden Wert einzutragen. Die eigentliche Umschaltung zwischen Text- und Grafikmodus erfolgt dann in der Rastervergleichs-IRQ-Routine ($C194). Schreibt man nach der Wahl des gewünschten Grafikmodus mittels POKE216,255 den HEX-Wert $FF in den Speicher, wird ein Teil dieser Interruptroutine nicht ausgewertet.

Der Beschleunigungseffekt beträgt gut 0,4% oder eben 4 Promille. Wird der Befehl GRAPHIC erneut verwendet, überschreibt er diese Manipulation wieder. Man kann den Trick allerdings nicht mit einem Splitscreen-Grafikmodus (GRAPHIC 2 oder GRAPHIC 4) kombinieren, da der übersprungene Teil der Routine genau diese Funktion steuert.

Wenige Prozente

Etwas massiver und auch geringfügig lohnender ist die komplette Deaktivierung der Interruptsteuerroutine für Grafik und Ton ($A84D), auch BASIC-Interrupt genannt. Hier werden die Spritebewegungen gesteuert, Kollisionen und Photonengriffel (Light Pen) ausgewertet und die Befehle PLAY und SOUND abgearbeitet. Wer eigene SID-Abspielroutinen verwenden will, kommt um die Deaktivierung dieser Funktionen sowieso nicht herum. Das Abschalten erfolgt durch Löschen des zugehörigen Steuerbits (Bit 0) in der Speicherstelle $0A04 (2564). Da der Normalwert $C1 (193) ist, erledigt man das mit einem POKE2564,192.

Der Beschleunigungseffekt dieser Maßnahme beträgt etwa 2,7%. Es ist geradezu erschütternd! Die beiden Effekte sind gleichzeitig einsetzbar und summieren sich zu atemberaubenden 3,2%! Genug der Ironie. Wer wirkliche Beschleunigung sehen will, muss massiver werden.

Der Griff zum Hammer

Die in unserem Land wohl bekannteste Routine zur Beschleunigung findet sich im 64er-Sonderheft 22, Seite 51. Das Progrämmchen heißt „C128-FASTER“ und installiert einen Patch für die Interruptroutine, der im oberen und unteren Rahmenbereich des Bildschirms den 2 MHz-Modus aktiviert. Kleiner Nebeneffekt: durch die Veränderung der Interruptroutine sind Splitscreen-Grafikmodi nicht mehr möglich.

Der Beschleunigungseffekt durch“C128-FASTER“ beträgt 26%, was einer mittleren Taktrate von 1,35 MHz entspricht. Eine Kombination mit dem Promilletrick ist wirkungslos, da die Grafikmodeumschaltung in etwas abgespeckter Form jetzt Teil des Patchs geworden ist. Der Prozenttrick wirkt jedoch auch hier additiv. Der „Speedfaktor“ liegt dann bei fast 28%, was einer gefühlten Taktrate von 1,38 MHz entspricht.

Epilog

Tuning Methode Umsetzung Effekt Anmerkung
Raster-IRQ verkürzen POKE216,255 0,4 % Splitscreen-Grafik nicht mehr möglich
BASIC-Interrupt aus POKE2564,192 2,7 % Kein SPRITE, PLAY und SOUND
2 MHz im Rahmen an “C128-FASTER” 26 % Splitscreen-Grafik nicht mehr möglich

Mit der Beschleunigung im oberen und unteren Bildschirmrahmen auf 2 MHz erreicht der C128 unter BASIC (und im 40-Zeichen-Modus) eine Verarbeitungsgeschwindigkeit, die gerade mal so der des C64 entspricht. Allerdings ist nur BASIC so massiv von der Komplexität des C128 betroffen. Programme in Assembler, die eigene Interruptroutinen ein- und das BASIC-ROM ausblenden, können die Geschwindigkeitsvorteile des „1,3 MHz-Modus“ hingegen voll ausspielen.

Veröffentlicht unter C128, Soft | Hinterlasse einen Kommentar

HomeCon XX (Terminplanung 2013)

Am 19. Januar, also schon morgen, findet wieder eine HomeCon statt.

HomeCon-Logo Halloween

Anmeldung wie immer unter: http://homecon.net/index.php/anmeldung
Detailinformationen zur Veranstaltung gibt es im HomeCon-Board des Forum64.

Termin der 20. HomeCon:
Samstag, den 19.01.2013 ab 10:00 Uhr
Alte Schule Grossauheim
Taubengasse 3 (Eingang Haggasse)
63457 Hanau-Grossauheim

Weitere Termine sind: 9. März und 11.+12. Mai, 10. August, 28. September, 30. November 2013.

Veröffentlicht unter Events | Hinterlasse einen Kommentar

Oil’s Well (PET/CBM)

Mr. NOP hat heute im Commodore PET Alive! Forum ein neues PET Spiel veröffentlicht. Wie er selber meint: wohl 20 Jahre zu spät, um große Verbreitung zu finden. Das Spiel heißt OIL’S WELL und kann im Forum heruntergeladen werden (Anmeldung erforderlich). Das Spielprinzip ist bekannt, man bohrt sich in die Erde und muss dabei das Öl (kleine Punkte) fördern. Seltsame Kreaturen im Untergrund stören dabei. Trifft man sie mit dem Bohrkopf, werden sie zerstört, doch beißen sie in das Kabel, muss man die Bohrung abbrechen. Wurde alles Öl gefördert kommt der nächste Level. Das Spiel ist komplett in Assembler geschrieben und es existieren Versionen für den PET 2001, den CBM 3032 und den CBM 4032.

Oil’s Well Bohrung
Tief unter der Erde gibt es seltsame Kreaturen …

Da ich ein fauler Mensch bin, habe ich zum Testen das Originaldiskimage mit der Maus in den VICE-Emulator gezogen. Das erste Programm von der Disk startete automatisch und stürzte ab. Kein Wunder, habe ich doch standardmäßig den CBM 4032 eingestellt und das erste Programm ist für den PET 2001. Das schrie geradezu nach einer automatischen Systemerkennung und einem Einsatz für meinen CBM Checker. Es hat mich den halben Sonntag gekostet, das umzusetzen.

Oil’s Well Startprogramm
Das Startprogramm basiert auf dem CBM Checker

Das neue Startprogramm (bitte jetzt keine unflätigen Kommentare zu meinen begrenzten Fähigkeiten als Art-Designer) prüft nun den Rechnertyp und lädt die korrekte Programmversion nach. Als Dreingabe habe ich das Programm „CBM4032 ANY HZ“ von Wolfgang Guenther eingebaut und daher kann man Oil’s Well jetzt auch auf einem echten CBM 8032 spielen (die Emulation in VICE funktioniert diesbezüglich immer noch nicht richtig). Die neue Programmdiskette kann man direkt hier runterladen.

Veröffentlicht unter CBM, Soft | 3 Kommentare

NAV: File-Browser für C64

Das Research Center for Advanced Commodore Study (dahinter verbirgt sich das Blog von Alan Reed) präsentierte vor zwei Tagen NAV, einen File-Browser für den C64, der speziell zur Navigation auf Geräten mit modernen Speichermedien wie SD-Karten konzipiert wurde. Neben Geräten wie dem uIEC und SD2IEC werden auch das IDE64 und natürlich echte Commodore-Laufwerke unterstützt. Der folgende Text ist eine sinngemäße Übersetzung von Alans Originalpostings.


Ich freue mich, NAV präsentieren zu können, einen neuen File-Browser für den C64. NAV kann mit einer Maus in Port 1, einem Joystick in Port 2, oder mit der Tastatur gesteuert werden. NAV arbeitet mit bis zu fünf Laufwerken und wurde mit folgenden Laufwerkstypen getestet: 1541, 1571, 1581, uIEC, IDE64

Jeder Laufwerkstyp hat sein eigenes spezifisches Icon.

Mit einfachem Mausklick blättert man durch Inhaltsverzeichnisse und Laufwerke. Geräte wie das uIEC, die Gigabytes an Software enthalten können, nach bestimmten Daten zu durchsuchen, kann nervtötend und sehr frustrierend sein. NAV erlaubt das einfache Arbeiten mit D64/D71/D81/DNP/M2I-Disk-Images, echten Commodore Disketten und dem IDE64. Und das mit bis zu 5 Laufwerken gleichzeitig!

Zum Browsen einfach auf das Laufwerk-Icon klicken!

Ein Druck auf die @-Taste läßt die Kommandozeile erscheinen, die genau wie das gute alte DOS Wedge funktioniert. Es wurden jedoch ein paar zusätzliche Kommandos implementiert. Mit „@HELP“ kann man sich die komplette Liste der Kommandos anzeigen lassen.

NAV findet man auf CommodoreServer.com unter ‚Public Disks‚, im Verzeichnis ‚Utilities/Disk Tools‚. Man kann es aber auch HIER herunterladen.


Posted By: HowlinAl in Blog Research Center for Advanced Commodore Study
Published: Thursday, January 10, 2013

Nachtrag (29.01.2012):
Inzwischen ist auf CommodoreServer die Version 9.2 erhältlich.
Alternativer Download vom Nightfall Blog.

Nachtrag (06.11.2013):
Die Version 9.6 (vom Februar 2013) scheint die bisher letzte zu sein.

Veröffentlicht unter C64, Soft | 14 Kommentare

Einzeiler (update)

Auf Commodore128.org wurden gestern Neuigkeiten zur “One Liners Competition” veröffentlicht. Leider wurde dabei das ursprüngliche Posting gelöscht, so dass der Link in meinem ersten Blog-Beitrag zu diesem Thema ungültig wurde. Der offizielle Start der Competition wird voraussichtlich in der nächsten Ausgabe der Commodore Free bekannt gegeben. Einsendeschluß für Beiträge soll Freitag, 8. März sein.

Die erlaubte Programmzeilenlänge ist nicht auf die von den jeweiligen Bildschirmeditoren direkt unterstützte Länge von 80 bzw. 160 Zeichen begrenzt; tricksen ist durchaus zulässig. In den Speicher gepokter und mit SYS gestarteter Maschinencode wird ebenfalls akzeptiert, reine Assemblerprogramme jedoch nicht. Beispiele kann man sich auf der jetzt als Diskimage veröffentlichten Beispieldiskette ansehen, die ich der Einfachheit halber hier als gezipptes File bereitstelle.

Muster vom Cover des Buchs: “10 PRINT CHR$(205.5+RND(1)); : GOTO 10″

Veröffentlicht unter C128, C64, CBM, Compo | Hinterlasse einen Kommentar

MPP4: Immer im Takt

Schneller, höher, weiter, lautet die Maxime im Sport. Schneller, bunter, klangvoller, könnte man das auf Computer übertragen. Für die Multiplattform-Programmierung kann sich das allerdings als (kleines) Problem erweisen, z.B. wenn man mit einfachen FOR-NEXT-Warteschleifen arbeitet. Der heutige Beitrag in dieser Reihe widmet sich dem „schneller“, wobei man sich in einem Irrtum befindet, wenn man meint, dass neuere 8-Bit-Rechner schneller als ältere gewesen sein müssen, und dem „Schleifenproblem“ (was uns wieder mit den spezifischen Eigenheiten der Rechner konfrontieren wird).

Die CPU: mal schnell, mal langsam

Grundsätzlich wird die Rechengeschwindigkeit durch den Takt des Prozessors (der CPU) bestimmt. Der ist je nach Rechnertyp mal schneller, mal langsamer. Vom C64 weiß man, dass schon zwischen einem NTSC- und einem PAL-Gerät merkliche Unterschiede bestehen. Ein Plus/4 taktet (scheinbar) schneller, ein C128 (ohne VIC-Bildschirmanzeige) ebenfalls. Doch der CPU-Takt ist nur die halbe Wahrheit und manchmal führt er uns auch an der Nase herum.

Tabelle 1: Vergleich der CPU-Taktraten der Commodore-Rechner:

Computer PET/CBM VC 20 P 500 C 64 Plus/4 C 128 1MHz C 128 2MHz
PAL 1 MHz 1,10 MHz 0,98 MHz 0,98 MHz 1,76 MHz 0,98 MHz 1,97 MHz
NTSC 1 MHz 1,02 MHz 1,02 MHz 1,02 MHz 1,79 MHz 1,02 MHz 2,04 MHz

Anmerkungen:
PET/CBM: der Takt ist unabhängig vom Videochip und daher gibt es kein PAL oder NTSC.
VC 20
: Kein Fehler! Die PAL-Version ist schneller.
P 500
: Die verfügbaren Quellen sprechen alle nur von 1 MHz; da jedoch ein VIC II verbaut wurde, ist zu vermuten, dass die gleichen Werte wie für den C64 gelten.
Plus/4: Die hohe Taktrate (hier gibt es aus unterschiedlichen Quellen leicht variierende Angaben) führt in die Irre. Im sichtbaren Bereich des Bildschirms wird auf halbe Taktrate zurückgeschaltet, da TED und CPU sich den Systemtakt teilen müssen. Die effektive mittlere Taktrate liegt wohl irgendwo bei 1 MHz. Wegen unterschiedlicher Anzahl von Bildern/Sekunde zeigt die mittlere Taktrate eine weitere Abhängigkeit von der jeweiligen Videonorm (PAL/NTSC).

BASIC: weniger ist manchmal mehr

Bei Multiplattform-Programmen ist die Geschwindigkeit des BASICs entscheidend. Diese ist von zusätzlichen Faktoren abhängig, die sich durchaus stärker als die Variatonen in der Taktrate auswirken können. Zum einen spielt die Komplexität des Interpreters eine gewichtige Rolle. Ein mächtigeres BASIC (wie beim C128 BASIC 7.0) verlangsamt die Ausführung, spezielle Implementierungen von Grundfunktionen wie die verbesserte Garbage Collection ab BASIC 4.0 beschleunigt Programme mit vielen Stringoperationen. Zum anderen spielt die Komplexität der Hardware eine Rolle. Beim C64 braucht sich der Interpreter nicht groß mit Bankswitching herumzuschlagen, beim C128 hat das jedoch durchaus einen spürbareren Einfluss. Auch beim P500 wirkt sich das komplizierte Bankswitching geschwindigkeitshemmend aus.

Für einen Praxistest verwenden wir folgendes Programm:

10 t1=ti:fori=1to10000:next:t2=ti
20 print (t2-t1)/60"sekunden"

Zur Erinnerung: Die reservierte Variable TI gibt die Zeit in sechzigstel Sekunden (1/60) an. Der Zähler für TI wird initialisiert (auf Null gesetzt), wenn der Rechner startet und auch jedesmal wenn man die Anweisung TI$="000000" ausführt. TI$ gibt die seit dem letzten Initialisieren vergangene Zeit in Stunden, Minuten und Sekunden an („hhmmss“).

Mir ist klar, dass eine einfache Schleife nicht die ganze Wahrheit über die Leistungsfähigkeit eines Rechners offenbart. Es handelt sich mit Absicht um einen simplen Vergleich. Ich tröste mich damit, dass er auf jeden Fall besser ist als ein Vergleich mit PRINT-Operationen, da dabei die zusätzlichen Berechnungen für das Setzen des Farbrams die Ergebnisse einseitig beeinflussen würden.

In Ermangelung der erforderlichen Hardwarevielfalt wurden alle Messungen mit dem Emulator VICE unter Win98 durchgeführt. Daher sind die Angaben mit Vorsicht zu genießen. Zudem zeigten sich in Einzelfällen Probleme mit dem Emulator, die einen eigenen Artikel wert sind.

Tabelle 2 und 3: Zeitverbrauch der FOR-NEXT-Schleife mit 10.000 Durchläufen:

Computer PET 2001 CBM 3032 CBM 4032 B CBM 4032 CBM 8032
Dauer [Sekunden] 9,25 s 9,22 s 9,45 s 10,83 s 11,40 s

Anmerkung: Die Messungen für PET 2001 und CBM 3032 mussten mit VICE 2.2 statt der aktuellen Version 2.4 durchgeführt werden, da VICE 2.4 bei diesen Rechnern eine Bildwiederholrate von 56 fps statt 50 fps anzeigt und folglich andere Berechnungszeiten als VICE 2.2 liefert.

Computer P 500 VC 20 C 64 Plus/4 C 128 (2 MHz)
PAL 15,4 s 9,38 s 11,20 s 13,55 s 15,92 s (7,62 s)
NTSC 10,20 s 10,87 s 17,98 s 15,52 s (7,33 s)

Anmerkung: Für den P 500 sind derzeit keine Angaben zu NTSC möglich, da die Umstellung auf NTSC unter VICE 2.4 dazu führt, dass der Emulator nur noch mit 87%iger Geschwindigkeit läuft, dies beeinträchtigt die Messung. Unter VICE 2.2 ist im Menü keine Auswahl zwischen PAL und NTSC vorhanden. Beim Plus/4 ist deutlich der Effekt der Videonorm zu erkennen. Durch die höhere Bildfrequenz (60 Hz) unter NTSC wirkt sich der Bremseffekt des TED stärker aus als unter PAL (50 Hz). Beim C128 ist zum Vergleich zusätzlich der Wert für den 2 MHz-Modus in Klammern angegeben.

Für Experten sei noch angemerkt, dass der C128 auch im 40-Zeichen-Modus mit ein paar Tricks auf ca. 1,3 MHz beschleunigt werden kann. Die Schleife braucht dann ca. 11,74 s (PAL). Man kann auch noch den BASIC-IRQ deaktivieren und weitere Millisekunden gewinnen, Aber das alles bringt den C128 nur in die Nähe der Geschwindigkeit eines C64.

Kurze Zwischenbilanz: Komplexität und verrotztes Design (Plus/4) lassen die neueren Rechner gegenüber den alten CBMs alt aussehen. Hier gilt: weniger ist mehr. Die Unterschiede in der Effektivgeschwindigkeit sind erheblich. Blinkeffekte oder Anzeigezeiten für Info-Texte sollte man daher nicht mit einer einfachen FOR-NEXT-Schleife lösen!

Der Turbo: schlimmer geht immer

Wer jetzt noch meint, man könne diese „leichten“ Variationen in der Geschwindigkeit ignorieren, der sollte bedenken, dass es noch andere Gründe gibt, es nicht zu tun. Die passenden Stichworte sind SuperCPU, Chameleon im Turbo-Mode und BASIC-Compiler!

Die Zeit: ein steter Fluss

Die Lösung des Warteschleifenproblems ist simpel (oder auch nicht, wie wir später sehen werden) und nicht neu! BASIC 2.0 liefert uns seit seinen Anfängen das Werkzeug, das wir dazu brauchen: TI

Beispiel 1: Eine simple Warteschleife, wie sie vielleicht für einen Blinkeffekt genutzt werden könnte:
for i=1 to 1000 : next i

Auf einem C64 erhalten wir eine Verzögerung von ca. einer Sekunde. Der C128 benötigt für die gleiche Schleife allerdings gute 1,5 Sekunden. Derartige Abweichungen sind, vorsichig ausgedrückt: „unschön“.

Immer exakt eine Sekunde liefert hingegen dieses Programmschnipsel:
10000 t=ti+59:fori=0to1:i=-(ti>t):next:return

Man kann das auch so schreiben:
10000 t=ti+60:fori=0to1:i=-(ti=>t):next:return

So geht’s noch eleganter:
10000 t=ti+60:fori=-1to0:i=ti<t:next:return

Für einen relativen Vergleich der Rechnergeschwindigkeiten kann man ermitteln, wie häufig eine Schleife durchlaufen wird. Dazu baut man einen Zähler ein. Integriert man weitere Elemente in die Schleife kann man so auch die verbleibenden Ressourcen abschätzen. Zur Demonstration mag sich die simple Schleife selbst genügen. Die nachstehende Tabelle basiert auf folgendem Programm:

10 x=0:t1=ti:t=ti+60:fori=-1to0:i=ti<t:x=x+1:next:t2=ti
20 print (t2-t1)/60"sekunden", x"loops"

Computer CBM 3032 CBM 4032 VC 20 C64 Plus/4 (NTSC) C128 (2 MHz)
Schleifen-durchläufe 162 140 157 131 124 (96) 102 (212)

Anmerkung: Die Zahlen gelten bei den farbfähigen Computern für die PAL-Geräte. Zum Vergleich ist beim Plus/4 zusätzlich der Wert für NTSC, beim C128 der für den 2 MHz-Modus, in Klammern angegeben.

Beispiel 2: Eine Warteschleife mit Abbruchoption, wie sie vielleicht für die Anzeige von Infotexten genutzt werden könnte. Das folgende Unterprogramm kombiniert elegant Zeitschleife und Tastaturabfrage:

10000 rem 10 sekunden textanzeige (weiter mit <taste>)
10010 t=ti+600:fori=-1to0:getg$:i=(ti<t)and(g$=""):next:return

Über TI läßt sich auch bei Spielen der zeitliche Verlauf steuern, indem (z.B.) Unterprogramme (nur) alle halbe Sekunde angesprungen werden und nicht, abhängig von anderen Operationen und dem jeweiligen Rechnertyp, häufiger. Der Schwierigkeitsgrad des Programms ist dann plattformunabhängig gleich. Wobei man zugeben muss: gleich schwach, denn der schwächste Rechner bestimmt dann das zulässige Tempo. Was nerven kann, wenn es sich um interpretiertes BASIC handelt.

Beabsichtigt man hingegen, die Programme zu compilieren (danach ist das jeweils compilierte Programm natürlich wieder systemspezifisch, aber man braucht es nur in einer Version zu pflegen), dann ist ein TI-gesteuertes Programm oft die einzige Möglichkeit es überhaupt noch spielen zu können.

Der Frust: Commodore ist eben Commodore!

Commodore wäre nicht Commodere, wenn sie nicht wieder die simpelsten Grundregeln mißachtet und Blödsinn fabriziert hätten. Zum Thema TI/TI$ muss es daher heißen: Achtung Falle! Man mag es sich nicht vorstellen, was in den Knallköpfen damals vorgegangen sein muss, als man sich entschloß die CBM II-Reihe mit einem BASIC auszustatten, dass die Systemvariable TI (TIME) nicht mehr kennt.

Zwar zeigt der P 500 ein BASIC 4.0 an (es ist allerdings Version 4.7), das zu BASIC 2.0 abwärtskompatibel sein soll, doch hilft das wenig. TI ist nicht verwendbar und TI$ (TIME$) erhielt (wohl als schwachen Ersatz) einen veränderten Wertebereich. Was die Sache noch schlimmer macht. In BASIC 2.0 ist TI$ sechsstellig (ti$=“000000″) im Format „hhmmss“ (Stunden, Minuten, Sekunden). Bei BASIC 4.7 kommt eine siebte Stelle hinzu. Diese steht für Zehntel Sekunden. Kürzere Zeiteinheiten sind in BASIC nicht mehr erfassbar.

Bei der im Abschnitt „BASIC: weniger ist manchmal mehr“ in Tabelle 3 angegebenen Rechenzeit habe ich daher gemogelt. Statt des oben angegebenen Programms habe ich das folgende verwenden müssen (und folgerichtig habe ich keine zweite Nachkommastelle angegeben, denn es gab hier nichts zu Runden):

10 ti$="0000000":fori=1to10000:next:t$=ti$
20 print val(right$(t$,3))/10+val(mid$(t$,3,2))*60"sekunden"

Doch was bedeutet das für die Multiplattform-Programmierung? Man muss entweder auf den hübschen TI-Trick verzichten, für den P 500 eine alternative „Schleife“ auf Basis von TI$ entwickeln oder den P 500 aus dem Kreis der unterstützten Rechner ausschließen (da waren’s nur noch vier: PET/CBM, C64, Plus/4, C128). Beim Verbreitungsgrad des P 500 fällt da im Zweifel die Entscheidung leicht. Doch ein Gutes hat die Sache: Spötter können die CBM II-Reihe jetzt als zweifelsfrei „zeitlos“ titulieren – und in Anbetracht des Designs, wäre in diesem Spruch sogar noch eine zweite Wahrheit verborgen.

Nachdem sich, sozusagen als Nebenprodukt dieses Beitrags, die erste der bereits angekündigten bösen Überraschungen offenbart hat, mag man erahnen, dass im nächten Teil weiteres Ungemach droht, wenn wir uns intensiver mit der Kompatibilität bezüglich BASIC 2.0 beschäftigen werden.

Veröffentlicht unter C128, C64, CBM, Soft | Hinterlasse einen Kommentar