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

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?

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?

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?

Zitat

Original von Roland
badline sollte seit zeile $f0 auch keine mehr aufgetreten sein...

Badlines gibt es von $30 bis $F7.

Zitat

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

Zitat

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

Zitat

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

Zitat

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

Zitat

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

Zitat

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

Zitat

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

Zitat

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

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

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?

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

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)

Zitat

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

Zitat

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