Hallo Besucher, der Thread wurde 2,6k mal aufgerufen und enthält 16 Antworten

letzter Beitrag von -trb- am

anfänger: 30x pro sekunde die farbe aller buchstaben des screens ändern

    hallo,


    suche mir gerade "assembler ist keine alchemie" zusammen weil ich es jetzt endlich anfange.


    kann leider nicht direkt mit dem c64 arbeiten und wähle deshalb den vice-emulator (für windows xp) weil dort auch gleich ein monitor mit dabei ist. dazu gleich
    frage #1: sind die tools immer noch geschmacksache oder haben sich optimale wege herauskristalisiert, die man einhalten sollte?


    muss wohl dazu sagen dass ich ziemlich aktiv war damals in den 80'ern und mich noch recht gut an alles erinnern kann - nur den einstieg in asm konnte ich nie richtig finden - bis jetzt. war in den letzten tagen in der bibliothek, hatte mir aus 2 büchern einiges herauskopiert und viel im internet gelesen und denke ich werde (hoffentlich auch mit eurer hilfe) den anfang finden...


    während ich hier also nebenbei lese möchte ich euch hier gerne zeitgleich immer mal wieder ein paar fragen stellen (dürfen). dieses ziel möchte ich gerne erreichen, aber ich weiss nicht wie ich es anfangen soll:
    frage #2: emulator mit monitor ist an, im emulierten c64 läuft smon, ich bin bei $0800 und möchte:
    1. den screen komplett mit @ zeichen füllen
    2. bei jedem frame (pal hat ja 30 pro sekunde) die farben ALLER @-zeichen gleichzeitig ändern (nicht zufällig, sondern bestimmt reihenfolge)
    3. diesen loop mit tastendruck beenden können.
    das kann nicht so schwer sein, aber wie genau geht's?


    bin für jede hilfe danbar!
    e2020

    Zitat von e2020

    sind die tools immer noch geschmacksache oder haben sich optimale wege herauskristalisiert


    Das bleibt Geschmackssache. Von der Windoof-Fraktion nutzen viele wie ich ACME/Relaunch.


    Zu deinem Problem 1: das ist in der Tat trivial, vielleicht scheitert es bei Dir nur daran, dass Du versuchst, es genau an den Basic-Start zu legen?


    Egal, Teil 1 geht jedenfalls in ACME-Syntax so:


    Teil 2:


    Wenn Du das gleiche mit dem Farbram machen willst, musst du halt zu den sta$400 $d400 zu-addieren. :) Comprende? Wenn nicht, hilft ein Blick in den Speicherbelegungsplan: http://www.c64-wiki.de/index.php/Speicherbelegungsplan


    Zum durchflashen des Farb- und/oder Zeichenrams einfach irgendwo $d012 abfragen und eine schleife basteln.


    Teil 3:
    Tasten abfragen ist gar nicht sooo easy in ASM. Schau hier mal rein:
    http://www.c64-wiki.de/index.p…astenabfrage_in_Assembler

    Hmm, ich weiß nicht, ob es Sinn macht, Dir das Programm jetzt Zeile für Zeile hier aufzuschreiben (falls das Dein Anliegen ist), wo bleibt denn da der Lerneffekt?


    Zitat von e2020

    frage #1: sind die tools immer noch geschmacksache oder haben sich optimale wege herauskristalisiert, die man einhalten sollte?

    Wenn Du eh mit einem Emulator, also auf dem PC arbeitest, empfiehlt sich der Einsatz eines Cross-Assemblers, z.B. Acme.


    Zitat von e2020

    1. den screen komplett mit @ zeichen füllen

    Das einfachste ist, das Screen-RAM ab $0400 mit Nullen zu füllen. 0 ist der Screencode für das Zeichen @.


    Zitat von e2020

    2. bei jedem frame (pal hat ja 30 pro sekunde) die farben ALLER @-zeichen gleichzeitig ändern (nicht zufällig, sondern bestimmt reihenfolge)

    Dafür gibt es auf dem C64 die komfortable Methode des Raster-Interrupts. Schlage mal bei Google bzw. hier im Forum dieses Stichwort nach, dort dürften sich zahlreiche Code-Beispiele finden. PAL hat in Deutschland übrigens 25 bzw. 50 Hz Bildwiederholfrequenz, nicht 30.


    Zitat von e2020

    3. diesen loop mit tastendruck beenden können.

    Für die Tastaturabfrage lässt sich die Kernal-Routine GETIN ($FFE4) verwenden. Dürfte ebenfalls in in jedem C64-Assembler-Buch beschrieben sein.


    CU
    Kratznagel

    Zitat von e2020

    2. bei jedem frame (pal hat ja 30 pro sekunde) die farben ALLER @-zeichen gleichzeitig ändern (nicht zufällig, sondern bestimmt reihenfolge)


    Das Farbram liegt bei $d800 und ab da 1000 Zeichen. Nur die unteren vier Bits eines Byte sind benutzt. Wenn Du die Routine, die TheRyk gepostet hat verstanden hast, sollte die Anpassung auf das Farbram kein Problem werden.


    30 pro Sekunde ist übrigens nicht ganz richtig. Es sind ca. 50 pro Sekunde, denn der C64 gibt immer nur ein PAL-Halbbild aus (kein Interlace) so dass er die doppelte Bildwiederholrate eines normalen PAL-Videos hat. Die 30 treffen auf NTSC-Video zu. Ein NTSC-C64 macht 60 Bilder pro Sekunde.


    "einmal pro Frame" erreichst Du am saubersten mit einem Rasterzeilen-IRQ - vorher CIA-IRQ abschalten nicht vergessen, sonst gibts lustige Effekte. Das ist aber schon der Schritt nach dem nächsten, denn wenn Du den Einstieg noch nicht hast, dann ist Hardwareprogrammierung vielleicht noch nicht ganz das Richtige. Vielleicht solltest Du erstmal das 6502-Konzept mit Flags, Registern und und und begriffen haben.


    Zitat von e2020

    3. diesen loop mit tastendruck beenden können.


    Hier gibts auch verschiedene Lösungen: Tastendruck direkt an der Hardware abfragen, oder doch lieber eine ROM-Routine den Job erledigen lassen? Man kann sich chon beim Einstieg gewaltig den Stil versauen, indem man versucht, erstmal alles selbst zu machen. Grundsätzlich gilt aber auch beim Assemblern, dass man zwischen "Programmieren" und "coden" unterscheidet. Je nachdem, welches Ziel Du verfolgst, schlägst Du eine der Richtungen ein: Coden, wenn Du Dich überhaupt nicht um Stil und Weiterverwendbarkeit Deines Machwerkes kümmerst. Oder "Programmieren", wenn's Struktur haben soll, wenn Du Lösungswege gehst, die "known good" sind und das ganze BlahBlah, das man auf der Uni so hört. Beides hat was für sich - ich will deswegen hier keine Diskussion antreten.


    Jens

    Zitat von Wiesel

    Wenn Du die Routine, die TheRyk gepostet hat verstanden hast, sollte die Anpassung auf das Farbram kein Problem werden.

    Ich habe versucht mich so unkryptisch wie möglich auszudrücken und nochmal per EDIT einen Kommentar dahinter gesetzt, weil ich mich noch gut erinnere, wie lange ich gebraucht habe, um mit den Tipps einiger echter Gurus was anfangen zu können. ;)

    Nebenfrage: Schreibe meine (kleinen) Assemblerprgs per Notepad, benutze dann ACME. Und zwar, weil Relaunch bei mir ums Verrecken nicht kompiliert / ACME nutzt, leider eben auch nicht Compile&Run, was ich sehr zu schätzen wüßte.
    Wie muss ich Relaunch einstellen, was beachten, damit ich (wie jeder "normale" WindowsUser) mit ACME benutzen kann? Und gibt´s auch ne Möglichkeit, gleich einen Packer (Exomizer) mit einzubinden?
    Danke

    okay, da bin ich wieder :)


    WOW! - DANKE FÜR EURE ANTWORTEN! - HIER SIND ALSO DIE ASM-HELDEN :)


    LOAD"!tasm74fx.prg",8,1
    so, finde ich mich gerade in tasm zurecht (gibt es eine aktuellere version als die von mir benutzte?), habe mir eine savedisk.d64 erstellt und frage mich:


    1. wo finde ich die beste funktionions-erklärungen/ dokumentation des ROMs (zeropage etc)?

    2. wie kann ich die ausführung meines codes im c64/in der emulation in zeitlupe angucken?
    also am besten UNTER 1 frame / sekunde? ich will mir den aufbau des screens mal genau angucken - ja genau, am liebsten zeichen für zeichen und zeile für zeile ...


    3. gibt es soetwas wie breakpoints im assembler auf dem c64/in der emulation (wie ich es von visual studio c# express kenne) ? und dann schritt-für-schritt execution?


    4. wozu überhaupt einen assembler? (vorteile/nachteile?) ich habe früher auf dem c64 nie compiliert :) ich glaube ich habe früher immer alles in smon gemacht - oder täusche ich mich da?


    5. habe mir die folgende 64er kurse ausgedruckt:
    für maschinensprache:
    * assembler ist keine alchemie
    * neuland assembler
    (6510 befehle, interrupts etc)


    für grafik:
    * reise durch die wunderwelt der grafik
    (vic-ii textmodes, sprites und bitmap-modi etc)


    * memory map mit wandervorschlägen
    (mem-adressierung & funktionen)


    werde alles (immerhin 200 seiten dina4) brav lesen und melde mich danach mit neuen fragen wieder :)
    danke für eure hilfe!


    e2020

    Vice hat so einen Monitor eingebaut, der kann debuggen, Breakpoints setzen, etc. Man kann ihm auch Labels mitgeben. Leider ist der Monitor für Visual Studio verwöhnte etwas gewöhnungsbedürftig.


    Eigenwerbung an:
    Ich bastle im Moment auch an einer Entwicklungsumgebung (C64-Studio), die ihren eigenen, an ACME angelehnten, Assembler hat, dich in Verbindung mit (Win)Vice dann aber durch deinen Sourcecode steppen lässt. Ist noch ziemlich beta, aber ich benutze die auch selber.


    Kuckst du hier: C64 Studio - Entwicklungsumgebung - Beta
    Eigenwerbung Ende

    Der Vice-Monitor lässt sich per Socket fernsteuern. Seine Antworten sind nicht wirklich dokumentiert, aber mit ein bißchen rumprobieren habe ich es im großen und ganzen hinbekommen. Ich steuere also eigentlich nur Funktionalitäten von Vice an (ruf mal den Punkt Monitor auf, wenn du den Emu offen hast).

    Nimm lieber BASIC, das ist viel weniger kompliziert!




    :weg:




    :LOL Da seht Ihr mal, wie das ist! :D

    Telespielator: Echte Männer essen rohes Fleisch, trinken Bier und coden in Assembler !
    BTT: Derzeit bevorzuge ich Relaunch in Verbindung mit Codenet, so bekomme ich das Kompilat auf der echten Kiste zu sehen ;)
    Aber mit Linux und Kate geht das natürlich auch formidabel.
    Gruß