Problem mit ClearScreen-Routine

WebFritzi · 27. August 2021

Hallo ihr. Könnte sich jemand mal bitte den Code im angehängten zip-File anschauen? Es geht vor allem um die folgende Routine (befindet sich in !zone Graphics):

Code

ClearScreen ldx #24
clr_loop_outer ldy #39
lda ScrTabLo,x
sta $fb
clr_loop_inner lda ScrTabHi,x
sta $fc
lda #42
sta ($fb),y
lda ColorTabHi,x
sta $fc
lda #8
sta ($fb),y
dey
bpl clr_loop_inner
dex
bpl clr_loop_outer
rts
...
...
ScrTabLo !byte $00,$28,$50,$78,$a0,$c8,$f0,$18,$40,$68,$90,$b8
!byte $e0,$08,$30,$58,$80,$a8,$d0,$f8,$20,$48,$70,$98,$c0
ScrTabHi !byte $04,$04,$04,$04,$04,$04,$04,$05,$05,$05,$05,$05
!byte $05,$06,$06,$06,$06,$06,$06,$06,$07,$07,$07,$07,$07
ColorTabHi !byte $d8,$d8,$d8,$d8,$d8,$d8,$d8,$d9,$d9,$d9,$d9,$d9
!byte $d9,$da,$da,$da,$da,$da,$da,$da,$db,$db,$db,$db,$db

Alles anzeigen

In dieser kleistere ich den Bildschirm voll mit dem Char No #42 (Multicolor 1, alle Pixel gesetzt). Relativ am Anfang des Programms rufe ich diese auf, und es funktioniert auch. Ich sehe auch nicht, was daran falsch sein soll. Wenn ich im Programm aber die 6x6-Button-Größe wähle, wird in der obersten Zeile des Bildschirms gemalt (weiße Linie), und das macht er bei einem erneuten Wechsel (z.B. auf 4x4) nicht weg. Naja, jedenfalls teilweise nicht. Manchmal schafft er es bis zur Hälfte der Linie und lässt es dann.

Wegen dieses Verhaltens muss das irgendwas mit dem installierten Raster-IRQ zu tun haben, aber ich verstehe nicht, was. Der feuert schließlich erst acht Zeilen später. Mit folgendem Code, der einfach nochmal die oberste Zeile überpinselt und den ich oben direkt vor rts schreibe, kann ich das Problem beheben, aber ich verstehe nicht, wieso:

Code

lda #42
ldy #39
huhu sta $0400,y
dey
bpl huhu

Kommt jemand von euch dahinter?

Mike · 27. August 2021

Zitat von WebFritzi

Kommt jemand von euch dahinter?

Ich tippe mal darauf, daß deine Raster-IRQ-Routine am Wert in $FB/$FC 'dreht'.

enthusi · 27. August 2021

Und zwischen screen und colorram ist ja ein fester offset.

Statt der color tabelle reicht ein clc adc #$d4.

sparhawk · 27. August 2021

Ausserdem kann inner_loop zwei Zeilen weiter runter. $fc sollte sich nicht ändern innerhalb der Schleife, also muss man es nicht jedesmal neu setzen. Und wenn das ausserhalb durch einen IRQ verändert würde, dann hast du vielleicht ein anderes Problem.

Hoogo · 27. August 2021

Ich habe auch keine Stelle gefunden, an der der Raster versehentlich $fb/fc ändern würde.

Zur Fehlersuche:

- Probier mal, statt der Extra-Löschroutine das Clearscreen durch ein SEI/CLI zu schützen, um auszuschließen, dass es nicht doch am Raster liegt.

- Mach das Clearscreen absichtlich langsamer, paar Nops sollten ja reichen. Wird das Problem dadurch größer?

- Das Farbram hat aber die korrekten Werte bekommen? Bau mal noch eine kleine Schleife vor das Clearscreen, das das Farbram oben auf eine absichtlich falsche Farbe stellt.

- Im Vice einen Haltepunkt am Ende des Clearcreens setzen und prüfen, ob &fb/fc und die REgister die erwarteten Werte haben.

WebFritzi · 27. August 2021

Zitat von Mike

Ich tippe mal darauf, daß deine Raster-IRQ-Routine am Wert in $FB/$FC 'dreht'.

Nope. Ändert nur $02, ein paar selbst definierte Speicherstellen und die Positionen des Cursorpointers.

JeeK · 27. August 2021

Statt $fb/$fc zwei andere Zeropage-Locations verwenden (z. B. $50/$51, wird sonst nur für die Stringverarbeitung temporär gebraucht). Dann kann man mal ausschließen, dass der Interrupt in $fb/$fc reinspielt.

Anmerkung zur Routine selbst. Wenn man nicht wirklich im laufenden Programm den Bildschirm an unterschiedlichen Positionen löschen muss, ist die Lösung ein ziemlicher Overkill (in Zeit und Platz).

Reicht hier nicht die Standardlösung?

Code

ldx #0
ldy #8 ; farbe für später
loop: lda #42 ; zeichen
sta $0400,x
sta $0500,x
sta $0600,x
sta $06e8,x ; nur bis 1000er-grenze
tya ; farbe
sta $d800,x
sta $d900,x
sta $da00,x
sta $dae8,x ; nur bis 1000er-grenze
inx
bne loop

Alles anzeigen

WebFritzi · 27. August 2021

Zitat von enthusi

Und zwischen screen und colorram ist ja ein fester offset.
Statt der color tabelle reicht ein clc adc #$d4.

Und davor noch ein lda $fc. Ist das dann schneller?

WebFritzi · 27. August 2021

Zitat von sparhawk

Ausserdem kann inner_loop zwei Zeilen weiter runter. $fc sollte sich nicht ändern innerhalb der Schleife, also muss man es nicht jedesmal neu setzen.

Doch, weil ich ja nicht nur den Screen, sondern auch die Farbe setze. Aber dein Kommentar hat mich jetzt darauf gebracht, dass ich für die Farbe ja auch $fd/$fe nutzen kann. Danke also.

WebFritzi · 27. August 2021

Zitat von JeeK

Statt $fb/$fc zwei andere Zeropage-Locations verwenden (z. B. $50/$51, wird sonst nur für die Stringverarbeitung temporär gebraucht). Dann kann man mal ausschließen, dass der Interrupt in $fb/$fc reinspielt.

Hab ich mal gemacht. Danke für diesen Ansatz zum Testen. Das Problem bleibt jedoch. An $fb/$fc kann es also definitiv nicht liegen.

Dann habe ich mal deine "Standard-Routine" genommen, und der Strich geht weg. Ich finde das äußerst merkwürdig.

sparhawk · 27. August 2021

Zitat von WebFritzi

Doch, weil ich ja nicht nur den Screen, sondern auch die Farbe setze. Aber dein Kommentar hat mich jetzt darauf gebracht, dass ich für die Farbe ja auch $fd/$fe nutzen kann. Danke also.

Stimmt. Hatte ich übersehen. Aber $fd benutzen ist sowieso effizienter weil das ständige neu setzen in der inneren Schleife entfällt.

WebFritzi · 27. August 2021

Zitat von Hoogo

- Probier mal, statt der Extra-Löschroutine das Clearscreen durch ein SEI/CLI zu schützen, um auszuschließen, dass es nicht doch am Raster liegt.

Auf die Idee war ich auch schon gekommen. Gleiches Problem.

Zitat von Hoogo

- Mach das Clearscreen absichtlich langsamer, paar Nops sollten ja reichen. Wird das Problem dadurch größer?

Kann ich leider im Moment nicht sagen, denn ob mit oder ohne NOPs zeichnet er den Strich (meistens) durch.

Zitat von Hoogo

- Das Farbram hat aber die korrekten Werte bekommen? Bau mal noch eine kleine Schleife vor das Clearscreen, das das Farbram oben auf eine absichtlich falsche Farbe stellt.

Gute Idee. Das sieht dann wie in den angehängten Bildern aus.

Zitat von Hoogo

- Im Vice einen Haltepunkt am Ende des Clearcreens setzen und prüfen, ob &fb/fc und die REgister die erwarteten Werte haben.

Wie mach ich das? Hab von sowas im Vice keine Ahnung.

WebFritzi · 27. August 2021

Ich habe jetzt mal im C64Studio einen Breakpoint beim letzten rts gesetzt. Die Bilder sehen ganz komisch aus. Es betrifft also offenbar nicht nur die oberste Zeile.

Hoogo · 27. August 2021

Zitat von WebFritzi

Ich habe jetzt mal im C64Studio einen Breakpoint beim letzten rts gesetzt. Die Bilder sehen ganz komisch aus. Es betrifft also offenbar nicht nur die oberste Zeile.

Das dürfte ein Effekt des Vice sein. Der Monitor hält die Maschine RICHTIG an, auch den Rasterstrahl! Erst, wenn der Strahl wieder an den veränderten Speicherstellen vorbeikommt wird auch der Bildschirm aktualisiert.

Die Version, die Du vorgestern hier gezeigt hast, dürfte ja ausreichend ähnlich sein, auch wenn der Code nur bis 5*5 geht und etwas anders sortiert ist.

Was ich noch probiert habe: Haltepunkt (im Vice) am Anfang des ClearScreen gesetzt, f 0400 0800 11 eingegeben, um den Bildschirm mit Müll zu füllen, DrawMap (?) (1027) mit jmp $1027 überschrieben. Der Bildschirm wird ordentlich gelöscht.

Vielleicht verhaut Dir irgendwas bei 6*6 die Tabellen, mit denen Du $fc/fd setzt?

WebFritzi · 27. August 2021

Zitat von Hoogo

Vielleicht verhaut Dir irgendwas bei 6*6 die Tabellen, mit denen Du $fc/fd setzt?

Das ist es!!! Ich habe mir mal den Speicher angeschaut. Und tatsächlich - nach dem Umschalten von 6x6 auf 4x4 steht da nicht mehr 00, sondern 1E im Speicher. Alles andere scheint so geblieben zu sein. Verrückt. Ich hasse solche Bugs. Gibt es im Debugger evtl. die Möglichkeit, auf das Ändern einer bestimmten Speicherstelle zu warten, so dass ich weiß, wo der Mist passiert?

Hoogo · 27. August 2021

Zitat von WebFritzi

Gibt es im Debugger evtl. die Möglichkeit, auf das Ändern einer bestimmten Speicherstelle zu warten, so dass ich weiß, wo der Mist passiert?

Tipp im Vice-Monitor mal "help bk" ein.

Endurion · 27. August 2021

Yes. Im "Breakpoint"-Fenster eine Speicheradresse eingeben (oder Label auswählen), Statt "Exec" "Store" auswählen, und der Breakpoint springt an, wenn in die Adresse geschrieben wird.

WebFritzi · 27. August 2021

Zitat von Hoogo

Zitat von WebFritzi

Gibt es im Debugger evtl. die Möglichkeit, auf das Ändern einer bestimmten Speicherstelle zu warten, so dass ich weiß, wo der Mist passiert?

Tipp im Vice-Monitor mal "help bk" ein.

Der schließt sich bei mir leider gleich wieder. Zuletzt hatte ich das Problem gelöst, indem ich in der Sektion "Machine->Monitor" das Häkchen bei "Enable Remote Monitor" rausgenommen habe. Das funktioniert jetzt nicht mehr. Ich verwende GTKVICE 3.5.

WebFritzi · 27. August 2021

Zitat von Endurion

Yes. Im "Breakpoint"-Fenster eine Speicheradresse eingeben (oder Label auswählen), Statt "Exec" "Store" auswählen, und der Breakpoint springt an, wenn in die Adresse geschrieben wird.

Daaanke!!! Ich hab's rausgefunden. Da stand direkt vor dem Screen Table:

Code

Numbers !byte 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20
!byte 21,22,23,24,25,26,27,28,29,30,31,32,33,34,35

So, und die freie Stelle des Puzzles steht bei 6x6 auf 36. So habe ich immer das erste Byte des Screen Tables für meine Zahlen verwendet. Oh Mann.

Dank euch habe ich den Fehler gefunden. Vielen Dank!!!