Posts by Squidward

    Mir ist gerade eine Idee gekommen, wie ich noch mehr Takte sparen kann...

    Willkommen bei den Assemblerianern... :)


    Mein Player aus BR-TV braucht 17 Cycles (plus einstellbare Delays in 1-Cycle-Schritten zur KHz-Anpassung), wenn ich mich recht erinnere. Er läuft aber nicht im IRQ, sondern wird von ihm nur unterbrochen, wenn ein Frame gefetcht wird. Ist halt eher ein Videoplayer mit Audio-Support als ein reiner Sample-Player. Deshalb musste ich vorsichtig mit a,x&y sein, da ich ja zwischendurch immer von völlig anderen Stellen aus der REU völlig andere Datenmengen in völlig andere Speicherbereiche des C64 fetchen musste :/ Am Ende hat der Player in y das REU Command erwartet und sonst nur mit dem Accu die Sample-Position und den Bankwrap gemanaged...

    -Akku auf Stack sichern (nötig, weil er zum Senden des REU-Kommandos gebraucht wird)

    Statt pha,pla kannst du einen Cycle sparen, wenn du stattdessen Selfmod-Code benutzt:

    Code
    1. Player_Start
    2. sta MOD_Accu_Save+1 ; schreibt den Accu hinter dem lda Befehl am Ende des Players in den Speicher
    3. ...
    4. ...
    5. Player_Wrap
    6. MOD_Accu_Save ; Label für Self-Mod Code
    7. lda #$ff ; wird ersetzt durch den Accu-Wert von Player_Start
    8. rti


    -per REU-Kommando das Sample in den SID schieben lassen (braucht 2+4+1 = 7 Takte) ***

    Wenn du einen Index frei hast kannst du den zuvor einmalig mit dem Command-Byte laden und im Player dann immer nur zur REU schreiben:

    Code
    1. STATT
    2. lda #253
    3. sta REU_Command
    4. NUR NOCH
    5. stx REU_Command ; x holds #253

    Spart zwei Cycles :)


    -per REU-Kommando das Sample in eine Variable in der Zeropage schieben lassen (braucht auch 7 Takte)

    -die Variable (Samplewert) ins X-Register laden (3 Takte)

    Den Zwischenschritt mit der Zeropage kannst du dir sparen, wenn du gleich (wie in meinem Beispiel aus Post #50 in Zeile 12) als Zieladresse das Byte im Speicher hinter dem ldx/ldy Befehl definierst (oben Zeilen 20-21) = Selfmod-Code


    :)


    In jedem Fall Gratulation zu deinem Assembler-Projekt! Dafür hast du dir gleich ein ganz schönes Mammut-Projekt ausgesucht ;)

    daddlertl

    Mal so als Idee für dich: Du könntest dir wahrscheinlich das Konvertieren der Wave-Dateien ins Mahoney Format sparen. Deine Abspielgeschwindigkeit liegt doch stets unter 22KHz, da sollte es reichen, die Wave-Datei einfach direkt beim Abspielen zu konvertieren. Das würde den Usern das Umwandeln ersparen. Ich hab das bei BR-TV nicht gemacht, weil ich auch 44.1KHz abspiele (aber selbst da wäre wohl noch genug Zeit dafür) und wegen Speed/Animation keinen Index (y,x) mehr so ohne weiteres "frei" hatte.


    Das Prinzip ist einfach: Ohne deinen Source-Code gesehen zu haben - irgendwann fetcht du ja das aktuelle Sample-Byte aus der REU an die Abspieladresse, in deinem Fall der schon konvertierte Wert. Du könntest aber auch den "Original"-Wert in einen Index fetchen (z.B. y) und mit dem dann per lda Tabelle,y den konvertierten Wert holen und an die Abspieladresse übergeben. Du müßtest nur zuvor den benutzten SID ermitteln, damit du die richtige Tabelle nutzt.


    Das ist quasi das gleiche, was du sonst im Umwandlungs-Tool machst. Nur eben on-the-fly, Byte per Byte, und ohne Abspeichern. Ungefähr so:


    Aber länger nichts mehr mit der REU gemacht, also falls da ein Denkfehler ist... :sleeping:


    :angel

    Wollte heute die Buttons eines Drumcomputer bleichen. Das hatte ich schon mal gemacht, allerdings alles zu lange in der Sonne gelassen - und so wurden aus grauen Buttons nicht wieder blaue, sondern hell-blau-graue mit Schlieren :)


    Dieses Mal wollte ich nur kurz bleichen und war dann ganz überrascht, dass es sich in diesem Fall trotz gleicher Optik nicht um Buttons, sondern eine "Gummimatte" handelte. Habe sie trotzdem kurz mit Saloncreme geblichen, und es hat tatsächlich funktioniert. Zwar nur ein wenig, aber ich hatte alles auch nur für eine halbe Stunde in der Sonne und hatte etwas Angst um das Material. Nicht, dass es sich zersetzt - war ja kein Plastik.


    Ja, die G7000 wechselt die Module on-the-fly, wahrscheinlich die einzige Konsole der Welt, die das tut :)


    Markus_64 : Grafikmüll ist quasi der "Start"-Bildschirm der Konsole, wenn kein Modul drin ist bzw. hier wohl eher, wenn keines erkannt wird. Putz mal die Kontakte, evtl. eben auch die der Konsole selber. Wenn da ein Pin verdeckt ist kann es schon sein, dass ein Modul gar nicht geht und ein anderes nur fehlerhaft läuft...

    Längst überfällig!

    Allerdings!


    Und der Artikel... mmmh. Wieder mal wurde die eigene Meinung zur Tatsache geschrieben, vermutlich, ohne selber einen Bezug zu damalstm zu haben. Wieso waren die Composer unbekannt? Ich kann bestimmt ein Dutzend Spieletests aus den 80ern raussuchen, in denen deutlich die Musik von Rob Hubbard oder Matt Gray erwähnt wird. Naja, egal...

    Wie ich schon sagte würde ich NICHT anfangen, Assembler per mathematischen Formeln zu beginnen. Lieber Sprites und Screen nutzen, oder Samples abspielen. Alles, was weiter geht als Addition&Subtraktion bzw. Verdoppeln/Halbieren sollte nicht Teil des Einstiegs sein. Von daher würde ich Post #35 von Unseen erstmal keine Beachtung als Gradmesser schenken, sorry :weg:Es ist genau das, was Leute vom Assembler-Lernen abschreckt.


    Ich hätte da mal eine Frage. Was ist der Vorteil wenn ein ADC #$00 genutzt wird, um ein eventuell gestztes Carry-Flag zu addieren, anstatt ein "BCC" zu nutzen?

    What Unseen said:

    Klar, kann man auch machen. Ich hielt die adc #$00-Variante für Einsteigerfreundlicher weil es das gleiche Prinzip wie bei einer 16+16-Addition ist.

    Ich hab in den letzten 2-3 jahren ein paar Leuten beim Assembler-Einstieg geholfen und es zunächst stets genau so geschrieben. Es ist für Einsteiger viel ersichtlicher "als Block" reiner Addition. Es macht dem Einsteiger auch überhaupt erstmal deutlich, warum der Befehl "ADdwithCarry" heißt und dass dieses Carry-Flag am Ende auch nur ein Bit ist. Das Überspringen per Branch ist dann schon eher die "Programmierer" Version, die ich am Ende auch benutze (da schneller), es sei denn, ich will immer die exakten Cycle :)

    Meiner Meinung nach gibt es nur drei kleine Hürden für Assembler:


    1. Logisches Verständnis

    Wer das logische Verständnis für Basic hat kann auch Assembler.

    Wer versteht, wie eine Schleife funktioniert und wann&warum das Programm bei bestimmten Bedingungen aus der Schleife rausspringt kann auch Assembler. Dort wird auch nur ein Schritt nach dem anderen gemacht.

    2. Hex-Zahlen

    Hört sich schlimm an, ist es aber nicht und macht das Programmieren viel einfacher. Ich weiß auch nicht aus dem Kopf, was $e2 für eine Zahl ist - und das brauch ich auch nicht. Echte Werte in Programmen schreibt man einfach weiterhin in Dezimal, wie z.B. die Anzahl der Leben. Aber Adressen oder einen 8Bit-Wert in zwei 4Bit-Werte teilen ist ungleich logischer in Hex.

    3. Die Eigenheiten des C64

    Man muss halt wissen (wo man nachschauen kann), wo beim C64 die Rahmenfarbe definiert ist, und wo die Sprites usw. Da muss man aber nicht alle Adressen und Bits im Kopf haben, sie stehen ja z.B. im Wiki.


    Dann kann man leicht mit einem schnell eingerichteten C64-Studio & Vice anfangen zu programmieren. Und Assembler hat am Ende nur eine handvoll Befehle... :)