dann läuft es auch aufm CPC
Und bestimmt auch noch schneller .
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von EgonOlsen71 am
dann läuft es auch aufm CPC
Und bestimmt auch noch schneller .
Und bestimmt auch noch schneller .
Zu schlagen wären ~300fps auf einem älteren 4Ghz i7 (man muss die LIMIT 40 -Anweisung dazu aus dem Code entfernen, sonst ist der auf 40fps gedeckelt)
Ein kleines Update: Es gibt ein spezielles GGET-Kommando, um Tastendrücke im Grafikfenster unabhängig von der Konsole auslesen zu können, man kann nun Bildschirmbereiche kopieren und Shapes aus Bildschirmbereichen erstellen. Außerdem kann man Shapes nun auch in Echtzeit rotieren und dabei uniform skalieren.
Geil!
@EgonOlsen, wenn Du von Interpreter/Compiler sprichst, klingt das etwas danach, als würde da BASIC V2 nach Java-Bytecode compiliert, das passiert ja soweit ich sehe nicht, sondern es wird nur in eine interne Objektstruktur übersetzt, die die BASIC/ASM-Kommandos abbildet, und die wiederum in einem Interpreter-Loop abgearbeitet wird? (wäre vielleicht noch ein erklärender Punkt für die Doku)
Wäre spannend zu sehen, wie schnell ein "richtiger" Compiler nach Java-Bytecode oder das Ergebnis eines Transpilers BASIC=>Java wäre.
So etwas nannte man damals p-code-Compiler. Und in der ganz frühen Hobby-Computer-Zeit (sagen wir mal 1975-1980) sprach man tatsächlich manchmal von 'compilieren', wenn der Interpreter nur die einzelnen Schlüsselwörter in ein-Byte-Token übersetzte. Wobei ich ehrlich gesagt keinen Microprpzessor-BASIC-Interpreter kenne, der nicht tokenisiert hat- allein schon aus Platzgründen.
(ich nutze bislang übrigens S-BASIC für die 'kleinen schnellen Programmieraufgaben', die die heutige Jugend meist in Python erledigt. Der geht zwar mehr auf das Sinclair-Basic zurück -daher auch der Name- aber dessen String-Funktionen haben mitr eh immer mehr zugesagt als die Microsoft-Variante.
Wenn man einige spezielle Befehle wegläßt, dann läuft es auch aufm CPC.
Erfahrungsmässig muss man dann aber beim CPC einen intensiven Gebrauch des EDIT Befehls machen.
Zitat von 1570...wenn Du von Interpreter/Compiler sprichst, klingt das etwas danach, als würde da BASIC V2 nach Java-Bytecode compiliert...
Ja, das stimmt. Deswegen ist meine Bezeichnung für das Ding auch etwas "unscharf". Es ist aber schon ein Compiler, der in einen Zwischencode compiliert. Dieser Zwischencode ist halt etwas unüblich, da er, wie du schon geschrieben hast, aus lauter Objektinstanzen besteht, die sich dann selber ausführen können und dadurch den Programmablauf ergeben. Die angesprochene Schleife iteriert nur über die Wurzeln dieser Instanzenbäume (einer pro Befehl) und startet die Ausführung...interpretieren würde ich das nicht nennen.
Aber ja, es ist ein eher ungewöhnliches Konzept...
Hm, ich würde schon sagen, dass das ein Interpreter-Loop ist oder sehr dicht dran: Er bringt insbesondere die gleichen Nachteile mit sich (die CPU/VM muss letztendlich viele Sprünge ausführen; in Registern werden in erster Linie Verwaltungsinformationen gespeichert, nicht die eigentlichen Operanden des Algorithmus; die VM kann zwar den Loop, nicht aber den ausgeführten Algorithmus optimieren). Die Objektinstanzen sind letztendlich eine Art angereicherter Syntaxbaum...? Compilerbauer haben sicher genauere Bezeichnungen dafür. Ein Objekt-Code wird ja eher nicht erzeugt (klar könnte man die Objekte serialisieren, aber hey, dann würde auch Office ein Textdokument "compilieren" und nicht einfach "laden" ).
Hm, ich würde schon sagen, dass das ein Interpreter-Loop ist oder sehr dicht dran: Er bringt insbesondere die gleichen Nachteile mit sich (die CPU/VM muss letztendlich viele Sprünge ausführen; in Registern werden in erster Linie Verwaltungsinformationen gespeichert, nicht die eigentlichen Operanden des Algorithmus; die VM kann zwar den Loop, nicht aber den ausgeführten Algorithmus optimieren).
Ja, irgendwie schon. Die Schleife ist sicher ähnlich einer Interpreter-Schleife, es wird eben nur nichts interpretiert. Die Begriffe sind leider nicht so ganz klar definiert. Guck dir mal an, was sich im Web-Entwicklungsumfeld alles "Compiler" nennt. SCSS zu CSS und solche Sachen. Das ist nicht einmal ein Program. Das ist eine Textumwandlung...
Naja, was auch immer es ist. Ich werde mal ein paar Benchmarks mit dem Fraktal machen und mal sehen, ob ich noch was rausholen kann...
boah (m)ein Traum wird fast war. Das simple Basic auf einem PC.
Das V2 Basic läuft bei mir nun in Eclipse. Ich starte darin immer die BasicShell. Auch die Beispiellistings aus dem Thread funktionieren.
Die Zusatzinfos mit GGET und Shapes, sind die im Archiv irgendwo mit dokumentiert?
Gerade das mächtige Grafikzeugs ist ja eben nicht V2 Basic. Ist das dann einfach V7 Basic von der Syntax her, etwas selbst ausgedachtes oder was ist die Referenz?
Wie funktioniert das Abspeichern von Listings? Kann die Laufzeitumgebung d64 Dateien beschreiben oder Windows Ordner mit dem SAVE-Befehl? Oder speichert man sich das als Text ab den man immer neu herein pasten muss?
Wie adressiere ich das Screen RAM?
Gibt es ein Äquivalent zu poke 1024,1 in der Art locate 1,1:print "A"; ?
Sound braucht es finde ich nicht. Aber 1000 Bytes ScreenRAM, Color RAM und 16 Farben wären ganz schön.
mb1860: Huh? Microsoft Basic gibts doch schon seit 1981 auf dem IBM PC. Dort war die ROM-Version sogar noch nutzloser als auf dem C64: Es konnte nicht nur die Grafik nicht bedienen, sondern es hatte auch keinerlei Unterstüützung für Diskettenbetrieb. Das mußte man dann bei Bedarf erst nachladen, in Form der altbnekannten GWbasic (unter MS-DOS) oder BasicA (auf Original-IBM-Systemen)
War schon irgendwie witzig, wenn ein PS/2 mit 486er-Prozessor ins ROM-Basic startet und verzweifelt nach den Kassetten-Routinen im BIOS sucht...
Aber zurück zum Java-Basic: Ich würde es als Compiler klassifizieren, auch wenn es keinen realen Prozessor als Ziel hat, sondern einen (beinahe Forth-ähnlichen) Instanzen-Aufrufer. Solche Kompilate sind bei 8-Bit-Compilern gar nicht mal unüblich- meist als JSR-Wüsten, aber immerhin. Die meisten µP haben halt viel zu wenige Register, als daß man eine Variable auch nur von einem Befehl zum nächsten im Prozessor halten könnte. Erst recht nicht dann, wenn man volle Fließkomma-Unterstützung gewährleisten will...
Die Zusatzinfos mit GGET und Shapes, sind die im Archiv irgendwo mit dokumentiert?
Gerade das mächtige Grafikzeugs ist ja eben nicht V2 Basic. Ist das dann einfach V7 Basic von der Syntax her, etwas selbst ausgedachtes oder was ist die Referenz?
Wie funktioniert das Abspeichern von Listings? Kann die Laufzeitumgebung d64 Dateien beschreiben oder Windows Ordner mit dem SAVE-Befehl? Oder speichert man sich das als Text ab den man immer neu herein pasten muss?
Die Grafikerweiterungen sind hier dokumentiert: https://github.com/EgonOlsen71…ster/GRAPHICS%20BASIC.txt
Es gab da keine Vorlage. Ich habe einfach gemacht, was ich für sinnvoll hielt.
Abspeichern kannst du in der Shell einfach mit SAVE"tralala.bas". Das speichert eine Textdatei ins lokale Verzeichnis, analog lädt LOAD"tralala.bas" das wieder von dort.
Du kannst auch das hier alternativ mal ausprobieren: https://github.com/nietoperz809/C64Screen
Das ist vom selben Entwickler, von dem ich die BasicShell übernommen habe, aber es ist etwas mehr C64-like.
Edit: Du kannst auch komplette Pfade zum Laden/Speichern angeben. So lädt z.B. LOAD"SRC/TEST/RESOURCES/EXT/FRACTAL.BAS" das Fraktal-Beispiel in die Shell.
Danke!
Das bedeutet, Du bietest einen sehr mächtigen Grafikmodus, aber keinen Textmodus.
Die Shell ist eben wirklich nur eine Shell, die sich Listings merken kann. Was ja nicht schlimm ist, ich wollte es nur wissen.
Du hast trotzdem etwas Tolles abgeliefert.
Nee. So ein Textmodus passt zur normalen Konsolenausgabe von Java gar nicht (die ist nämlich Grütze) und zur Shell irgendwie auch nicht so richtig. Aber wie gesagt: Guck mal diese andere Shell an, zu der ich verlinkt habe. Ich bildet zumindest ein paar Dinge nach. Ob ein Textmodus dabei ist, weiß ich jetzt aber nicht...
Falls nicht, kann ich bestimmt auch irgendeine Art Textmodus zusammenzimmern...
Edit: Eben ausprobiert...da ist sowas dabei. Man kann inns Screenram und ins Frabram poken und sieht das Ergebnis.
So etwas nannte man damals p-code-Compiler. Und in der ganz frühen Hobby-Computer-Zeit (sagen wir mal 1975-1980) sprach man tatsächlich manchmal von 'compilieren', wenn der Interpreter nur die einzelnen Schlüsselwörter in ein-Byte-Token übersetzte. Wobei ich ehrlich gesagt keinen Microprpzessor-BASIC-Interpreter kenne, der nicht tokenisiert hat- allein schon aus Platzgründen.
(ich nutze bislang übrigens S-BASIC für die 'kleinen schnellen Programmieraufgaben', die die heutige Jugend meist in Python erledigt. Der geht zwar mehr auf das Sinclair-Basic zurück -daher auch der Name- aber dessen String-Funktionen haben mitr eh immer mehr zugesagt als die Microsoft-Variante.
Ich glaub beim BASIC der TRS-80 Model I-III (das irgendwie dabei ist) lag das Programm wirklich textuell im Speicher. Die Laufzeit war auch entsprechend ... (aber meine Erinnerungen gehen da leider schon ziemlich weit zurück, wobei ich einen Irrtum nicht ausschließen kann).
Unter Linux verwendet ich gerne auch https://sourceforge.net/projects/cbmbasic/files/cbmbasic/, ist eine sehr getreue Umsetzung des BASIC V2 (inklusive den diversen Bugs) fürs schnelle Scripting ...
Unter Linux verwendet ich gerne auch https://sourceforge.net/projects/cbmbasic/files/cbmbasic/, ist eine sehr getreue Umsetzung des BASIC V2 (inklusive den diversen Bugs) fürs schnelle Scripting ...
In dem Projekt haben sie den Orginalinterpreter von 6502-ML nach C umgewandelt und dann neu für x86 kompiliert. Dadurch ist es im Prinzip einen 1-zu-1-Nachbildung mit allen Einschränkungen (Speicherlimit, Gleitkommaberechnung per Software usw.). Leider war zumindest die Windows-Version für mich dann aber doch nicht 100% kompatibel. Was auf dem C64 und bei meinem Kram problemlos lief, hat cbmbasic gerne in eine Endlosschleife gezwängt oder es gleich ganz abstürzen lassen. Das ist immer dann passiert, wenn viele Gleitkommaberechnungen vorkamen. Aber vielleicht läuft das Linuxkompilat ja besser.
Mir gefällt Deine Version deutlich besser.
Gerne warte ich, bis Du FarbRAM und ScreenRAM drin hast und evtl. chr$ Codes und Screen Pokes. Man sollte alle diese Adressen auch peeken können und Cursor Farben setzen können (vgl. chr$ Codes).
Evtl. auch ein poke 646,farbe möglich machen und eigenes Charset definieren.
So eine Art "begrenze Textmodus Emulation", ohne dass es ausartet mit Register und Hardware Ansprache. Aber eben so, dass man den Textmnodus zum Zeichnen, für ASCII Art oder einfache Spiele nutzen kann. Das wird dann sexy in Verbindung mit Deinen Shapes, bzw. "Sprites".
Dein Basic wird dann richtig rocken, wenn man nicht nur Grafik Demos, sondern Spiele machen kann, die mit dem echten V2 Basic auch mit Compiler nicht gehen wüden.