Są dwa rozkazy hsync... 010 włącza - tryb "natywny" - pixel co cykl koloru (np. antic 14), oraz 011 - tryb "hi res" - GTIA dzieli cykl koloru na dwie czesci z czym jest pewien problem - otóż GTIA dostaje zegar 3.54 MHz (PAL) lub 3.57 MHz (NTSC). - z tego wynika, że pixel w hi-res ma długość ... no właśnie 1/2 cyklu koloru - i w zależności od jakości oscylatora komputera niekoniecznie wypełnienie tego zegara wynosi 50 % - powinien to zapewnić sam GTIA, ale w niektórych wykonaniach coś jest skopane i nie zapewnia. Efekt? W hi-res co drugi pixel jest chudy / gruby oraz .... słynne walnięte tryby GTIA. Dobrze byłoby, gdyby przy ew. projektowaniu G2, zegar taktujący dać 14.187 / 2 = 7.09MHz czyli oscylator 14.18 jak w XE a wejście zegara G2 7.09MHz - dzięki dzielnikowi nie będzie problemu z symetrią pixeli. Problem jest z takim oscylatorem - nie ma go w standardowym szeregu! (jest za to 14.318 dla NTSC).
Jeśli by spritey zrobić na własnej pamięci G2, wówczas.... Dlaczego tracić dane, które podawane są jako dotychczasowe duszki ? Jest tego 5 bajtów co linię. Mam taki pomysł :
Każdy z tych bajtów (numery 0...4) przełącza zestawy rejestrów kolorów (6 kompletnych zestawów). Jest to nic innego jak ograniczona (w poziomie do 5 zmian) mapa kolorów ! Co Wy na to?
Acha.... Stara GTIA musi oczywiście zostać - kompatybilność.... plus generacja synchronizacji ! :-)
Jeszcze jedno : W tym celu kupiłem układ ALTERA ACEX1K (TQFP 144).... 130 pln... Potrzebna jeszcze pamięć do spriteow.... i wiele wiele pracy czasu wolnego dużo też ... :-(