Hello, Guest the thread was called4.4k times and contains 41 replays

last post from ZeHa at the

Mit was programmiert ihr Intros in Assembler?

  • 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 :)

  • 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

  • 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 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"...