Hallo!
Hat sich hier schon jemand am gcc für 6502 versucht?
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 Claus am
Hallo!
Hat sich hier schon jemand am gcc für 6502 versucht?
ich nicht. aber es gibt auch eine cross umsetzung des c64 turbo ass+ assemblers:
http://www.forum64.de/index.php?attachment/98991-disk-zip/
entpacken und bass.exe aufrufen. disk.exe ist noch ein praktisches tool um gleich den output des assemblers ins diskimage einzubinden.
etwa folgende batchdatei erstellen:
bass.exe meinprogramm.txt REM meinprogramm.exe assemblieren; output: meinprogramm.prg
disk.exe a meinedisk.d64 meinprogramm.prg REM adde zum diskimage meinedisk.d64 das programm meinprogramm.prg
es gibt ein gutes programm, das alte turbo ass+ files zu ascii files umwandelt (wie es bass.exe braucht). dies hat mir sauhund mal hier mitgeteilt. den namen weiß ich jetzt nicht mehr.
Also ich versuch den gerade zu compilieren, und die beiden Zeilen mit den Git-Clone Befehlen tun mal nicht für mich. Stattdessen funktionieren die Zeilen, wie sie auf der github Website angezeigt werden, also ohne das git@ ...
So, compiliert. Ich wollte den gcc mit 800 MB in ner VM erstellen. Ging nicht. Mit 2GB und 2 Kernen lief er dann zügig durch. Konnte auch hello.c in dem tests Verzeichnis compilieren. Ergebnis ist mal 137 Bytes gross. Schau mir das gerade mit da65 an, wobei ich noch zweifle, dass es auf nem c64 laufen würde. Adresse 0 und 1 werden am Anfang auf 0xff gesetzt, der eigentliche Code scheint aber bei 0x200 zu beginnen?
So sieht ein Assembler-Listing vom hello world mal aus:
Wird anscheinend ab Startadresse 0x200 compiliert? 0801 (nach dem Bildschirmspeicher) wär sinnvoller?
Der baut wohl erst mal einfach allgemein für 6502. Entweder muss man dem Compiler sagen, dass man für C64 kompilieren will, oder das geht (noch) gar nicht.
Ich hab -mmach=c64 angegeben und das hat er wohl gefressen. Gibt auch ne Linker Config für den c64.
Mal ne ganz dämliche Frage: in Zeile 48 ist ein RTS, nach einer Leerzeile geht es ohne eine Marke weiter - wird der Code von Zeile 50-55 überhaupt aufgerufen? Oder hab ich was übersehen?
Hmmh...meine erste Idee war, dass das Daten sind, und kein Code. Das 'Hello world' müsste ja in dem Code stehen. Ist aber wohl auch falsch.
Ich würde gerne mal den Autor fragen, hab aber noch keine Mail-Adresse o.ä. gesehen.
Da ist aber einiges seltsam: es gibt ja ein JSR nach 0246, was soll denn da sein? Die Labelnamen sind auch komisch, wieso sind die denn alle jenseits von ffxx? Zeigt der Disassembler auch das richtige an?
Gute Frage. Ich hab den da65 genommen, weil gcc ja anscheinend auch die cc65 Tools nimmt.
Ich hab jetzt mal dem Compiler gesagt, dass er ein Assemblerlisting erzeugen soll. Das sieht wesentlich sinniger aus.
Ja, das sieht besser aus! Er denkt halt leider, dass der Bildschirm bei fff0 ist
Logisch!
Man betrachte die Sources:
Aber einfach die Adresse zu ändern bringt auch nix, weil er in putc den Pointer nicht inkrementiert? Ich änder das mal provisorisch.
So...Sources geändert:
Erzeugter Code sieht passender aus:
Hab das mal mit
6502-gcc -mmach=c64 hello.c -O2 -o hello.prg
compiliert.
Dann ein d64 erzeugt:
c1541 -format test,1 d64 test.d64
und das prg drauf kopiert:
c1541 test.d64 -write hello.prg hello.prg
In vice kann ich das nun mit load "hello.prg",8 laden oder mit ,8,1.
Im .2 Fall crashed vice, im 1. Fall fehlt mir ja so ne Basic-Zeile zum Start des Programms (wobei es wohl es an der falschen Stelle im Speicher steht).
Die einfachste Lösung wär wohl schauen, dass das prg eine passende Ladeadresse bekommt, es dann mit ,8,1 laden und dann mit sys <adr> aufrufen?
Muss ich mal drüber nachdenken...
Ach ja: hier mal das d64:
Und hier ein hexdump vom Code:
Der Dump startet mit a9 ff, was doch lda #$ff ist, oder?
Kommt im Assembler Listing nicht vor...
Ich denke, die ersten 16 Bytes werden vom Linker als plattformspezifische Initialisierung erzeugt. Dass 00 und 01 initialisiert werden, deutet für mich stark darauf hin. Warum allerdings mit ff? Macht das cc65 auch?
EDIT: ff scheint nicht falsch zu sein, es sollte wohl die Default-Speicherkonfiguration (Basic-ROM und Kernal aktiv) aktivieren.
Wie schaut denn die Linker-Config aus? Ich habe in ld65 mal in die C64-Config geschaut, da wird erwartungsgemäß eine 2-Byte Ladeadresse erzeugt, dann ein Header (der Basic-Stub) und dann beginnt ab 080d das Segment für den eigentlichen Code.
EDIT: Ach Quatsch, jetzt lese ich erst, dass gcc-6503 ja den Linker und Assembler aus cc65 verwendet. Das sollte also passen. Unter diesen Umständen vermute ich, dass in die beiden Segmente für Ladeadresse und Basic-Stub einfach nichts geschrieben wird.
EDIT2: Startadresse und Basic-Stub werden in c64.lib erzeugt, die muss für ein funktionierendes PRG dazugelinkt werden, also
Dann sollte es prinzipiell gehen...
Der ld65 kann bei obigem Aufruf nix mit dem Dateiformat vom hello anfangen. Ich kann die c64.lib aber direkt mit dem gcc anscheinend einfügen mittels:
6502-gcc -mmach=c64 /usr/share/cc65/lib/c64.lib hello.c -O2 -o hello.prg
Nu ist mein hellp.prg 20 Bytes grösser, fängt allerdings immer noch mit dem lda #$ff an. Fehlt also immer noch eine Ladeadresse. Ich hängs mal hier an.
Die Linker-Config vom gcc steht in
/usr/src/gcc-6502/gcc-6502-bits/ldscripts
, und sieht so aus:
Wo hast Du die Config für das Einfügen der Basiczeile beim cc65 gefunden? In dem c64.cfg File seh ich nix davon?
Danke mal für eure wertvollen Tipps!