Meine Einführung in C64 Maschinensprache / Assembler

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

  • Meine Gründe waren warum ich da nicht weider gemacht habe, gut erklärte Beispiele zu finden.

    Beispiele im Assmbler gab es ja sehr viele, aber ich wollte für mich immer Wissen warum so und nicht anders programmiert wurde.

    Anhand von guten Beispielen lernt man besser als durch rein theoretische Beschreibungen.

    Wichtig ist halt Learning by Doing.

    Genau, sich auch die Hände schmutzig machen. Nur lesen und anschauen verfliegt wieder schnell.

  • 64erGrufti hat da schon recht, die Zielgruppe sind jene Nutzer die bereits in Basic am C64 programmiert haben, nun aber auch in Maschinensprache / Assembler einsteigen wollen.

    Das ist ja auch richtig, man braucht in einem solchen Kurs ja nicht zu erklären, wo der Computer eingeschaltet wird. Da kann man sagen: Lies erst die Bedienungsanleitung, dann lies das BASIC-Handbuch, z.B. die Abschnitte über PEEK/POKE und Speicherstellen sowie über Binär- und Hex-Zahlen. Und auf der Grundlage dieses Wissens beschäftige Dich dann mit dem Assembler-Kurs. Finde ich richtig so.

  • Wie habt ihr denn bisher so versucht in die Thematik reinzufinden und was waren die Gründe warum ihr dann wieder aufgegeben habt euch damit zu beschäftigen?

    Bei BASIC hatte man vollständige Befehle und konnte sofort loslegen. Für Assembler brauchte man erstmal einen solchen und musste sich die "komplexeren Befehle" erarbeiten, diese Einstiegshürde war wohl zu hoch. Das Reindenken in das DEZ BIN HEX Geschubse mit A X Y und den Speicheradressen war abstrakt und ich hatte den Anfang des Fadens nie wirklich gefunden. Da auch die Vision fehlte, bzw. es zu kompliziert erschien, in Assembler sowas wie ein Spiel zu erschaffen, hab ich resigniert. Weiss gar nicht mehr, was ich damals probiert hatte. Ein älterer Kumpel hatte ein Maschinensprachebuch gekauft, glaube ich, aber das verlief auch im Sand. Unter den Freunden gab es leider keine ambitionierten Programmierer, ich stand ziemlich allein auf weiter Flur.

    Heutzutage mit den Tools am PC und dem grenzenlosen Internet hat man mehr Überblick und es fällt viel leichter. Dass ich Jahrzehnte später tatsächlich was in Assembler auf dem C64 programmiert bekomme, hätte ich damals nicht gedacht. Dennoch werd ich auf Beginnerlevel bleiben. Der Gedanke, dass man Assembler jetzt (besser) versteht, reicht völlig aus. :)

  • Wie habt ihr denn bisher so versucht in die Thematik reinzufinden und was waren die Gründe warum ihr dann wieder aufgegeben habt euch damit zu beschäftigen?

    Für mich ist ein großes Problem, daß man in Assembler nicht ohne weiteres Text ausgeben kann. Wie soll ich denn sehen, wenn was schiefläuft, wenn ich nichtmal mit "PRINT" ("printf", "writeln" oder was auch immer) die Werte von Variablen oder von mir aus Registern ausgeben kann?

    Und schon das grundlegende "Hello World" ist erstmal gar nicht möglich. Wo also anfangen?

    (In dem Spectrum-Video oben wird eine Entwicklungsumgebung namens "ZX Spin" benutzt, in der man im Debug-Modus die Assemblerbefehle in einem großen Programm schrittweise ausführen kann, und dann die Werte aller Register in einem speziellen Fenster angezeigt bekommt. Sowas bräuchte man wohl mindestens. (Daran war damals, 1982, aber gar nicht zu denken. Vermutlich hatten das professionelle Entwickler aber schon auf ihren Workstations. Aber halt nicht der "gemeine Harry" :) .))

  • Und klein anfangen!

    Ich denke, das ist der wichtigste Ratschlag überhaupt!

    Ziele sind gut, aber sie müssen auch zum Budget passen.

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • Wie habt ihr denn bisher so versucht in die Thematik reinzufinden

    So Mitte 80er, als ich Basic einigermassen autodidaktisch drauf hatte und kapierte, da sah ich in Zeitschriften Assembler-Listings, und verstand absolut nur Bahnhof. Da stand auch schonmal was von "Monitor", aber das war für mich die Kiste wo der blaue Startbildschirm erscheint, und mir war nicht ersichtlich was das damit zu tun haben sollte. Bis ich dann irgendwann mal in einem Bibliotheksbuch erwähnt sah, was "Assemblercode schreiben" beinhaltet, womit man das macht, und wie daraus etwas mit SYS Ausführbares wird. Ab da ging's leichter. Lehre daraus: unbedingt auch die Werkzeuge erklären. Danach kam dann auch mehr Systemkenntnis dazu, so dass all die schicken Erklärungen und Tricks in Zeitschriften gleich viel mehr Sinn machten...

    was waren die Gründe warum ihr dann wieder aufgegeben habt euch damit zu beschäftigen?

    Naja, man wurde älter, andere Interessen überwiegten, das Leben kam einem in die Quere...

    Bis ich vor ein paar Jahren damit begonnen habe, in Code rumzuschnüffeln um all meine alten Originaldisks zu cracken, hatte ich so ziemlich alles "von früher" vergessen.

  • Wie habt ihr denn bisher so versucht in die Thematik reinzufinden und was waren die Gründe warum ihr dann wieder aufgegeben habt euch damit zu beschäftigen?

    Für mich ist ein großes Problem, daß man in Assembler nicht ohne weiteres Text ausgeben kann. Wie soll ich denn sehen, wenn was schiefläuft, wenn ich nichtmal mit "PRINT" ("printf", "writeln" oder was auch immer) die Werte von Variablen oder von mir aus Registern ausgeben kann?

    Und schon das grundlegende "Hello World" ist erstmal gar nicht möglich. Wo also anfangen?

    (In dem Spectrum-Video oben wird eine Entwicklungsumgebung namens "ZX Spin" benutzt, in der man im Debug-Modus die Assemblerbefehle in einem großen Programm schrittweise ausführen kann, und dann die Werte aller Register in einem speziellen Fenster angezeigt bekommt. Sowas bräuchte man wohl mindestens. (Daran war damals, 1982, aber gar nicht zu denken. Vermutlich hatten das professionelle Entwickler aber schon auf ihren Workstations. Aber halt nicht der "gemeine Harry" :) .))

    Das kann man gar nicht oft genug betonen: Fast jeder Kurs fängt mit irgendwelchen Erklärungen zu Binär, Op Codes, 2er Komplement und Zahlensystemen an. Das, ganz ehrlich, interessiert gerade am Anfang niemanden (pauschale Vermutung)!

    Und ich halte es auch nur begrenzt für sinnvoll, 2er Komplement ist blanker Unsinn in der Phase.

    Ich fand es hier ganz gut dass dies kaum vorkommt.

    Einfach machen: Mit einfachsten Mitteln direkt in den Bildschirm und in die Register! Man muss sofort was sehen und Erfolge bekommen und das gilt nicht nur für die angeblich "heutige Jugend", das ist mir Anfang 80er auch schon so gegangen.

    Zum Debuggen:

    Ja, das IST ein Problem. Aber dank Entwicklungsumgebungen und Emulator kann man das umgehen. Nur ist das auch zu Beginn recht komplex.

    Daher: Ich finde es gerade sehr spannend auch hier wieder alternative Lösungswege aus den 80ern und 90ern auszugraben:

    - Log Ausgaben:

    Werte direkt in den Screen: A=1 B=2 (Zeichen in ASCII Tabelle suchen), diese entweder direkt oder korrespondiert als Marker ausgeben.

    - Einzelschritt Modus:

    Immer in kleinen Schritten durch das Programm, nie zu viel testen in Assembler. Kleine Blöcke. RTS setzen mittendrin.

    - Fortschrittsmarker

    Wo ist das Programm gerade, bis wohin lief es und ab wann nicht mehr? Screen, Farben, Bildschirm Rahmenfarbe als Signalfarbe nutzen.

    - Modular

    Das Programm in kleine Blöcke aufteilen. Bevor man später größere Zusammenhänge bearbeitet, das Problem in kleine Teile bereits im Konzept aufteilen.

    - Nicht optimieren

    Und wenn es noch so blöd aussieht und offenbart dass die Mathekenntnisse gegen Null gehen: Egal! Wen interessierts? Wenn die Software läuft kann man in späteren Iterationen optimieren.

    - OS nutzen

    Du kannst mit dem Kernel schon etwas ausgeben, am Anfang würde ich den noch nicht abstellen. Es gibt dort eine Reihe nützlicher Funktionen.

    - Details!

    Assembler verzeiht nichts! Jede kleine Abweichung in einem Befehl kann stundenlanges Suchen nach sich ziehen!

    Beispiel: STA verändert keine Flags, LDA schon! (Zero, Negative). Das kann in einer Schleife dysfunktional werden wenn nach einem DEY noch ein LDX,LDA,LDY folgt vor BNE / BEQ, zum Beispiel bei Schleifen die auf den Punkt ohne Null runterzählen sollen.

    Daher: Lernen genau auf die Befehle und Adressarten zu schauen! z.B. Bei LDA <ADRESSLABEL das # vergessen?)

    Wie man das einem Anfänger beibringt ohne zu desillusionieren wäre noch eine Aufgabe...

    - Talk to the duck!

    Sinnvolle Methode kann sein: Talk to the Duck -> Lest eurer Ente (oder was auch immer) genau das vor was der Befehl tun soll und kontroliert ob das auch so dort steht.

    Bitte melde dich an, um diesen Link zu sehen.

    btw Hello World ist wirklich sehr einfach! Es liegt nur daran wie man es erklärt bekommt. Aber ich weiss was Du meinst: ja

  • Aber dank Entwicklungsumgebungen und Emulator kann man das umgehen.

    Laut Beschreibung auf der Wiki-Seite soll SMON das auch können. Ich habs noch nicht ausprobiert. Dann sollte es jedenfalls auch ohne Emulator direkt am C64 gehen.

    Das wäre vielleicht auch eine Idee, mit in den Kurs zu integrieren, dass man mal "live" zu schaut, wie sich die Register und Adressen verändern (soweit das mit SMON geht).

  • Das kann man gar nicht oft genug betonen: Fast jeder Kurs fängt mit irgendwelchen Erklärungen zu Binär, Op Codes, 2er Komplement und Zahlensystemen an. Das, ganz ehrlich, interessiert gerade am Anfang niemanden (pauschale Vermutung)!

    Genau das erwarte ich persönlich von einem Kurs. ;)

    Es gibt verschiedene "Lehrtypen" und auch verschiedene "Lerntypen".

    Ich zum Beispiel wollte und will bei einem Thema erst einmal eine grundlegende Einführung und Erklärung, um was es im Ganzen geht, damit ich eben weiß, was ich lerne. Und danach mit Beispielen ins Detail gehen.

    Wenn ich ohne Hintergrundinfo zuerst Beispiele sehe und im Grunde keinen blassen Schimmer habe, was da eigentlich passiert, dann interessiert mich das auch nicht so, es weckt nicht meine Neugierde, weil ich die übergeordneten Zusammenhänge überhaupt nicht verstehen kann.

    Andere wollen es lieber genau andersherum. Ist ja nicht schlimm und auch gut so. :)

  • Für den Beginn würde ich nicht sofort in ein Listing einsteigen sondern den Direktmodus nutzen und kurz erläutern.

    Was meinst Du mit dem "Direktmodus"?

    Im Original:

    Bitte melde dich an, um diesen Link zu sehen.

    (Seite 3 unten unter der Tabelle)

    Oder:

    Bitte melde dich an, um diesen Link zu sehen.

  • Ja, bin genau bei Dir. Es ging mir um die Balance.

    Ohne Kontext war auch nicht gemneint, nur so viel Kontext, dass Anfänger mitkommen können. Kontext der 8 Stunden später mal wichtig werden könnte ist auch nicht gut.

    Moderne Kurse lassen dem Lernenden die Wege offen: Willst du jetzt mehr über den Hintergrund oder weiter Experimentieren?

  • Im Original:

    Bitte melde dich an, um diesen Link zu sehen.

    (Seite 3 unten unter der Tabelle)

    Oder:

    Bitte melde dich an, um diesen Link zu sehen.

    Das geht aber doch im Assembler gar nicht. Zumindest ist mir da nix bekannt. Spätestens wenn BNE etc. kommen, ist damit auf jeden Fall Schluss.

    Genau das erwarte ich persönlich von einem Kurs. ;)


    Es gibt verschiedene "Lehrtypen" und auch verschiedene "Lerntypen".

    Genau deswegen mein Vorschlag, ein Einführungskapitel zu machen, was aber so gestaltet ist, dass man auch im nächsten Kapitel starten kann, wenn man die Grundlagen schon kennt.

  • Oder:

    Bitte melde dich an, um diesen Link zu sehen.

    Das geht aber doch im Assembler gar nicht. Zumindest ist mir da nix bekannt. Spätestens wenn BNE etc. kommen, ist damit auf jeden Fall Schluss.

    Das bezog sich direkt auf Seite 1 den zweiten Satz des PDF "Wenn wir unseren C64 einschalten können wir sofort in BASIC programmieren."

    Können wir, aber auf Seite 3 des PDF: "Und das ist überhaupt kein Problem, denn dies können wir aus Basic heraus mit dem BASIC Befehl

    POKE 5376,162 durchführen."

    Das machst Du auf Seite 4 auch dann (Bild), das ist der Direktmodus und nicht das Listing.

    Du kannst ja einfach auch POKEn ohne LISTING. Bleibt alles im Speicher und kann aufeinander aufbauen (Sofern man die Kiste nicht abschiesst wg Tippfehler)

  • Daran war damals, 1982, aber gar nicht zu denken. Vermutlich hatten das professionelle Entwickler aber schon auf ihren Workstations. Aber halt nicht der "gemeine Harry"

    Die GEOS-Emtwickler benutzten einen "In Circuit Emulator" (ICE), Kostenpunkt 5000 Dollar.

    docbobo berichtete: Bitte melde dich an, um diesen Anhang zu sehen.

  • Du kannst ja einfach auch POKEn ohne LISTING. Bleibt alles im Speicher und kann aufeinander aufbauen (Sofern man die Kiste nicht abschiesst wg Tippfehler)

    Ich verstehe jetzt immer noch nicht das Problem. markusk2020 fängt erstmal mit dem Direktmodus auf S.5 an. Dann macht er das in ein Listing. Das finde ich aber auch nicht falsch. Ein Listung hat den Vorteil, dass ich es abspeichern kann. Außerdem kann ich Änderungen vornehmen, falls ich etwas falsch gemacht habe. Klar kann man auch direkt mit einem Listung anfangen. Aber das erste Beispiel ist noch so einfach und kurz, da finde ich das schon OK. Markus arbeitet sich Stück für Stück vor. Zu große Schritte wären für einen Anfänger vielleicht schon zu viel.

    in der man im Debug-Modus die Assemblerbefehle in einem großen Programm schrittweise ausführen kann, und dann die Werte aller Register in einem speziellen Fenster angezeigt bekommt. Sowas bräuchte man wohl mindestens. (Daran war damals, 1982, aber gar nicht zu denken. Vermutlich hatten das professionelle Entwickler aber schon auf ihren Workstations. Aber halt nicht der "gemeine Harry" :) .))

    Also Debuggen scheint man mit SMON schon zu können. Es gibt Trace und Breakpoints. Und das Ding ist laut Wiki von 1985. Zumindest da fing sowas an.

  • Ohne Kontext war auch nicht gemneint, nur so viel Kontext, dass Anfänger mitkommen können.

    Das ist eben so'n Punkt, wo man schnell und unvermeidlich an der Zielgruppe vorbeischiesst, denn "den" Anfänger gibt es nicht. Das ist eine heterogene Gruppe mit sehr unterschiedlichen Vorkenntnisabstufungen. Entweder man baut vorne die ganzen lästigen Grundlagen mit Bienen und Blumen Bits und Bytes ein (die man im Zweifelsfall als Rezipient ja auch überspringen kann), oder man definiert am Einstieg, was für Vorkenntnisse und Werkzeuge so einigermassen vorhanden sein sollten.

  • Entweder man baut vorne die ganzen lästigen Grundlagen mit Bienen und Blumen Bits und Bytes ein (die man im Zweifelsfall als Rezipient ja auch überspringen kann), ...

    Ich habe es auch schon öfter direkt hingeschrieben in Büchern gelesen, dass man die ersten Kapitel auch überspringen kann, wenn man über den Inhalt schon genug weiß. Finde ich auch ganz in Ordnung so. Man fängt vorne quasi "bei Null" an und arbeitet sich dann immer mehr Wissen an. Das Schöne finde ich an so einem Vorgehen, dass das Buch an sich "ein Ganzes" ist. Das hat von vorne bis hinten einen aufbauenden roten Faden, auf dem der Leser je nach Kenntnisstand aufspringen kann.

  • Ohne Kontext war auch nicht gemneint, nur so viel Kontext, dass Anfänger mitkommen können.

    Das ist eben so'n Punkt, wo man schnell und unvermeidlich an der Zielgruppe vorbeischiesst, denn "den" Anfänger gibt es nicht. Das ist eine heterogene Gruppe mit sehr unterschiedlichen Vorkenntnisabstufungen. Entweder man baut vorne die ganzen lästigen Grundlagen mit Bienen und Blumen Bits und Bytes ein (die man im Zweifelsfall als Rezipient ja auch überspringen kann), oder man definiert am Einstieg, was für Vorkenntnisse und Werkzeuge so einigermassen vorhanden sein sollten.

    Genau das ist der Punkt. Deshalb ja der Vorschlag, Einführungskapitel, was man bei bedarf überspringen kann. So kann man jeden mit nehmen.

    Aber selbst im gesamten Lauf des Kurses ziehen sich diese Unterschiede durch. Der eine lernt schnell, der andere braucht länger. Für einen schnell lernenden ist das vielleicht viel zu ausführich erklärt und er langweilt sich zwischendurch immer. Für einen anderen ist es vielleicht schon zu schnell, oder gerade noch so richtig. Das kannst Du aber nur mit einem dynamischen Kurs handeln. Mit einem starren Buch geht das nicht. Da muss man einfach einen Mittelweg finden.

    Gleiches gilt für die Lehrmethoden. Keine Lehrmethode ist die ultimative. Der eine versteht es, wenn es Dozent A eklärt, der andere versteht da nur Bahnhof und mag lieber Dozent B. Das sind ganz natürliche Unterschiede und man wird auch nie alle unter einen Hut bekommen. Deshalb sind in der Lehre Lerngruppen gut. Da kann ein Teilnehmer, der es vom Dozenten verstanden hat, es vielleicht jemand anderem auf andere Weise erklären.

  • Mit einem starren Buch geht das nicht. Da muss man einfach einen Mittelweg finden.

    Bei einem Buch muss ich als Käufer/Leser entscheiden, ob mir der dortige Weg zusagt oder nicht. Kein Buch oder Kurs ist "für alle" geeignet. Das liegt in der Natur der Sache. ;)

  • Hallo zusammen!

    Falls ich am Wochenende Zeit finde werde ich das Kapitel über den Stack und die Unterprogramme fertigstellen bzw. das Dokument dann auf GitHub stellen.

    Am Ende des Kapitels stelle ich ein Programmbeispiel vor in dem zur Wiederholung und Festigung so ziemlich alles vorkommt was vorher gezeigt wurde. Es ist jetzt kein seitenlanges Listing (nur rund 50 Zeilen), aber doch schon ein wenig anspruchsvoller als die vorherigen Programme weil die einzelnen Puzzleteile eben zu einem größeren Ganzen zusammengesetzt werden.

    Nach diesem Kapitel lege ich jetzt mal einen Stopp ein um Korrekturen vorzunehmen bzw. den einen oder anderen Verbesserungsvorschlag einfließen zu lassen.

    Abschließend ein paar Fragen an diejenigen unter euch die geschrieben haben, dass sie vorher noch nie oder nur wenig mit Maschinensprache / Assembler zu tun hatten und den Kurs eventuell sogar selber im Emulator oder am echten C64 durchgespielt haben:

    1. Ist euch der Einstieg in Maschinensprache / Assembler dadurch leicht oder zumindest leichter als bisher gefallen?
    2. Hat das Tempo gepasst bzw. waren die Beispiele dem Wissensstand angemessen der bis dahin vermittelt wurde?
    3. Hab ich die Beispiele ausreichend gut erklärt sodass klar war was in dem Programm geschieht?

    lg, Markus

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