c64scene.pl

Cześć,
Świąteczne wieczorki postanowiłem spędzić na spełnieniu marzeń z dzieciństwa, czyli oczywiście napisania stabilnej "rutyny" rastra. Wybór padł na Visual Studio Code + KickAss + wtyczka do VSCode i oczywiście C64Debugger. Stabilizacji dokonałem metodą na przerwanie w przerwaniu, co generalnie ładnie udało się docyklować. Zachęcony sukcesem zamarzyło mi się poruszać barem wedle sinusa w dół i w górę... nawet się udało i wtedy napatoczyłem się na bad-linie, z którymi nie umiem sobie rozsądnie poradzić, więc odwołuję się do wiedzy i doświadczenia forumowiczów.
Jak to ogólnie ugryźć? Sprawdzanie, czy dana linia jest zła już w niej nie sprawdza się, bo jak VIC zabierze te swoje 40 cykli to już na porównanie RASTER z YSCROLL braknie czasu. Sprawdzać jakoś prymitywniej zakładając określoną wartość YSCROLL? A może jakoś pozbyć się bad-line? (znaki na ekranie chciałbym zostawić na wypadek chęci napisania czegoś ). Co radzicie?
Pozdrawiam,
MCN

Bartek Kachniarz takie rzeczy objaśniał w niezapomnianych artykułach "Pamiętnik artylerzysty" w C&A

Masz różne sposoby - on pokazywał z tabelką dla linii rastra i dekrementacją rejestru, a w tabelce były wartości opóźnień.
Generalnie staraj się wychodzić z założenia że nie sprawdzasz w jakiej jesteś linii, tylko po scyklowaniu wiesz w jakiej jesteś linii.
Wtedy działasz w pętli lub unrolled code.
Możesz także odsuwać sobie ekran w dół i mieć każdą linię o tej samej ilości cykli (FLD)

Pomysł z tabelką opóźnień wydaje się zacny. Dzięki!
FLD tym razem chciałbym uniknąć, choć wydaje się, że rodzi sporo możliwości na fajną zabawę liniami.

Nie ma co wynajdywać koła na nowo:
https://codebase64.org/doku.php?id=base:double_irq
albo z wyjaśnieniem:
https://codebase64.org/doku.php?id=base ... _explained
Ogólnie codebase przyjacielem każdego początkującego.