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?

  • 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! :)

  • Quote

    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


    Quote

    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.

  • Quote

    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 :)


    Quote

    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....


    Quote

    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


    Quote

    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 :)


    Quote

    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... =)

  • Quote

    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:


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



    mmmh so weit so gut -> http://codebase64.org/doku.php…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)

  • Quote

    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....

  • Quote

    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.

  • Quote

    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 :)


    Quote

    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... =)

  • Quote

    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