Sprites im unteren Sideborder


  • sauhund
  • 1661 Aufrufe 14 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Sprites im unteren Sideborder

    mmmh, ich hab diese nacht mal spasseshalber ein bischen vor mich hingecodet.... und zwar wollte ich einen simplen scroller mit sprites im unteren border basteln, wobei der sideborder offen sein sollte. soweit so gut... alles runtergehackt, und erstaunlicherweise ging das sogar :schreck!:

    so, der "spass" fing jetzt aber an als ich das ganze ein paar rasterzeilen hochschieben wollte..... dann ging irgendwie garnix mehr, das timing ansich scheint zwar ok zu sein (alle umschaltstellen sauber untereinander), aber ich krieg das timing dann nicht mehr so verschoben das das erste beschreiben von d016 auch am anfang des letzten zeichens passiert, hmpf.

    die rahmenbedingungen sind folgende: textfenster fängt bei line $30 an (also $d011=$30), unterer border wird wie üblich geöffnet (muss ich wohl nicht erklären). im unteren border sollen nebeneinander 8 (x-expandete) sprites bei offenem sideborder dargestellt werden. (der eigentliche scroller ist an der stelle ja mal egal).

    wenn ich nun die sprites an Y position $ff darstelle funktioniert alles wie erwartet.... schiebe ich die sprites aber nun ein paar lines höher, sagen wir nach $f9 flippt das timing aus. ok gut, kann ich teilweise nachvollziehen, das wäre ja der bereich in dem man eine 26. charline hinprügeln kann.... auf der andren seite verwirrt mich das doch irgendwie :=) ich muss an der stelle mein timing pro line 1 cycle kürzer machen, dann sind zumindest die umschaltstellen wieder untereinander, ABER ich krieg die dann nich zum 39. char geschoben, wo sie aber zum border aufmachen sein sollten... warum? :bmotz:

    kann mich da mal wer erleuchten? roland? hogo? fröhn? oder wer auch immer? =)

    kann man an der stelle *überhaupt* 8 sprites mit offenem border hinkriegen? ist das timingmässig wie eine charline zu behandeln? oder ein sonderfall? oder wie? :blah!

    und was könnte denn generell sonst der grund dafür sein das ich das timing nicht wie ich will cyclemässig verschieben kann? klar, die sprite-fetches hauen dazwischen, aber das tun die ja auch wenn die sprites ab line $ff angezeigt werden .... also was sonst?
  • RE: Sprites im unteren Sideborder

    klingt sehr verwirrend...vor allem, wenn man kein beispielcode hat ;)
    eigentlich sollte es keine probleme geben, dass von $ff auf $f9 zu schieben....
    badline sollte seit zeile $f0 auch keine mehr aufgetreten sein...

    hmmm--- border mit $dec $d016 auf machen, ja?
    denn mit sta geht mit 8 sprites ja nicht...

    ansonsten.... zeigen! :)
  • eigentlich sollte es keine probleme geben, dass von $ff auf $f9 zu schieben.... badline sollte seit zeile $f0 auch keine mehr aufgetreten sein...


    ja, so dachte ich mir das eigentlich auch

    hmmm--- border mit $dec $d016 auf machen, ja? denn mit sta geht mit 8 sprites ja nicht...


    ja klar

    *kratz* also äh, wenn du sagst das muss genauso gehen dann probier ich nochmal ein bischen, kann ja dann nur irgendeine doofe kleinigkeit sein =P

    ansonsten poste ich später mal das ergebnis, funktionierend oder nicht :)
  • Einzige Theorie bei mir: Wie stabilisierst Du den Raster? Ein Fehler da muß ja nicht heissen, daß es flackert, es kann auch passieren, daß sich das zufälligerweise doch stabilisiert, aber halt auch vom Ende der Rasterroutine abhängt. Dann ändert meist jedes Wackeln am Programm die Positioen ganz unerwartet.

    Dann fällt mir noch ein, daß man den unteren Border gar nicht unbedingt öffnen muß, wenn man mit dem Öffnen des seitlichen Borders vor dem Rahmen anfängt und einfach nicht aufhört. Dann kann man sich an der Stelle auch nicht versehentlich das Scrollregister durcheinanderwirbeln. Aber selbst wenn dürfte das nciht den beschriebenen Effekt haben.

    Un daß Du die Sprites nicht um 8, sondern um 6 Zeilen verschoben hast fällt mir auf. Falls deine Rasterroutine Badlines überstreicht könnte das das Timing verändern, aber auch das dürfte nicht den beschriebenen Effekt haben.

    Dann könnte man noch verschiedene Emulatoren probieren. Wenn's auf denen genauso aussieht würde ich wundersame neue VIC-Tricks ausschliessen.

    EDIT: Ach ja, Page-boundaries würden mir noch einfallen. Auf jeden Fall würde ich auf einen Programmfehler tippen.
    Vollmond war gestern!

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von hoogo ()

  • Einzige Theorie bei mir: Wie stabilisierst Du den Raster? Ein Fehler da muß ja nicht heissen, daß es flackert, es kann auch passieren, daß sich das zufälligerweise doch stabilisiert, aber halt auch vom Ende der Rasterroutine abhängt. Dann ändert meist jedes Wackeln am Programm die Positioen ganz unerwartet.


    nunja, in dem fall benutze ich nichtmal nen interrupt, sondern schalten den irq aus und mache alles im hauptprogram :) ich hab aber trotzdem mal ne 0815 rastersync routine reingepastet (so eine die immer jede line den fehler halbiert), ist aber sinnfrei und ändert auch wie erwartet genau garnix :)

    Dann fällt mir noch ein, daß man den unteren Border gar nicht unbedingt öffnen muß, wenn man mit dem Öffnen des seitlichen Borders vor dem Rahmen anfängt und einfach nicht aufhört. Dann kann man sich an der Stelle auch nicht versehentlich das Scrollregister durcheinanderwirbeln. Aber selbst wenn dürfte das nciht den beschriebenen Effekt haben.


    das ist aber mal ein guter tip....

    Un daß Du die Sprites nicht um 8, sondern um 6 Zeilen verschoben hast fällt mir auf. Falls deine Rasterroutine Badlines überstreicht könnte das das Timing verändern, aber auch das dürfte nicht den beschriebenen Effekt haben.


    badlines sind da ja wie gesagt garkeine mehr

    Dann könnte man noch verschiedene Emulatoren probieren. Wenn's auf denen genauso aussieht würde ich wundersame neue VIC-Tricks ausschliessen.


    hehe, ich teste natürlich nebenher auch auf nem richtigen c64 :)

    EDIT: Ach ja, Page-boundaries würden mir noch einfallen. Auf jeden Fall würde ich auf einen Programmfehler tippen.


    natürlich, es ist mit ziemlicher sicherheit - wie immer - irgendeine doofe kleinigkeit.

    am besten nochmal alles löschen und neu machen glaub ich... =)
  • sonst kommt ja nie was neues cooles dabei raus


    hehe eigentlich soll es ja nur ein kleines beispiel für codebase64.org werden :) wär ich doch nich auf die doofe idee gekommen das das besser aussieht wenn die sprites ein paar lines früher angezeigt werden :schreck!:

    btw, macht es einen unterschied ob ich nun mehrere 2 bzw 3 byte lange oder weniger längere befehle zum timen der loop bzw vorher zum richtig schieben des timings benutze? (vonwegen instruction fetches die den bus blockieren oder sowas?) evtl liegt hier ja das problem :)
  • hrm, also hier erstmal mein "funktionierender" versuch .... irgendwie hab ichs aber noch immer nich hingebogen das das auf ner andren rasterline klappt, sollte ich das $d011 beschreiben besser mit in die loop packen? (ich wills eigentlich jetzt nicht unrolled machen und zeilenweise austimen - das ginge sicher irgendwie, wär aber irgendwie zu billig =P)

    aber evtl mache ich auch irgendwas anderes total falsch ? grrr :bmotz:

    was ich auch nicht raffe: ich wollte den rastersync kram der einfachheit halber rauswerfen, weil er ja *eigentlich* nicht nötig sein sollte (interrupts sind ja gesperrt!) ... trotzdem flackerts aber ohne den sync ... warum zum geier? :aerger:

    Brainfuck-Quellcode

    1. !cpu 6502
    2. !to "test1.prg", cbm
    3. ;--------------------------------------------------
    4. ; basic stub
    5. *= $0801
    6. !byte $0c,$08,$0a,$00,$9e,$32,$30,$36,$34,$00,$00,$00,$00
    7. ;--------------------------------------------------
    8. *=$0810
    9. sei
    10. ; init ghostbyte with some pattern to make border more visible
    11. ; and so we can see character boundaries in the border
    12. lda #%10000000
    13. sta $3fff
    14. ; setup textscreen Y position
    15. lda #$18
    16. sta $d011
    17. ; init X scroll
    18. lda #$c8
    19. sta $d016
    20. ; now setup the 8 sprites
    21. lda #$ff
    22. sta $d015 ;enable
    23. lda #%11111111
    24. sta $d01d ;xpand-x
    25. lda #$0
    26. sta $d017 ;xpand-y
    27. sta $d01c ;muco
    28. sta $d01b ;prio
    29. ldx #0
    30. ldy #0
    31. ll
    32. txa
    33. sta $d027,x ; sprite colors
    34. lda #spritedata/64
    35. sta $07f8,x ; sprite pointers
    36. lda #$ff
    37. sta $d001,y ; y-pos
    38. iny
    39. iny
    40. inx
    41. cpx #8
    42. bne ll
    43. ; sprite data
    44. ldx #0
    45. lda #$ff
    46. l2
    47. sta spritedata,x
    48. inx
    49. cpx #63
    50. bne l2
    51. lda #0
    52. sta $d000
    53. lda #0+(2*24)
    54. sta $d000+(1*2)
    55. lda #0+(4*24)
    56. sta $d000+(2*2)
    57. lda #(0+(6*24))&$ff
    58. sta $d000+(3*2)
    59. lda #(0+(8*24))&$ff
    60. sta $d000+(4*2)
    61. lda #(0+(10*24))&$ff
    62. sta $d000+(5*2)
    63. lda #(0+(12*24))&$ff
    64. sta $d000+(6*2)
    65. lda #(0+(14*24))&$ff
    66. sta $d000+(7*2)
    67. ; x-pos MSB
    68. lda #%11000000
    69. sta $d010
    70. jmp main_loop
    71. *=$0900 ; align to some page so branches do not cross a page boundary and fuck up the timing
    72. ;-------------------mainloop---------
    73. main_loop
    74. ; since we need cycle exact non jittering timing we must stabilize the raster
    75. ldx #$d1
    76. jsr rastersync
    77. ldy #$c8 ; value for 40 columns mode
    78. lda #$f8
    79. rl1 cmp $d012
    80. bne rl1
    81. ; open the lower border
    82. lda #$18&$f7
    83. sta $d011
    84. lda #$ff
    85. rl2 cmp $d012
    86. bne rl2
    87. ; delay so the first write to $d016 happens exactly at the
    88. ; beginning of the last character before the border
    89. ; 0: 4 cycles 1: 9 cycles 2: 14 cycles 3: 19 cycles etc
    90. ldx #6 ; 2
    91. wl1 dex ; 2
    92. bpl wl1 ; 3 (2)
    93. nop ; 2
    94. ; the actual loop to open the sideborders
    95. ldx #21
    96. ol1
    97. dec $d016 ; 6
    98. sty $d016 ; 4
    99. nop ; 2
    100. nop ; 2
    101. nop ; 2
    102. nop ; 2
    103. nop ; 2
    104. nop ; 2
    105. nop ; 2
    106. nop ; 2
    107. nop ; 2
    108. nop ; 2
    109. nop ; 2
    110. nop ; 2
    111. nop ; 2
    112. clc ; 2
    113. bcc sk1 ; 3
    114. sk1
    115. dex ; 2
    116. bpl ol1 ; 3
    117. ; -> 46 ( 63-((8*2)+1) )
    118. ; reset $d011 for next round of upper/lower border opening
    119. lda #$18
    120. sta $d011
    121. jmp main_loop
    122. ;--------------------------------------------------
    123. ; simple polling rastersync routine
    124. *=$0d00 ; align to some page so branches do not cross a page boundary and fuck up the timing
    125. rastersync:
    126. lp1:
    127. cpx $d012
    128. bne lp1
    129. jsr cycles
    130. bit $ea
    131. nop
    132. cpx $d012
    133. beq skip1
    134. nop
    135. nop
    136. skip1: jsr cycles
    137. bit $ea
    138. nop
    139. cpx $d012
    140. beq skip2
    141. bit $ea
    142. skip2: jsr cycles
    143. nop
    144. nop
    145. nop
    146. cpx $d012
    147. bne onecycle
    148. onecycle: rts
    149. cycles:
    150. ldy #$06
    151. lp2: dey
    152. bne lp2
    153. inx
    154. nop
    155. nop
    156. rts
    157. spritedata=$0fc0
    Alles anzeigen
    Dateien
    • test1.prg

      (1,33 kB, 20 mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von sauhund ()

  • mmmh, ich glaube das mit dem $d011 beschreiben war einfach ne scheissidee, so gehts dann auch mit sprites ab line $fa. :@1@:

    Quellcode

    1. main_loop
    2. ; since we need cycle exact non jittering timing we must stabilize the raster
    3. ; ldx #$d1
    4. ; jsr rastersync
    5. ldy #$c8 ; value for 40 columns mode
    6. lda #$fa
    7. rl2 cmp $d012
    8. bne rl2
    9. ; delay so the first write to $d016 happens exactly at the
    10. ; beginning of the last character before the border
    11. ; 0: 4 cycles 1: 9 cycles 2: 14 cycles 3: 19 cycles etc
    12. ldx #5 ; 2
    13. wl1 dex ; 2
    14. bpl wl1 ; 3 (2)
    15. nop ; 2
    16. nop ; 2
    17. nop ; 2
    18. nop ; 2
    19. ; the actual loop to open the sideborders
    20. ldx #21
    21. ol1
    22. dec $d016 ; 6
    23. sty $d016 ; 4
    24. nop ; 2
    25. nop ; 2
    26. nop ; 2
    27. nop ; 2
    28. nop ; 2
    29. nop ; 2
    30. nop ; 2
    31. nop ; 2
    32. nop ; 2
    33. nop ; 2
    34. nop ; 2
    35. nop ; 2
    36. nop ; 2
    37. clc ; 2
    38. bcc sk1 ; 3
    39. sk1
    40. dex ; 2
    41. bpl ol1 ; 3
    42. ; -> 46 ( 63-((8*2)+1) )
    43. jmp main_loop
    Alles anzeigen


    mmmh so weit so gut -> codebase64.org/doku.php?id=sou…ites_in_bottom_sideborder

    eine sache ist mir noch aufgefallen... kann man eigentlich ein sprite weiter als bis position 0 nach links schieben? ist mir jetzt erst beim testen aufm emu aufgefallen das das ja garnicht "ganz links" ist dann ... auf meinem monitor sieht man das nicht =P (aber vielleicht ja auf andren...darum wäre mittig schieben schon nicht doof, wenn es denn geht)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von sauhund ()

  • Original von sauhund
    eine sache ist mir noch aufgefallen... kann man eigentlich ein sprite weiter als bis position 0 nach links schieben? ist mir jetzt erst beim testen aufm emu aufgefallen das das ja garnicht "ganz links" ist dann ... auf meinem monitor sieht man das nicht =P (aber vielleicht ja auf andren...darum wäre mittig schieben schon nicht doof, wenn es denn geht)


    ja, kann man.
    allerding kommt nach nach #00 nicht #FF, sondern #F7 (mit gesetztem $D010 Bit).
    Ist eigentlich ja auch gar klar, da der PAL C64 63 Zyklen pro Zeile hat, was in Pixel umgerechnet $1F8 ist, und eben nicht $200....
  • Original von sauhund
    was ich auch nicht raffe: ich wollte den rastersync kram der einfachheit halber rauswerfen, weil er ja *eigentlich* nicht nötig sein sollte (interrupts sind ja gesperrt!) ... trotzdem flackerts aber ohne den sync ... warum zum geier? :aerger:
    [/code]


    ehm, das stimmt aber nur unter einer voraussetzung:
    dass dein code taktzyklenmässig so getimt ist, dass er inklusive der warteloop auf die startrasterzeile immer mit dem selben zyklenvesatz startet, wie nach dem rastersync.

    so, wenn ich da jetzt nicht vertue bedeutet das, dass die routine, die nach dem loop kommt ein vielfaches von 7 an taktzyklen verbrauchen muss, da der loop ja 7 zyklen braucht.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Roland ()

  • allerding kommt nach nach #00 nicht #FF, sondern #F7 (mit gesetztem $D010 Bit). Ist eigentlich ja auch gar klar, da der PAL C64 63 Zyklen pro Zeile hat, was in Pixel umgerechnet $1F8 ist, und eben nicht $200....


    aahhhh ok. welche x position nehme ich denn da dann damit die 8 sprites genau zentriert sind?

    edit: es müsste -8, also $f0 sein, richtig? also für das erste sprite versteht sich :)

    ehm, das stimmt aber nur unter einer voraussetzung: dass dein code taktzyklenmässig so getimt ist, dass er inklusive der warteloop auf die startrasterzeile immer mit dem selben zyklenvesatz startet, wie nach dem rastersync. so, wenn ich da jetzt nicht vertue bedeutet das, dass die routine, die nach dem loop kommt ein vielfaches von 7 an taktzyklen verbrauchen muss, da der loop ja 7 zyklen braucht.


    args ja klar, natürlich....ist schon spät... =)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von sauhund ()

  • Original von sauhund
    aahhhh ok. welche x position nehme ich denn da dann damit die 8 sprites genau zentriert sind?

    edit: es müsste -8, also $f0 sein, richtig? also für das erste sprite versteht sich :)


    yo,
    8*6 chars = 48 chars breit.
    also 4 links, 40 im screen, 4 rechts.
    also: $18 - $20 (-8 extra), also: $f0

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Roland ()

  • Benutzer online 1

    1 Besucher

  • Tags