Hallo Besucher, der Thread wurde 13k mal aufgerufen und enthält 112 Antworten

letzter Beitrag von M. J. am

Zu dumm für Assembler? Was Hänschen nicht gelernt..

    Ich habe mir den Grundwortschatz der englischen Sprache aus dem Internet geladen, das waren etwa 2000 Vokabeln.

    Diese habe ich auswändig gelernt, indem ich diese mit anderen Dingen verküpft habe. Nach etwa 5 Wochen hatte ich das Meiste intus.

    Natürlich muss ich das von Zeit zur Zeit wiederholen, sonst vergesse ich das Gelernte wieder.

    Die Grammatik ist da noch nicht mit inbegriffen. Das kommt alles noch.:)


    Fremdsprechen zu lernen ist auch nicht so mein Ding, aber was muss das muss.


    Wenn ich mal in der Schule so lernbegierig gewesen wäre.:)



    Achja, man muss es wollen.8) Mir war/ist es peinlich das nicht zu können.

    Könnt ihr mir nicht 'mal ehrlich zustimmen, anstatt mehr oder weniger nur süffisantes blah blah darauf abzugeben ? Natürlich hat auch ASM Vorteile, aber um die ging's jetzt 'mal eben gar nicht. Sonst hätte man wieder 'was 10-seitiges schreiben müssen damit jeder im Forum befriedet ist u. alle nicht erwähnten Details auch noch drin vorkommen.. . So einfach ist das !


    Zitat von oobdoo

    Wenn das Projekt größer wird, ist das zerlegen in kleinere Teile irgendwann trotzdem nicht mehr zu vermeiden.

    Die Vorgehensweise auf einem 8-Bit BASIC-Computer ist nicht übertragbar auf ein modernes BASIC wie VisualBasic.net.

    Irgendwann kommt man an einen Punkt wo einem dieser Spagetti-Code über den Kopf wächst.

    -Kommt drauf an (wie derjenige programmiert, besser ist ohne Goto Orgie = kein allzu verknoteter Spagetti-Code), man kann mit REM Zeilen die Übersicht bewahren. U. sich die Funktionen der einzelnen Variablen

    separat aufschreiben auf ein Blatt Papier, damit einem die nach längerer Zeit nicht entfallen.

    Ausserdem gibt's per z.b. Action Power CRT Renumber, Merge Befehle.., so dass man auch in Baisc jeden Part separat angehen / programmieren kann.

    U. das erst später zu einem ganzen Programm zusammen-merged. Zwischendrin jederzeit neue Zeilen einbauen geht auch, weil man mit Renumber jederzeit beliebig große Lücken zwischen den Zeilenschritten schaffen kann.

    -Irgendwann ist der Basic Speicher ausserdem voll, so richtig super riesig werden die Listings jeweils also sowieso nicht.


    Übersicht muss also nicht verloren gehen. In Basic erkennt man ja auch in jeder Ziele besser um was es gerade geht, insb. wenn es sein eigenes irgendwo noch bekanntes Programm ist.

    In ASM sieht jede Zeile -in einem optisch btw. noch viel längeren Code als das Basic je sein kann..- gleich kryptisch aus, wenn man da nach etwas bestimmtes sucht. Man erkennt auf Anhieb da gar nichts sofort wieder. ;)

    Klar, die die damit täglich 'was machen schon.


    Zitat von ZeHa

    Das ist fuer mich der Post des Tages :hammer:


    In Assembler ist alles so kompliziert, daher sind die Spiele auch alle so kacke, in BASIC geht das viel besser, daher sind die BASIC-Spiele auch alle so genial

    Dann hast du nicht bergreifen wollen worum es mir ging. Siehe auch hier erster Satz im Post.


    Die Grundfrage und Thema des Threads war ja schon eine ganz andere, und nur darauf habe ich geantwortet (was für manche ASM so schwierig macht damit v.a. komplexeres zu erschaffen.. !, + daher gibt es von Normalos auch so viele im Kern sehr simple immer gleiche Ballerspielchen).

    Die Antwort von dir ist also in diesem Zusammenhang gesehen völlig am Thema vorbei.

    Nein. Du bekommst jetzt meine Aussage mit dem Programmieren auf einem PC mit dem auf einem 8-Rechner durcheinander.

    Was auf 8-Bit BASIC durchaus gut klappt, wird irgendwann ab einer bestimmten Codegröße nicht mehr in einer Programmiersprache auf einem modernen PC funktionieren.

    Dort kannst Du einen Prorgammcode nicht beliebig lang machen (geht natürlich technisch schon), aber irgendwann ist die Übersicht dahin. Du scrollst Dich zu Tode und

    auch Lesezeichen sind dann kein Allheilmittel mehr.

    Zitat von Kickmaster64

    Kann es sein das manche Leute ein natürliches Talent dafür haben?

    Bin mir nicht sicher, aber irgendwie denke ich schon. Bevor ich Assembler gelertn habe, hat jeder gesagt dass das Mega shcwierig ist und ich hatte immer total Respekt davor. Habs auch gar nicht versucht weil es ja klar war dass es so furchtbar schwierig ist. Fand es allerdings ehrfurchtgebietend dass man damit die ganzen Coolen Tricks machen konnten, die in den Intros so benutzt wurden. Und dann habe ich in einem Data Becker Buch ein paar Zeilen gesehen bei denen jeder einzelne Befehl genau erklärt wurde (war aber kein Assembler Buch sondern IMO Tips & Tricks oder sowas). Jedenfalls habe ich das gesehen und dachte mir, das sieht doch gar nicht so schwer aus und habe dann mit ein paar Befehlen rumexperimentiert. Einfach ausprobiert was passiert wenn ich das so mache und war begeistert wie das abging.

    Mein erstes Program war einfach nur:


    $C000: DEC $D020

    $C003: DEC $D021

    $C006: JMP $C000


    Das habe ich mit einem Monitor direkt in den Speicher getippt. Habe auch jahrelang so programmiert, das man das mit Sourcecode macht wusste ich gar nicht und das habe ich erst angefangen auf dem Amiga 1000 als ich dann dort Assembler gelernt habe (mit DevPac). :) Jedenfalls habe ich mich damit beschäftigt und immer mehr gelernt. Ich fand das einfach total logisch und überhaupt nicht wirklich schwer (ausser die Umrechung in Hex, da habe ich lange gebraucht bis der Grosschen gefallen ist). Damals dachte ich mir dass das doch eigentlich total einfach ist und habe dann versucht das einem Freund zu erklären der Assembler lernen wollte und es total cool fand das ich das einfach so gelernt hatte. Er hat es allerdings nie richtig verstanden und einfach nur ein paar Tricks auswendiug gelernt die ich ihm gezeigt hatte. Aber er hat eben nie wirklich verstanden was er da tut. Ich habe dafür nie wirklich verstanden warum ihm das so schwerfiel weil es eben für mich total logisch war und ich dachte immer, wenn man jemanden etwas nur genau genug erklärt dann MUSS er das einfach verstehen. Das glaube ich mittlerweile nicht mehr.

    Also ja, ich denke schon dass ein gewisses Talent dafür nützlich ist. Allerdings kann man das trotzdem auch lernen, es ist nur eine Frage der Zeit und wie viel Zeit man investiert.

    Bei mir wars sicher auch nur die Tatsache das ich früh ein Final Cartridge hatte, und der Monitor nur einen Tastendruck entfernt war. Somit fing ich an mit den Befehlen die im Handbuch standen im Speicher herumzustöbern. Die Adressen der SID Register standen im C64 Handbuch, und dann sieht man zwangsläufig irgendwann den Code der mit diesen Adressen hantiert. Ein kurzes SYS 4096 und SYS 4099 später und da war auf einmal ein hängender Ton. Dann nochmal SYS 4099 und der Ton hatte sich verändert.

    So hab ich dann mit BASIC das erste Mal eine SID Musik abgespielt (ich glaube es mussten 6 : in der Schleife sein für eine ungefähr korrekte Verzögerung).

    Damit war der Grundstein gelegt, ab da wollte ich mehr wissen. Und auf das Wollen kommt's an.

    Als ich angefangen habe gabs noch kein Final Cartridge, aber ich hatte P-Mon zufäälig auf einer Diskette. Wusste gar nicht was das ist, aber ich war neugierig und habe damit rumexperimentiert. Das mit den Assemblerbefehlen kam dann etwas später aber es hat sicher auch geholfen dass ich mit dem Monitor vorher schon etwas Erfahrung gesammelt hatte, auch wenn ich kaum wusste was der alles kann. :)

    Ich denke mal dass meine herangehensweise sicher geholfen hat. Ich habe durch den Monitor die Möglichkeit gehabt, Assembler direkt im Computer auszuprobieren. Wenn man heute anfängt und vor allem mit dem Ziel Assembler zu lernen, dann geht man viel komplizierter ran. Da lernt man erstmal einen bestimmten Assembler(Compiler) kennen, wie man damit ein Programm übersetzt usw.. Das sind viele Schritte die bei mir weggefallen sind. Auf einem PC geht das sowieso gar nicht mehr so direkt. Aber es kommt auch darauf an wie jemand lernt. Ich denke eine einfache herangehensweise wäre, wenn man erstmal nur ein paar Befehle ausprobiert und sich direkt im Debugger ansieht was da so passiert. Welche Register sich wie verändern, welche Flags und Speicheradressen, ohne das man glkeich ein komplexes Programm schreibt. Denn damit ist Assembler natürlich schwieriger, weil man sich nicht mit ein paar Befehlen auseinandersetzt, sondern gleich mit einem Problem das man eben in viele kleine Einzelschritte zerlegen muss, und von denen man am Anfang nicht mal weiss welche das sein sollten.


    Man kann z.B. ein einfaches kleines Problem nehmen wie z.B. eine vorgegebene Zahl mit 10 zu addieren. Welches Register nehme ich dafür, welche Befehle brauche ich uind wo steht dann das Ergebniss. Das kann man sich direkt im Debugger ansehen und muss nichtmal eine Ausgabe machen, weil das schon wieder deutlich komplizierter wird. Das kann man auch in einem weiter Schritt machen.

    Klingt nach einer harten Methode... In der Schule ging es ja mit einer handvoll Wörtern los, die gleich einfache Sätze gebildet haben. Englisch-Kurse mit CD oder für Windows95 sollten nicht schwer zu finden sein, ist vielleicht einfacher.

    Ich guck grad bei Weltbild, was es an Lehrbüchern für meine Sprache gibt, ist doch eine Menge.

    Zitat von Stephan Scheuer

    Das Gilt für alle englischsprachigen Videos. Die reden einfach zu schnell. Bis ich im Kopf den ersten Satz übersetzt habe, sind die schon zwei Sätze weiter.

    Einfach immer und immer wieder versuchen. Der Übersetzungsschritt im Kopf wird irgendwann wegfallen, dann verstehst du es quasi 'nativ' und dann ist es auch kein Problem mehr. Ich habe das Verstehen auch nur über YouTube gelernt. Ich kann am Ende eines Videos (oder auch Textes) nicht einmal mehr sagen, ob das nun Deutsch oder Englisch war und ich war in der Schule damals in Englisch auch eher so der 4er Kandidat.

    Viel lesen und 'hören' bei Assembler und Englisch.

    Im Monitor bestehenden Code im Action replay ändern und sehen was passiert. Dazu ein zwei ProfiCorner in der 64er - so fing es bei mir an. Englisch schon als Schüler gern gelesen, um Übersetzungen zu vermeiden. Fühlte sich schon immer falsch an irgendwie. Im Studium und Beruf dann fast ausschließlich Englisch.

    OT Sprachen lernen:

    Fürs Vokabellernen würde ich ein Vokabellernprogramm wie ANKI empfehlen. wobei solch ein Programm sicherlich Geschmackssache ist. Einige kommen gut damit klar, anderen ist es zu öde. Aber probieren sollte man es mal. Grammatik lernt man am besten schrittweise mit einem ordentlichen Lehrbuch. Was das Hören und Verstehen anbelangt, so muß man dem Gehirn ausreichend Training und Zeit geben, die neuen Muster zu automatisieren. Das Gehirn ist nun einmal eine große Musterverarbeitungsmaschine. Die will immer wieder und wieder mit Daten gefüttert werden. Also: Am besten wiederholt englische Filme angucken (habe selber damals[tm] mit "Monty Python's Flying Circus" gelernt), damit sich die für das Hören zuständige Verarbeitungseinheit im Gehirn an den Lautfluß gewöhnt. Ist die dann ausreichend trainiert d. h. programmiert worden, ist die Sprechgeschwindigkeit auch kein Problem mehr, da dann der neu entwickelte Coprozessor einem die Arbeit des Worterkennens abnimmt. Um nun aber den englischen Wörtern an sich auch die richtige, unmittelbare Bedeutung zu geben, ist es am besten, direkt auf Englisch zu denken. d. h. auch in Gedanken nicht mehr zu übersetzen, sondern direkt in Englisch zu formulieren. Dadurch wird das Gehirn dazu gezwungen, entsprechende Verbindungen von den reinen Wörtern (Lautfolge, Schreibweise) zu ihrer eigentlichen Bedeutung aufzubauen, so daß man später überhaupt nicht mehr übersetzen muß.


    Eigentlich ist der Spruch "Was Hänschen nicht lernt, lernt Hans nimmermehr" ein ziemlicher Blödsinn. Klar gibt es Beschränkungen in dem, was man lernen kann. Man wird eine Fremdsprache nie so gut beherrschen wie ein Muttersprachler, aber doch immerhin so gut, daß man damit ausreichend kommunizieren kann. Das Gehirn lernt ständig neu dazu. Es ist eher die Frage, unter welchen Umständen es lernt und mit welcher Absicht. Als kleines Kind lernt man die Umwelt ohne Zielsetzung kennen und nimmt einfach alles auf. Als Erwachsener hingegen filtert man sehr viel heraus, überlagert es dafür mit (negativen) Erfahrungen und sortiert dann Dinge oft falsch ein, was den Lernprozeß behindert.


    Am besten also, man befreit sich zu Beginn von allem möglichen Ballast wie "Ich habe gehört, Assembler soll schwer sein" usw. und setzt sich wie ein kleines Kind an den Rechner um einfach was auszuprobieren. Das setzt Neugier voraus, aber nicht notwendigerweise Talent. Genausowenig wie man Talent braucht zum Autofahren, kann man auch Programmieren lernen, wenn man eine Bereitschaft mitbringt und sich nicht selbst blockiert. Dazu gehört auch, daß man wie bei einem Legokasten einfach das nimmt, was vorhanden ist, daraus kleine, simple Modelle bastelt und nicht gleich zu Beginn versucht, ein Super-Technik-Modell zu erstellen. Das heißt konkret: Alles, was mit schwierigen mathematischen Operationen zusammenhängt (Multiplikation, Division oder gar Fließkommazahlen) ist für den Anfang ungeeignet.


    Wie viele geschrieben haben, ist das Herumprobieren mit einem Monitor eine gute Methode, die anfängliche Hürde zu nehmen. Wer z. B. ohnehin Probleme hat bei der Anwendung von Programmierumgebungen, wird u. U. durch die Komplexität der Tools bereits unnötig abgeschreckt. Malen lernt man auch besser mit Stift und Papier und nicht mit Gimp. Tippt man hingegen ein paar Befehle ein wie das genannte Schreiben von Werten in die VIC-Register, erfährt man sehr schnell ein Erfolgserlebnis, das zu weiteren Schritten anspornen kann. Wie vorher erwähnt, sind kurze Programme, die die Bildschirmanzeige verändern, hierfür die erste Wahl. Besonders der C64 mit seinen Farben und den Sprites bietet für Anfänger genügend Möglichkeit sich auszutoben und sorgt dabei für einige Aha-Effekte.


    Allgemein betrachtet besteht der gesamte Lernprozeß dann aus drei Stufen:

    1.) Das Erlernen von Vokabeln und Grammatik bzw.

    das Erlernen der Befehle und des Programm-/Speicheraufbaus.

    2.) Die Verwendung der sprachlichen Elemente, um Texte zu übersetzen oder Antworten zu formulieren bzw.

    Basicprogramme ganz oder teilweise in Assembler umsetzen oder eigene kleine Programme schreiben.

    3.) Erkennen, welches Potential in der Sprache steckt und selber kreativ Texte schreiben bzw.

    erkennen, was man mit der handvoll Assemblerbefehle anstellen kann und das neue Superspiel wntwickeln.


    Stufe 1 ist gar nicht so schwer. Stufe 2 schon anspruchsvoll, aber machbar. Der wirkliche Aufwand kommt in Stufe 3. Daher sollte man diese Stufe als Anfänger vor sich herschieben und sich nicht damit verrückt machen, wenn man diese noch nicht erreicht hat.

    Zitat von Taxim

    Bei guten Programmierern ist mir schon eine gewisse (oder auch die totale) Mathegeilheit aufgefallen.

    Dann bin ich kein guter Programmierer...;(

    Bei mir war das damals so, dass ich Basic problemlos verstanden habe, aber Assembler war ein Buch mit sieben Siegeln. Ich hatte mir damals ein Assembler Buch vom Hofacker Verlag gekauft, aber das brachte mir das Verständnis absolut nicht herüber, war eben sehr auf Basic "eingeschossen". Da stand z.B. für LDA: "Es wird ein Wert in der Akku geladen." Aber was der Akku überhaupt ist, wozu der überhaupt gebraucht wird, was x und y register machen, wurde nicht erwähnt (oder ich habe es einfach nicht mehr gesehen vor lauter "Frust").


    Ca. 1-2 Jahre später bekam ich dann vom Data Becker Verlag ein Assembler- Buch in die Hände. Da wurden die Assembler und Basic Befehle gegenüber gestellt, und da ist dann sofort der Groschen gefallen. Man zeigte kleine Programme in Basic und dazu den entsprechenden Assemblercode und erwähnte, dass Rechenoperationen immer nur über den Akku zu laufen haben.


    Sowas z.B.


    Code
    1. LET A=10 LDA#10
    2. LET A = A+5 ClC: ADC# 5


    Auch wie dann Schleifen und Bedingungen zu programmieren sind, es gibt eben keine IF Abfragen in Assembler wie in Basic, sondern nur Branch if zero, Branch if not zero, etc. Das wurde dort sehr ausführlich erläutert.


    Code
    1. 10 X = 0                        LDX#0
    2. 20 X = X +1                     INX
    3. 30 IF X <> 200 THEN GOTO 20     CPX #200: BNE 20

    Arcade & Pinballs: F14 Tomcat, TOTAN, Visual Pinball, MAME Arcade Cab, Münzschieber Glückskarussel
    Musikproduktion: Korg Kronos 61 (2nd 256GB SSD 4GB), Korg M50 61, Akai MPD32, Alesis IO4, KORG Nanopad 2
    Retro: In liebevolle Hände abgegeben.
    Heimkino: Epson TW6000, Xbox 360 Kinect mit Amazon Prime, Nintendo Wii


    "Weise eine kluge Person auf einen Fehler hin und sie wird sich bedanken. Weise eine dumme Person darauf hin und sie wird dich beleidigen"


    Wenn man den Leuten erzählen würde, dass das Gehirn eine App ist, fangen sie vielleicht an, es zu gebrauchen.

    Zitat

    Taxim


    Dazu fehlt mir einfach dieses Mathe-Informatiker-Logik-Superhirn.

    Mir auch. Ich bin begeistert von Mathematik, ich programmiere auch (irgendwie mit der Hand am Arm), bin aber mathematisch talentlos.


    So what. Das was man mag soll man tun und wo es an schneller Auffassungsgabe fehlt macht man es mit fanatischer Zähigkeit wett. Es ist keine Frage des ob, sondern nur des wann.

    Zitat von rogie67

    es gibt eben keine IF Abfragen in Assembler wie in Basic, sondern nur Branch if zero, Branch if not zero, etc.

    Was ja auch gewissermaßen eine IF-Abfrage ist, nur mit anderer "Grammatik".


    BASIC

    X=X+1 : IF X=7 THEN [ACTION]


    ASM

    INX : CPX #7 : BEQ (Branch IF EQual zero) [ACTION]


    Zwar bezieht sich der Vergleich genau genommen auf den Rest der Subtraktion zwischen X und 7, und es ist auch gut zu wissen, dass das so ist, aber das "equal" passt auch direkt, weil die Differenz zweier Zahlen bei Gleichheit eben ZERO ist und bei Ungleichheit NOT ZERO. Beim BASIC ist das intern nicht anders, und da müssen wir auch nicht ständig drüber nachdenken.


    Hauptunterschied: Der Maschinencode braucht etwa 7 Millionstel Sekunden zur Ausführung, das BASIC-Pendant braucht .. äh .. länger.


    -//-


    Eselsbrücken müssen nicht elegant sein oder wörtlich genommen werden, sondern nur funktionieren, sag ich immer. So kann man sich Gedankengänge sparen. Beispiele:


    BEQ: wenn EQual

    BNE: wenn Nicht Equal

    BCC: wenn ClitzeClein

    BCS: wenn Crößer oder (das)Selbe


    oder ..


    "Mein Vater Erklärt Mir Jeden Sonntag Unnötige Neuerungen" anstatt "Mein Vater Erklärt Mir Jeden Sonntag Unsere Neun Planeten". ;)

    Zitat von atomcode

    Hauptunterschied: Der Maschinencode braucht etwa 7 Millionstel Sekunden zur Ausführung, das BASIC-Pendant braucht .. äh .. länger.

    Naja...jein. Was hier im Thread bei diesen Vergleichen scheinbar komplett übersehen wird ist, dass BASIC immer mit Gleitkommazahlen rechnet. D.h. nur wenn das X im BASIC-Code immer zwischen 0 und 254 liegt und ganzzahlig ist, dann ist dein ASM-Code äquivalent. Ansonsten nicht! Natürlich rechnet BASIC im Speziellen dadurch viel langsamer als Maschinensprache. Aber würde man die BASIC-Rechnung 1-zu-1 in Maschinensprache übersetzen (also als Gleitkommarechnung), dann wäre das nicht so extrem viel schneller, weil dann "nur" der Interpreter-Overhead wegfällt.

    Zitat von M. J.
    Zitat von Taxim

    Bei guten Programmierern ist mir schon eine gewisse (oder auch die totale) Mathegeilheit aufgefallen.

    Dann bin ich kein guter Programmierer...;(

    :verehr: Mein großes Vorbild. :thumbsup:

    Meine ersten Programierversuche auf dem C64 erfolgten in BASIC. Allerdings stellte ich dann bald fest, dass sich einiges nicht in BASIC realisieren ließ. Grund dafür war, dass jede BASIC-Zeile durch den Interpreter erst in Maschinensprache übersetz und somit die benötiigte Rechenzeit zu groß war. ASSEMLER war hier die Lösung, also legte ich mit HypraAss zu. In dem Begleitbuch waren hier nicht nur die Funktionen der Code sondern auch anhand von Beispielen deren Funktionen umfangreich beschrieben. Dabei fiel mir auf, dass viele Opto-Code den BASIC-Togen äquivalent waren (rogie67 hat hierzu schon einige Beispiele dargestellt).

    Zitat von Taxim

    Aber ich bin mir auch sicher, dass ich nie etwas Besonderes proggen könnte. Dazu fehlt mir einfach dieses Mathe-Informatiker-Logik-Superhirn.

    Wer hat das schon? :D

    Ich programmiere beruflich und bin auch kein Überflieger. Vieles ist Routine und über Jahre antrainiert.

    Da macht es auch keinen großen Unterschied ob ich Assembler oder C#/DOTNET programmiere.


    Überflieger sind die Leute, die in ein paar Stunden irgendwelche wilden Demos zusammencoden.

    Zitat von EgonOlsen71

    D.h. nur wenn das X im BASIC-Code immer zwischen 0 und 254 liegt und ganzzahlig ist, dann ist dein ASM-Code äquivalent.

    Das setzte ich voraus, weil es ja eben im ASM-Beispiel auch so ist. Dass das BASIC V2 Fließkommazahlen einsetzt, wo es gar nicht nötig ist, ist ja sein eigenes Problem; das ist ja in dem Fall kein Vorteil, das man rechtfertigen müsste. Hätte es einen echten Integer-Typ, hätte ich den fairerweise wohl genommen. Ging jetzt eher um die IF-THEN-Struktur.


    Es ist das häufigste Szenario. Selbst Berechnungen mit 16bit-Zahlen braucht man gar nicht mal so oft. Und Fließkommazahlen hab ich in Assembler noch nie gebraucht. Würde ich für irgendwas gebrochene Zahlen brauchen, könnte ich mir auch superschnelle Festpunkt-Module machen, 24 Bit würde mir wahrscheinlich reichen.

    Seit dem ich mich irgendwann in der Vergangenheit auch wieder dem C128/C64 zugewand habe, wollte ich natürlich auch Programmieren. Meine Ideen in Software bringen. In Basic und auch ASM.

    Habe mir dann alles an Literatur darüber besorgt, was ich bekommen konnte (und das ist einiges an echten Büchern und auch pdf) und hab einfach angefangen.


    Für mich war es am einfachsten, kommentierten Quellcode zu analysieren und zu versuchen die Vorgänge zu verstehen. Oder auch ASM-Code zu analysieren und so mit Hilfe der Literatur zu verstehen, was das Programm an welcher Stelle macht und warum. Ich habe mir sehr viele Notitzen gemacht und so dann auch einige eigene kleinere Programme zustande gebracht. Wie z. Bsp. eine kleine graphische Workbench mit Mausbedienung, Windows und Laufwerkserkennung in Basic7, oder auch das programmieren der 24h TOD-Clock (CIA) mit der Systemzeit aus der U2+ und IRQ gesteuerter Ausgabe des ganzen in einer 26.Bildzeile auf dem 80-Zeichenschirm des C128. Oder auch Radiobutton mit Mausbedienung in Basic oder den Z80 im C128 zu aktivieren und rudimentär zu programmieren und solche Dinge. Und da ich auch manchmal ein bisschen faul bin, hab ich auch vorhandenen Code einfach gemopst und für meine Zwecke angepasst und verwendet. Das setzt aber auch vorraus, dass man den Code aber auch versteht. Logisch. Und Faulheit ist m. E. nicht mal etwas schlimmes. Es macht das Leben oft auch einfacher und angenehmer. :D


    Was ich nicht auf Anhieb verstehe, kaue ich so oft durch, bis ich es verstehe (wenn das Interresse dafür groß genug ist). Das mag auch an meinem Sternzeichen liegen, welches den Ruf hat, allem auf den Grund gehen zu müssen. Das ist bei mir extrem ausgeprägt, wenn mich etwas interresiert. Und das hilft mir auch. Allerdings hab ich leider auch nicht das tolle Durchhaltevermögen. Wenn ich ein bestimmtes Level erreicht habe, passiert es auch, dass ich das Interresse verliere. Das ist dann wieder ein Handycap. Deshalb hab ich auch in der Vergangenheit warscheinlich auch so gut wie garnichts in der Richtung gemacht. Naja, gab auch paar andere wichtige Gründe. Aber es macht doch viel Spaß und lenkt auch gut vom Alltag ab.


    Wie auch immer, Interresse muss m. E. dafür schon da sein und jeder lernt auf andere Weise.