letzter Beitrag von -trb- am
Wenn ihr heute erst mit Assembler anfangen würdet...
- tilobyte
- Erledigt
-
-
... dann mit diesem Buch.
Das habe ich auch und kann es nur empfehlen. Man fängt da klein an und die Beispiele sind so beschrieben das sie auch auf anderen 6502 basierten Systemen funktionieren.
-
Das habe ich auch und kann es nur empfehlen. Man fängt da klein an und die Beispiele sind so beschrieben das sie auch auf anderen 6502 basierten Systemen funktionieren.
Das finde ich nicht schlecht, dass man von Anfang an unterscheiden kann, was C64-Hardware ist und was 6502.
-
Man fängt da klein an und die Beispiele sind so beschrieben das sie auch auf anderen 6502 basierten Systemen funktionieren.
Da einige offensichtlich diesen Satz nicht verstanden haben, eine kurze Erklärung.
In dem Buch wird primär die Programmierung des 6502 beschrieben. Da diese CPU
aber auch in anderen Computern vorkommt, hat man die Beispiele immer entsprechend,
meist sind es nur Adressen, an den jeweiligen Computer angepasst.
-
Wurde das hier schon genannt ?
https://www.assemblytutorial.com/
Mit Beispielen für viele viele Systeme, einige C64 Beispiele sind auch unter 6502 zu finden
-
Da einige offensichtlich diesen Satz nicht verstanden haben, eine kurze Erklärung.
Dann habe ich ja alles richtig verstanden.
-
Meine Erfahrung: 6502 Assembly lernen und verstehen ist das eine. Um erfolgreich Ergebnisse auf einem 8-Bitter wie C64/128 zu erziehlen, ist aber auch das Verständnis der jeweiligen Hardware unumgänglich.
Ich habe mit dem Studium von Assemblerlistings angefangen und versucht mit Hilfe von Büchern nachzuvollziehen (wobei nicht jedes Buch hilfreich war), was wo wie und wan im Programm passiert. Dann habe ich versucht das in meinen eigenen Kreationen für meine Zwecke abgewandelt einzusetzen. Kommentierte Listings sind da natürlich am Anfang das Mittel der Wahl gewesen. Später dann auch unkommentierte reversed. Mache ich teilweise immer noch so. Heute hat man ja auch uneingeschränkten Zugang zu allen Informationen die man braucht. War ja früher auch nicht so einfach und oft auch eine Geldfrage.
Für mein Verständnis sollte es aber für interessierte Menschen kein Problem darstellen, die an der Lösung von Problemen (was anderes ist das Programmieren nämlich nicht) Spaß hat. Da kommt eigentlich keine lange Weile auf und so lange man gerne Probleme löst, bleibt auch die Motivation erhalten, bis das Problem programmtechnisch gelöst ist und sich ein Erfolg einstellt. Dran bleiben!
-
Wurde das hier schon genannt ?
https://www.assemblytutorial.com/
Mit Beispielen für viele viele Systeme, einige C64 Beispiele sind auch unter 6502 zu finden
Wer Papier mag: der Autor dieser Seiten hat inzwischen auch zwei Bücher geschrieben.
- Learn Multiplatform Assembly Programming (Z80, 6502, 68k, '86, ARM)
- Learn Multiplatform Assembly Programming 2 (ARM-Thumb, 65816, 6809, PDP-11, RISC-V)
Aber es sicher zielführender, sich am Anfang erstmal auf eine bestimmte CPU und ein konkretes System (also wohl 65xx und C64) zu konzentrieren, und dort sattelfest zu werden.
Was vielleicht ganz witzig sein kann, ist so eine Web-basierte Kombi aus IDE und Emulator wie beim 8-Bitworkshop:
-
Wer Papier mag: der Autor dieser Seiten hat inzwischen auch zwei Bücher geschrieben.
Die beiden Bücher habe ich mir auch gekauft. Ich bin auf sie über den Youtubekanal des Autors aufmerksam geworden, den ich einfach mal hier verlinke:
https://www.youtube.com/c/ChibiAkumas
Wer dem Autor den Besitz der physischen Bücher nachweist, indem er ihm davon ein Foto per E-Mail schickt, bekommt dafür kostenlos das entsprechende eBook zugeschickt.
Ansonsten ist der Kanal selber höchst empfehlenswert. Es gibt unzählige Videos zur Assemblerprogrammierung. Teilweise ganz allgemein, oder eben speziell für eine konkrete Plattform, wobei er eine große Bandbreite von Computern und Spielkonsolen abdeckt. Auch der allgemeine Grundlagenkurs zur Assemblerprogrammierung, der in beiden Büchern enthalten ist, ist auf seinem Kanal zu finden, aufgeteilt auf 11 Videos.
-
Anreiz war für mich immer etwas, was sonst (unter BASIC) wirklich lange dauert schnell hinzu bekommen oder wo sich am Bildschirm etwas tut.
Klassiker:
* ROM ins RAM kopieren - hier lernt man mit Zeiger und Adressen, Zähler und Schleifen zu hantieren, sei es fürs BASIC-ROM oder Character-ROM ...
* Bildschirm und/oder Bildschirmfarbe füllen - auch hier Zeigermanipulation im Bereich von 0 bis 999, also Umgang mit 16-Bit-Adressen.
* Hires-Grafik: da kommen schon etwas komplexere Zeigeroperationen und Adressberechnungen vor und Bit-Manipulationen. Schon alleine das Löschen der Grafik (oder generell von Speicherbereichen) kann einen schon ein kleines Wow heraus locken (wenn man weiß, wie sich BASIC hier plagt).
* Scrollen (kein Finescrolling, ganz einfach), um das Kopieren von Speicherbereichen zu verinnerlichen und gleichzeitig einen optischen Effekt bekommt.
* Spritedatenfinder: Daten per Tastensteuerung aus verschiedenen Speicherbereichen in ein dargestelltes Sprite kopieren (um Spritedaten zu suchen). Hier kann man den Umgang mit der Tastatur und das Speicherkopieren aneignen.
Das aber immer wieder im Abgleich mit bestehenden Lösungen. Diese Art von Reverse-Engineering und Analysen anderer Programme sind immer sehr aufschlussreich.
Man kann es auch vorsichtig angehen lassen, indem man bestehende kleine Programme nimmt und diese (etwa mit einem Monitor) ändert und die Effekte beobachtet.
-
Anreiz war bei mir anfangs eigentlich hauptsächlich die Neugier, wie ein Mikroprozessor funktioniert und programmiert wird.
Damals war ich scharf auf alles, was sich programmieren ließ.
-
Schon alleine das Löschen der Grafik (oder generell von Speicherbereichen) kann einen schon ein kleines Wow heraus locken (wenn man weiß, wie sich BASIC hier plagt).
So ist es! Das Löschen des Grafikspeichers über eine BASIC-Schleife gehörte sicher bei vielen C64-Besitzern zu den Schlüsselmomenten ihrer Laufbahn. Meistens wurde in den Abtipp-Programmen schon mal auf den Grafikmodus umgeschaltet und dann erst der Grafikspeicher gelöscht, sodass man dabei zusehen konnte. Das bizarr langsame, kaskadenförmige Dahinschwinden des Grafikmülls sorgte für Erstaunen und Ratlosigkeit.
Wenn man dann vielleicht mal eine entsprechende Maschinenspracheroutine abgetippt hatte, schien dieser Vorgang einfach nicht mehr zu existieren. Der Grafikspeicher war einfach auf Knopfdruck frei.
-
Zum Beispiel muss man erstmal wissen, was die Register A, X und Y sind und wozu man die braucht. LDA heisst "Lade in den Akkumulator", aber wozu ist der gut und warum sollte man das ueberhaupt tun?
Kleine fertige Beispielprogramme nachvollziehen und verstehen. Das hilft ungemein.
Mit Sicherheit, aber die erklaeren einem auch nicht unbedingt was ein Register ueberhaupt ist. Und warum man immer alles in einen "Akkumulator" laden muss usw. Ich denke dieses Grundwissen sollte man sich schon irgendwie anlesen bzw. erklaert bekommen.
So gings mir damals. Viel Basic-Listings abgetippt und den Ballon und ähnliches aus Büchern gemacht und einfache Programme mit paar Sprites usw. Also wirklich nur Basics. War dann aber sehr motiviert und wollte unbedingt dieses sagenumwobene superschnelle Assembler lernen. Also Taschengeld für ein Buch (keine Ahnung mehr was für eins das war) zusammengespart und losgelegt.
Die Ernüchterung kam aber recht schnell. Ich wusste einfach nicht wieso in dem Buch bestimmte Dinge gemacht werden. Es zeigte wohl auch Register und die Umrechnung usw. - also den Grundstock an Wissen an, aber schon bei den einfachsten Befehlen fragte ich mich immer: Wieso macht der das?
Bei Basic konnte man gleich mit Schleifen und Co. loslegen, nach dem Alter fragen, diese mit einfacher Mathe in Tage umrechnen lassen, einen nach dem Namen fragen und ihn damit begrüßen usw. Bei Assembler kam das (zumindest am Anfang des Buchs) überhaupt nicht auf. Alles wirkte so abstrakt auf mich und das wollte einfach nicht in meinen Kopf wieso man das macht. Lade Zahl soundso in das Register soundso, ja, gut und schön, aber wie bekomme ich damit ein einfach Programm zum laufen das (wie oben erwähnt) einfach eine nach dem Namen des Users fragt und ihn begrüßt (nur so als Beispiel, von komplexerem war nicht mal zu träumen).
Auf jeden Fall hab ich dann irgendwann den Stecker gezogen, weil ich einfach nicht weiter gekommen bin. Vielleicht war ich auch zu jung und zu ungeduldig, oder das Buch einfach schlecht.
Hab oft andere Bücher im Buchladen über Assembler aufgeschlagen und darin geschmökert, aber die waren MIR alle zu abstrackt und es wollte einfach nicht in meinen Kopf, wie man überhaupt anfängt ein Programm zu schreiben wenn man gefühlt nur Register/Zahlen hin und herschiebt - von der Unübersichtlichkeit fange ich lieber gar nicht erst an. ;DHab dann auch mal auf YT gesucht um mir überhaupt die Arbeitsweise eines Computers verständlich zu machen. Der Grundaufbau war dann halbwegs klar, aber dann kam immer ein Sprung über die Springfield-Schlucht und plötzlich wurde nur noch Chinesisch erklärt und ich war wieder mal raus. Auch heute such noch noch ab und an bei YT um mir das erklären zu lassen - also wie man überhaupt auf die Idee kam damals Computer so zu bauen und wie die ersten Programmierer/Pioniere das bewerkstelligen konnten darauf Programme zu schreiben. Aber auch hier gibts wohl nur Computererlärungen für Dummies und Hawking-User erklärt wie man etwas macht. So etwas, was nach dem einfachen Aufbau eines PC kommt und wie dann überhaupt einfachste Programme von diesem ausgeführt werden fehlt mir immer noch - was ich sehr schade finde, weil mich es halt wirklich interessiert und es einfach nicht in meinen Kopf will. :-/
-
Die Ernüchterung kam aber recht schnell. Ich wusste einfach nicht wieso in dem Buch bestimmte Dinge gemacht werden. Es zeigte wohl auch Register und die Umrechnung usw. - also den Grundstock an Wissen an, aber schon bei den einfachsten Befehlen fragte ich mich immer: Wieso macht der das?
Dann war's vielleicht einfach das falsche Buch. Ein gutes Buch sollte die wesentlichen Grundlagen erklären.
Manchmal liegt's aber auch am Vorwissen. Assemblerprogrammierung ist sehr hardwarenah. Wenn man vorher nicht's mit Elektronik zu tun hatte und zum Beispiel nicht weiß, was ein Schieberegister oder Binärzähler ist und wie die funktionieren, dann steht man bei einige Befehlen schnell auf dem Schlauch. Dann die Boolsche Algebra für die logischen Verknüpfungen (wobei man die eigentlich auch schon in Basic braucht). Das nächste Thema ist die Dezimal/Hexadezimal/Binär-Umrechnung.
Das sind alles zusätzliche Hürden, wenn man damit vorher nichts zu tun hatte. Wobei man, wie gesagt, einiges davon auch schon für Basic braucht. Nur bei Assembler ist es verschärft.
-
es wollte einfach nicht in meinen Kopf, wie man überhaupt anfängt ein Programm zu schreiben wenn man gefühlt nur Register/Zahlen hin und herschiebt
Genau das ist der springende Punkt!
Das ist das, was man begreifen muss. Da muss es quasi Klick machen, der Groschen muss fallen. Und ja, gerade wenn man mit BASIC schon simple Sachen hinbekommen hat (weil damit ja auch simple Sachen problemlos gehen), dann fuehlt man sich erstmal total zurueckgeworfen, wenn man auf einmal nur noch Zahlen rumschieben kann und sich fragt, wie daraus jetzt ueberhaupt jemals ein Programm werden soll.
Deshalb finde ich es aber auch gut, dann erstmal ganz andere Dinge zu zeigen, z.B. Bildschirmrand flackern lassen, Bildschirm mit Sternchen fuellen, sowas. Denn das geht auch mit erstaunlich wenig Befehlen, aber dadurch begreift man dann auch, was man mit der Maschine eigentlich so machen kann. Es waere also aus meiner Sicht falsch, zu versuchen, ein "Zahlenrate-Spiel" oder ein "Hallo wie ist Dein Name"-Programm in Assembler umsetzen zu wollen. Sondern man muss erstmal diejenigen Dinge tun, die mit Assembler besonders einfach sind. Also quasi die "Hello Worlds" des Assembler. Und diese sind halt eben anders als die in BASIC
-
Ich bin mit Assembler angefangen, als ich eine Disk-Version von Simons' Basic in die Finger gekriegt habe. Da SB einen ziemlich großen Haufen von Fehlern hat, und die mich immer genervt haben, bin ich mit SMON rangegangen und hab versucht rauszufinden, was da fehlerhaft war. Mit Hypra-Ass hab ich dann die ersten Patches geklöppelt (und in der 64'er veröffentlicht) und irgendwann später einfach das ganze Basic neu gemacht (TSB). Da bin ich dann immer noch dabei...
Arndt
-
Die Ernüchterung kam aber recht schnell. Ich wusste einfach nicht wieso in dem Buch bestimmte Dinge gemacht werden. Es zeigte wohl auch Register und die Umrechnung usw. - also den Grundstock an Wissen an, aber schon bei den einfachsten Befehlen fragte ich mich immer: Wieso macht der das?
Dann war's vielleicht einfach das falsche Buch. Ein gutes Buch sollte die wesentlichen Grundlagen erklären.
...
Das sagt sich heute so einfach. Früher hatte kaum jemand Ahnung von Assembler Pogrammieren und somit war auch gar nicht klar, welches Buch gut oder eben nicht so gut war. Du bist in einen Buchladen gegangen, der Verkäufer hat mit den Schultern gezuckt und dich in die Richtung mit den Büchern über Computer geschickt. Ab da war man dann meistens auf sich selbst gestellt.
Wenn du dein mühsam gespartes Taschengeld einmal in einen Fehlkauf gesteckt hattest, hast du dann vielleicht auch aufgegeben.
-
Die Ernüchterung kam aber recht schnell. Ich wusste einfach nicht wieso in dem Buch bestimmte Dinge gemacht werden. Es zeigte wohl auch Register und die Umrechnung usw. - also den Grundstock an Wissen an, aber schon bei den einfachsten Befehlen fragte ich mich immer: Wieso macht der das?
Dann war's vielleicht einfach das falsche Buch. Ein gutes Buch sollte die wesentlichen Grundlagen erklären.
...
Das sagt sich heute so einfach. Früher hatte kaum jemand Ahnung von Assembler Pogrammieren und somit war auch gar nicht klar, welches Buch gut oder eben nicht so gut war. Du bist in einen Buchladen gegangen, der Verkäufer hat mit den Schultern gezuckt und dich in die Richtung mit den Büchern über Computer geschickt. Ab da war man dann meistens auf sich selbst gestellt.
Wenn du dein mühsam gespartes Taschengeld einmal in einen Fehlkauf gesteckt hattest, hast du dann vielleicht auch aufgegeben.
Deswegen kann es trotzdem das falsche Buch gewesen sein. Wie gut ein Buch ist, ist doch unabhängig davon, wie lange man darauf spart.
-
Also Taschengeld für ein Buch (keine Ahnung mehr was für eins das war) zusammengespart und losgelegt.
Vielleicht war es ja "Programmieren in Maschinensprache" aus dem Markt&Technik-Verlag. Sieht gut aus, hat aber anscheinend schon einige Interessenten zur Verzweiflung getrieben.
-
Ein gutes Buch sollte die wesentlichen Grundlagen erklären.
Jupp, genau darum drücken sich aber nach meiner Erfahrung viele (die meisten?) Bücher.
Viele Lehrbücher gehen so:
1.) Babykram, Babykram und noch mehr Babykram
2.) Ein kurzes Anreißen von soliden Grundlagen
3.) Dann plötzlich Raketenwissenschaft oder ellenlange Listings, die reingedumpt werden.
4.) Danke für die Aufmerksamkeit
