Meine Einführung in C64 Maschinensprache / Assembler

Es gibt 719 Antworten in diesem Thema, welches 94.533 mal aufgerufen wurde. Der letzte Beitrag (19. November 2025 um 17:56) ist von 64erGrufti.

  • Hallo!

    Um die Unschönheit mit dem Überspringen von Code zu beseitigen, habe ich den Code des Spriteprogramms bzw. das Kapitel angepasst. Die Änderungen sind auch schon auf GitHub.

    Das Diskimage heißt nun übrigens ASSEMBLERKURS.D64, bin da lokal bei mir mit den Images immer durcheinandergekommen, daher habe ich das Image für den Kurs separiert.

    lg, Markus

    Hier der Link zum Github - Repo des Assembler-Kurses: Bitte melde dich an, um diesen Link zu sehen.

  • Guten Morgen zusammen!

    Ich überlege mir gerade welche Themen ich in diesem Kurs eigentlich noch behandeln will.

    Folgende Themen will ich aktuell noch unterbringen:

    • Sprite-Kapitel fertigstellen
    • Grundlagen der Grafikprogrammierung
    • Selbstdefinierte Zeichensätze
    • Grundlagen der Soundprogrammierung
    • Die wichtigsten Kernal-Routinen

    Ich glaube, das ist für einen Einsteiger-Kurs mehr als genug und fortgeschrittenere Themen kann man dann ja eventuell in einem weiteren Kurs bringen.

    Das Ziel, das ich mit diesem Kurs verfolge, ist ja nicht, ein möglichst umfassendes C64-Assemblerwerk zu schaffen, sondern einen leichten und verständlichen Einstieg in die Materie möglich zu machen.

    Es geht mir darum, diese Einstiegshürde, welche viele andere und auch mich selbst trotz mehrmaliger Anläufe bisher immer wieder an dem Thema scheitern ließ, zu überwinden und eine solide Basis zu schaffen, auf der jeder dann für sich selbst aufbauen und eigene Ziele verfolgen kann.

    lg, Markus

    Hier der Link zum Github - Repo des Assembler-Kurses: Bitte melde dich an, um diesen Link zu sehen.

  • Gut, wenn Du noch einen Fortsetzungskurs machen willst, dann kann ich das mit den Themen die Du noch nicht bringen willst verstehen.

    Allerdings denke ich, dass der gesamte Assembler-Befehlssatz trotzdem im Einstiegskurs gut aufgehoben wäre.

    Ich weiß nicht, ob es nicht auch noch für den Einstiegskurs ein Thema wäre, moderne Assembler mit Labels (wie eben Turbo Assembler, ExAss, Hypra Ass usw.) anzusprechen.

    Ich wäre auf jeden Fall schon mal heiß auf die Fortsetzung mit den anderen Themen.

  • Hallo!

    Ich habe das Kapitel über die Sprite-Programmierung fertiggestellt und auf GitHub zur Verfügung gestellt. Neu hinzugekommen ist der Umgang mit der horizontalen Positionierung in Kombination mit der Speicherstelle 53264.

    lg, Markus

    Hier der Link zum Github - Repo des Assembler-Kurses: Bitte melde dich an, um diesen Link zu sehen.

  • Habs mir heute mal durch gelesen. Jetzt muss man schon ganz schön genau denken. Aber so ist das bei Assembler. Ich muss mir das nochmal in einer ruhigen Minute zu Gemüte führen, heute bin ich zu kaputt. Sieht aber schon gut aus.

  • Mein persönliches Feedback:

    Prinzipiell recht gut verfasst.

    Aber.

    Man sollte bei einer 1:1 Umsetzung zwischen Basic und ML aber auch erwähnen das mache Dinge mit den entsprechenden Befehlen wesentlich einfacher und kürzer bzw schneller wären.

    Also Spritedaten nicht kopieren sondern gleich am richtigen Offset im Speicher definieren.

    Immer gleiche Berechnungen mit dem konkreten Wert ersetzen.

    Zu den einfärbigen Sprites könnte man noch erwähnen das man die auch durch Überlagerung mehrfarbig machen kann.

  • Also Spritedaten nicht kopieren sondern gleich am richtigen Offset im Speicher definieren.

    Die Idee hatte ich tatsächlich auch mal. Man muss nur aufpassen, man kann nur bis $4000 gehen, da der Pointer nicht weiter reicht. Aber das Beispiel liegt ja im passenden Bereich.

    Nachdem ich nochmal drüber geschlafen habe, ist mir aber doch noch eine Bemerkung eingefallen, die wir prinzipiell schon mal hatten.

    Ich denke, spätestens jetzt bei den Sprites sind wir an einem Punkt angekommen, wo die Komplexität zunimmt. Ein Punkt an dem ich gestern zwar müde gegenüber stand, aber ich denke auch in wachem Zustand jetzt langsam problematischer wird, sind die absoluten Adressen. Es wurden schön die Unterprogramme erläutert und später ins Hauptprogramm eingesetzt. Allerdings kann sich der Mensch kognitiv nun mal besser Namen merken, als Zahlen (zumindest trifft das auf den größten Teil zu). Das führt dazu, dass man im Hauptprogramm zwar die Unterprogramme aufruft, aber wieder nicht mehr genau weiß, welches Unterprogramm an welcher Adresse stand. Das macht das Verständnis schwerer. Als Beispiel für sowas kann man das Internet sehen. Dort läuft alles über IP-Adressen. Da sich der Mensch aber solche Adressen schlechter merken kann, hat man den DNS eingeführt (auch wenn man damit noch andere schöne Dinge machen kann).

    Deshalb bin ich der Ansicht, dass es langsam ratsam wäre, einen Assembler mit Labels zu verwenden. Ich denke mal, die Einführung in einen solchen Assembler sollte man schon vor das Kapitel Sprites legen und dort bereits verwenden.

    Als Einführung fand ich das arbeiten direkt im Speicher schon gut, aber inzwischen kommen wir an einen Komplexitätsgrad, an dem es Zeit für einen symbolischen Assembler wird. Der Leser soll sich ja auf das Lernen von Assembler konzentrieren und nicht noch mit dem ständigen Nachsehen "welche Adresse war jetzt wieder für was zuständig?" beschäftigt werden. Das stört den eigentlichen Lernprozess und führt doch eher wieder zu dem Effekt, dass jemand aussteigt und der Kurs sein Ziel nicht erreicht.

    P.S.

    Ich würde auch die Adressen der Register, wie z.B. $D010 usw. durch Labels ersetzen. So wird der Code verständlicher und man kann sich auf die eigentliche Programmieraufgabe konzentrieren.

  • Hallo!

    Das Kapitel über Sprites wird definitiv das letzte Kapitel sein, in dem mit dem SMON gearbeitet wird. Bin gerade am Evaluieren, welchen Assembler ich dann zukünftig verwenden werde.

    Es wird jedoch mit Sicherheit einer werden, der direkt auf dem C64 läuft, also z.B. der Turbo Assembler.

    lg, Markus

    Hier der Link zum Github - Repo des Assembler-Kurses: Bitte melde dich an, um diesen Link zu sehen.

  • Ich würde auch die Adressen der Register, wie z.B. $D010 usw. durch Labels ersetzen. So wird der Code verständlicher und man kann sich auf die eigentliche Programmieraufgabe konzentrieren.

    Am Anfang scheint das vorteilhafter zu sein. Aber mit der Zeit prägen sich die paar Registeradressen schon ein und man findet sich in fremden Quelltexten besser zurecht. Ist ja in Basic auch so. 53280 ist Rahmenfarbe, 53281 ist Hintergrundfarbe usw.

  • Es wird jedoch mit Sicherheit einer werden, der direkt auf dem C64 läuft, also z.B. der Turbo Assembler.

    lg, Markus

    Es ist dir aber schon bewusst,

    das diese Art der Programmierung die unkomfortabelste ist. Anfängern macht man es dadurch nur noch schwerer.

    Ich würde mit Cross-Assembler in gewohnter Moderne, Entwickeln und Debuggen. Auf der echten HW Testen.

  • Ich finde einen Assembler auf dem C64 besser.

    Retro ist Retro :D

    Es geht ja hier erstmal darum Assembler zu lernen.

    Später, bei schwierigeren Aufgaben bzw. längeren Programmen, kann man immernoch auf einen Crossassembler umsteigen - wer mag.

    Es soll Leute geben, die haben Demos im Monitor programmiert. :D

    C64 + SX-64 + Mega65 + Ultimate 2Plus L + 1541 II + 1581 + 1581 Replica + Spectrum N-Go + ZX Touch + Kaktus + Ersatzkaktus :D

  • Bin da ganz Deiner Meinung, damals gabs diese ganzen modernen Entwicklungsumgebungen ja auch nicht und man musste mit dem auskommen was zur Verfügung stand.

    Klar, den VICE gabs damals ebenfalls nicht, den verwende ich jedoch primär für den Kurs (Screenshots) weil das am echten C64 eben problematisch ist.

    Hier der Link zum Github - Repo des Assembler-Kurses: Bitte melde dich an, um diesen Link zu sehen.

  • Ich finde einen Assembler auf dem C64 besser.

    Retro ist Retro :D

    Ich würde das gar nicht wegen Retro bevorzugen, sondern weil man da offen für Plattformen ist. Nimmt man jetzt irgendeine Cross-IDE, so legt mna sich auf ein bestimmtes Betriebssystem fest. Nutzer, die auf einem anderen Betriebssystem arbeiten, können dann nicht richtig mit machen. Und es geht dabei ja eigentlich um den C64. Alle haben einen C64 (oder irgendeinen Emulator), aber unterschiedliche Arbeitssysteme. Von daher finde ich es schon besser, eine gemeinsame Basis zu verwenden. Und das ist nun mal der C64.

    Am Anfang scheint das vorteilhafter zu sein. Aber mit der Zeit prägen sich die paar Registeradressen schon ein und man findet sich in fremden Quelltexten besser zurecht. Ist ja in Basic auch so. 53280 ist Rahmenfarbe, 53281 ist Hintergrundfarbe usw.

    Ja, aber:

    Anfängern macht man es dadurch nur noch schwerer.

    Genau aus diesem Grunde finde ich, dass man die ganzen Adressen erstmal außen vor lassen sollte. Natürlich muss man diese benutzen. Aber um es dem Anfänger leichter zu machen, bietet sich da eher an, dass er weiß, es gibt eine solche Adresse, diese ist auch am Anfang des Programms definiert, später im Code wird diese allerdings dann durch einen Alias ersetzt, wo der Anfänger auch gleich etwas damit anfangen kann.

    Man sollte immer den Zweck des Kurses im Auge behalten. Zweck des Kurses ist ja, dass der Leser Assembler lernt, und nicht die Adressen des C64. Sicherlich hast Du schon Recht, dass man sich besser in Programmen im Speicher zurecht findet, wenn man die Adressen verinnerlicht hat. Das ist aber erstmal nicht Ziel dies Kurses und überfordert den Leser nur. Immer alles der Reihe nach. Wenn man den Leser überfordert, steigt er aus und der Kurs war für die Katz.

    Das ist genau der Punkt, der meiner Meinung nach im überwiegenden Fall der Einführungsvorlesungen in die Programmierung falsch gemacht wird. Nicht nur, dass der Lerner mit Programmierung klar kommen sollen, nein man überfordert sie gleich noch mit einer hochkomplizierten Programmiersprache. Da lobe ich mir die Vorlesung von Klaus Knopper. Der hat das verstanden.

    Deshalb würde ich auch dafür plädieren, dass der Sprite-Teil auf einen symbolischen Assembler umgestellt wird. Ich meine, es ist Markus's Kurs. Aber ich vermute, dass bei der derzeitigen Version schon einige überfordert werden und aussteigen. Das wäre echt schade, weil ich den Kurs wirklich gut finde.

  • Es soll Leute geben, die haben Demos im Monitor programmiert. :D

    Auf Computern mit eingebautem Monitor (Apple 2, C 16) wurden damit auch kommerzielle Spiele programmiert.

    Ja, aber das waren mit Sicherheit keine Anfänger. Für Anfänger muss man es schon einfach machen, damit sie nicht aussteigen.

  • Genau aus diesem Grunde finde ich, dass man die ganzen Adressen erstmal außen vor lassen sollte. Natürlich muss man diese benutzen. Aber um es dem Anfänger leichter zu machen, bietet sich da eher an, dass er weiß, es gibt eine solche Adresse, diese ist auch am Anfang des Programms definiert, später im Code wird diese allerdings dann durch einen Alias ersetzt, wo der Anfänger auch gleich etwas damit anfangen kann.

    Man kann sich Wörter auch leichter merken als Zahlen.

    Das GEOS-MegaAssembler-Buch hatte ja auch einen Einsteigerkurs im Buch und nur ganz am Anfang werden direkte Einsprungadressen verwendet. Aber schon kurze Zeit später werden nur noch die Labels verwendet (und die Adressen ggf. bei neuen Labels 1x erwähnt).

    Im Monitor arbeitet man ja nur selten, aber zugegebenermaßen sind dann die Adressen hilfreich. Häufiger arbeitet man im Assembler, und da ist es eben einfacher "jsr DoMenu" zu schreiben als "jsr $c151".

    Daher fände ich es zum Einstieg auch einfacher Labels zu verwenden. Man kann ja im Anhang dann so eine Liste wie die von Drachen auflisten, wo die gebräuchlichsten Adressen aufgeführt sind. Die kann man dann per Include-Anweisung in den eigenen Quelltext einbinden und muss sich dann nicht mehr um Adressen kümmern.

    OK, im Monitor geht das eben nicht, daher würde ich den Einsatz des Monitors auf ein paar Schritte am Anfang begrenzen und so früh wie möglich mit dem Assembler beginnen. Gut wäre wenn es einen Assembler gibt mit dem man einfache Programme schreiben, assemblieren, testen kann, ohne den Assembler danach jedes mal wieder neu laden zu müssen. Kenne mich da aber nicht aus (z.B. nach $C000 assemblieren, starten, und über RUN zurück zum Assembler...)

    Für den Einsatz im Monitor hab ich ja dann später die Label-Liste, wenn die sortiert ist, dann findet man die Adresse zu einem Label recht schnell...

    Es ist auch für das Verständnis beim lesen eines Quelltextes hilfreich wenn man Labels verwendet. Selbst die kryptischen Adressen im C64-ROM (SETLFS, OPENCHN, CHKIN usw..) sind immer noch verständlicher als die ROM-Adressen selbst.

    Im Assembler kann man auch Kommentare ergänzen. Auch das macht vieles einfacher...

    Just my 2ct...

    P.S. Hab mir eben die aktuelle Version auf GitHub angeschaut, schon vieles erklärt :thumbup:

  • Bin da ganz Deiner Meinung, damals gabs diese ganzen modernen Entwicklungsumgebungen ja auch nicht und man musste mit dem auskommen was zur Verfügung stand.

    Den Kurs auf dem C64 zu machen, ist sicher die richtige Wahl. Unabhängig davon ist man aber immer bestrebt, die bestmögliche Entwicklungsumgebung zu verwenden. Daher ist es gut, dass man Assembler heute nicht wie damals angehen muss, denn die Nutzung einer geeigneten Assemblersoftware auf dem C64 kann man durchaus auch zu den Einstiegshürden zählen. :)

    Gerade der Komfort, den man auf einem PC mit all den Tools zur Entwicklung von C64 Software hat, hilft beim Überblick und somit dem Verständnis von Assemblercode. Ohne das C64 Studio am PC, wo man mehr als 25 Zeilen hat und ausgiebig kommentieren kann, hätte ich keinen erneuten Ausflug in die C64 Assemblerwelt unternommen. Auch wenn man Assembler dann (besser) versteht und kleine Programme realisieren kann, kann es einem immer noch schwerfallen, in Maschinensprache kreativ zu werden.

    Cool, dass du diesen Assembler Kurs erstellst. :thumbup:

  • ch überlege mir gerade welche Themen ich in diesem Kurs eigentlich noch behandeln will.

    Man muss nur aufpassen, man kann nur bis $4000 gehen, da der Pointer nicht weiter reicht. Aber das Beispiel liegt ja im passenden Bereich.

    Bankswitching und die Funktion von $d018 wäre definitiv ein geeignetes Thema. ;)

    Wenn einer, der mit Mühe kaum, geklettert ist auf einen Baum, schon meint, daß er ein Vogel wär, so irrt sich der.

    Wilhelm Busch