Hallo Besucher, der Thread wurde 12k mal aufgerufen und enthält 45 Antworten

letzter Beitrag von Boulderdash64 am

C64 & Basic V3.5

    Um den Punkt im OP noch abzurunden:

    Zitat von Boulderdash64

    gibts auch Möglichkeiten, wie beim plus/4 den freien Basic-Speicher größer zu machen, falls man mal etwas mehr Platz benötigt?

    Ja. Paradoxon-BASIC leistet das Gewünschte, indem es den BASIC-Interpreter teilweise "unter" den I/O-Bereich und den KERNAL schiebt. Man bekommt damit ca. 51 KB frei für BASIC-Programme. Wurde verschiedentlich hier im Forum64 schon erwähnt und auch verlinkt. Wenn's noch mehr Speicher sein soll, käme (als Steckmodul!) Business-BASIC in Betracht. Das schaufelt 60 KB frei - ist also in der gleichen "Gewichtsklasse" wie BASIC 3.5 einzuordnen.


    Von BASIC 3.5 gibt es, wie bereits erwähnt einen soft-loadablen Port, der in der 64'er veröffentlicht wurde. Das ist auch ungefähr das Beste, was man erwarten kann: eine Nachrüstung per ROM gestaltet sich *etwas* schwierig, da BASIC+KERNAL beim C16/C116/+4 zusammen 32K belegen (auch der KERNAL ist etwas größer). Andererseits liefert es naturgemäß keinen Support für Sprites mit. Dafür mit TEDMON aber einen integrierten Maschinensprache-Monitor. :)


    Simons' BASIC hat den Vorteil, daß es recht verbreitet ist und damit geschriebene Programme einen faßbaren Nutzerkreis finden. Ein paar Bugs darin wurden mit TSB (Tuned Simons' BASIC) ausgeräumt, was auch ein paar zusätzliche Funktionen mitbringt.


    ...


    Generell steht und fällt die Brauchbarkeit von BASIC-Erweiterungen mit dem Überlapp der Funktionalität, die man für das eigene Programm braucht: nicht wenige Erweiterungen verstehen sich als eierlegende Wollmilchsau und bringen einen Haufen Befehle mit, von denen der Programmierer mal dachte, daß sie sicherlich mal nützlich sein könnten (klassischer Fall von "Creeping Featurism") - werden aber nur 1 oder 2 Befehle/Funktionen für das eigene Programm gebraucht, dann liegt der Rest des Codes tot im Speicher herum.


    Dann ist's natürlich nett, wenn man sich eine BASIC-Erweiterung ganz nach eigenem Wunsch zusammenbauen kann. :D


    Wichtig ist dann auch noch, daß es einfach möglich ist, automatisch zuerst die BASIC-Erweiterung und dann die Nutzlast (also, das eigene Programm) zu starten. Muß man das bei einem fertigen Programm nämlich (immer noch) händisch machen, leidet das User-Erlebnis ganz erheblich.

    Zitat von Ace

    Ein Basic in 3.5 als Erweiterung für den c64 fände ich auch nice.


    Mit 16 oder 32 Kilobyte RAM ist das kein großes Problem (und gibts ja auch schon mit besagtem 64er-Listing), aber man würde ein 60K-System haben wollen mit Basic-3.5 im ROM. Und dafür müßte man heftig basteln, um ein brauchbares Bank-Switching hinzubekommen. Plus: Kernal auf Links ziehen, weil der riesige IO-Block des C64 nicht dauerhaft eingeblendet sein kann. Natürlich ist das nicht im eigentlichen Sinne schwierig, aber doch eine Fleißaufgabe für mehr als ein verregnetes Wochenende. Und da ein Plus/4 oder C128 jetzt nicht sooo exotische Maschinen sind, hat das halt noch keiner umgesetzt...

    Zitat von Mike

    Generell steht und fällt die Brauchbarkeit von BASIC-Erweiterungen mit dem Überlapp der Funktionalität, die man für das eigene Programm braucht: nicht wenige Erweiterungen verstehen sich als eierlegende Wollmilchsau und bringen einen Haufen Befehle mit, von denen der Programmierer mal dachte, daß sie sicherlich mal nützlich sein könnten (klassischer Fall von "Creeping Featurism") - werden aber nur 1 oder 2 Befehle/Funktionen für das eigene Programm gebraucht, dann liegt der Rest des Codes tot im Speicher herum.


    Dann ist's natürlich nett, wenn man sich eine BASIC-Erweiterung ganz nach eigenem Wunsch zusammenbauen kann. :D


    Auch dafür gibt es eine Lösung im 64er Magazin: Hypra Basic

    Zitat von mc71

    aber man würde ein 60K-System haben wollen mit Basic-3.5 im ROM. Und dafür müßte man heftig basteln, um ein brauchbares Bank-Switching hinzubekommen.

    Je nachdem, wie man "brauchbares Bank-Switching" definiert, kann der Hardwareteil auch sehr einfach werden. Business Basic, welches immerhin ein so gutes BankSwitching hat, dass sehr viel Speicher frei wird, ist in der 1541 Ultimate II in ca. 35 VHDL-Zeilen vollständig implementiert. Möglierweise könnte man sogar dessen Hardware wiederbenutzen und nur ein anderes CRT laden.


    Allerdings der Softwareteil dürfte nicht so einfach ausfallen...

    Zitat von Mike

    Dann ist's natürlich nett, wenn man sich eine BASIC-Erweiterung ganz nach eigenem Wunsch zusammenbauen kann.

    Zitat von ogd

    Auch dafür gibt es eine Lösung im 64er Magazin: Hypra Basic

    Na, ja, eher "Lösung".


    So vom Anschauen gibt das nicht viel mehr her als die Möglichkeit, zuvor mit SYS aufgerufene Routinen mit einem BASIC-Schlüsselwort aufzurufen. Nutzt(e) der SYS die gängigen Aufrufe (CHKKOM, GETBYT, ...) um Parameter einzulesen, ging das dann auch mit dem neuen Befehl.


    Aber darüberhinaus sehe ich z.B. kein Adreß-Management für die Routinen - die werden mit der Adresse benutzt an der sie assembliert worden sind. Lasse ich in dem Baukasten z.B. eine Routine aus, bleibt der freiwerdende Platz ungenutzt.


    ...


    Was ich auch eher meinte: irgendwann mal betreibt man vielleicht mal den Aufwand, sich eine BASIC-Erweiterung komplett selbst zu schreiben, mit Tokenizer, Detokenizer, Token-Dispatch (mit gefälligst korrektem Handling des Shortcuts im IF-Befehl!) und (... so denn gebraucht ...) Formelauswertung. Das ganze als Quelltext für einen symbolischen Assembler und dann nimmt man eben wirklich nur rein, was man braucht.


    Die etwas abgespecktere Variante läßt vielleicht Tokenizer und Detokenizer weg, und nimmt stattdessen einen Token-Marker (z.B. "@") als Erkennungszeichen für neue Befehle. Den IF-Shortcut läßt man dann vielleicht auch weg, dann ist eben immer ein Doppelpunkt zwischen THEN und einem neuen Befehl notwendig.


    Ich hab' beide Varianten verschiedentlich implementiert und auch in Gebrauch. Ohne genaue Kenntnis des BASIC-Interpreters geht da natürlich nichts. Dafür ist die Anwendung der neuen Befehle genauso einfach, wie man es für ein BASIC-Programm erwartet. :)

    Zitat von Mike

    Aber darüberhinaus sehe ich z.B. kein Adreß-Management für die Routinen - die werden mit der Adresse benutzt an der sie assembliert worden sind. Lasse ich in dem Baukasten z.B. eine Routine aus, bleibt der freiwerdende Platz ungenutzt.

    Da sollte nichts freibleiben, die werden doch verschoben und neu verlinkt.

    Zitat von Paradroid

    Da sollte nichts freibleiben, die werden doch verschoben und neu verlinkt.

    Ich muß mich an der Stelle (teilweise) korrigieren. Hypra-BASIC unternimmt in der Tat den Versuch, die Befehlsmodule zu relozieren.


    Das stellt allerdings erhöhte Anforderungen an den Aufbau dieser Module, bzw. bedingt Restriktionen. Ein automatischer Relokator wird zunächst mal nur in der Lage sein, absolute Adressen von Befehlen anzupassen. Sobald Adreßtabellen ins Spiel kommen, wird die Sache gleich viel unangenehmer *) und praktisch völlig unmöglich, sobald Adreß-Low- und -High-Bytes als #Immediate-Operanden auftauchen. **)


    In der Anleitung wird diesbezüglich nur wenig erzählt, außer daß die Module in einen Befehls- und einen Datenteil aufgesplittet sein sollen und Hypra-BASIC der Umfang dieses Datenteils ebenfalls mitgeteilt werden soll. Daraus kann ich nur schlußfolgern, daß Hypra-BASIC auch nicht den Versuch macht, den Datenteil der Module irgendwie zu interpretieren.


    ...


    Geht alles viel angenehmer auf Quellcode-Basis.



    *) erstmal müssen Programmbereiche und Datenbereiche sauber getrennt werden und dann muß klar sein, wo in den Datenbereichen Adreßtabellen vorhanden sind. Sind die Adreßtabellen dann auch noch in Low- und Highbytes getrennt (was gar nicht so selten ist), muß noch geklärt werden, welches Low- zu welchem High-Byte gehört. Das bedingt wiederum eine Analyse des zugreifenden Codes.


    **) woher soll der Relokator wissen, daß es sich hier jeweils um den Teil einer Adresse oder doch ganz andere Daten handelt? Dieses Problem stellt sich mit einiger Regelmäßigkeit, wenn man fremden Code reversed und setzt einiges an Guesswork im umliegenden Programmcode voraus. Man kann mit 100%iger Wahrscheinlichkeit ausschließen, daß Hypra-BASIC das kann.

    Ich klinke mich mal als BASIC 3.5er Programmierer hier ein. ^^
    Eigentlich müssen nicht zwingend 60k an BASIC-Speicher frei sein. Es reichen auch 40k. Man kann ja Zeichensatz und Sprites dahinter ablegen, wie jetzt auch. also die 38911 sind auf jeden Fall mehr, als beim C16/116 in Grundausstattung. Mit 40k kann man im 3.5er schon sehr viel machen. Dumm ist nur, daß das 3.5er keine Spritebefehle kennt. Man müßte also die (S)(G)SHAPE Befehle umschreiben, so daß sie als Sprrite-Befehle funktionieren.


    Und, als Modul für den C64er; würde ich mir auch zulegen, aber bitte mit einem eingebauten Fastloader ala Final Cartridge 3. :)

    Jo, BIF´s Basic gibt es bereits tatsächlich.


    Auf meiner Homepage gibt es einen 2-Datei Basic-Kurs als .prg-Dateien .


    1. Basic-Praxis
    2. Kommentar zu Basic.Praxis



    Ein Update des Basic-Kurses "Basic-Praxis", den ich auch mal in der DT veröffentlicht habe.


    Mit vielen Interessanten Themen:


    Unter andern Eingabe, Ausgabe, Grafik, Zeichensatz, Sortieren, Kopieren, Speicheraufbau des C64 usw.



    Schönen Gruß.