Pewnie każdy to wie ... ale:
Zegar atari: 1773447Hz (cykli na sekundę)
Zakładam 25 klatek/sek.
zostaje:
70937 cykli na klatkę.
Odświerzanie, dma, muzyka itd ... zaokrąglę to do 64000cykli/ramkę żeby łatwiej było.
160x200(pixeli)=32000 pixeli
Zostaje 2 cykle na pixel.
Zakładając że ekran jest w trybie 2bpp daje to 8 cykli na bajt.
LDA -> ~4 cykle, bardziej realnie 5
STA-> ~4 cykle, bardziej realnie 5
A gdzie reszta ??
Zmniejszając pionową rozdzielczość do 100pixli jest 2x więcej czasu, ale nadal to za mało na obliczenia wg jakiegokolwiek 'wysokopoziomowego' algo pixel by pixel.
Wg mnie to jest niemożliwe.
Chyba że zastosuje się jakieś tricki ... Ta rotująca szachownica z dema oxyronow jest w rozdzielczości 160*96 i właśnie trickowo jest to zrealizowane. Nie wiem jeszcze jak ale chyba nie chce mi się dłużej nad tym siedzieć.
Edit: nie mógłbym spać gdybym nie popatrzył na to.
napi* pod afresem $b000 są generowane paterny, paternów jest ... całe 16 - 8 bitowych, ale są ułożone w sprytny sposób i w sprytny sposób następnie kopiowane na ekran. Paterny są wykorzystywane do "rysowania" linii przejść pomiędzy kolorami. Reszta jest wypełniana poprostu $00 albo $ff.
Dalej zgaduję bo tego już nie analizowałem.
Gdzieś jest zaszyta tablica co dokąd w jakich odstępach kopiować, ew. jest to na wstępie gdzieś obliczone. Teoretycznie można w ten sposób stwożyć niemal dowolną szachownicę niewielkim nakładem mocy.
W załączeniu nieco obrobiona bitmapa pokazująca paterny. Org miała rozdzielczość 8x4096, ale żeby była bardziej czytelna przeskalowałem na 64x4096.
Smacznego.
Post's attachmentspaterny64.pbm 32.03 kb, liczba pobrań: 6 (od 2013-04-12)
Tylko zalogowani mogą pobierać załączniki.
"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce"
https://github.com/willyvmm/mouSTerjmp $e477