XC-BASIC: Neuer Basic-Cross-Compiler

ogd · 14. Februar 2019

Mit XC-BASIC ensteht ein neuer Basic-Cross-Compiler für den C 64.

Im Anhang das compilierte Beispiel. (Quelltext dazu)

spacer · 22. Februar 2019

Hallo, guten Tag.
Danke für die Info.

Gleitkomma funktioniert noch nicht.

danke.
Gruss

ogd · 22. Februar 2019

Zitat von spacer

Wo gibt es bitte für den ASM-Code den Assembler ?

Bei batari Basic zum Beispiel ist der DASM mit dabei. Den eInfach mit xcbasic64.exe aus XC-BASIC\bin\win_x86_64\ und snake.bas aus XC-BASIC\examples\ in ein Verzeichnis kopieren und dort folgende Befehle zum Übersetzen eingeben:

Code

xcbasic64 snake.bas >snake.asm
dasm snake.asm -osnake.prg

spacer · 22. Februar 2019

Alles klar.

Ich hoffe das dieses XCBasic64 schnell erweitert wird mit Strings , Gleitkomma , Sin/cos usw. und ein Sys um Spezielle ASM aufzurufen.
Sonst ist es wertlos für einen Programmierer.

Danke.
Gruss

Mac Bacon · 22. Februar 2019

Zitat von spacer

Ich hoffe das dieses XCBasic64 schnell erweitert wird mit Strings , Gleitkomma , Sin/cos usw. und ein Sys um Spezielle ASM aufzurufen.
Sonst ist es wertlos für einen Programmierer.

Da es Open Source ist, kannst Du ja mit gutem Beispiel voran gehen und entsprechende Verbesserungen einreichen.

spacer · 23. Februar 2019

Habe ich schon gemacht.

Gruss

Hamrath · 1. April 2019

Inzwischen ist einiges passiert bei XC-BASIC und heute hab ich das erste Mal wirklich was vernünftiges compiliert gekriegt.

Im Buch "Programming the Commodore 64 The Definitive Guide" von RC West (gibt's auch in der Wolke) habe ich einen Labyrinthgenerator gefunden, der ähnlich, aber wesentlich einfacher ist als der, den ich in meinem Spiel Maze Of Death verwende. Da ich gerade überlege, Maze Of Death nach XC-Basic zu konvertieren, hab ich heute mal mit dem Generator angefangen und diesen erfolgreich compilieren können.

Wer sich das mal anschauen möchte, ich hab die Original-BASIC- sowie die XC-BASIC-Version angehängt, inkl. PRG-Dateien zum Geschwindigkeitsvergleich.

XC-BASIC-mazegen.zip

Mein XC-BASIC-Code ist aber alles andere als perfekt, denk ich. Ich hab da ein paar Fallstricke umgehen müssen, die ich aufgrund der etwas seltsamen Art von XC-BASIC hatte. Alles in allem bin ich aber zufrieden - vor allem mit der Geschwindigkeit.

spacer · 1. April 2019

hmmm.
Die haben noch nicht viel geschafft in der Entwicklung bei XC-BASIC.

Gruss

Hamrath · 1. April 2019

Zitat von spacer

hmmm.
Die haben noch nicht viel geschafft in der Entwicklung bei XC-BASIC.

Gruss

Es ist bloß ein Entwickler und er hat schon einiges geschafft. Immerhin versteht der Compiler inzwischen AND und OR. Ich hab auch einiges an Issues gemeldet, die immer schnell geändert wurden. Nächstes Ziel sind Floats.

Nicht zu vergleichen mit TurboRascal, aber ich glaube, der Grundgedanke ist auch ein anderer. Hier geht es wirklich um BASIC, vergleichbar mit einem C64-BASIC-Compiler. Coole Demos wird oder das nächste Sam's Journey man hiermit wohl kaum schreiben. Aber vielleicht bastle ich demnächst mal eine Wirtschaftssimulation damit.

spacer · 1. April 2019

Na , da bin ich mal Interessant.

Die fertigen PRG sind unverhältnis groß.

Snake.prg ist 5,8 kr. Unverhältnis groß.
Auch das mazegen.prg als PRG zu gross.

Eigentlich wünscht man sich etwas angenomes kleines.

Gruss

Stephan Scheuer · 1. April 2019

Kann der XC-BASIC Compiler mit dem Basic Boss mithalten?

Hamrath · 1. April 2019

Zitat von Stephan Scheuer

Kann der XC-BASIC Compiler mit dem Basic Boss mithalten?

Das interessiert mich auch und ich werde es heute mal testen. War heute Nacht einfach zu spät.

Einen Vorteil seh ich bei der Speicherverwaltung, da du fast 50kb nutzen kannst.

spacer · 1. April 2019

-----------------------------------------------------------
Nicht zu vergleichen mit TurboRascal, aber ich glaube, der Grundgedanke ist auch ein anderer.
----------------------------------------------------------

Da ist kein Grundgedanke anders. Beide habe ein Ziel.
Compilieren und PRG erzeugen und starten.

Der TurboRascal hat sich mühe gegeben und ist immer dran an der weiteren Entwicklung. Die PRG sind super klein und super schnell.

Der XC-BASIC ist schlampig und lässt sich schleifen ohne sich mühe zu geben.
Gibt sich wenig mühe und hält sich verdeckt im Hintergrund.

Gruss

Hamrath · 1. April 2019

Zitat von spacer

Die fertigen PRG sind unverhältnis groß.

Snake.prg ist 5,8 kr. Unverhältnis groß.
Auch das mazegen.prg als PRG zu gross.

Eigentlich wünscht man sich etwas angenomes kleines.

Alles anzeigen

Ja, richtig. Ich muss den Code aber noch optimieren. Da geht noch was an der Größe, denke ich. Bspw. musste ich bei mehrzeiligen IF-Abfragen tricksen, weil die XC-BASIC (noch) nicht kann. Meine aktuelle Lösung ist aber dumm, bzw. meiner Müdigkeit gestern geschuldet.

spacer · 1. April 2019

Das kannst du nichts Optimieren , der Code verliert sonst an Übersichtlichkeit.
Der DASM hat es nicht so drauf, der kann nicht viel anders, schau dir den DASM mal an.
Es gibt da wenig Aufklärung . Ich habe da auch schon etwas gesucht.

Gruss

spacer · 1. April 2019

TurboRascal und XC-Basic sind ähnlch und haben in der Verwirklichjung kein unterscheid.
Beide sind ähnlich in ihren Aufgaben. Beide vollen das selbe erzeugen , ein PRG erzeugen.

Zwei Sprite laden.
700 Byte gross die PRG.
Save und Load habe ich selber ergänzt, weil es das TurboRascal nicht kann.
So schön ist es zu lernen und zu ergänzen.

Gruss

Code

program datei_save_8;
// 679 - 703 adressen frei
var
hiadrs : byte;
loadrs : byte;
hiadre : byte;
loadre : byte;
adrs: integer;
adre: integer;
i : integer;
lang : byte;
adr: integer;
hiadr : byte;
loadr : byte;
text : string = ("SPRITE");
procedure save(adrps, adrpe: integer, langs : byte );
begin
hiadrs:=adrps/256;
loadrs:=adrps-hiadrs*256;
hiadre:=adrpe/256;
loadre:=adrpe-hiadre*256;
asm("
lda langs
ldx #$a7
ldy #$02
jsr $ffbd
lda #$01
ldx $ba
bne .skip
ldx #$08
.skip
ldy #$00
jsr $ffba
lda loadrs
ldy hiadrs
sta $c1
sty $c2
ldy loadre
lda hiadre
iny
bne .endadr
clc
adc #$01
.endadr
sty $ae
sta $af
jmp $f5ed
");
end;
procedure load(adrp : integer , langg :byte);
begin
hiadr:=adrp/256;
loadr:=adrp-hiadr*256;
asm("
lda langg
ldx #$a7
ldy #$02
jsr $ffbd
lda #$01
ldx $ba
bne .skip1
ldx #$08
.skip1
ldy #$00
jsr $ffba
ldx loadr
ldy hiadr
lda #$00
jsr $ffd5
");
end;
procedure initsprites();
begin
i:=200;
setspriteloc(0,$C8,0);
setspriteloc(1,$C9,0);
spritepos(i,150,0);
spritepos(78,120,1);
SPRITE_BITMASK:=%00000011;
end;
begin
lang:=6;
memcpy(@text,0,^679,lang);
adr:=$3200;
load(adr, lang);
initsprites();
Loop();
end.

Alles anzeigen

Hamrath · 1. April 2019

Zitat von spacer

Das kannst du nichts Optimieren , der Code verliert sonst an Übersichtlichkeit.
Der DASM hat es nicht so drauf, der kann nicht viel anders, schau dir den DASM mal an.
Es gibt da wenig Aufklärung . Ich habe da auch schon etwas gesucht.

Gruss

Wenn ich Mist programmiere, und das hab ich eindeutig in Zeile 33 und 39, dann produziert DASM auch bloß Mist.

Die wilden Sprünge von Zeile 33 nach 60 und von 39 nach 68 sind unnötig, das geht besser. War aber gestern schon zu spät und mir ist es erst heute morgen eingefallen.

Und wenn ich auf dem C64 ein BASIC-Programm mit BASIC-BOSS kompiliere, werden die Programme auch größer. Schneller werden sie trotzdem. Und dafür ist XC-BASIC gedacht: schnelleres BASIC programmieren, nicht einfacher Assembler. Interrupt-Programmierung o.ä. ist da gar nicht vorgesehen.

Stephan Scheuer · 1. April 2019

Nutzt du beim BASIC-BOSS auch die Direktiven? Ist wahrscheinlich eine überflüssige Frage.

EgonOlsen71 · 1. April 2019

Zitat von spacer

Das kannst du nichts Optimieren , der Code verliert sonst an Übersichtlichkeit.
Der DASM hat es nicht so drauf, der kann nicht viel anders, schau dir den DASM mal an.

Der Assembler hat damit nichts zu tun. Er übersetzt ja nur den vom Compiler erzeugten Assemblercode. Wie der optimiert ist, hängt alleine vom Compiler selber ab und nicht vom Assembler. Der Compiler könnte stattdessen auch direkt Maschinensprache ausspucken, das würde nichts ändern.

spacer · 1. April 2019

----------------------------------------
Und dafür ist XC-BASIC gedacht: schnelleres BASIC programmieren, nicht einfacher Assembler. Interrupt-Programmierung o.ä. ist da gar nicht vorgesehen.
---------------------------------------

Warum schneller, das begreife ich nicht wenn ich spiele mit dem C64.
Warum erfindet man erst so ein Mist von XC-Basic, der einen keine freude bringt.
Warum ein sogenannter schnelleres Basic , der ein nur sorgen macht und das alles nichts begreift.

Gruss