Posts by Mike

Ich probier's mal:

Auf dem Desktop liegt ein frisches Verzeichnis mit dem Namen "Patch", da hab ich gerade "patch.prg" aus meinem Post-Attachment im Ursprungsthread und die Datei "basic" aus dem C64-Verzeichnis von VICE hineinkopiert:

In x64 nimmst Du jetzt folgende Einstellungen vor: TDE (True Drive Emulation) aus und Virtual Device Traps ein. Das ermöglicht VICE den Zugriff auf das Host-Dateisystem derart, daß ein PC-Verzeichnis als "Diskette" gemountet werden kann:

Die Autostart-Settings änderst Du nun derart, daß eine in das Hauptfenster von VICE gezogene Datei automatisch das drumherum liegende Verzeichnis als Diskette mountet: "PRG autostart mode: Virtual FS".

Als letzte Vorbereitung nimmst Du noch das Häkchen aus "Write P00 files" heraus. Das macht nur Ärger.

Jetzt ziehst Du einfach "patch.prg" in das Hauptfenster von x64. Das Verzeichnis "Patch" mit "patch.prg" und "basic" drin wird automatisch gemountet und nach kurzer Zeit (die Du gerne mit Settings > Maximum Speed > No Limit verkürzen kannst) steht dann auch die Datei "basic-p" drin:

Nun kopierst Du "basic-p" in das C64 Verzeichnis von VICE:

In "Settings > ROM settings ..." gibst Du den Namen des gepatchten BASIC-ROMs an:

... und nun zum Test. Eine der Multiplikationen zeigt mit dem originalen BASIC-ROM ein falsches Ergebnis an:

"basic-p" eignet sich direkt dazu, auf dem PC in ein passendes EPROM gebrannt zu werden.

Viel Erfolg!

Michael

In den VICE-Directories steht m.W. erst mal nur das originale BASIC-ROM drin, sollte sich das mit einer neueren Version geändert haben? Diese Datei wäre dann aber die, auf die Du den Patch anwenden würdest.

Auf jeden Fall kann man in den Einstellungen auch ein alternatives BASIC-ROM angeben, das "läuft" in meinem emulierten VC-20 und C64 auch immer mit. In meinem echten VC-20 ist es auch in echt drin.

Quote from Etosha

... cool, dass Du den "Römer" erkannt hast ...

Ich war mir schon ziemlich sicher, hab aber TinEye um eine zweite Meinung gebeten.

Salve, Cäsar!

Quote from Etosha

Gefunden hier im Forum habe ich einen Fix als PRG-Datei [...]

Nur rein interessehalber - es handelt sich bei dem Fix nicht zufällig um meinen Patch für die ver-bug-te Fließkomma-Multiplizierroutine?

Das Programm um ein bereits abgespeichertes *.bin-File (also, pure Daten ohne den 2-Byte-Header mit der Ladeadresse) des BASIC-ROMs zu patchen hatte ich ja hier gepostet, nicht aber das bereits gepatchte BASIC-ROM, aus gutem Grund: es gibt nämlich einen aktiven Rechte-Inhaber, der den Daumen auf dem originalen ROM drauf hat.

Du findest das *.bin-File aber in einer aktuellen Fassung von VICE. Mein Patch checkt auch, daß er gerade die richtige Datei bearbeitet.

Viele Grüße,

Michael

Ohne zumindest ein bischen Fachchinesisch auszuhalten wirst Du wohl kaum auf einen grünen Zweig kommen.

Auch wenn Du nicht verraten willst um welches Motiv es sich handelt wäre z.B. interessant wie groß das Bild ist (nicht in KB, sondern Breite und Höhe in Pixeln), damit eingehend das Bildformat (nicht gemeint, welcher Dateityp, sondern Breite-Höhen-Verhältnis). Beim C64 ist die Ausgabe mit 320x200 (oder 160x200 in Multicolor) festgelegt - kennst Du dich mit IrfanView *) genügend gut aus, daß Du einen geeigneten Ausschnitt deines Bildes auf 320x200 bekommst? So, daß das Motiv noch erkennbar ist? Dann: der C64 hat nunmal nur 16 Farben. Ist dein Bild farbig, oder in Graustufen oder gar nur eine Liniengrafik? Von solchen Bedingungen hängt dann ab, wie Du weiter vorgehen mußt. Ein Patentrezept gibt es hier nicht. Die C64-Grafik ist so viel schlechter als alles was ein PC heute kann, daß Du beim 'Runterrechnen' immer Kompromisse eingehen mußt.

Wenn das alles dann mal geklärt ist, gibt es dann schon brauchbare Tools. Die eigentliche Anzeige auf dem C64 ist, sobald die gewandelte Datei vorliegt, ein rein programmiertechnisches Problem - das lösen wir zwischen dem ersten und zweiten Frühstück.

VG,

Michael

*) oder irgendein anderes, auf den PC oder Mac laufendes Bildbearbetungsprogramm

Quote from tokra

Ich würde das so angehen: [...]

Es gibt bei diesem flexiblen BASIC-Stub nur noch ein kleineres Problem in Bezug auf VICE: standardmäßig ist die Load-Option beim Autostart auf LOAD"*",8,1 gesetzt. Heißt, mit dem 'falschen' gesteckten Speicherausbau landet der SYS nur an der Ladeadresse aus dem PRG-File-Header und nicht an dem BASIC-Start, der durch den Speicherausbau vorgegeben ist. Damit findet der RUN-Befehl nichts was er gescheit ausführen kann. Da nutzt also jegliche Programmiertechnik, die relokatiblen Code erzeugt (oder erzeugen kann) einfach mal gar nix.

In der Praxis wird es wohl nur darum gehen, daß man Programme für den nicht erweiterten VC auf robuste Weise ans laufen bringt, obwohl eine Speichererweiterung 'gesteckt' ist und VICE einem zusätzlich Knüppel zwischen die Beine wirft. Der umgekehrte Fall ('großes' PRG auf kleiner Maschine) wird aufgrund des zu erwarteten Speichermangels wohl kaum praxisrelevant sein.

Das folgende Programm schreibt einen Bootloader auf Disk. Wenn dieser Bootloader mit ",8,1" geladen wird, schaltet er vorhandene Speichererweiterungen ab, lädt ein frei wählbares Programm nach und startet es automatisch.

Lädt man ihn (doch) mit ",8", dann sieht man nach LIST so einen BASIC-Stub, wie tokra ihn beschrieben hat. Das dadurch gestartete Maschinenprogramm *ist* relokatibel und startet wiederum den gewünschten Payload mit abgeschalteter Speichererweiterung:

Für den Fall, daß das Nutzprogramm doch eine bestimmte Speichererweiterung braucht, kann ein zuerst nachgeladenes Programm erst einmal testen, ob der Erweiterungspeicher auch existiert, dann den Speicher wieder expandieren und dann das eigentliche Zielprogramm laden und starten.

Viele Grüße,

Michael

Quote from BlondMammuth

Faszinierend. Hätt ich so echt nicht erwartet. Aber da sehen wir wie teuer solche Array-Zugriffe sind.

In einem anderen Thread war M. J. einem ähnlichen Phänomen auf den Grund gegangen. Da war eine mit HYPRA-COMP kompilierte Linienziehroutine nicht so schnell, wie sie hätte sein können, obwohl die Adreßberechnung durch einen Table-Lookup sowohl in BASIC als (grundsätzlich) auch für das Kompilat schon ziemlich eingedampft/optimiert worden war:

Quote from M. J.

Daß Deine kompilierte Version im Vergleich zur VM so langsam ist, kam mir ein wenig komisch vor und ließ mir keine Ruhe, so daß ich der Ursache anhand des laufenden Code in Vice auf den Grund gehen mußte. Dabei stieß ich dann (leider wie erwartet) auf eine starke Bremse: Die Indexberechnung für das Array verwendet die Routine im Basicrom ab $b34c, die eine 16 Bit-Multiplikation beinhaltet. Mit anderen Worten: Für jeden einzelnen Punkt, der gesetzt wird, wird auch eine Multiplikation durchgeführt anstelle eines einfachen Verschiebens der Indexbits. Welch Wunder also, daß die Routine so langsam ist. Hätte der Compiler diese Indexberechnung optimiert, wäre deine Version wesentlich schneller.
Auch aus diesem Grunde wäre es sinnvoll, einen Vergleich mit dem gcc durchzuführen, denn dort sollten derartige Optimierungen eigentlich vorgenommen werden.

Heißt, diese generische 16-Bit-Multiplikation wirkt auch hier als Bremse. Eine spezielle Multiplikation für ein 1D-Array mit 5 (Fließkomma) oder 2 (Integer) Bytes pro Element wäre es gewesen.

Ich hätte noch DIM X%(400),Y%(400) nehmen können, um den Speicherbedarf der Arrays zu verkleinern, aber dann kommen noch mindestens zwei weitere Integer<->Float-Umwandlungen pro Schleifendurchlauf dazu ... und das ist dann noch langsamer:

4) Einlesen mit READX%(T),Y%(T): 254 Jiffies. Zeichnen mit X=X%(T):Y=Y%(T): 3093 Jiffies.

Der erste Teil ist also klar noch mal langsamer (Float->Integer-Wandlung), beim zweiten Teil 'kürzt' sich vermutlich die zusätzliche Integer->Float-Wandlung genau dagegen weg, daß die Multiplikation mit 2 statt mit 5 eine 16-Bit-Teil-Addition weniger braucht.

Quote from BlondMammuth

Liest er dann während des Zeichnens oder erst alle aus und dann erst? Wär interessant, wieviel Overhead das READ verursacht.

Ich hatte das gar nicht in Betracht gezogen, aber gerade ausprobiert. Dazu muß man natürlich alle Koordinaten in zwei großen Feldern mit DIMX(400),Y(400) speichern.

1) Die rekursive Version braucht 5756 Jiffies.

2) Auslesen mit READX,Y während des Zeichnens braucht 3048 Jiffies.

3) Bei deinem Vorschlag schlägt das Einlesen mit READX(T),Y(T) schon mal mit 246 Jiffies zu Buche. Das anschließende Zeichnen, in dem die Koordinaten dann mit X=X(T):Y=Y(T) aus den Arrays übernommen werden, ist dann - unerwarteterweise - mit 3092 Jiffies langsamer! In der Summe, 3338 Jiffies.

Während schon zu erwarten war, daß die Gesamtzeit von 3) mit 3338 über 2) mit 3048 liegt, sind schon die zwei Arrayzugriffe X=X(T):Y=Y(T) teurer als READX,Y mit dem notwendigem Parsen der DATAs in das Fließkommaformat. Das hat mich jetzt schon etwas überrascht.

Zusammen damit, daß bei 3) auch noch die zwei großen Arrays fast 4 KB extra brauchen ohne irgendeinen Vorteil zu bringen, ist 3) damit wohl aus dem Spiel.

Quote from BlondMammuth

Ja klar, aber wär der Teil mit der Parameter-Übergabe in Maschinensprache gelöst (Soft Stack), wär es noch schneller.

Ich habe zum Vergleich auch eine Version geschrieben, welche die Koordinaten aller 400 Voxel einfach aus DATA-Zeilen ausliest. Damit ist der rekursive Overhead zwar komplett eliminiert, aber natürlich zeigt das dann die rekursive Natur des Menger-Schwamms auch nicht mehr. Das bringt etwa den Faktor 2 an Geschwindigkeit.

Quote from BlondMammuth

Ähnliches gilt für parametrisierte Unterprogramme (Prozeduren oder Funktionen, wie man sie halt nennen will). Da könnte man allerdings zu einem Trick greifen, und einfach einen zusätzlichen Software-Stack definieren, auf dem man Parameter übergeben kann. Das wäre dann natürlich ein Zusatz-Aufwand, und langsamer, aber langsamer als was? Langsamer als die üblichen BASIC-Variablen natürlich, aber will man in einem BASIC-Programm heute einen Stack einbauen, muss man sowieso ein Array dafür definieren, und dann hat das noch dazu nur einen festgelegten Typ, und das wäre noch viel langsamer und braucht mehr Programm-Code.

Man siehe mir bitte nach, daß dieses Beispiel für den VC-20 (mit mindestens +8K Speichererweiterung) ist, aber so ein Software-Stack funktioniert verblüffend gut. Es wird ein Menger-Schwamm mit der Iterationstiefe 2 gezeichnet. Mehr gibt die Grafik-Auflösung ohnehin nicht her:

Hier ist das zugehörige BASIC-Programm. Die Grafik läuft über eine eigene BASIC-Erweiterung, MINIGRAFIK:

Die Unterroutine ab Zeile 15 wird mehrfach rekursiv aufgerufen, und die Zeilen 21 und 23 'beackern' den Software-Stack.

Der eigentliche Clou m.M.n. ist allerdings, daß das GOSUB in Zeile 22 tatsächlich als Barriere auf dem CPU-Stack wirkt und die FOR-Schleifen trotz gleicher Variablen-Namen auch erneut angelegt werden! Die ursprüngliche Version hatte die FOR-Schleifen noch händisch mit IF...GOTO nachgebaut, die Version hier ist kürzer, nutzt den CPU-Stack jetzt aber fast zur Gänze aus.

Viele Grüße,

Michael

P.S. hier ist das Original: Heute so gecodet... ...

Quote from Stephan Scheuer

Natürlich, wird der Filetyp #$86 analysiert und die Dateien dann erfasst. Nur die original 1581-Partitionen unterstützt das Tool nicht. Wozu auch? Die werden so selten genutzt, das lohnt sich nicht.

Hier sind zwei Beispiel-*.d81-Images, wo mir die CBM-Partitionen der 1581 geholfen haben, das Hauptverzeichnis einigermaßen aufgeräumt zu halten. Für den VC-20 mit +24K Speichererweiterung.

VG,

Michael

Quote from ogd

Die eleganteste Lösung wäre wie gesagt, die inversen Zeichenmuster dem Videochip per Hardware unterzujubeln. Falls zu kostspielig, weil mindestes ein 8-fach-Inverter erforderlich, die ersten 128 Zeichen ins Ram kopieren und um die zweiten (inversen) 128 Zeichen erweitern. Ist per Software ein Klacks. In beiden Fällen wären 2 KByte Rom für andere Zwecke gewonnen.

Der TED im C16/C116/+4 macht das tatsächlich standardmäßig so, die zweiten 128 Zeichen werden da invertiert aus den ersten 128 'gewonnen'. Ist aber auch abschaltbar - will einen ja keiner zwingen, die zweite Hälfte eines Zeichensatzes immer mit inversen Kopien der ersten Hälfte zu füllen. Dann sind alle 256 Zeichen frei definierbar.

Entsprechend ist das Char-ROM (bzw. dessen Anteil am Gesamt-ROM) auch nur 2 KB groß (Groß+Grafik/Klein+Groß).

Interessanterweise ist der Cursor beim TED ein spezielles Hardwaresprite! Es invertiert blinkend die 8x8-Pixelfläche unter sich - heißt, daß der Cursor immer noch wie erwartet funktioniert, selbst wenn ein voller Zeichensatz mit 256 Zeichen aber ohne Inverse genutzt wird.

...

Die Methode, einen Zeichensatz on-the-fly mit inversen Zeichen im RAM zu konstruieren braucht aber nicht nur den Platz für die Inversen, sondern auch für die Originale - und der Platz im RAM wäre dauerhaft weg, selbst im 'Normalbetrieb' ...

Hallo, Klaus!

Quote from loeffel

Quote from Mike

Im Falle von I.M.L. kann dir geholfen werden:

Hey Michael,

auch nochmal ein dickes Dankeschön an dich direkt, für deine Mühe.

Das ist so cool, mir diese Sachen jetzt nochmal anschauen zu können.

Ich bin echt geflasht und sprachlos.

VIELEN Dank!!!

Display More

Gern geschehen.

Bei anderer Gelegenheit wurde mir hier im Forum64 auch schon mal in ähnlicher Weise geholfen, verlorene Schätze wiederzufinden. Ich war damals längere Zeit dran gewesen, eine Spielesammlung aus Abtipp-Spielen für den nicht-erweiterten VC-20 zusammenzustellen (welche ich schon in den 80ern so zwischen hatte) und zwei Spiele waren nur sehr schwer aufzutreiben. Aber mit der Hilfe hier kam alles zusammen, Details findest Du hier: "Suche Spiel 'Froschfänger' für VC20" und in "Meine Spielesammlung - VC20 - Forum64".

Viele Grüße,

Michael

Untertitel: ... heute so programmiert (würde jedenfalls auch in diese Rubrik passen).

Hier gibt es die originale Version für den C128. Ich hatte die Routine auch schon seinerzeit, um 1991, auf den Archimedes portiert; allerdings noch mit einem "65xx-Mindset" und darum war die dann nicht ganz so schnell wie sie hätte sein können. Aber jetzt:

Selbst auf den langsamsten Archimedes Rechnern mit 'nur' 8 MHz ARM2 Prozessoren läuft die Animation mit 50 Hz im Frame. Durch die Befehle 'MOV R0,#19:SWI "OS_Byte"' wird gewartet, daß der Rasterstrahl in den unteren Rahmen eintritt und das synchronisiert so die Routine mit dem Bildschirmaufbau.

Der verwendete Bildschirmmodus (MODE 9) hat 320x256 Punkte in 16 Farben, genutzt werden allerdings nur die Farben Schwarz und Weiß - aus Hardwaregründen gibt es die gleiche Auflösung nur mit 1 Bit/Pixel nicht auf dem VIDC - dann hätte ich auch LDRB/STRB in der Hauptschleife nutzen können. Es hätte aber geschwindigkeitstechnisch auch keinen Unterschied gemacht.

Die innere Schleife ist 8-fach ausgerollt und vollzieht gleichzeitig den Aufbau der Bitmap beim VIC-II am C64 nach, was schon für den Effekt wesentlich ist. Mit dem Aufruf SYS "OS_ReadVduVariables" holt sich das Programm ganz OS-konform die Startadresse des Bildschirmspeichers.

Geht, funktioniert, und es gilt nach wie vor: Der Effekt ist nichts für Leute, bei denen flackernde Muster epileptische Anfälle auslösen können!

Viele Grüße,

Michael

Hallo, Klaus!

Im Falle von I.M.L. kann dir geholfen werden: dieses Tool hatte ich vor reichlich 10 Jahren mal aus der "Compute Mit 11/85" abgetippt, inclusive dem Demo-Programm, welches den Anfang der Klaviersonate Nr. 16 in C-Dur von Mozart spielt.

Die Compute-Mit-Ausgaben sind alle in der F64 Wolke archiviert, damit Du da Zugang bekommst mußt Du noch ein paar Beiträge schreiben und dich evtl. auch ein paar Tage gedulden.

Bis dahin hab' ich mal I.M.L. (als DATA-Lader und als direkt ausführbares PRG), den DATA-Lader als Text-File, das Demo-Programm und die Anleitung als ZIP angehängt.

Viele Grüße,

Michael

Quote from wizardofOz

Vermutlich ist es mir dann bei sehr kleinen Directories nur nicht immer aufgefallen oder ich habe mich mit dem VC20 vertan, für den load"*",8,1 den Inhalt an die richtige Stelle lädt.

Nö, LOAD"*",8,1 funktioniert bei C64 und VC-20 genau gleich und LOAD"$",8,1 lädt auch beim VC-20 nicht an die 'richtige' Stelle. Ohne Speichererweiterung ist der BASIC-Start bei $1001, mit +8K RAM oder mehr bei $1201. Nur wenn eine +3K-RAM-Erweiterung gesteckt ist, ist der BASIC-Start dann bei $0401 und dann funktioniert LOAD"$",8,1 - aber auch nur weil der BASIC-Start dann zufälligerweise mit dem fixem Wert aus dem CBM DOS übereinstimmt. Natürlich funktioniert LOAD"$",8 auch beim VC-20 immer richtig, egal wo der BASIC-Start ist.

Die noch älteren PET-CBM-Rechner hatten aber, wie Unseen schon schrieb, den BASIC-Start fix bei $0401 und waren gar nicht dazu in der Lage, BASIC-Programme woanders als nach $0401 hin zu laden. Da das Directory aber als BASIC-Programm geladen werden können sollte, mußte es die gleiche Ladeadresse wie 'normale' BASIC-Programme der PET-CBM-Rechner bekommen.

Quote from enthusi

Aber ich denke die Ausgangsfrage ist sehr klar mit 'nein' zu beantworten. Zarch war schließlich ein Showcase was der Archimedes mit reiner CPU Power (statt Blitter etc) kann.

+1

Und am besten ist wohl, man wiederholt diese Aussage auf jeder neuen Seite in diesem Thread.

Ich kann jedem Zweifler nur empfehlen, das Original mal selbst auf einem Archimedes zu spielen - dann spürt man am eigenen Leib, wie vermessen diese Anfrage war.

In Ergänzung zu M.J.'s Beitrag #13 - der Kommentar zum Spieltest in der Happy Computer 4/88, auf Seite 79, spricht eigentlich für sich:

Quote

Zarch und seine Folgen

Ich fahre mit meinem Wagen auf der A9 von München in Richtung Nürnberg. Viele LKWs und der Feierabend-Verkehr machen die Autobahn dicht. Plötzlich drehe ich mich um, damit ich mehr sehen kann, als der Rückspiegel offenbart. Ich war sicher, daß mir eine Zielsuchrakete folgte und mich fast erwischt hätte. Doch da sind nur Autos. Ich sehe wieder nach vorne und suche neben dem Tachometer vergeblich meinen Radarschirm. Aber da ist nichts. Sind meine sämtlichen Radarstationen etwa schon abgeschossen? Die Drone hinter mir feuert mit ihrer Laser-Kanone. Ich reiße mein Steuer hoch...

Ich muß verrückt sein. Auf der A9 gibt es keine Zielsuchraketen und in meinem Auto keinen Radarschirm. Die Drone hinter mir war ein LKW, dem meine Fahrweise aufgefallen ist. Es ist das Spiel, das mich so quält. Zarch auf dem Archimedes hat mich so gefesselt wie kein anderes Spiel zuvor. Ich spiele selten mit meinem Computer und wenn, dann meistens eine gute Partie Schach. Aber da gibt es auch keinen Laser.

Zarch fesselt und wenn man die Steuerung mit der Maus im Griff hat, kann es mitunter schon zu Problemen mit der Steuerung des eigenen PKW kommen.

Einziger Haken bei Zarch: Die Handlung ist etwas geschmacklos und man hätte die Thematik sorgfältiger auswählen sollen. (wo)

Display More

Ich hab' vor kurzem SR auch wieder angestartet. Zu zweit, mit Pilot (Joystick) und Astrogator (Tastatur).

Man kann SR in ca. 12 Stunden durchspielen (aber nur wenn man einem Plan hat, ja) - derweil schippern wir Supercomputer und Erze zwischen Karonus und Gryphon hin und her. Ohne Particle Beam kann man sich ja nicht in die Wildnis wagen.

Eine Investition ins Schiff, die sich allerdings echt nicht lohnt, ist das 75% ECM. Der dreifache Preis ggü. 50% ECM ist übertrieben, außerdem kann man mit etwas Geschick die Raketen auch mit dem Laser abschießen.

P.S. weiß einer von euch, aus welchem Film der Screenshot hier ist?

Das fällt für mich allerdings in die Kategorie 'selbstgemachtes Problem'. Auf den frühen PET-Rechnern stehen in der KERNAL-Sprungtabelle nicht mal SETNAM, SETLFS, OPEN, CLOSE etc. zur Verfügung, die Routinen sind alle noch im BASIC-Interpreter! Die abstrahierte Fassung kam erst mit dem KERNAL im VC-20.

Genaueres findest Du auf der Seite von Michael Steil, pagetable.com, hier: https://www.pagetable.com/?p=926

P.S. zu deinem weiteren Beitrag: ja, mit POKE781,X:SYS65478 kann man die Eingabe auf eine Datei umlenken (und mit SYS65484 wieder zurückstellen) aber da gibt es bessere Anwendungsfälle für, als LOAD mit GET nachzubauen.

Quote from WebFritzi

Ok, und in der Routine muss ich jetzt erstmal zum entsprechenden SYS-Aufruf kommen. Wie komme ich denn da dran?

Wenn im BASIC-Text SYS49152,A steht und ausgeführt wird, dann steht der interne Textzeiger des BASIC-Interpreters (TXTPTR, in der Routine CHRGET ab $0073 - ja, im RAM!) genau auf dem Komma.

Der BASIC-Interpreter hat die 49152 ausgewertet, hinter der "2" ein Zeichen gefunden, das nicht mehr zu einer Zahl gehören kann und führt jetzt erstmal deine Maschinenroutine ab 49152 aus.

Wenn die jetzt nichts besonderes macht und dann mit RTS zurückkehrt, überprüft der Interpreter das Zeichen 'unter' TXTPTR nochmal und findet das Komma. In der Folge gibt's dann einen ?SYNTAX ERROR.

Deine Routine ab 49152 muß also jetzt den Parameter selbst einlesen. Zuerst soll überprüft werden, ob hinter der SYS-Adresse ein Komma steht. Das macht die Routine CHKCOM bei $AEFD. Wenn im BASIC-Text ein Komma steht, wird TXTPTR eins weiter geschoben und JSR $AEFD kehrt einfach zurück. Steht da kein Komma, gibt's wiederum einen Syntax Error.

TXTPTR steht jetzt auf dem ersten Zeichen, von dem wir erwarten, daß es einen numerischen Ausdruck darstellen könnte: es könnte einfach eine Ziffernfolge sein, eine einfache Variable oder ein komplizierterer numerischer Ausdruck. Funktioniert alles. Wenn es sich um einen 8-Bit-Wert handelt, kann die Routine GETBYT bei $B79E den Wert direkt mit JSR $B79E in das X-Register einlesen und von dort kannst Du den Wert im Rest deiner Maschinencode-Routine weiterverarbeiten.

Praktischerweise gibt es für die Kombination CHKCOM+GETBYT eine Routine im BASIC-Interpreter, die beides im einen macht, bei $B7F1. Sie wird von POKE und WAIT benutzt.

Also, mal als Beispiel:

... und mit SYS49152,X setzt Du nun Rahmen- und Hintegrundfarbe gleichzeitig auf den Wert X. Wie gesagt, für X ist eine einfache Zahl, eine numerische Variable oder ein komplizierter numerischer Ausdruck erlaubt.

Wenn diese Routine dann zurückkehrt, steht der Textzeiger auf dem Zeichen hinter dem numerischen Ausdruck, bei einem syntaktisch einwandfreien Programm also entweder auf einem Doppelpunkt oder auf einem Zeilenende (wodurch der Interpreter vor Ausführung des nächsten Befehls erstmal an den Anfang der nächsten Zeile geht).

...

Der SYS57812 im anderen Thread springt nun genau in die Routine im BASIC-Interpreter ein, die die Parameter für LOAD und SAVE auswertet. Die prüft zwischen LOAD/SAVE und dem Dateinamen nicht etwa auf ein Komma ab, und darum kommt hier der Dateiname unmittelbar hinter der SYS-Adresse zu stehen.

...

In weiteren sind genauere Kenntnisse der Abläufe im BASIC-Interpreter und KERNAL schon dringend empfehlenswert. "64 intern" (mit allen bekannten Errata) + AAY64 sind deine Freunde.

Viele Grüße,

Michael