Hello, Guest the thread was called1.2k times and contains 20 replays

last post from DMHas at the

Denkfehler bei bit $d011

  • Hallo zusammen,


    ich "bastel" gerade an einem kleinen Demo und habe das Problem, das meine Routine nicht auf das Bit 7 von $D011 (Rasterzeile über 256). Die Befehlsfolge wartet nicht darauf, das die Rasterzeile oberhalb 255 ist (sprich Bit 7 gesetzt in $D011). Für mein Verständis dürfte sie nur weiterlaufen, wenn $d012 = 1 & $d011 Bit 7 gesetzt ist. Laut Vice wartet die Routine immer auf Rasterzeile 1 und nicht auf Rasterzeile 256. Irgendwo habe ich einen Denkfehler - nur wo? Ich habe mir schon Tage den Kopf zerbrochen.


  • kann ich irgendwie nicht so ganz glauben ...

    Im Anhang findest du (ihr) das Programm zum Testen. ich habe es mit Vice und HOXS64 getestet. Mein C64 ist derzeit nicht aufgebaut.
    Die entsprechende Routine ist von $38C6 bis $3912 zu finden. Ein beliebiger Tastendruck sollte (zum Testen) wechseln zwischen Text anzeigen und Text ausblenden....

  • 1.) Wie Mac Bacon richtig schrieb, ist der BMI-Sprung verkehrt und müßte BPL heißen. Das Bit 7 in d011 entspricht dem 8. Bit des Rasterzeilenzählers (also 2 ^ 8). Wenn Du auf eine Zeile > 255 warten willst, muß dieses bei Abfrage gesetzt sein. Folglich: Ist es nicht gesetzt (BPL) ==> warte weiter.
    2.) Dein Vorgehen ist unstimmig. Einerseits sagst Du, Du wolltest auf Zeile 256 warten, andererseits wartest Du aber auf Zeile 257. Wenn Du auf 256 warten willst, muß d012 Null sein, denn 256 = %100000000. (Die obere 1 ist in d011, die unteren 8 Nullen sind in d012.)
    3.) Warum willst Du unbedingt auf 256 warten? Die Bildschirmanzeige hört doch schon früher auf. Könntest Du nicht auch auf 255 warten? Das hätte den großen Vorteil, daß Du d011 nicht zusätzlich abfragen mußt.

    Code
    1. lda #255
    2. loop: cmp $d012
    3. bne loop

    wäre dann alles, was Du brauchst.

  • Ob es Zeile 256 oder 257 macht kein Unterschied. Ich möchte bloß warten, dass der Rasterstrahl außerhalb des zu beschreibenden Farbrambereiches ist, bevor ich die Farben ändere. Von daher sollte die Lösung mit lda #255 / cmp $d012 auch tun.


    Vielleicht kann aber trotzdem jemand mir das oben genannte Rätsel (für mich) erklären?

  • Vielleicht kann aber trotzdem jemand mir das oben genannte Rätsel (für mich) erklären?

    Das hat Mac Bacon bereits getan. Nebenbei: Der Vice-Monitor zeigt mir an, daß bei Adresse $38d4 tatsächlich ein BPL und nicht ein BMI steht.

    Im Anhang findest du (ihr) das Programm zum Testen.

    Wenn ich eine Taste drücke, passiert gar nichts. Ansonsten scrollt der Text problemlos durch. Daher kann ich leider nicht nachvollziehen, was jetzt genau Dein Problem ist. :/


    Edit: Meinst Du etwa genau das: Daß nichts passiert? Dann könnte das vielleicht daran liegen, daß die Interruptroutine in der Zeile 257 aktiv ist. Das Hauptprogramm läuft ja nicht gleichzeitig, sondern wird erst nach dem IRQ weiter fortgeführt. Dann aber - so vermute ich mal - ist der Rasterzeilen-Zähler schon längst weiter gelaufen. Ergo: Das Hauptprogramm sieht niemals 257, und der Test versagt immer.


    Edit2: Ergänze doch bitte einmal in der Warteschleife den Befehl "DEC $d020", um die Rahmenfarbe pausenlos zu verändern, und schau, an welchen Stellen auf dem Bildschirm die Rahmenfarbe stabil bleibt und nicht flimmert. Das sind die Phasen, in denen der IRQ arbeitet. Sollte sich eine solche Phase mit der Rasterzeile 257 überschneiden, wäre das der Fehler.

  • Beim Scrolltext unten soll gar nix passieren. :thumbsup: Der obere schwarze Test mit hellgrauem Hintergrund soll durch ein Farbfading ausgeblendet werden. Das war so meine Idee.
    Um meinen Gedankengang zu verstehen ein paar erklärende Worte: sofern ich das richtig verstanden habe, sind Zahlen von 0 - $7F positiv (N = 0) und $80 bis $FF (gesetztes 7. Bit) negativ (N = 1). Nach dem ich $D011 mit BIT $D011 getestet habe, wird das N-Flag automatisch (7. Bit) gesetzt oder (7. Bit) gelöscht. Wobei das 7. Bit in $D011 für Rasterzeilen größer 255 steht, wenn es gesetzt ist. Entsprechend müßte man mit BPL und BMI rausbekommen, wann sich die Rasterzeile im Bereich größer 255 befindet.


    Nutze ich BMI wird, wie weiter oben von Mac Bacon erklärt, bei Rasterzeile 01 die Schleife verlassen und die weiteren Befehle abgearbeitet.



    Nutze ich BPL, sollte die Schleife bei Rasterzeile 01 und gesetzten 7. Bit von $D011 verlassen werden. Das passiert aber nicht. Die Wartschleife wird gar nicht mehr verlassen und das ist mein Verständnisproblem. Irgendwo habe ich hier gedanklich oder im Quelltext einen Fehler der mir nicht bewußt ist. :cry:



    Diese Doppelabfrage kommt daher, das ich nur einmal pro Bildschirmaufbau das Farbfading ausführen möchte und nicht wenn der Rasterstrahl in Zeile $01 und Zeile $100 ist.


    Natürlich ist das Abfragen der Zeile $FF wesentlich sinnvoller! :applaus:

  • Edit: Meinst Du etwa genau das: Daß nichts passiert?

    Ja, das ist mein Problem. Ich teste ich später - spiele gerade noch mit einer anderen Möglichkeit den Text auszublenden.


    Update: Kurz mal getestet mittels der Farbänderung im Rahmen. Ich glaube, das Problem ist, das die benötigte Zeit für die Farbramänderung zu lange dauert. Ich teste mal weiter ....
    Der geänderte Rahmen geht unten durchgehend und oben bis zum ersten Rasterinterrupt. Ich denke da liegt das Problem.


    Scheint doch nicht daran zu liegen. Ich teste das morgen nochmal in Ruhe.

  • Ausgehend vom Quelltext im ersten Posting. Diese Stelle in der Schleife läuft ins Leere:



    Code
    1. dey ; Farbwert verringern
    2. bpl farb_fading+2

    Dort gibt es kein Label "farb_fading", wahrscheinlich ist "farb_fading_loop" gemeint? Edit: Ne, das wäre ja auch Quatsch. "farb_fading_wait_raster" ist passend. Aber wieso +2?



    Außerdem wird das X-Register nicht mit #$27 neu initialisiert, nachdem es auf null heruntergezählt wurde, da die Initialisierung lediglich außerhalb der Schleife erfolgt. Vor dem dey müsstest du also noch ein ldx #$27 einfügen, damit die Schleife funktioniert. Edit: Oder einfach das Label "farb_fading_wait_raster" entsprechend verlegen.

  • Ausgehend vom Quelltext im ersten Posting. Diese Stelle in der Schleife läuft ins Leere:

    Code
    1. dey ; Farbwert verringern
    2. bpl farb_fading+2

    Dort gibt es kein Label "farb_fading", wahrscheinlich ist "farb_fading_loop" gemeint? Edit: Ne, das wäre ja auch Quatsch. "farb_fading_wait_raster" ist passend. Aber wieso +2?


    Außerdem wird das X-Register nicht mit #$27 neu initialisiert, nachdem es auf null heruntergezählt wurde, da die Initialisierung lediglich außerhalb der Schleife erfolgt. Vor dem dey müsstest du also noch ein ldx #$27 einfügen, damit die Schleife funktioniert. Edit: Oder einfach das Label "farb_fading_wait_raster" entsprechend verlegen.


    Das Label farb_fading habe ich vergessen mit zu kopieren. So sieht der Anfang der Routine aus:


    Code
    1. farb_fading ldy #$07 ; Anzahl der zu schreibenden Farbwerte
    2. ldx #$27 ; 1 Bildschirmzeile

    Mit bpl farb_fading+2 wird dann direkt zu ldx #$27 gesprungen. mc71 hat es richtig erklärt. farb_fading Ist Aufrufname der Routine für jsr.

  • @DMHas: Ja, leuchtet ein. War schon spät gestern.


    Hast du's denn jetzt hinbekommen? Dein Intro habe ich jetzt mal heruntergeladen. Wenn ich diesen Teil


    Code
    1. farb_fading_wait_raster lda #$01
    2. cmp $d012
    3. bne farb_fading_wait_raster+2
    4. bit $d011
    5. bmi farb_fading_wait_raster


    wie hier vorgeschlagen im RAM ändere zu

    Code
    1. farb_fading_wait_raster lda #$ff
    2. cmp $d012
    3. bne farb_fading_wait_raster+2
    4. nop
    5. nop
    6. nop
    7. nop
    8. nop

    funktioniert es so wie es soll. Zumindest das Ausblenden. Das Einblenden ist natürlich "hart".

  • -trb-: Kein Thema! Ich habe schließlich nicht alle angeben gemacht (das vergessene Label)! Daher kein Grund sich zu entschuldigen. Beim Einblenden nutze die gleichen Farbwerte nur rückwärts gelesen. Hatte ich hier nur noch implementiert.


    Die Frage warum in Vice immer Rasterzeile 01 (mit Bit $d011 Abfrage) angezeigt wird, statt 256 / 257 ist noch nicht geklärt. Aber es ist nicht wirklich so dramatisch, da das Einblenden über die Farben nicht so funktioniert wie ich es mir vorstelle. Ich finde keine wirklich schönen Farbwerte die elegant aussehen. Daher teste ich gerade das Ausblenden über ASL, was mir besser gefällt. Beim Einblenden muß ich noch etwas rumprobieren...


    Trotzdem nochmals Danke an alle für die Hilfestellung!

  • Die Frage warum in Vice immer Rasterzeile 01 (mit Bit $d011 Abfrage) angezeigt wird, statt 256 / 257 ist noch nicht geklärt.

    Anscheinend hattest Du meinen zweiten Edit nicht gesehen.
    Im Programm wird ab Adresse $4897 ein Interrupt gesetzt für die Zeilennummer 255. Dieser Interrupt findet damit parallel statt zur Deiner Rasterzeilenabfrage im Hauptprogramm. Während der Zeilen 256 und 257 ist die Interruptroutine aktiv, so daß Deine Warteschleife niemals den Wert 257 lesen kann.

    Code
    1. .C:4897 A9 DC LDA #$DC
    2. .C:4899 8D 14 03 STA $0314
    3. .C:489c A9 48 LDA #$48
    4. .C:489e 8D 15 03 STA $0315
    5. .C:48a1 A9 FF LDA #$FF <--- !!!!!
    6. .C:48a3 8D 12 D0 STA $D012
    7. .C:48a6 A9 1D LDA #$1D
    8. .C:48a8 8D 18 D0 STA $D018
    9. .C:48ab A9 FF LDA #$FF
    10. .C:48ad 8D 19 D0 STA $D019
  • Anscheinend hattest Du meinen zweiten Edit nicht gesehen.Im Programm wird ab Adresse $4897 ein Interrupt gesetzt für die Zeilennummer 255. Dieser Interrupt findet damit parallel statt zur Deiner Rasterzeilenabfrage im Hauptprogramm. Während der Zeilen 256 und 257 ist die Interruptroutine aktiv, so daß Deine Warteschleife niemals den Wert 257 lesen kann.

    In der Tat habe ich den überlesen! :schande:


    Ein Anfang wäre evtl., wenn du in die hier beschriebene Routine eine Verzögerung einbaust, damit nicht immer schon nach einem Frame die jeweils neue Farbe ins Colorram geschrieben wird. Dadurch wirkt das schon sanfter.

    Habe ich auch schon probiert. Auch Farben dopplet zu nutzen ähnlich den unteren beiden Rasterbars und die Color-Fading Tabellen von Codebase. Aber meine Ausblendeffekte sahen egal wie immer zum :kotz aus. Wahrscheinlich habe ich kein Händchen hierfür.