Nie, żeby dyktować komuś co ma robić, ale trochę żal, że IK+ się "znudziło" i zostało osierocone :P Tyle lat, taki rozmach (www), stopień zaawansowania projektu i przysłowiowa "d..." :/

pavros, tam przytaczam pewna anegdotę z 6502.org, ale ty się nie dąsaj na moje pokpiwania - fajnie ze się udało, w sensie fajnie, bo na c64 takie coś się robi ot tak, ale szkoda ze metodami suszonymi i - jak Gary pisze - niekoniecznie powtarzalnymi
podobnie sprawa się ma z tym co zrobił Gary - chociaż nie wymaga suszenia i działa na większości (?) monitorów/telewizorów CRT, o tyle z LCD jest już kiepsko i tym samym nie mogę sobie pozwolić na używanie takiego trybu

Dodałem informacje na temat zmian HBLANK w czasie aktywności DGF. Zupdateowany pdf można ściągnąć stąd.

HBLANK przy aktywnych efektach DGF.
Aktywność samodzielnego efektu DGM (czyli gdy przełączenie z GTIAX na NORMAL następuje nie później niż w cyklu CPU 109) nie ma żadnego wpływu na HBLANK.
Aktywność efektu DPS powoduje kilka zmian. Długość ACTIVE DISPLAY zwiększa się o 1 cykl koloru (dokładnie o cykl 222) z 188 do 189 cykli a tym samym długość HBLANK zmniejsza się z 40 do 39 cykli. HBLANK rozpoczyna się o jeden cykl koloru później niż normalnie – w cyklu 223, natomiast kończy się jak normalnie. W cyklu 222 wyświetlana jest grafika (na takiej samej zasadzie jak w cyklach 220 i 221) i obiekty PMG oraz wykrywane są kolizje PMG. W linii, w której następuje pierwsze włączenie DPS (który widoczny jest dopiero od następnej linii), zakres pozycji, w których widoczne są PMG oraz wykrywane są między nimi kolizje, to 34 – 222. Jest on zgodny z zakresem cykli koloru wydłużonego ACTIVE DISPLAY. W kolejnych liniach, gdzie DPS jest aktywny, zakres pozycji, w których widoczne są PMG oraz wykrywane są między nimi kolizje, to 33 – 221 (pozycje poziome wpisywane do rejestrów HPOSxx). Wynika to z faktu, że PMG są opóźnione o 1 cykl koloru. Przykładowo, pozycja PMG 33 jest wyświetlana w cyklu koloru 34. Fakt, że wykrywanie kolizji obejmuje pozycję PMG 33, może być wykorzystany przy wykrywaniu aktywności i pomiarze stabilności efektu DPS.
W pierwszej linii ekranu bez DPS następującej po bloku linii z włączonym DPS nie działa DMA obiektów PMG, o czym wspominałem w akapicie „DPS”. Ten problem ma miejsce dokładnie w pierwszym 40-cyklowym HBLANK następującym po 39-cyklowym.

Czy ten xegs ma GTIA z uszkodzonymi trybami GTIA? Ja mam jedno 130XE z takim właśnie GTIA i na tym komputerze nie udało mi się uzyskać efektów DGF. Nawet mocne podgrzewanie nic nie dawało.

Przeczytaj proszę dokładnie. Ja nie piszę o HSYNC tylko o HBLANK. To nie jest tożsame. HBLANK to czas wygaszenia do poziomu czerni ale nie sam impuls HSYNC. Długość HBLANK mierzę programowo sprawdzając, w jakich pozycjach PMG działa wykrywanie kolizji. Długość HSYNC jest podana w dokumentach o GTIA, CGIA i FGTIA i wynosi 16 cykli koloru dla PAL/NTSC i bodajże 16,5 dla SECAM, ale o tym nigdzie nie wspominałem.

Napiszę jeszcze raz. Ja mierzę długość HBLANK programowo. To znaczy przy użyciu odpowiednich programów wykonywanych przez CPU w Atari. Nie używam zewnętrznych przyrządów pomiarowych, więc nie jestem narażony na taki typ błędu pomiarowego, o którym piszesz. Ponadto dokładność tylko co do cyklu koloru jest wystarczająca, przynajmniej do opisu działania GTIA jak i na potrzeby opisu zachowania GTIA w warunkach rozgrzania. Nawet dokumentacja GTIA, FGTIA i CGIA pochodząca od firmy Atari (dostępna w sieci w formacie pdf) podaje długość HBLANK z dokładnością do cyklu. Ta dokumentacja podaje, że HBLANK zajmuje dokładnie 40 cykli. Programowa metoda pomiaru polega na ustawianiu dwóch duszków (PMG) w zadanej pozycji (która odpowiada konkretnemu cyklowi koloru w linii ekranu z zakresu 0-227) i sprawdzeniu czy wykrywana jest kolizja. Oczywiście duszki są spreparowane tak, że mają szerokość 1 piksela w najmniejszej szerokości duszka czyli jednego cyklu koloru. W ten sposób można wyznaczyć dokładnie w których pozycjach/cyklach działa wykrywanie kolizji. Z dokumentacji układu GTIA wiem, że wykrywanie to nie działa w obszarze HBLANK. Z dokumentacji GTIA wiem też, że HBLANK zajmuje dokładnie 40 cykli koloru. Moje pomiary wykonywane opisaną metodą potwierdzają to co mówi dokumentacja. Pokazują, że w dokładnie 40-u pozycjach/cykla wykrywanie kolizji nie działa. Pokazują też, które konkretnie to są cykle. Tą samą metodą (tymi samymi programami) sprawdzam wykrywanie kolizji PMG w warunkach podgrzanego GTIA. Pomiary pokazują, że teraz HBLANK jest o jeden cykl krótsze. Oczywistym jest, że tą metodą nie uzyskam dokładności większej niż co do jednego cyklu koloru. Ale też nie ma sensu mierzyć tego dokładniej. Chodzi o to by poznać długość HBLANK w cyklach. Nie w nanosekundach. Jak już pisałem, sama dokumentacja od Atari podaje długość HBLANK w cyklach. Być może w rzeczywistości HBLANK trwa np 40,1 cykla. Ale część ułamkowa nie ma znaczenia dla opisu samej zasady działania GTIA. Ja stwierdzam, że przy rozgrzaniu GTIA długość HBLANK zmniejsza się o jeden cykl, czyli do 39 cykli. Być może w rzeczywistości trwa wtedy np 39,1 cykla. Tu część ułamkowa również nie ma znaczenia dla opisu działania GTIA w warukach rozgrzania.

wyjsciowym?
zadnym
wyjscie monitorowe ci zostaje

Hmm...
Pomijając to że GTIA jest chyba jednym z bardziej zakręconych układów Atari a przy tym najgłupszym (nie potrafi nic autonomicznie zdziałać). To ja bym zrobił tak.
Rejestr COLBKs ustawić na jakąś wartość żeby generowany był sygnał luma ($ff np). Potem zdjął bym oscylogramy z pinów:
AN2,AN1,AN0,OSC,COL i ew Ø2.

NA podstawie danych z linii ANx oraz tego kiedy pojawia się i znika sygnał na pinie COL można wszystko sprawdzić czego potrzebujesz.

Edit:
W wersji minimum:
ustawić colbks
Poke 559,0
I porównać zmianę przebiegu na AN1, COL, i OSC jako referencja.

No Candle, o takiej opcji nawet nie marzyłem. Będę cię wypatrywał na najbliższych zlotach.

wszystko prawda, ale jesli trzeba grzac gtia to jemu sie srodek rozjezdza, chyba ze to antik sie tak naprawde podgrzewa
pavros, zmien suszare na lutlampe i sproboj bardziej bezposrednich metod ;)
(aha, zamrazacz tez kup)