Hello, Guest the thread was called1.6k times and contains 32 replays

last post from goloMAK at the

GIST BASIC - meine kleine Freiheit! :)

  • Ich fand BASIC-Erweiterungen immer sehr interessant, aber schwer zu schreiben! Die Vorbilder, die ich fand, waren entweder gar nicht kommentiert oder nur sehr spärlich. Außerdem arbeiteten viele ohne Tokenizer, sodass mein armer C64 die Befehle bei der Ausführung immer im Klartext abklappern musste. Das wollte ich nicht!


    Ich wollte eine BASIC-Erweiterung:

    * mit (möglichst) verständlichem Source-Code

    * mit einem anständigen Tokenizer

    * mit (möglichst) leichter Erweiterbarkeit


    Ich bin kein Profi mit 20 Jahren Hacker-Erfahrung, sondern nur ein kleiner Hobby-Programmierer. Insgesamt habe ich mich vielleicht ein gutes Jahr mit Maschinensprache beschäftigt. Aber ich habe mir immer gesagt: Wenn ich mal eine solche Erweiterung fertig habe, dann haue ich sie raus. Vielleicht bringt sie ja anderen etwas.


    Ein gewisses Aha-Erlebnis brachte dann das Buch von Riemenschneider: "Alles über Maschinensprache". Das hat gewissermaßen das Eis gebrochen.


    Jetzt habe ich etwas fertig: "GIST BASIC". Der Name ist Programm. :) Ich habe wirklich nur das aus meiner Sicht Nötigste eingebaut.


    Der Source-Code wurde mit dem C64 Studio erstellt. Start mit "SYS 49152"!


    Die Erweiterung läuft meines Wissens ohne echte Bugs, kann aber sicher noch an etlichen Stellen verbessert werden!


    Also, falls gewünscht: Viel Spaß mit Programm und/oder Source-Code. :)


    Zum Abschluss zitiere ich noch ein paar Infos aus dem source file:


  • Coole Sache, gefaällt mir.


    Schade dass die Anzahl der BASIC Token so beschränkt ist.

    Sonst könnte man, die passende Modul Hardware vorausgesetzt, beliebig viele Befehle hinzu fügen.

    Das Modul müsste natürlich banking beherrschen und sich unsichtbar machen können.

    So hätte man dann die ganzen 38K RAM für BASIC und auch die üblichen Bereiche ($C000) wieder frei.


    Theoretisch, wenn es flexibel gemacht ist, könnte man ein oder mehrere Befehle als Modul sehen.

    Die Befehlserweiterung Module könnte man automatisiert zusammen stellen.

    Jeder könnte sich dann "sein persönliches" BASIC zusammenstellen.

  • Fürs Zusammenstellen von Befehlen gabs in der 64er "Hypra-Basic", mit dem sich Fragmente zusammenstückeln ließen. Ne zeitlang gabs alle paar Hefte eine handvoll neuer Befehle zum Eintippen.

  • Schade dass die Anzahl der BASIC Token so beschränkt ist.

    Dafür kann man ja einen "Shift-Token" benutzen, der dann zwei-Byte-Token erzeugt.
    Hat doch selbst Commodore so gemacht, IIRC.


    Also, falls gewünscht: Viel Spaß mit Programm und/oder Source-Code. :)

    Ich habe kurz reingeschaut. Darf ich mal kurz einen Verbesserungsvorschlag machen?

    Wieso der Aufwand? Wieso definierst du hightab und lowtab nicht direkt?


    Ich kenne den Assembler jetzt nicht, aber etwas in der Art

    Code
    1. ; === Tabelle mit Startadressen der Befehle
    2. hightab:
    3. !byte >(cmd0-1), >(cmd1-1), >(cmd2-1), >(cmd3-1), >(cmd4-1), >(cmd5-1), >(cmd6-1), >(cmd7-1)
    4. lowtab:
    5. !byte <(cmd0-1), <(cmd1-1), <(cmd2-1), <(cmd3-1), <(cmd4-1), <(cmd5-1), <(cmd6-1), <(cmd7-1)

    (die Syntax könnte abweichen)

    sollte doch auch tun und spart die ganze pointcmd-Funktion sowie die Aufrufe.

  • Leider kann ich Maschienensprache so gar nicht.

    Müsste ich mich mal ranwagen.

    Das Buch von Riemenschneider wäre Deine Empfehlung?

    Also, angefangen habe ich mit 64er-Sonderheften (insbesondere Nr. 35). Und dem Einführungsbuch von Data Becker (Das Maschinensprache-Buch zum C64 & C128).


    Das Riemenschneider-Buch ist in meinen Augen insgesamt etwas anspruchsvoller, deswegen bin ich erst später dazu gekommen.


    Sehr wichtig war mich auch: "Mapping the Commodore 64" aus dem Compute-Verlag.


    Aber es gibt glaube ich hier im Forum auch diverse gute Threads, wo Tipps zu Literatur ausgetauscht werden.

  • Schade dass die Anzahl der BASIC Token so beschränkt ist.

    Sonst könnte man, die passende Modul Hardware vorausgesetzt, beliebig viele Befehle hinzu fügen.

    Frank Riemenschneider schreibt dazu:


    "Die meisten Erweiterungen, wie z.B. Simons Basic, benutzen die 2-Byte-Token-Methode. Zunächst wird jedem Erweiterungsbefehl ein sogenanntes Erkennungstoken vorangestellt, das [...] den Befehl als Erweiterung kennzeichnet. Erst dann folgt das eigentliche Token für den Befehl. Damit kann man alle möglichen Codes von 0 bis 255 für seine Befehle benutzen."


    Wobei ich nicht weiß, ob das wirklich "die meisten" Erweiterungen so machen. Vielleicht eher die bekanntesten. :)


    Das Prinzip könnte man natürlich fortspinnen, mit einem 2-bytigen Erkennungstoken. Dann könnte man 51*256 = rund 13000 neue Befehle einbauen.


    Ohne Erkennungstoken ist immerhin der Bereich $CC bis $FE frei, also 51 Token.

  • Danke für das Feedback! Vorschläge sind willkommen, u.a. dafür ist der Thread auch gedacht.


    Witzigerweise habe ich gestern noch genau diesen Einfall gehabt, war mir aber nicht sicher, ob das überhaupt so vom Compiler verstanden wird.


    Bei Gelegenheit probiere ich das aber definitiv aus. Im Moment brauche ich erstmal etwas Abstand von diesem Projekt, habe in den letzten Wochen einfach zu viel Zeit damit verballert. :)

  • Das Riemenschneiderbuch würde mich auch interessieren. Scheint aber mittlerweile recht selten zu sein. Online gibts das nicht irgendwo?

    Doch, doch.


    https://www.retrozone.ch/c128/

    Der Link ist ja eine richtige Fundgrube an toller 128er-Literatur. :thumbsup:

  • So, jetzt gibt es ein Update. :)


    Verbesserungen:

    * Der Source-Code wurde erheblich aufgeräumt und entrümpelt. Danke noch einmal an strik für den Tipp mit der Tabelle.

    * Der Programmcode ist dadurch auch kürzer und etwas schneller geworden.

    * Das Einfügen neuer Befehle ist leichter geworden.

    * Man muss jetzt nicht mehr "NEW" nach dem Programm-Start eingeben. (*)

    * Der PLOT-Befehl wurde etwas überarbeitet.



    (*) Frage: Ich habe jetzt die Speichervektoren $2d bis $32 händisch überschrieben. Eigentlich hätte ich einfach lieber den NEW-Befehl oder auch CLR-Befehl vom Programm aus aufgerufen. Weiß einer, wie das geht?


    Hier noch ein Auszug aus dem Source-Code:

  • Eigentlich hätte ich einfach lieber den NEW-Befehl oder auch CLR-Befehl vom Programm aus aufgerufen. Weiß einer, wie das geht?

    BASIC-Befehl NEW $A642

    BASIC-Befehl CLR: $A65E


    (NEW benutzt CLR)


    Einfach per JSR anspringen.


    Ich empfehle, dass du dir "64 intern" aus der Wolke holst, da kannst du so etwas im dokumentierten ROM-Listing auch selber suchen. Die Adressen der BASIC-Befehle (abzüglich 1 aus programmiertechnischen Gründen) liegen ab $A00C.

  • Da liegt nicht das Problem, ich habe hier alle möglichen ROM-Listings als pdf und teilweise auch auf Papier. Und die Einsprungadressen sind mir durchaus bekannt.

  • goloMAK , du nutzt den falschen Einsprung zu der NEW Routine.

    du solltest mal SYS42564, bzw. $A644 probieren;)

    zur Erklaerung ein kurzer Auszug aus dem ROM-Listing:

    Code
    1. A641: 60 RTS Ruecksprung
    2. -------------------------------- BASIC-Befehl NEW
    3. A642: D0 FD BNE $A641 Kein Trennzeichen: Syntax Error (da wir von BASIC, oder unserer Routine kommen erfolgt hier ein Ruecksprung, siehe A641)
    4. Hier ist der Einsprung von $E444
    5. A644 (ab hier ist der wirkliche NEW Befehl)

    Edit:

    Noch ein bischen ausfuehrlicher:

    falls du von Basic einen SYS-Aufruf machst, dann wird ueber den Basic-Interpreter der SYS-Befehl abgearbeitet, und anhand der Zahl hinter dem SYS-Befehl dann nach $A644 gesprungen. Da kommt es nun darauf an, was im ACCU ist, ist es gleich 0, dann wird der NEW-Befehl ausgefuehrt, ist es ungleich 0, dann wird BNE A641 ausgefuehrt, was zu einem sofortigem Ruecksprung fuehrt.

    Das ist auch so in wenn du von Assembler ein JSR A642 ausfuerst. Hier koennte man den ACCU vorher mit 0 laden (LDA #00), dann wird die NEW-Routine auch ausgefuehrt wenn man bei A642 einspringt.


    MfG

    Claus

  • Ich hatte doch einen Screenshot gepostet.

    Ähm... Sorry, den hatte ich komplett übersehen.

    Ich bin wahrscheinlich schon zu trainiert darauf, Bilder in Foren zu ignorieren, wenn ich nicht explizit darauf hingewiesen werde.

    Der Erklärung von ClausS kann ich nur zustimmen. Daran hatte ich spontan auch nicht direkt gedacht.


    Ein Tipp, wenn du so etwas hast: Im Emulator (VICE z.B.) erst einen Breakpoint setzen, dann den SYS ausführen und schauen, was passiert. Da wäre das abweisende BNE direkt aufgefallen. Das soll eigentlich sicherstellen, dass nach NEW oder CLR nichts neues folgt ("NEW 10" oder "NEWER FILE" im Quelltext soll nicht dafür sorgen, dass das Programm versehentlich weg ist).