Názory k článku Praktické použití grafických režimů nabízených čipem ANTIC
-
Nebylo by možné v tom GR.8 první oblast posunout dolů v tom 4kB bloku tak, aby se dotýkala oblasti druhé? Potom by to byl kontinuální blok paměti, i když by ten první blok začínal někde na 4096-3840. Teď nevím, jestli to tak není v BASICu, protože si vzpomínám, že šlo vyplňovat pomocí POKE celou obrazovku (ale to je dávno, možná si to dělám zelenější, než to bylo).
-
Je to tak, vyzkoušel jsem to teď v emulátoru. V BASICu to je:
GR.8 : FOR I=0 TO 159 : POKE 33104+I*40,85 : NEXT I
Pochopitelně, když si na konec řádku přidáte ještě nekonečnou smyčku a použijete "GR. 8+16", tak to můžete vyzkoušet přes celou obrazovku (bez spodního textového okna), pak to bude už super-ultra-mega-hyper průkazné :)
Dal by se vlastně využít stejný trik jako v příkladu předtím, s místem na DL a kód: od začátku 4kB bloku můžeme mít kód, DL, příp. padding a obrazovou paměť. Ta nemusí začínat ani přesně na 4096-3840, protože nemáme povinnost, aby celkově (ten její druhý blok) _končil_ na hranici 4kB bloku, jen si dáme malý padding, abychom měli konec prvního 4kB bloku na konci obrazového řádku.
Pak celé to omezení ANTICu de facto znamená jen o dva bajty delší DL.
P.S.: A až bychom psali skutečnou hru s delším kódem a složitější strukturou v RAM, tak bychom možná využili schopnosti jak původních blokových zápisů na Atari diskety (i kazety ve std. režímu bez Turba!), tak i moderních XEX souborů, tj. obsahovat několik bloků s uvedením, kam se mají v RAM nahrát. Pak nemusí v RAM být po nahrátí programu zabraný souvislý úsek. A dokonce se může nějaký úsek nahrát i vícekrát a mezi bloky spouštět kód - tak jdou dělat triky jako zobrazení úvodního obrázku a pokračování v nahrávání...
-
Pavel TišnovskýZlatý podporovateljj je to tak, díky za doplnění.
Popravdě jsem měl problém donutit linker k tomu něco takového (polo)automaticky nakonfigurovat. Jasně, jde to narvat explicitně do linker configu (vypočítat si offsety atd.), ale přece musí existovat lepší cesta. Původní Atari Macro Assembler to zvládal (a to měl jen 8 kB!, evidentně dnes něco děláme špatně :-)
-
Pavel TišnovskýZlatý podporovatel
hmm tak si říkám - věnovat jeden díl tomu, jak se kdysi programovalo v těch interaktivních assemblerech. to se dneska už často nevidí...
-
Pavel TišnovskýZlatý podporovatel
TM 2304 mi nic neříká, ale zkusím dohledat. Já to psával jako DATA do BASICu, jenže jakýkoli skok bylo utrpení, kdo měl pořád počítat dvojkový doplněk :-)
-
Jeden z dopadů nutnosti znova uvést instrukci pro počátek videoram je ten, že na daném grafickém řádku je touto instrukcí mírně posunuté časování. Pokusil jsem se to ukázat na následující obrazovce.
Legenda: obrazovka v gr. 8 (ANTIC mód 0F) , kam jsem umístil několik vertikálních čar. S ohledem na tabulku v článku (mód má podporovat pouze jednu barvu ve dvou odstínech) asi tušíte "zradu" :) Ta má podobu jednoduchého programu v přerušení po konci prvního obrazového řádku (DLI): v cyklu pro každý obrazový řádek dvakrát změní barvu popředí (tam a zpět) s určitým časováním. Je vidět, že zatímco všeobecně to funguje - odladil jsem časy instrukcí, aby pěkně obarvovaly jen levý sloupec a pravý ne - tak na řádku s ANTIC instrukcí pro opětovné nastavení počátku video paměti je časování posunuté a obarvený je na tomto řádku i pravý sloupec vertikálních čar.
0600: 48 PHA 0601: 8A TXA 0602: 48 PHA 0603: A2 BF LDX #$BF 0605: A9 0D LDA #$0D 0607: 8D 0A D4 STA $D40A ;WSYNC 060A: 8D 17 D0 STA $D017 ;COLPF1 060D: 20 83 06 JSR $0683 0610: A9 00 LDA #$00 0612: 8D 17 D0 STA $D017 ;COLPF1 0615: CA DEX 0616: D0 ED BNE $0605 0618: 68 PLA 0619: AA TAX 061A: 68 PLA 061B: 40 RTI
(uložení čehokoli do WSYNC donutí čekat na další obrazový řádek, COLPF1 je barevný registr, který měníme, JSR je skok do podrutiny obsahující samá NOP - jejich počtem ladím časování)
