letzter Beitrag von Zirias/Excess am
Hallo,
ich möchte mit dem Programmieren in Assembler anfangen. Als Ziel habe ich solche Intros vor meinem geistigen Auge. Also Programme die Laufschrift, ein Bild und Musik auf dem Monitor darstellen. Gibt es hier Leute die auch so etwas machen? Wenn ja, was nutzt ihr da so für Prgramme?
Ja, solche Leute wurden hier schon mal gesichtet.
Generell empfohlen werden ACME (http://www.c64-wiki.de/index.php/ACME) und das C64 Studio (s. auch C64 Studio - Entwicklungsumgebung ff). Beide sind zueinander recht kompatibel und genießen den unschätzbaren Vorteil, daß die Entwickler, MacBacon und Endurion, hier im Forum anzutreffen sind.
Am angenehmsten ist es wohl am PC zu programmieren (Cross Development) mit einer IDE.
Man kann aber auch mit einem Editor wie Notepad++ und ACME als Assembler programmieren.
Schau dir mal hier die Themen an: Cross Development
Unter Windows sind z.B. Das C64 Studio, CBM Prg Studio und Relaunch64 bekannt.
C64 Studio hat im Zusammenspiel mit WinVICE auch einen Source Code Level Debugger, Du kannst also zeilenweise Deinen ASM Code in der IDE debuggen.
Soviel ich weiss, ist das ein Alleinstellungsmerkmal. Es hat auch einen Spriteeditor drin, was aber das CBM Prg Studio auch hat.
Am Mac ist Relaunch64 dank Java auch lauffähig. Für Mac gibt es aber z.B. auch das Tool von DustLayer.
Und unter Linux geht AFAIK Relaunch64 und sonst halt per Editor + ACME (was überall geht).
Ich nutze 64Tass und bin damit recht zufrieden.
ACME ist auch toll, der Entwickler ist auch hier im Forum unterwegs und beisst nicht, wenn man ihn was fragt 
C64 Studio ist auch schnieke, mit IDE, Grafiktools und was nicht noch alles, und der Entwickler ist ebenfalls hier aktiv und freundlich, es setzt allerdings zum Betrieb .NET voraus.
Wenn du aus der C-Ecke kommst ist vielleicht auch das CC65 Cross Compiler Paket (inklusive Assembler, versteht sich) n Blick wert, da kann ich allerdings auf die Schnelle nicht mit einem Link dienen
Vielen Dank für die Erklärungen und die Links. Ich werde mich da mal durchlesen. Ich nutze Windows10 als Betriebssystem und dort den Vice Emulator. Einen richtigen C64 habe ich auch noch mit SD2IEC und 1541.
und dort den Vice Emulator
Genau! Für´s Programmieren aber die x64sc.exe von Vice nutzen / in den Cross-Developer deiner Wahl einbinden; die ist genauer...
Wobei ich den letzten Build gerne mit Codenet auf einen echten C64 schiebe und teste 
SMON am realen C64 Bj. 84 
HI,
der Windows-Port vom ACME mit ein paar Beispielen ist hier zu finden.
http://www.emu64.de/acme/
Die Beispiele sind von einigen bekannten Demos und Intros. (ok vom 2011, ich muss mal ein
paar neuere hinzufügen)
Hier noch ein netter Artikel um ACME mit Notpad++ zu koppeln. Wobei ich persönlich den Relaunch64 von Daniel
empfehle.
Gruß Höp
Wenn du aus der C-Ecke kommst ist vielleicht auch das CC65 Cross Compiler Paket (inklusive Assembler, versteht sich) n Blick wert, da kann ich allerdings auf die Schnelle nicht mit einem Link dienen
Die Toolchain wird seit geraumer Zeit auf Github weitergepflegt und steht inzwischen unter der zlib Lizenz.
Wobei ich den letzten Build gerne mit Codenet auf einen echten C64 schiebe und teste
Funktioniert das gut mit dem Codenet? Ist das nicht eine Geschichte mit der Netzwerkerweiterung für den C64, wo man den per Netzwerkkabel mit dem PC verbindet?
Ich nutze immer den KickAssembler.
Codenet funktioniert ganz hervorragend sogar. Ich benutze dazu ein MMCReplay mit RR-Net sowie eine 1541-Ultimate 1+ dafür. Praktisch und schnell ist auch die Disk-Tranfermöglichkeit mit Warpcopy. Leider bekommt man die Hardware nicht mehr so leicht.
Huhu!
Ich habe lange mit CBM Prg Studio gearbeitet weil dieser hervorragende Assembler-Kurs damit arbeitet:
http://www.retro-programming.de
Der Kurs-Betreiber ist übrigens auf C64 Studio im Lauf des Kurses umgeswitcht. Und zwar ab Teil 2 des Computerspielprojekts. Es hat im Kurs auch Demo-Effekte (Scrolling, Color Cycling, RasterBars, Sprite Scroller).
Ich selber nutze mittlerweile nur noch cc65 als Kommandozeilen-Tool und einen Texteditor.
http://cc65.github.io/cc65/
Die generierten Prgs kommen auf SD Karte und werden per SD2IEC auf dem echten C64 gestetet. Oder halt wie sonst unter VICE.
Diese großen Fenster-Umgebungen sind mir (momentan) zu heavy. cc65 gibt es außerdem auch als MorphOS Build, d.h. ich kann auf meinem Powerbook G4, wo das Amiga-Betriebssystem MorphOS drauf ist, mit dem Texteditor Scribble ASM coden, mit der Amiga Shell unter cc65 kompilieren
und die Prgs dann mit dem MorphOS VICE 2.4 Build testen. Das ist einfach geil.
Ich nutze für die C64 ASM Entwicklung ein Dropbox-Verzeichnis, auf das ich von Windows und MorphOS aus zugreife. Windows und MorphOS sind was C64 ASM angeht komplett austauschbar. Nur dass ich es mit MorphOS halt lieber tue.
Es ist toll, aus dem C64 Intern Monitor-Listings in den Texteditor zu übertragen, anzupassen und es läuft als Prg! Vor allem mit so netten Direktiven wie .charmap, womit ich Klartext für Scrolltexte eingeben kann und es werden die richtigen BS-Pokes ausgesucht (wenn man nicht Tilesets für Scrollschriften verwendet soweit bin ich noch nicht).
Wenn Dir also Kommandozeile kein Graus ist und Du plattformunabhängig entwickeln willst empfehle ich cc65.
Edit:
Ich empfehle zusätzlich einen Maschinensprache-Monitor wie den auf der C64 Intern Diskette beigegebenen. Oder man nimmt den von VICE, aber ein C64 Monitor der nicht vom Emulator kommt ist mir in dem Fall lieber.
Ich verwende auch den KickAssembler allerdings (im Moment noch) die KickAssembler IDE.
Der Assembler an sich ist plattformunabhängig (da Java), die IDE ist allerdings ein Windows-Programm.
Man kann aber genauso gut Relaunch64, Eclipse oder einen anderen beliebigen Texteditor verwenden.
Danke für die Verschläge. Ich bin jetzt beim C64Studio mit ACME + VICE hängen geblieben und spiele mit ein paar Tuts rum und mache fleißig Notizen.
Ich selber nutze mittlerweile nur noch cc65 als Kommandozeilen-Tool und einen Texteditor.
[...]
mit dem Texteditor Scribble ASM coden, mit der Amiga Shell unter cc65 kompilieren
Nur zur Sicherheit: Du benutzt aber schon den Assembler ca65 aus dem cc65-Paket, nicht den C-Compiler via asm()-Direktive, oder?
@ Mac Bacon
Genau. Den Assembler und den Linker. Der kennt ein extra c64 Profil weil der Assembler selber ja allgemein für 6502 geeignet ist und über den Linker wird dann spezifisch für 8 Bitter kompiliert die einen 6502 drin haben wie etwa Apple II oder Atari 800 XL.
Der C Compiler nutzt den Assembler und Linker ebenfalls, nachdem er Asm Code aus dem C Code gebastelt hat. Ich baue den Asm Code direkt, brauche den C Compiler daher nicht.
Ich habe übrigens immer noch nicht verstanden was ein Linker macht und was das Objekt genau ist was der Linker produziert. Ist es ein Binary in dem Maschinensprache, SID Daten, Koala Daten und Sprite Daten zusammen geführt sind und die zuvor als separate Files vorlagen?
Edit :
Ich nutze von diesen beiden Befehlsmustern hauptsächlich das untere :
1.
cl65 -o file.prg --start-addr $C000 -t c64 -C c64-asm.cfg source.s
2.
Basic Zeile hinzufügen statt reines Bin zu erzeugen:
cl65 -o file.prg -u __EXEHDR__ -t c64 -C c64-asm.cfg source.s
Leicht vereinfacht: Objektfiles enthalten fertigen Maschinencode, bei dem aber die Labels, die zur Assemblierzeit unbekannt sind, durch Platzhalter ersetzt sind. Am Ende des Files ist dann eine Tabelle, in der steht, dass an der Position x im Objektfile eigentlich die Adresse des Labels y stehen soll. Außerdem gibt es eine Tabelle, in der die Labels samt ihrer Adresse stehen, die im Sourcefile aus dem das Objektfile erzeugt wurde definiert sind.
Der Linker nimmt die Objektfiles, schaut, welche Labels alle so definiert werden und wo Platzhalter für Labels stehen und ersetzt die Platzhalter dann entsprechend.
Das erspart einem, sich das Hirn zu zermartern, welche Sourcefiles denn welche anderen includieren müssen. Außerdem kann es Situationen lösen, die anders nur sehr umständlich zu bewältigen sind, wie zyklische Abhängigkeiten.
Ein Beispiel aus der Praxis:
Programm A soll zur Laufzeit Programm B von Diskette nachladen.
Wenn Programm B fertig geladen ist, soll ein Label aus Programm B angesprungen werden.
Um Platz zu sparen, soll Programm B direkt hinter Programm A geladen werden.
Um jetzt Programm A zu assemblieren, muss das Label aus Programm B bekannt sein, sonst kann ja der Sprungbefehl nicht erzeugt werden.
Um aber Programm B zu assemblieren, muss die Endadresse von Programm A bekannt sein, sonst kann man ja die Adressen der Labels in Programm B gar nicht bestimmen.
Leider kann man also keins der beiden Programm assemblieren.
Ein Linker löst dieses Problem, weil die beiden Programm erst unvollständig zu Objektfiles assembliert, und dann vom Linker endgültig zu fertigem Code finassiert werden können.
P.S.: ich benutze übrigens aus exakt diesem Grund auch ca65/ld65. Es gibt m.E. bessere und komfortablere Assembler, aber fehlender Object-Output ist für mich mittlerweile ein klares Ausschlusskriterium zumindest für Programme die Nachladen.
finassiert
Interessant, was man durch die dusselige Autokorrektur alles so lernen kann. "Finassieren" musste ich glatt erst mal nachschlagen. Gemeint habe ich aber das aus Autokorrektursicht offensichtlich viel extravagantere "finalisieren"...
