Szczegółowy opis zjawiska DGF by TDC 2013-02-23 15:50:36
W
relacji z WAP-NIAKa 2012, mogliśmy dowiedzieć się kilku faktów
dotyczących nowego zjawiska oraz trybu graficznego DGI. Dziś
doczekaliśmy się wyczerpującego opisu tego fenomenu nieznanego
dotychczas od strony sprzętowej i koderskiej. Wiele osób pytało o
szczegóły, również z innych części świata, no i się nareszcie
doczekaliśmy. Paweł "Pavros" Rosowski podesłał nam
wyczerpujący i ciekawy opis techniczny oraz inne jego obserwacje,
które towarzyszyły jego zmaganiom z zagadnieniem:
Artykuł ten objaśnia jakie efekty oraz tryby graficzne można uzyskać przy odpowiednio rozgrzanych układach graficznych GTIA i ANTIC. Pozwala również zrozumieć jak unikać takich efektów gdy nie są pożądane, a dochodzi do (samoczynnego) rozgrzania układów. Opisane efekty i tryby związane są z opóźnieniami wewnętrznych funkcji układu GTIA o jeden tzw. cykl koloru. Opis zawiera również ciekawe informacje dla osób próbujących odtworzyć schemat wewnętrzny układu GTIA.
Słownik terminów używanych dalej w tekście
Terminy znane:
PRIOR – rejestr sterujący układu GTIA o adresie $D01B. Służy do wyboru trybu GTIA oraz określenia priorytetów sprite’ów.
GTIACTL – alternatywna nazwa rejestru PRIOR, używana przez mnie w kodzie programów.
GTIA9 (właściwie GTIA1) – tryb GTIA o rozdzielczości poziomej 80, pozwalający wyświetlić 16 jasności jednego koloru (hue), uzyskiwany przez zapis $40 (OR <priority>) do rejestru GTIACTL lub przez polecenie GR.9 w Basicu.
GTIA10 (właściwie GTIA2) – tryb GTIA o rozdzielczości poziomej 80, pozwalający wyświetlić 9 niezależnych kolorów, uzyskiwany przez zapis $80 (OR <priority>) do rejestru GTIACTL lub przez polecenie GR.10 w Basicu.
GTIA11 (właściwie GTIA3) – tryb GTIA o rozdzielczości poziomej 80, pozwalający wyświetlić 16 kolorów (hue) w jednej wspólnej jasności, uzyskiwany przez zapis $C0 (OR <priority>) do rejestru GTIACTL lub przez polecenie GR.11 w Basicu.
GTIAX – dowolny z trzech trybów GTIA.
NORMAL (właściwie GTIA0) – nazwa trybu układu GTIA dla zwykłych trybów graficznych, tzn. nie-GTIA – tryb uzyskiwany przez zapis $00 (OR <priority>) do rejestru GTIACTL.
PMG – grafika graczy i pocisków (Player Missile Graphics) – nazwa dla sprite’ów w Atari.
Pole gry (playfield) – grafika obejmująca kolory 0-3 (COLPF0-COLPF3), ale nie kolor tła COLBAK.
Cykl CPU – cykl zegara ø2 1.77MHz (1.79MHz w NTSC) taktującego CPU.
Cykl koloru – cykl zegara Osc 3.54MHz (3.579MHz w NTSC) równoważny jednemu pikselowi w rozdzielczości poziomej 160. Stanowi połowę cyklu CPU. Numeracja cykli koloru jest zgodna z pozycjami poziomymi obiektów PMG. Pełna linia obrazu składa się z 228 cykli koloru (114 cykli CPU).
Piksel lores – piksel w rozdzielczości poziomej 160 równoważny jednemu cyklowi koloru.
Piksel hires – piksel w rozdzielczości poziomej 320 równoważny połowie piksela lores i połowie cyklu koloru.
HBLANK – niewidoczna część linii obrazu obejmująca cykle koloru 222-227 oraz 0-33 (cykle CPU 111-113 oraz 0-16), łącznie 40 cykli koloru (20 cykli CPU). W trakcie HBLANK nie działa wykrywanie kolizji obiektów PMG.
ACTIVE DISPLAY – widoczna część linii obrazu obejmująca cykle koloru 34-221 (cykle CPU 17-110), łącznie 188 cykli koloru (94 cykle CPU).
VBLANK – czas wygaszania pionowego obejmujący wygaszone linie obrazu 248-311 w PAL/SECAM, 248-261 w NTSC oraz 0-7 w każdym z systemów. Zawiera w sobie czas VSYNC. W trakcie VBLANK nie działa wykrywanie kolizji obiektów PMG.
VSYNC – czas synchronizacji pionowej obejmujący 3 pełne linie 275-277 w PAL/SECAM, 255-257 w NTSC.
Terminy nowe (ukute przeze mnie):
DGM – Delayed Gtia Mode – efekt przesunięcia (opóźnienia) zawartości linii obrazu w trybach GTIAX o pół piksela (1 cykl koloru) w prawo.
DPS – Delayed Pmg and hSync – efekt przesunięcia (opóźnienia) grafiki graczy i pocisków PMG oraz impulsu synchronizacji poziomej o 1 cykl koloru. W wyniku przesunięcia hsync efekt na ekranie jest taki, że grafika jest przesunięta w lewo, a PMG pozostają na normalnej pozycji.
DPS2 – Delayed Pmg and hSync in every second (2) line – efekt będący szczególnym przypadkiem zastosowania DPS co drugą linię i dający przesunięcie o jeden piksel hires w lewo od pozycji normalnej.
DGF – Delayed Gtia Functions – nazwa zjawiska opóźnienia funkcji układu GTIA obejmująca efekty DGM i DPS.
DG9 – Delayed Gtia mode 9 – tryb powstały przez zastosowanie efektu DGM w trybie GTIA9.
DG10 – Delayed Gtia mode 10 – tryb powstały przez zastosowanie efektu DGM w trybie GTIA10.
DG11 – Delayed Gtiamode 11 – tryb powstały przez zastosowanie efektu DGM w trybie GTIA11.
Efekty DGF
Jak napisałem we wstępie opis ten dotyczy efektów opóźnienia o jeden cykl koloru funkcji układu GTIA, a tym samym przesunięcia treści linii obrazu o jeden piksel lores. Efekty te można użyć do podwojenia rozdzielczości trybów GTIA (80 pikseli), o ile zastosujemy interlace poziomy, czyli naprzemienne wyświetlanie dwóch półobrazów gdzie dana linia obrazu w jednej klatce nie jest przesunięta, a w drugiej jest przesunięta o jeden piksel lores. Dodatkowym efektem jest w takim wypadku poszerzenie palety kolorów obrazu ze względu na mieszanie się połówek nakładających się pikseli obu półobrazów. Zasada jest ta sama co w trybie HIP. Tu jednak możliwe jest mieszanie linii w GTIA9 z przesuniętą o piksel lores linią w GTIA9. W HIP następuje mieszanie linii w GTIA9 z linią w GTIA10, która jest stale przesunięta względem GTIA9 o piksel lores. Okazało się również, że istnieje możliwość podwojenia rozdzielczości trybów standardowych lores (160 pikseli) na tej samej zasadzie to jest poprzez naprzemienne wyświetlanie dwóch półobrazów gdzie dana linia obrazu w jednej klatce nie jest przesunięta, a w drugiej jest przesunięta o jeden piksel hires. Przesunięcie o piksel hires uzyskuje się w inny, bardziej skomplikowany sposób niż przesunięcie o piksel lores. Będzie to opisane w dalszej części tekstu.
Istnieją dwa różne sposoby na uzyskanie przesunięcia treści linii w trybie GTIAX o jeden piksel lores – efekt DGM i DPS. Istnieje możliwość wyświetlenia każdego z nich samodzielnie bądź obu naraz. Oba efekty należą do jednej kategorii, którą nazwałem DGF.
Warunkiem koniecznym do wystąpienia DGF jest odpowiednie rozgrzanie układów graficznych GTIA i ANTIC. Nie jest znana dokładna temperatura jaką muszą osiągnąć układy natomiast z grubsza wiadomo ile czasu zajmuje dochodzenie do stabilnych efektów DGF w różnych temperaturach otoczenia. Temperatury te są różne pomiędzy różnymi egzemplarzami Atari, a całkowity czas dochodzenia danego egzemplarza do DGF w tej samej temperaturze też się zmienia. Dzięki przeprowadzonym badaniom ustaliłem, że w temperaturze otoczenia 25°C czas dochodzenia do stabilnego DGF w minutach waha się pomiędzy 150 a 250 natomiast w 29°C pomiędzy 30 a 40. Czas ten można skrócić nawet do 3 minut podgrzewając Atari przy pomocy np. suszarki do włosów. Ponadto aby utrzymać stabilny DGF na długie godziny temperatura otoczenia musi mieć minimalnie 25°C.
Stabilność DPS może wymagać wyższej temperatury niż stabilność DGM. Stabilność DGF oznacza stabilność zarówno DGM jak i DPS. Jest prawdopodobne, że są takie egzemplarze Atari gdzie występuje jedynie DGM, a DPS jest nieosiągalne.
Okazuje się, że są takie egzemplarze Atari, gdzie DGF nie występuje w ogóle, czyli nie występuje ani DPS ani DGM. Osobiście posiadam jeden taki egzemplarz. Jest to Atari 130XE wyprodukowane w 1990 roku, posiadające płytę z 4-ma kośćmi RAM oraz układ GTIA z uszkodzonymi trybami GTIA. Nie mam pewności czy odporność na DGF ma związek z uszkodzonymi trybami GTIA.
DGM
Efekt DGM polega na tym, że piksele trybów GTIAX są przesunięte w prawo o pół piksela (lub jeden piksel lores). GTIA łączy w jeden piksel rozdzielczości 80 dwa 2-bitowe słowa z linii AN1 i AN0 o jeden cykl koloru za późno, licząc względem strumienia danych podawanych przez ANTIC na linie AN2-AN0. Inaczej mówiąc łączy w jeden piksel dwa młodsze bity pierwszego piksela z dwoma starszymi bitami drugiego piksela. Dwa młodsze bity pierwszego piksela stają się więc starszymi bitami „opóźnionego” piksela, a dwa starsze bity drugiego piksela – młodszymi bitami „opóźnionego”. Tak więc dane przygotowane do wyświetlenia w trybach GTIAX będą wyświetlane zupełnie niepoprawnie, gdy uaktywnimy efekt DGM. Można to skorygować na dwa sposoby. Pierwszy to przesunąć (opóźnić) dane podawane przez ANTIC o jeden piksel lores ustawiając właściwie rejestr HSCROL i adres danych w Display List oraz uaktywniając przesuw poziomy w Display List w liniach, gdzie włączony jest DGM. Drugi sposób to zmienić dane obrazka w pamięci tak by były poprawne dla DGM.
Efekt DGM może być włączony w dowolnej linii ekranu niezależnie od tego, czy jest włączony w innych liniach. W szczególności DGM może być włączony co drugą linię. Pozwala to na przykład na uzyskanie trybu podobnego do HIP, ale tylko przy użyciu GTIA9.
Efekt DGM odkrył w roku 1994 niejaki Bryan – członek społeczności AtariAge.
O odkryciu wspomina tu:
W pozycji 3 załączone są 2 przykłady wykorzystania DGM (dokładnie DG9) oraz screenshoty przed i po rozgrzaniu układów graficznych. Bryan nazwał swój tryb VZI – VertiZontal Interlacing. Tryb jest bardzo zbliżony do HIP. W jednej klatce obrazu opóźnione o jeden cykl koloru są wszystkie linie parzyste, w drugiej wszystkie nieparzyste. Jako metodę korekcji danych niepoprawnie łączonych pikseli Bryan zastosował przesuw poziomy przy użyciu HSCROL.
Przykłady Bryana aktywują zarówno DGM jak i DPS, a dokładnie DPS2 (patrz akapit „Zależności między efektami DGF”). Efekt DPS2 powoduje widoczne na ekranie ugięcie obrazu (i przesunięcie o jeden piksel hires w lewo!), ale na screenshotach Bryana nie jest to widoczne. Oznacza to, że w maszynie Bryana DPS był nieosiągalny bądź temperatura była zbyt niska, aby DPS się uaktywnił.
W przykładach Bryana efekt DGM włączany jest przy pomocy trybu GTIA9, co na niektórych maszynach znacznie skraca czas występowania efektu ze względu na wyższy próg temperaturowy (patrz akapit „Wpływ sposobów włączania efektów DGF na ich stabilność”).
DPS
Efekt DPS polega na tym, że GTIA wykonuje swoje funkcje to jest nakładanie obiektów PMG oraz generację impulsu synchronizacji poziomej hsync o jeden cykl koloru później niż normalnie, licząc względem strumienia danych podawanych przez ANTIC na linie AN2-AN0.W wyniku przesunięcia hsync efekt na ekranie jest taki, że grafika jest przesunięta w lewo, a PMG pozostają na normalnej pozycji.
Efekt przesunięcia grafiki w wyniku opóźnienia hsync nie jest natychmiastowy. Mija około 5 linii ekranu od momentu uaktywnienia opóźnienia do ustabilizowania się przesunięcia. W tych 5-ciu liniach widoczne jest „ugięcie” obrazu, czyli płynne przejście pomiędzy normalną, a przesuniętą o jeden piksel lores grafiką, inaczej mówiąc pomiędzy normalną i przesuniętą pozycją impulsu hsync. Jest to cecha urządzeń wyświetlających.
Zaobserwowałem taki efekt na kilku telewizorach, monitorze C= 1084S, karcie AV capture, konwerterze AV-VGA oraz rzutniku i sądzę, że ta cecha jest wspólna dla wszystkich urządzeń wyświetlających zgodnych z systemami PAL/NTSC/SECAM. Cecha ta powoduje, że nie można uzyskać przesunięcia w dowolnej linii niezależnie od sąsiednich. Należy więc stosować przesunięcie dla całego ekranu bądź dla wieloliniowych bloków, a każdy z nich poprzedzić i zakończyć przynajmniej 6-cioma pustymi liniami w celu ukrycia „ugiętych” fragmentów obrazu.
Z efektem DPS związany jest pewien problem. W pierwszej linii ekranu bez DPS następującej po bloku linii z włączonym DPS nie działa DMA obiektów PMG. Problem musi być związany z powrotem układu GTIA z opóźnionego do normalnego timingu. Prawdopodobnie GTIA gubi aktywne zbocze sygnału HALT, które inicjuje odczyt serii danych PMG z magistrali danych.
Efekt DPS występuje niezależnie od trybu układu GTIA to jest NORMAL lub GTIAX, a w przypadku NORMAL także niezależnie od trybu określonego przez ANTIC to jest lores lub hires.
Efekt DPS odkryłem w roku 2009.
DPS2
Jeżeli DPS zastosujemy w co drugiej linii ekranu to wspomniana cecha urządzeń wyświetlających do wygładzania przejścia pomiędzy normalną i przesuniętą pozycją impulsu hsync spowoduje uśrednienie przesunięcia grafiki we wszystkich liniach w pozycji, która jest przesunięta dokładnie o pół piksela lores (czyli jeden piksel hires) w lewo od pozycji normalnej. Ten efekt jest szczególnym przypadkiem efektu DPS. Nazwałem go DPS2. Jest on podstawą dla trybu graficznego DGI, który zaprezentowałem w demie KNIGHT. Należy pamiętać, że w liniach, w których zastosowany jest DPS (czyli w co drugiej linii), obiekty PMG są przesunięte o jeden piksel lores w prawo względem zadanej pozycji podczas gdy w pozostałych liniach PMG są usytuowanie normalnie. To komplikuje trochę ich użycie do podkolorowania obrazu. Ponadto dochodzi problem z wspomnianym brakiem DMA obiektów PMG, który w DPS2 występuje w co drugiej linii i utrudnia użycie PMG jeszcze bardziej.
Podsumowując, problem z przesuniętymi obiektami PMG występuje w liniach z włączonym DPS, a problem z brakiem DMA PMG w liniach z wyłączonym DPS, czyli oba problemy występują na przemian w kolejnych liniach. Problem z brakiem DMA można obchodzić poprzez zapisywanie danych do rejestrów kształtów PMG przy pomocy CPU. Jednak to redukuje czas dostępny na inne zmiany. Przy pracy nad demem KNIGHT okazało się, że często udaje się wykorzystać ten sam bajt kształtu w więcej niż jednej linii (pomimo przesunięć o piksel co drugą linię), dzięki czemu brak DMA nie jest tak uciążliwy, ale to oczywiście zależy od konkretnego obrazka. Ogólnie opracowanie programu rastra używającego DPS2 jest bardzo trudne.
Jak włączać efekty DGF
Z punktu widzenia programisty efekty DGF włącza się w następujący sposób:
Efekt DGM w danej linii obrazu uzyskujemy poprzez przełączenie z NORMAL na GTIAX w obszarze ACTIVE DISPLAY (cykle CPU 17-110). Warunkiem koniecznym jest aby przełączenie nastąpiło nie wcześniej niż w cyklu 17. Tak więc związany z włączeniem GTIAX zapis rejestru PRIOR ($D01B) może nastąpić najwcześniej w cyklu CPU 16. W tym wypadku zmiana wpływa na układ GTIA od cyklu 17. Nie ma znaczenia w jakim trybie działa układ GTIA w trakcie HBLANK. Znaczenie ma tylko pierwsze przełączenie z NORMAL na GTIAX, a kolejne nie. Wystąpienie HBLANK wyłącza DGM. Oznacza to konieczność uaktywniania DGM w każdej linii gdzie ma być widoczny.
Efekt DPS uzyskujemy właściwie tak samo, z tym że będzie on widoczny dopiero w następnej linii ekranu. Dodatkowym warunkiem koniecznym dla DPS jest, aby GTIAX był aktywny w momencie rozpoczęcia HBLANK (tego HBLANK poprzedzającego linię, w której widoczny będzie efekt, a więc tego występującego już po włączeniu DGM). Warunek ten jest spełniony gdy GTIAX jest aktywny w cyklu CPU o numerze 110 (cykle koloru 220 i 221). Przełączenie z NORMAL na GTIAX może więc nastąpić najpóźniej w cyklu 109. Metoda włączania DPS ze względu na dodatkowy warunek jest szczególnym przypadkiem metody włączania DGM.
Wpływ sposobów włączania efektów DGF na ich stabilność
Opisane sposoby włączania działają w warunkach pełnej stabilności zjawiska DGF. W sytuacji, gdy stabilność DGF jest osiągnięta w znacznym stopniu, ale nie jest pełna, uzyskanie stabilnych efektów DGM i DPS też jest możliwe. Uzyskanie DGM wymaga wtedy większej niż jeden liczby cykli CPU w trybie NORMAL przed przełączeniem na GTIAX (największa stabilność przy 2-3 cyklach) natomiast uzyskanie DPS wymaga większej niż jeden liczby cykli CPU w trybie GTIAX przed cyklem 110 oraz jak najmniejszej (najlepiej zero) liczby takich cykli po cyklu 110. Stosując się do tych zasad można uzyskać stabilne efekty DGF przy trochę niższych temperaturach niż wymagane do pełnej stabilności DGF oraz utrzymać te efekty przez dłuższy czas. Inaczej mówiąc, w ten sposób można obniżyć próg temperaturowy dla aktywności efektów DGF.
Ma znaczenie, przy pomocy którego trybu GTIA, a właściwie jakiej wartości zapisywanej do PRIOR włączamy DGM. Włączenie oznacza tu pierwsze przełączenie z NORMAL na GTIAX w obszarze ACTIVE DISPLAY. Uaktywnienie oznacza, że efekt jest rzeczywiście widoczny. Są takie układy GTIA, dla których włączanie DGM przy pomocy GTIA10, czyli wartości $80 OR <priority>, jest znacznie korzystniejsze, ponieważ uaktywnienie się DGM następuje wtedy w znacznie niższej temperaturze niż przy użyciu innej wartości. Aktywność efektu utrzymuje się również znacznie dłużej, na przykład kilka godzin w temperaturze otoczenia 22°C. Z kolei aktywność efektu DGM włączanego przy pomocy GTIA9 czyli wartości $40 OR <priority> ma wyższy próg temperaturowy i następuje znacznie później oraz zanika znacznie wcześniej. Może trwać na przykład tylko kilkanaście minut w temperaturze otoczenia 22°C. Aktywność efektu DGM włączanego przy pomocy GTIA11, czyli wartości $C0 OR <priority> ma najwyższy próg temperaturowy. Dlatego najlepiej włączać DGM przy pomocy GTIA10, a potem ewentualnie przełączać na inny tryb GTIA w zależności, który z trybów DG9, DG10 czy DG11 chcemy wyświetlić. Istnieją też takie układy GTIA, dla których próg temperaturowy aktywności efektu DGM jest niezależny od tego czy do rejestru PRIOR wpisujemy wartość $40 OR <priority> czy $80 OR <priority>.
Podsumowując, w celu włączenia DGF (DGM lub DPS) zalecane jest używanie trybu GTIA10, czyli wartości $80 OR <priority>. Zaraz potem można zmienić tryb jeżeli pożądany jest inny niż GTIA10.
Pisząc programy wykorzystujące efekty DGF należy zakładać osiągnięcie przez GTIA pełnej stabilności DGF. Jeżeli kiedykolwiek emulatory będą emulować efekty DGF to powinny robić to tak jakby osiągnięta była pełna stabilność DGF. Pełna stabilność oznacza, że włączenie danego efektu DGF powoduje jego natychmiastowe uaktywnienie i widoczność na ekranie.
Jak wykrywać aktywność efektów DGF i określać ich stabilność
Efekt DPS wymaga z reguły wyższej temperatury układu GTIA niż efekt DGM. Wykrycie stabilnego DPS jest równoznaczne ze stwierdzeniem stabilnego DGM. Wykrywanie DPS realizuje się z użyciem mechanizmu wykrywania kolizji PMG z grafiką obrazu. Wykorzystuje się fakt, że przy aktywnym DPS obiekty PMG są przesunięte o jeden piksel lores w prawo względem swej normalnej pozycji wobec grafiki obrazu.
Jeżeli w programie wykorzystujemy tylko efekty DGM to bardziej sensowne jest wykrywanie stabilności tylko tego efektu ze względu na niższy próg temperaturowy niż dla DPS. Wykrywanie DGM jest możliwe dzięki mechanizmowi wykrywania kolizji pomiędzy obiektami Missile a grafiką w trybie GTIA10. Wykorzystuje się fakt, że przy aktywnym DGM granice pikseli rozdzielczości 80 są przesunięte o jeden piksel lores, a ich wartości są inne niż w przypadku, gdy przesunięcia nie ma (patrz akapit „DGM”).
Stopień stabilności efektu DGF określa się jako stosunek ilości linii ekranu, w których DGF okazał się aktywny do ilości linii, w których DGF był włączony. Ilość badanych linii powinna być oczywiście jak największa. Ponadto całkowita stabilność może być stwierdzona dopiero wtedy, gdy jest ona maksymalna dla kilkudziesięciu kolejnych klatek obrazu.
Napisałem trzy krótkie programy służące do wykrywania pełnej stabilności efektów DGF. Program o nazwie DPSCHECK wykrywa stabilność efektu DPS włączanego przy pomocy GTIA10, program DGMCHECK – stabilność efektu DGM włączanego przy pomocy GTIA10. Natomiast program DGMG9CHK sprawdza stabilność efektu DGM włączanego przy pomocy GTIA9. Programy nie posiadają bloku RUNAD, a ich przeznaczeniem jest doklejanie na początku plików .xex będących programami wyświetlającymi grafiki w trybach korzystających z odpowiednich efektów DGF.
Zależności między efektami DGF
Choć efekty DGM i DPS włącza się praktycznie w ten sam sposób to jest możliwe uzyskanie każdego z nich oddzielnie. Można też oczywiście uzyskać oba naraz. Wszystko zależy od momentów, w których następują zmiany rejestru PRIOR.
W celu włączenia samodzielnego efektu DGM należy przełączyć z NORMAL na GTIAX w cyklu 16 lub później, byle przed rozpoczęciem wyświetlania grafiki oraz przełączyć z GTIAX na NORMAL w cyklu 109 lub wcześniej, byle po zakończeniu wyświetlania grafiki.
W celu włączenia samodzielnego efektu DPS należy przełączyć z NORMAL na GTIAX w cyklu 109 lub wcześniej, byle po zakończeniu wyświetlania grafiki oraz przełączyć z GTIAX na NORMAL w cyklu 110 lub później, byle przed cyklem 109 następnej linii.
W celu włączenia obu efektów jednocześnie należy przełączyć z NORMAL na GTIAX w cyklu 16 lub później, byle przed rozpoczęciem wyświetlania grafiki oraz przełączyć z GTIAX na NORMAL w cyklu 110 lub później, na przykład tuż przed kolejnym przełączeniem na GTIAX.
Jak rozgrzewać GTIA
W trakcie rozgrzewania układu GTIA musi być włączony efekt DPS. Najlepiej aby był włączony w jak największej liczbie linii ekranu. Rozgrzewanie GTIA bez włączonego DPS jest nieskuteczne. Po takim nieskutecznym rozgrzewaniu, a następnie włączeniu DPS lub DGM nadal potrzebne jest rozgrzewanie aby oba efekty DGF uzyskały widoczność i stabilność, choć wtedy potrzeba mniej czasu.
W trakcie rozgrzewania włączanie DPS powinno odbywać się przy użyciu trybu GTIA10 lub GTIA9. Rozgrzewanie przy użyciu GTIA11 jest nieskuteczne. Jeżeli użyjemy GTIA9 to dla niektórych układów GTIA będzie wymagana wyższa temperatura niż przy użyciu GTIA10. Zalecane jest używanie trybu GTIA10 przy rozgrzewaniu GTIA.
Ciekawe obserwacje i próby wyjaśnienia jak powstają efekty DGF
Temperatura
Przede wszystkim należy zauważyć, że ze wzrostem temperatury układów scalonych wiąże się wzrost czasów propagacji sygnałów. To oznacza, że w warunkach rozgrzania układu pewne sygnały mogą być opóźnione. Takie opóźnienie jest z pewnością przyczyną powstawania efektów DGF. Opóźnienie dokładnie o jeden piksel lores, czyli jeden cykl koloru oznacza, że jakiś przerzutnik (bądź przerzutniki) wewnątrz GTIA przechowujący stan układu i taktowany zegarem koloru 3.58MHz zatrzaskuje swój stan później o cały cykl, czyli „gubi” jedno aktywne zbocze sygnału zegarowego. Takie „gubienie” następuje raz na linię ekranu. Nie jest możliwe pełne wyjaśnienie przyczyn powstawania DGF bez szczegółowej znajomości schematu wewnętrznego układu GTIA.
O synchronizacji GTIA z ANTIC’iem oraz jej wpływie na DPS
Kiedyś w trakcie eksperymentów z tzw. bugiem ANTICa w linii 240, synchronizacją pionową i poziomą zauważyłem, że możliwy jest wpływ na synchronizację poziomą w liniach wygaszonych (VBLANK) skutkujący przeróżnymi „ugięciami” obrazu, natomiast nie jest możliwy wpływ na synchronizację poziomą w 240 liniach normalnych (o ile nie jest aktywny DGF). W tych liniach obraz jest zawsze w prawidłowym położeniu. Wniosek z tej obserwacji jest taki, że GTIA synchronizuje się z ANTIC-iem w każdej z 240 normalnych linii oraz nie synchronizuje się w liniach wygaszonych. Wiadomo, że synchronizacja następuje, gdy ANTIC podaje na szynę AN2-AN0 sygnał HBLANK czyli wartość binarną 010 (lub 011 jeśli w następnej linii ma być hires). Z podanego wcześniej wniosku wynika, że ANTIC nie podaje sygnału HBLANK w liniach wygaszonych (VBLANK) albo, co bardziej prawdopodobne, ANTIC podaje sygnał HBLANK ciągle przez cały czas trwania VBLANK (z wyjątkiem trzech linii gdzie podaje sygnał VSYNC), a GTIA synchronizuje się z ANTIC-iem tylko przy przejściu z ACTIVE DISPLAY do HBLANK. Za tą drugą opcją przemawia fakt, że puste linie normalne różnią się od linii wygaszonych tym, że w wygaszonych nie mamy wpływu na ich kolor. Musi być więc różnica między sygnałem podawanym przez ANTIC w jednych i drugich liniach. Jedyną możliwością jest, że w pustych liniach normalnych jest to sygnał BACKGROUND (binarnie 000), a w wygaszonych sygnał HBLANK.
Fakt, że w standardowych warunkach GTIA wyświetla obraz poprawny pod względem synchronizacji poziomej we wszystkich liniach ekranu (w tym w liniach wygaszonych) oznacza, że GTIA posiada wewnętrzny licznik, który zlicza cykle koloru i pozwala we właściwym momencie wygenerować impuls synchronizacji poziomej niezależnie od tego, czy ANTIC podaje sygnał HBLANK czy nie. Licznik taki jest z pewnością synchronizowany z sygnałem HBLANK, gdy ten jest podawany przez ANTIC (w 240 liniach normalnych).
Wygląda na to, że przyczyną powstawania efektu DPS jest spóźnione o jeden cykl koloru docieranie sygnału HBLANK z ANTICa do GTIA i synchronizowanie się wewnętrznego licznika cykli koloru GTIA z tak opóźnionym sygnałem. Innym możliwym wytłumaczeniem jest, że GTIA „gubi” przejście od ACTIVE DISPLAY do HBLANK ponieważ jest w trybie GTIAX i być może oczekuje takiego przejścia co drugi cykl koloru i wskutek tego nie synchronizuje się oraz że opóźnienie o jeden cykl koloru związane z DGM powoduje również opóźnienie wewnętrznego licznika cykli koloru, a co za tym idzie opóźnienie impulsu synchronizacji poziomej.
Zauważyłem, że jeżeli DPS jest włączony przed końcem ostatniej 240-stej normalnej linii ekranu i skutkuje przesunięciem PMG i impulsu synchronizacji poziomej w linii następnej to przesunięcie to utrzymuje się przez wszystkie linie wygaszone (VBLANK) aż do pierwszej (z 240 normalnych) linii u góry ekranu. Dopiero tu DPS przestaje być skuteczny o ile nie zostanie włączony tuż przed rozpoczęciem pierwszej linii normalnej i następnych. Ta obserwacja potwierdza, że GTIA nie synchronizuje się z ANTIC-iem w trakcie wyświetlania linii wygaszonych (VBLANK) oraz że ma wewnętrzny licznik cykli koloru.
Czy ANTIC wpływa na efekty DGF?
W czasie stabilizowania się efekty DGF pojawiają się i znikają losowo w poszczególnych liniach ekranu. Widoczne jest to jako przesuwanie się zawartości linii o piksel w prawo lub w lewo. Nazwijmy to pulsowaniem. W przypadku efektu DPS dochodzi jeszcze uginanie się obrazu w sąsiedztwie linii z uaktywnionym takim efektem. W pewnych momentach pulsowanie danej linii wygląda na zupełnie niezależne od pozostałych, ale w innych momentach można zauważyć powtarzające się całe grupy linii, które pulsują według takiego samego wzoru. Układ GTIA nie potrafi rozróżniać linii. Nie zawiera licznika linii i nie wie, którą linię ekranu aktualnie przetwarza. Polega tylko na sygnałach podawanych przez ANTIC na szynę AN2-AN0. Wydaje się, że gdyby jedynie układ GTIA był odpowiedzialny za wprowadzanie opóźnień, które skutkują efektami DGF, to te efekty pojawiałyby się i znikały jednocześnie we wszystkich liniach ekranu. Tak jednak nie jest i ten fakt wskazuje na to, że ANTIC jest współodpowiedzialny za powstawanie opóźnień. Udało mi się zaobserwować ciekawy przypadek, który wydaje się tego dowodzić. Zanim go jednak opiszę, muszę dokonać krótkiego wprowadzenia.
Badania przeprowadzałem w taki sposób, że dzieliłem ekran na dwie części, po 100 linii w trybie $0E ANTIC’a każda, przedzielone kilkunastoma liniami. W obu częściach w każdej linii włączony był efekt DPS. W obu częściach włączony był ekran rozszerzony (wide field), który pobiera 48 bajtów na linię w trybie $0E. W Display Liście instrukcja LMS (czyli ustawiająca początkowy adres danych obrazu) występowała tylko w pierwszej ze stu linii każdego bloku. Ilość danych potrzebna dla 100-u linii to 100*48=4800, czyli więcej niż 4kB. Jak wiadomo, wewnętrzny rejestr ANTIC’a wskazujący dane do pobrania jest inkrementowany automatycznie tylko w obrębie 4kB (inkrementacji podlegają tylko bity 11-0) co oznacza, że rejestr wskazujący składa się z 12-bitowego licznika oraz 4-bitowego rejestru zwykłego przechowującego niezmienne najstarsze 4 bity adresu podanego w instrukcji LMS. Licznik 12-bitowy po dojściu do najwyższej wartości $FFF przekręca się, czyli zaczyna liczyć od 0. Tak więc jeżeli 100-u liniowy blok danych obrazu zaczynałby się na granicy 4-kilobajtowego bloku pamięci, np. od adresu $5000 to musiałoby następować jedno przekręcenie się licznika (w linii o numerze (4096 div 48) = 85). A teraz wracam do obserwacji. Udało mi się zaobserwować przypadek, gdzie w opisanych powyżej warunkach (jednakowych w każdej linii 100-liniowego bloku) efekt DPS uaktywniał się dokładnie w jednej linii w obu 100-liniowych blokach.
Po wnikliwym dochodzeniu ustaliłem, że w obu przypadkach jest to linia następująca bezpośrednio po linii, w której dochodzi do przekręcenia się wewnętrznego 12-bitowego licznika ANTICA’a wskazującego dane obrazu (przypomnę jeszcze, że DPS jest widoczny w linii następującej po włączeniu go). Efekt ten występował jako pierwszy zauważalny w całym procesie uaktywniania się DPS/DGF. Później efekt pojawiał się sukcesywnie w coraz większej ilości linii. Podsumowując, jedyny czynnik, jaki mógł spowodować, że DPS wystąpił tylko w jednej ze 100-u linii, to inne opóźnienie (czas propagacji) sygnału podanego przez ANTIC na szynę AN2-AN0 w przypadku przekręcenia się wewnętrznego licznika niż opóźnienie w przypadku, gdy takie przekręcenie nie występuje. Ta obserwacja upewnia mnie w przekonaniu, że ANTIC jest współodpowiedzialny za powstawanie efektów DGF.
Dwa rodzaje HBLANK
Teraz jeszcze obserwacja, która nie ma związku z DGF, ale może być ciekawa dla osób próbujących odtworzyć schemat wewnętrzny układu GTIA. Jak wspomniałem wcześniej, w trakcie wygaszania poziomego ANTIC podaje na szynę AN2-AN0 sygnał HBLANK, czyli wartość binarną 010 jeśli w następnej linii ma być lores lub 011 jeśli w następnej linii ma być hires. Ma to miejsce w cyklach CPU 111-113 (koniec linii) oraz 0-16 (początek następnej linii). ANTIC pobiera instrukcję z DisplayList w cyklu 1 i wtedy dowiaduje się jaki będzie tryb w następnej linii. Odpowiednią wartość sygnału HBLANK wystawia więc na szynę AN2-AN0 dopiero w cyklu 2. Sądzę, że w cyklach 111-113 oraz 0-1 na szynę AN2-AN0 ANTIC podaje wartość sygnału HBLANK taką, jak dla poprzedniej linii, a w cyklach 2-16 wartość właściwą dla bieżącej linii. Obie wartości będą różne, jeżeli następuje zmiana trybu z hires na lores bądź odwrotnie oraz takie same jeżeli zmiana trybu nie następuje. Sądzę, że GTIA wybiera tryb pracy tzn. hires lub lores na podstawie wartości sygnału HBLANK w ostatnim cyklu koloru należącym do okresu HBLANK. Natomiast dla GTIA nie ma znaczenia, który z tych sygnałów jest podawany przez ANTIC, aby wygenerować sygnały (poziomy) wygaszania poziomego i synchronizacji poziomej.
Tryby wykorzystujące DGF
Wykorzystując efekty DGF można uzyskać kilka nowych trybów graficznych na małym Atari. Większość z nich jest trybami interlace’owymi, gdzie jeden z dwóch półobrazów jest poziomo przesunięty o pół piksela w danej rozdzielczości względem drugiego. Dzięki temu uzyskujemy podwojenie rozdzielczości poziomej oraz zwiększenie liczby dostępnych kolorów bądź odcieni w wyniku mieszania się nakładających się połówek pikseli z obu półobrazów.
DGI – Delayed Gtia hires Interlace – tryb, który zademonstrowałem w demie KNIGHT. Charakteryzuje się rozdzielczością poziomą 320 pikseli (hires) przy standardowej szerokości pola. Powstaje przez naprzemienne wyświetlanie dwóch półobrazów w rozdzielczości poziomej 160 (lores), czyli w trybie ANTIC’a $0E lub $04 opcjonalnie podkolorowanych przy pomocy obiektów PMG. W jednym z półobrazów zastosowany jest efekt DPS2 dający przesunięcie o jeden piksel hires w lewo od pozycji normalnej.
DGX – Delayed Gtia cross(X) interlace – tryb będący kombinacją DGI i zwykłego pionowego interlace’u telewizyjnego (opracowanego dla Atari przez Rybagsa). W tym trybie linie półobrazów nie nakładają się, lecz występują naprzemian, a rozdzielczość pionowa jest podwojona. Widzimy piksele lores ułożone jak cegły w murze, czyli w jednej linii nieprzesunięte, w następnej przesunięte o połowę długości, w następnej znów nieprzesunięte itd. Tryb DGX został również zademonstrowany w demie KNIGHT. Wykorzystana grafika nie była jednak tworzona z myślą o takim sposobie wyświetlania więc użycie DGX nie powoduje tu poprawy jakości.
D9I – Delayed gtia9 Interlace – tryb charakteryzujący się rozdzielczością poziomą 160 pikseli przy standardowej szerokości pola. Powstaje przez naprzemienne wyświetlanie dwóch półobrazów w trybie GTIA9 czyli w rozdzielczości poziomej 80. W jednym z półobrazów zastosowany jest efekt DPS dający przesunięcie o jeden piksel lores w lewo od pozycji normalnej.
D10I – Delayed gtia10 Interlace – tryb charakteryzujący się rozdzielczością poziomą 160 pikseli przy standardowej szerokości pola. Powstaje przez naprzemienne wyświetlanie dwóch półobrazów w trybie GTIA10 czyli w rozdzielczości poziomej 80. W jednym z półobrazów zastosowany jest efekt DPS dający przesunięcie o jeden piksel lores w lewo od pozycji normalnej.
D9X – Delayed gtia9 cross(X) mode – tryb nieinterlace’owy polegający na tym, że wszystkie linie są wyświetlane w trybie GTIA9, a co druga jest przesunięta o pół piksela w prawo dzięki zastosowaniu efektu DGM (DG9). Piksele rozdzielczości poziomej 80 są ułożone jak cegły w murze, czyli w jednej linii nieprzesunięte, w następnej przesunięte o połowę długości, w następnej znów nieprzesunięte itd.
D10X – Delayed gtia10 cross(X) mode – tryb nieinterlace’owy polegający na tym, że wszystkie linie są wyświetlane w trybie GTIA10, a co druga jest przesunięta o pół piksela w prawo dzięki zastosowaniu efektu DGM (DG10). Piksele rozdzielczości poziomej 80 są ułożone jak cegły w murze.
D9XI – Delayed gtia9 cross(X) Interlace – tryb charakteryzujący się rozdzielczością poziomą 160 pikseli przy standardowej szerokości pola. Powstaje przez naprzemienne wyświetlanie dwóch półobrazów w trybie D9X, gdzie w jednym półobrazie linie parzyste są nieprzesunięte, a nieparzyste przesunięte o pół piksela w prawo. Natomiast w drugim półobrazie linie parzyste są przesunięte o pół piksela w prawo, a nieparzyste są nieprzesunięte. Tryb ten jest bardzo zbliżony do trybu HIP lecz tu we wszystkich liniach występuje tryb GTIA9. Jest to taki sam tryb jak VZI – VertiZontal Interlacing opracowany w 1994 roku przez Bryana.
D10XI – Delayed gtia10 cross(X) Interlace – tryb charakteryzujący się rozdzielczością poziomą 160 pikseli przy standardowej szerokości pola. Powstaje przez naprzemienne wyświetlanie dwóch półobrazów w trybie D10X na podobnej zasadzie jak tryb D9XI.
Programy
DGF INIT (DGFINIT.XEX) – program, który inicjuje efekty DGF przy rosnącej temperaturze układów GTIA i ANTIC według podanego wyżej opisu. Program mierzy również stabilność (dostępność) efektów DGF i podaje ją w procentach. Efekty DGF włącza przy pomocy zalecanego GTIA10 i wyniki pomiarów dotyczą efektów włączanych tą właśnie metodą. Efekty włączane przy pomocy np. GTIA9 mogą wciąż być niedostępne gdy program pokazuje 100%-ową stabilność. Do wykrywania aktywności DGF w danej linii program używa mechanizmu wykrywania kolizji obiektów PMG z grafiką obrazu. W chwili gdy efekty DGF osiągną 100%-ową stabilność włącza się dźwiękowy sygnał alarmowy oraz wyświetlony zostaje całkowity czas dochodzenia do stabilności. Sygnał trwa około 1 minuty i może być wyłączony wcześniej przez naciśnięcie dowolnego klawisza. Naciśnięcie B powoduje wyświetlenie grafiki tła używanej przez program przy inicjowaniu DGF i pozwala na obserwację zachowania się (pulsowania) poszczególnych linii ekranu w trakcie procesu stabilizacji DGF. Naciśnięcie Esc powoduje wyjście do DOSa.
DPS CHECK (DPSCHECK.XEX) – program, który sprawdza, czy efekt DPS (włączany przy pomocy zalecanego GTIA10) jest stabilny (dostępny) w 100%. Program nie posiada bloku RUNAD, a jego przeznaczeniem jest doklejanie na początku plików .xex będących programami wyświetlającymi grafiki w trybach korzystających z DPS. Jeżeli program wykryje, że DPS nie jest stabilny (dostępny) w 100% to wyświetli stosowny komunikat oraz natychmiast wróci do DOSa zapobiegając dalszemu ładowaniu się i uruchomieniu programu głównego.
DGM CHECK (DGMCHECK.XEX) – program, który sprawdza, czy efekt DGM (włączany przy pomocy zalecanego GTIA10) jest stabilny (dostępny) w 100%. Podobnie jak DPS CHECK program nie posiada bloku RUNAD, a jego przeznaczeniem jest doklejanie na początku plików .xex będących programami wyświetlającymi grafiki w trybach korzystających z DGM.
DGM G9 CHECK (DGMG9CHK.XEX) – program, który sprawdza, czy efekt DGM (włączany przy pomocy GTIA9) jest stabilny (dostępny) w 100%. Podobnie jak DPS CHECK program nie posiada bloku RUNAD, a jego przeznaczeniem jest doklejanie na początku plików .xex będących programami wyświetlającymi grafiki w trybach korzystających z DGM.
DGF DEMO – demo efektów DPS i DGM zastosowanych w trybach GTIA9 i GTIA10. Naciśnięcie spacji ujawnia ukryte ugięte części obrazu. Naciśnięcie Esc powoduje wyjście do DOSa. Polecam przejrzenie kodu źródłowego tego programu. W folderze Src\dgfmode znajdują się oddzielne pliki źródłowe dla efektów DPS, DG9 i DG10 oraz ich kombinacji.
KNIGHT – demo trybów DGI i DGX wykorzystujące grafikę „Knight” autorstwa Tomasza „Levi” Lewandowskiego stworzoną dla C64 w trybie Interlaced FLI. Pozwala również wyświetlić samodzielnie oba półobrazy. Program wykrywa brak pełnej stabilności DGF i jeżeli taka sytuacja nastąpi blokuje możliwość wyświetlania trybów DGI i DGX, a także półobrazu z efektem DPS2, który wyświetlałby się nieprawidłowo ze względu na różnice w poziomych pozycjach obiektów PMG w co drugiej linii. Naciśnięcie 1 powoduje wyświetlenie tylko półobrazu przesuniętego o piksel hires w lewo, czyli tego z efektem DPS2, naciśnięcie 2 – tylko półobrazu bez przesunięcia, 3 – pełnego obrazu w trybie DGI, 4 i 5 – dwóch wariantów obrazu w trybie DGX (400i), które różnią się tym, który z półobrazów jest wyświetlany wyżej, a który niżej. Naciśnięcie spacji zatrzymuje płynący napis. Esc powoduje wyjście do DOSa.
CACTUVZI i FARMVZI – programy wyświetlające obrazki w trybie VZI (D9XI) opracowane przez Bryana. W programach tych do włączania efektu DGM używany jest tryb GTIA9, przez co na niektórych maszynach efekt będzie dość krótkotrwały (patrz akapit „Wpływ sposobów włączania efektów DGF na ich stabilność”). Do programów tych można dokleić na początku program DGMG9CHK.XEX w celu dodania mechanizmu wykrywania pełnej stabilności efektu DGM.
Wszystkie wymienione programy mojego autorstwa potrzebują nie więcej niż 48kB pamięci RAM i nie korzystają z pamięci RAM pod OS ROM, dzięki czemu mogą działać również na Atari 800. Programy działają zarówno na maszynach PAL jak i NTSC.
Ciekawe screenshoty
Poniżej zamieszczam kilka spośród licznych screenshotów zrobionych podczas prac nad DGF.
To już koniec
Opisane efekty DGF oraz powstałe z ich użyciem tryby graficzne nie mogą znaleźć poważnych zastosowań ze względu na ograniczoną dostępność (długi czas oczekiwania na samoistne rozgrzanie się układów graficznych, konieczność rozgrzewania tych układów, niewystępowanie efektów DGF w niektórych egzemplarzach Atari). Uważam jednak, że warto było zbadać i opisać zjawisko DGF, po prostu po to, żeby je poznać i wyjaśnić jedną z bardziej skrywanych tajemnic Atari. Ponadto oglądanie trybu DGI – hiresu z mnóstwem kolorów na standardowym Atari przyniosło mi ogromną radość i choćby tylko dla tego trybu warto było takie badania przeprowadzić.
Tym, którzy chcieliby zobaczyć opisane efekty, a obawiają się tak drastycznych metod podgrzewania Atari jak przy użyciu suszarki, polecam włączać komputer w upalne letnie dni. Komputer samoczynnie rozgrzeje się do wymaganej temperatury w około 30 minut. Oczywiście przy włączonym programie DGF INIT. W chłodniejszych porach roku proponuję ustawić Atari w pobliżu kaloryfera, a jeśli ktoś dysponuje własnym CO to również zaaplikować przysłowiowe „więcej węgla”.
Pliki do ściągnięcia: DGF_demo_ATR.zip oraz plik ze źródłami DGF_sources.zip.
Na naszym forum jest też wątek dotyczący zagadnienia DGF.
Artykuł ten objaśnia jakie efekty oraz tryby graficzne można uzyskać przy odpowiednio rozgrzanych układach graficznych GTIA i ANTIC. Pozwala również zrozumieć jak unikać takich efektów gdy nie są pożądane, a dochodzi do (samoczynnego) rozgrzania układów. Opisane efekty i tryby związane są z opóźnieniami wewnętrznych funkcji układu GTIA o jeden tzw. cykl koloru. Opis zawiera również ciekawe informacje dla osób próbujących odtworzyć schemat wewnętrzny układu GTIA.
Słownik terminów używanych dalej w tekście
Terminy znane:
PRIOR – rejestr sterujący układu GTIA o adresie $D01B. Służy do wyboru trybu GTIA oraz określenia priorytetów sprite’ów.
GTIACTL – alternatywna nazwa rejestru PRIOR, używana przez mnie w kodzie programów.
GTIA9 (właściwie GTIA1) – tryb GTIA o rozdzielczości poziomej 80, pozwalający wyświetlić 16 jasności jednego koloru (hue), uzyskiwany przez zapis $40 (OR <priority>) do rejestru GTIACTL lub przez polecenie GR.9 w Basicu.
GTIA10 (właściwie GTIA2) – tryb GTIA o rozdzielczości poziomej 80, pozwalający wyświetlić 9 niezależnych kolorów, uzyskiwany przez zapis $80 (OR <priority>) do rejestru GTIACTL lub przez polecenie GR.10 w Basicu.
GTIA11 (właściwie GTIA3) – tryb GTIA o rozdzielczości poziomej 80, pozwalający wyświetlić 16 kolorów (hue) w jednej wspólnej jasności, uzyskiwany przez zapis $C0 (OR <priority>) do rejestru GTIACTL lub przez polecenie GR.11 w Basicu.
GTIAX – dowolny z trzech trybów GTIA.
NORMAL (właściwie GTIA0) – nazwa trybu układu GTIA dla zwykłych trybów graficznych, tzn. nie-GTIA – tryb uzyskiwany przez zapis $00 (OR <priority>) do rejestru GTIACTL.
PMG – grafika graczy i pocisków (Player Missile Graphics) – nazwa dla sprite’ów w Atari.
Pole gry (playfield) – grafika obejmująca kolory 0-3 (COLPF0-COLPF3), ale nie kolor tła COLBAK.
Cykl CPU – cykl zegara ø2 1.77MHz (1.79MHz w NTSC) taktującego CPU.
Cykl koloru – cykl zegara Osc 3.54MHz (3.579MHz w NTSC) równoważny jednemu pikselowi w rozdzielczości poziomej 160. Stanowi połowę cyklu CPU. Numeracja cykli koloru jest zgodna z pozycjami poziomymi obiektów PMG. Pełna linia obrazu składa się z 228 cykli koloru (114 cykli CPU).
Piksel lores – piksel w rozdzielczości poziomej 160 równoważny jednemu cyklowi koloru.
Piksel hires – piksel w rozdzielczości poziomej 320 równoważny połowie piksela lores i połowie cyklu koloru.
HBLANK – niewidoczna część linii obrazu obejmująca cykle koloru 222-227 oraz 0-33 (cykle CPU 111-113 oraz 0-16), łącznie 40 cykli koloru (20 cykli CPU). W trakcie HBLANK nie działa wykrywanie kolizji obiektów PMG.
ACTIVE DISPLAY – widoczna część linii obrazu obejmująca cykle koloru 34-221 (cykle CPU 17-110), łącznie 188 cykli koloru (94 cykle CPU).
VBLANK – czas wygaszania pionowego obejmujący wygaszone linie obrazu 248-311 w PAL/SECAM, 248-261 w NTSC oraz 0-7 w każdym z systemów. Zawiera w sobie czas VSYNC. W trakcie VBLANK nie działa wykrywanie kolizji obiektów PMG.
VSYNC – czas synchronizacji pionowej obejmujący 3 pełne linie 275-277 w PAL/SECAM, 255-257 w NTSC.
Terminy nowe (ukute przeze mnie):
DGM – Delayed Gtia Mode – efekt przesunięcia (opóźnienia) zawartości linii obrazu w trybach GTIAX o pół piksela (1 cykl koloru) w prawo.
DPS – Delayed Pmg and hSync – efekt przesunięcia (opóźnienia) grafiki graczy i pocisków PMG oraz impulsu synchronizacji poziomej o 1 cykl koloru. W wyniku przesunięcia hsync efekt na ekranie jest taki, że grafika jest przesunięta w lewo, a PMG pozostają na normalnej pozycji.
DPS2 – Delayed Pmg and hSync in every second (2) line – efekt będący szczególnym przypadkiem zastosowania DPS co drugą linię i dający przesunięcie o jeden piksel hires w lewo od pozycji normalnej.
DGF – Delayed Gtia Functions – nazwa zjawiska opóźnienia funkcji układu GTIA obejmująca efekty DGM i DPS.
DG9 – Delayed Gtia mode 9 – tryb powstały przez zastosowanie efektu DGM w trybie GTIA9.
DG10 – Delayed Gtia mode 10 – tryb powstały przez zastosowanie efektu DGM w trybie GTIA10.
DG11 – Delayed Gtiamode 11 – tryb powstały przez zastosowanie efektu DGM w trybie GTIA11.
Efekty DGF
Jak napisałem we wstępie opis ten dotyczy efektów opóźnienia o jeden cykl koloru funkcji układu GTIA, a tym samym przesunięcia treści linii obrazu o jeden piksel lores. Efekty te można użyć do podwojenia rozdzielczości trybów GTIA (80 pikseli), o ile zastosujemy interlace poziomy, czyli naprzemienne wyświetlanie dwóch półobrazów gdzie dana linia obrazu w jednej klatce nie jest przesunięta, a w drugiej jest przesunięta o jeden piksel lores. Dodatkowym efektem jest w takim wypadku poszerzenie palety kolorów obrazu ze względu na mieszanie się połówek nakładających się pikseli obu półobrazów. Zasada jest ta sama co w trybie HIP. Tu jednak możliwe jest mieszanie linii w GTIA9 z przesuniętą o piksel lores linią w GTIA9. W HIP następuje mieszanie linii w GTIA9 z linią w GTIA10, która jest stale przesunięta względem GTIA9 o piksel lores. Okazało się również, że istnieje możliwość podwojenia rozdzielczości trybów standardowych lores (160 pikseli) na tej samej zasadzie to jest poprzez naprzemienne wyświetlanie dwóch półobrazów gdzie dana linia obrazu w jednej klatce nie jest przesunięta, a w drugiej jest przesunięta o jeden piksel hires. Przesunięcie o piksel hires uzyskuje się w inny, bardziej skomplikowany sposób niż przesunięcie o piksel lores. Będzie to opisane w dalszej części tekstu.
Istnieją dwa różne sposoby na uzyskanie przesunięcia treści linii w trybie GTIAX o jeden piksel lores – efekt DGM i DPS. Istnieje możliwość wyświetlenia każdego z nich samodzielnie bądź obu naraz. Oba efekty należą do jednej kategorii, którą nazwałem DGF.
Warunkiem koniecznym do wystąpienia DGF jest odpowiednie rozgrzanie układów graficznych GTIA i ANTIC. Nie jest znana dokładna temperatura jaką muszą osiągnąć układy natomiast z grubsza wiadomo ile czasu zajmuje dochodzenie do stabilnych efektów DGF w różnych temperaturach otoczenia. Temperatury te są różne pomiędzy różnymi egzemplarzami Atari, a całkowity czas dochodzenia danego egzemplarza do DGF w tej samej temperaturze też się zmienia. Dzięki przeprowadzonym badaniom ustaliłem, że w temperaturze otoczenia 25°C czas dochodzenia do stabilnego DGF w minutach waha się pomiędzy 150 a 250 natomiast w 29°C pomiędzy 30 a 40. Czas ten można skrócić nawet do 3 minut podgrzewając Atari przy pomocy np. suszarki do włosów. Ponadto aby utrzymać stabilny DGF na długie godziny temperatura otoczenia musi mieć minimalnie 25°C.
Stabilność DPS może wymagać wyższej temperatury niż stabilność DGM. Stabilność DGF oznacza stabilność zarówno DGM jak i DPS. Jest prawdopodobne, że są takie egzemplarze Atari gdzie występuje jedynie DGM, a DPS jest nieosiągalne.
Okazuje się, że są takie egzemplarze Atari, gdzie DGF nie występuje w ogóle, czyli nie występuje ani DPS ani DGM. Osobiście posiadam jeden taki egzemplarz. Jest to Atari 130XE wyprodukowane w 1990 roku, posiadające płytę z 4-ma kośćmi RAM oraz układ GTIA z uszkodzonymi trybami GTIA. Nie mam pewności czy odporność na DGF ma związek z uszkodzonymi trybami GTIA.
[kliknij aby zobaczyć w pełnym
rozmiarze]
DGM
Efekt DGM polega na tym, że piksele trybów GTIAX są przesunięte w prawo o pół piksela (lub jeden piksel lores). GTIA łączy w jeden piksel rozdzielczości 80 dwa 2-bitowe słowa z linii AN1 i AN0 o jeden cykl koloru za późno, licząc względem strumienia danych podawanych przez ANTIC na linie AN2-AN0. Inaczej mówiąc łączy w jeden piksel dwa młodsze bity pierwszego piksela z dwoma starszymi bitami drugiego piksela. Dwa młodsze bity pierwszego piksela stają się więc starszymi bitami „opóźnionego” piksela, a dwa starsze bity drugiego piksela – młodszymi bitami „opóźnionego”. Tak więc dane przygotowane do wyświetlenia w trybach GTIAX będą wyświetlane zupełnie niepoprawnie, gdy uaktywnimy efekt DGM. Można to skorygować na dwa sposoby. Pierwszy to przesunąć (opóźnić) dane podawane przez ANTIC o jeden piksel lores ustawiając właściwie rejestr HSCROL i adres danych w Display List oraz uaktywniając przesuw poziomy w Display List w liniach, gdzie włączony jest DGM. Drugi sposób to zmienić dane obrazka w pamięci tak by były poprawne dla DGM.
Efekt DGM może być włączony w dowolnej linii ekranu niezależnie od tego, czy jest włączony w innych liniach. W szczególności DGM może być włączony co drugą linię. Pozwala to na przykład na uzyskanie trybu podobnego do HIP, ale tylko przy użyciu GTIA9.
Efekt DGM odkrył w roku 1994 niejaki Bryan – członek społeczności AtariAge.
O odkryciu wspomina tu:
1.
Internal ANTIC and GTIA schematics I (www.atariage.com)
2. Internal ANTIC and GTIA schematics II
3. Internal ANTIC and GTIA schematics III
4. Internal ANTIC and GTIA schematics IV
2. Internal ANTIC and GTIA schematics II
3. Internal ANTIC and GTIA schematics III
4. Internal ANTIC and GTIA schematics IV
W pozycji 3 załączone są 2 przykłady wykorzystania DGM (dokładnie DG9) oraz screenshoty przed i po rozgrzaniu układów graficznych. Bryan nazwał swój tryb VZI – VertiZontal Interlacing. Tryb jest bardzo zbliżony do HIP. W jednej klatce obrazu opóźnione o jeden cykl koloru są wszystkie linie parzyste, w drugiej wszystkie nieparzyste. Jako metodę korekcji danych niepoprawnie łączonych pikseli Bryan zastosował przesuw poziomy przy użyciu HSCROL.
Przykłady Bryana aktywują zarówno DGM jak i DPS, a dokładnie DPS2 (patrz akapit „Zależności między efektami DGF”). Efekt DPS2 powoduje widoczne na ekranie ugięcie obrazu (i przesunięcie o jeden piksel hires w lewo!), ale na screenshotach Bryana nie jest to widoczne. Oznacza to, że w maszynie Bryana DPS był nieosiągalny bądź temperatura była zbyt niska, aby DPS się uaktywnił.
W przykładach Bryana efekt DGM włączany jest przy pomocy trybu GTIA9, co na niektórych maszynach znacznie skraca czas występowania efektu ze względu na wyższy próg temperaturowy (patrz akapit „Wpływ sposobów włączania efektów DGF na ich stabilność”).
Obraz w trybie VZI Bryana. U góry widoczne
ugięcie.
Większa dolna część obrazu przesunięta o jeden piksel hires w lewo
Większa dolna część obrazu przesunięta o jeden piksel hires w lewo
Obraz w trybie VZI Bryana
DPS
Efekt DPS polega na tym, że GTIA wykonuje swoje funkcje to jest nakładanie obiektów PMG oraz generację impulsu synchronizacji poziomej hsync o jeden cykl koloru później niż normalnie, licząc względem strumienia danych podawanych przez ANTIC na linie AN2-AN0.W wyniku przesunięcia hsync efekt na ekranie jest taki, że grafika jest przesunięta w lewo, a PMG pozostają na normalnej pozycji.
Efekt przesunięcia grafiki w wyniku opóźnienia hsync nie jest natychmiastowy. Mija około 5 linii ekranu od momentu uaktywnienia opóźnienia do ustabilizowania się przesunięcia. W tych 5-ciu liniach widoczne jest „ugięcie” obrazu, czyli płynne przejście pomiędzy normalną, a przesuniętą o jeden piksel lores grafiką, inaczej mówiąc pomiędzy normalną i przesuniętą pozycją impulsu hsync. Jest to cecha urządzeń wyświetlających.
Zaobserwowałem taki efekt na kilku telewizorach, monitorze C= 1084S, karcie AV capture, konwerterze AV-VGA oraz rzutniku i sądzę, że ta cecha jest wspólna dla wszystkich urządzeń wyświetlających zgodnych z systemami PAL/NTSC/SECAM. Cecha ta powoduje, że nie można uzyskać przesunięcia w dowolnej linii niezależnie od sąsiednich. Należy więc stosować przesunięcie dla całego ekranu bądź dla wieloliniowych bloków, a każdy z nich poprzedzić i zakończyć przynajmniej 6-cioma pustymi liniami w celu ukrycia „ugiętych” fragmentów obrazu.
Z efektem DPS związany jest pewien problem. W pierwszej linii ekranu bez DPS następującej po bloku linii z włączonym DPS nie działa DMA obiektów PMG. Problem musi być związany z powrotem układu GTIA z opóźnionego do normalnego timingu. Prawdopodobnie GTIA gubi aktywne zbocze sygnału HALT, które inicjuje odczyt serii danych PMG z magistrali danych.
Efekt DPS występuje niezależnie od trybu układu GTIA to jest NORMAL lub GTIAX, a w przypadku NORMAL także niezależnie od trybu określonego przez ANTIC to jest lores lub hires.
Efekt DPS odkryłem w roku 2009.
DPS2
Jeżeli DPS zastosujemy w co drugiej linii ekranu to wspomniana cecha urządzeń wyświetlających do wygładzania przejścia pomiędzy normalną i przesuniętą pozycją impulsu hsync spowoduje uśrednienie przesunięcia grafiki we wszystkich liniach w pozycji, która jest przesunięta dokładnie o pół piksela lores (czyli jeden piksel hires) w lewo od pozycji normalnej. Ten efekt jest szczególnym przypadkiem efektu DPS. Nazwałem go DPS2. Jest on podstawą dla trybu graficznego DGI, który zaprezentowałem w demie KNIGHT. Należy pamiętać, że w liniach, w których zastosowany jest DPS (czyli w co drugiej linii), obiekty PMG są przesunięte o jeden piksel lores w prawo względem zadanej pozycji podczas gdy w pozostałych liniach PMG są usytuowanie normalnie. To komplikuje trochę ich użycie do podkolorowania obrazu. Ponadto dochodzi problem z wspomnianym brakiem DMA obiektów PMG, który w DPS2 występuje w co drugiej linii i utrudnia użycie PMG jeszcze bardziej.
Podsumowując, problem z przesuniętymi obiektami PMG występuje w liniach z włączonym DPS, a problem z brakiem DMA PMG w liniach z wyłączonym DPS, czyli oba problemy występują na przemian w kolejnych liniach. Problem z brakiem DMA można obchodzić poprzez zapisywanie danych do rejestrów kształtów PMG przy pomocy CPU. Jednak to redukuje czas dostępny na inne zmiany. Przy pracy nad demem KNIGHT okazało się, że często udaje się wykorzystać ten sam bajt kształtu w więcej niż jednej linii (pomimo przesunięć o piksel co drugą linię), dzięki czemu brak DMA nie jest tak uciążliwy, ale to oczywiście zależy od konkretnego obrazka. Ogólnie opracowanie programu rastra używającego DPS2 jest bardzo trudne.
Jak włączać efekty DGF
Z punktu widzenia programisty efekty DGF włącza się w następujący sposób:
Efekt DGM w danej linii obrazu uzyskujemy poprzez przełączenie z NORMAL na GTIAX w obszarze ACTIVE DISPLAY (cykle CPU 17-110). Warunkiem koniecznym jest aby przełączenie nastąpiło nie wcześniej niż w cyklu 17. Tak więc związany z włączeniem GTIAX zapis rejestru PRIOR ($D01B) może nastąpić najwcześniej w cyklu CPU 16. W tym wypadku zmiana wpływa na układ GTIA od cyklu 17. Nie ma znaczenia w jakim trybie działa układ GTIA w trakcie HBLANK. Znaczenie ma tylko pierwsze przełączenie z NORMAL na GTIAX, a kolejne nie. Wystąpienie HBLANK wyłącza DGM. Oznacza to konieczność uaktywniania DGM w każdej linii gdzie ma być widoczny.
Efekt DPS uzyskujemy właściwie tak samo, z tym że będzie on widoczny dopiero w następnej linii ekranu. Dodatkowym warunkiem koniecznym dla DPS jest, aby GTIAX był aktywny w momencie rozpoczęcia HBLANK (tego HBLANK poprzedzającego linię, w której widoczny będzie efekt, a więc tego występującego już po włączeniu DGM). Warunek ten jest spełniony gdy GTIAX jest aktywny w cyklu CPU o numerze 110 (cykle koloru 220 i 221). Przełączenie z NORMAL na GTIAX może więc nastąpić najpóźniej w cyklu 109. Metoda włączania DPS ze względu na dodatkowy warunek jest szczególnym przypadkiem metody włączania DGM.
Wpływ sposobów włączania efektów DGF na ich stabilność
Opisane sposoby włączania działają w warunkach pełnej stabilności zjawiska DGF. W sytuacji, gdy stabilność DGF jest osiągnięta w znacznym stopniu, ale nie jest pełna, uzyskanie stabilnych efektów DGM i DPS też jest możliwe. Uzyskanie DGM wymaga wtedy większej niż jeden liczby cykli CPU w trybie NORMAL przed przełączeniem na GTIAX (największa stabilność przy 2-3 cyklach) natomiast uzyskanie DPS wymaga większej niż jeden liczby cykli CPU w trybie GTIAX przed cyklem 110 oraz jak najmniejszej (najlepiej zero) liczby takich cykli po cyklu 110. Stosując się do tych zasad można uzyskać stabilne efekty DGF przy trochę niższych temperaturach niż wymagane do pełnej stabilności DGF oraz utrzymać te efekty przez dłuższy czas. Inaczej mówiąc, w ten sposób można obniżyć próg temperaturowy dla aktywności efektów DGF.
Ma znaczenie, przy pomocy którego trybu GTIA, a właściwie jakiej wartości zapisywanej do PRIOR włączamy DGM. Włączenie oznacza tu pierwsze przełączenie z NORMAL na GTIAX w obszarze ACTIVE DISPLAY. Uaktywnienie oznacza, że efekt jest rzeczywiście widoczny. Są takie układy GTIA, dla których włączanie DGM przy pomocy GTIA10, czyli wartości $80 OR <priority>, jest znacznie korzystniejsze, ponieważ uaktywnienie się DGM następuje wtedy w znacznie niższej temperaturze niż przy użyciu innej wartości. Aktywność efektu utrzymuje się również znacznie dłużej, na przykład kilka godzin w temperaturze otoczenia 22°C. Z kolei aktywność efektu DGM włączanego przy pomocy GTIA9 czyli wartości $40 OR <priority> ma wyższy próg temperaturowy i następuje znacznie później oraz zanika znacznie wcześniej. Może trwać na przykład tylko kilkanaście minut w temperaturze otoczenia 22°C. Aktywność efektu DGM włączanego przy pomocy GTIA11, czyli wartości $C0 OR <priority> ma najwyższy próg temperaturowy. Dlatego najlepiej włączać DGM przy pomocy GTIA10, a potem ewentualnie przełączać na inny tryb GTIA w zależności, który z trybów DG9, DG10 czy DG11 chcemy wyświetlić. Istnieją też takie układy GTIA, dla których próg temperaturowy aktywności efektu DGM jest niezależny od tego czy do rejestru PRIOR wpisujemy wartość $40 OR <priority> czy $80 OR <priority>.
Podsumowując, w celu włączenia DGF (DGM lub DPS) zalecane jest używanie trybu GTIA10, czyli wartości $80 OR <priority>. Zaraz potem można zmienić tryb jeżeli pożądany jest inny niż GTIA10.
Pisząc programy wykorzystujące efekty DGF należy zakładać osiągnięcie przez GTIA pełnej stabilności DGF. Jeżeli kiedykolwiek emulatory będą emulować efekty DGF to powinny robić to tak jakby osiągnięta była pełna stabilność DGF. Pełna stabilność oznacza, że włączenie danego efektu DGF powoduje jego natychmiastowe uaktywnienie i widoczność na ekranie.
Jak wykrywać aktywność efektów DGF i określać ich stabilność
Efekt DPS wymaga z reguły wyższej temperatury układu GTIA niż efekt DGM. Wykrycie stabilnego DPS jest równoznaczne ze stwierdzeniem stabilnego DGM. Wykrywanie DPS realizuje się z użyciem mechanizmu wykrywania kolizji PMG z grafiką obrazu. Wykorzystuje się fakt, że przy aktywnym DPS obiekty PMG są przesunięte o jeden piksel lores w prawo względem swej normalnej pozycji wobec grafiki obrazu.
Jeżeli w programie wykorzystujemy tylko efekty DGM to bardziej sensowne jest wykrywanie stabilności tylko tego efektu ze względu na niższy próg temperaturowy niż dla DPS. Wykrywanie DGM jest możliwe dzięki mechanizmowi wykrywania kolizji pomiędzy obiektami Missile a grafiką w trybie GTIA10. Wykorzystuje się fakt, że przy aktywnym DGM granice pikseli rozdzielczości 80 są przesunięte o jeden piksel lores, a ich wartości są inne niż w przypadku, gdy przesunięcia nie ma (patrz akapit „DGM”).
Stopień stabilności efektu DGF określa się jako stosunek ilości linii ekranu, w których DGF okazał się aktywny do ilości linii, w których DGF był włączony. Ilość badanych linii powinna być oczywiście jak największa. Ponadto całkowita stabilność może być stwierdzona dopiero wtedy, gdy jest ona maksymalna dla kilkudziesięciu kolejnych klatek obrazu.
Napisałem trzy krótkie programy służące do wykrywania pełnej stabilności efektów DGF. Program o nazwie DPSCHECK wykrywa stabilność efektu DPS włączanego przy pomocy GTIA10, program DGMCHECK – stabilność efektu DGM włączanego przy pomocy GTIA10. Natomiast program DGMG9CHK sprawdza stabilność efektu DGM włączanego przy pomocy GTIA9. Programy nie posiadają bloku RUNAD, a ich przeznaczeniem jest doklejanie na początku plików .xex będących programami wyświetlającymi grafiki w trybach korzystających z odpowiednich efektów DGF.
W górnej części ekranu włączony efekt DGM, w
dolnej DGM+DPS. Brak aktywności efektów
Widoczna aktywność efektów. Stabilność
efektu DPS w dolnej części ekranu wynosi 35%
Stabilność efektu DPS w dolnej części ekranu
wynosi 92%
Zależności między efektami DGF
Choć efekty DGM i DPS włącza się praktycznie w ten sam sposób to jest możliwe uzyskanie każdego z nich oddzielnie. Można też oczywiście uzyskać oba naraz. Wszystko zależy od momentów, w których następują zmiany rejestru PRIOR.
W celu włączenia samodzielnego efektu DGM należy przełączyć z NORMAL na GTIAX w cyklu 16 lub później, byle przed rozpoczęciem wyświetlania grafiki oraz przełączyć z GTIAX na NORMAL w cyklu 109 lub wcześniej, byle po zakończeniu wyświetlania grafiki.
W celu włączenia samodzielnego efektu DPS należy przełączyć z NORMAL na GTIAX w cyklu 109 lub wcześniej, byle po zakończeniu wyświetlania grafiki oraz przełączyć z GTIAX na NORMAL w cyklu 110 lub później, byle przed cyklem 109 następnej linii.
W celu włączenia obu efektów jednocześnie należy przełączyć z NORMAL na GTIAX w cyklu 16 lub później, byle przed rozpoczęciem wyświetlania grafiki oraz przełączyć z GTIAX na NORMAL w cyklu 110 lub później, na przykład tuż przed kolejnym przełączeniem na GTIAX.
Jak rozgrzewać GTIA
W trakcie rozgrzewania układu GTIA musi być włączony efekt DPS. Najlepiej aby był włączony w jak największej liczbie linii ekranu. Rozgrzewanie GTIA bez włączonego DPS jest nieskuteczne. Po takim nieskutecznym rozgrzewaniu, a następnie włączeniu DPS lub DGM nadal potrzebne jest rozgrzewanie aby oba efekty DGF uzyskały widoczność i stabilność, choć wtedy potrzeba mniej czasu.
W trakcie rozgrzewania włączanie DPS powinno odbywać się przy użyciu trybu GTIA10 lub GTIA9. Rozgrzewanie przy użyciu GTIA11 jest nieskuteczne. Jeżeli użyjemy GTIA9 to dla niektórych układów GTIA będzie wymagana wyższa temperatura niż przy użyciu GTIA10. Zalecane jest używanie trybu GTIA10 przy rozgrzewaniu GTIA.
Ciekawe obserwacje i próby wyjaśnienia jak powstają efekty DGF
Temperatura
Przede wszystkim należy zauważyć, że ze wzrostem temperatury układów scalonych wiąże się wzrost czasów propagacji sygnałów. To oznacza, że w warunkach rozgrzania układu pewne sygnały mogą być opóźnione. Takie opóźnienie jest z pewnością przyczyną powstawania efektów DGF. Opóźnienie dokładnie o jeden piksel lores, czyli jeden cykl koloru oznacza, że jakiś przerzutnik (bądź przerzutniki) wewnątrz GTIA przechowujący stan układu i taktowany zegarem koloru 3.58MHz zatrzaskuje swój stan później o cały cykl, czyli „gubi” jedno aktywne zbocze sygnału zegarowego. Takie „gubienie” następuje raz na linię ekranu. Nie jest możliwe pełne wyjaśnienie przyczyn powstawania DGF bez szczegółowej znajomości schematu wewnętrznego układu GTIA.
O synchronizacji GTIA z ANTIC’iem oraz jej wpływie na DPS
Kiedyś w trakcie eksperymentów z tzw. bugiem ANTICa w linii 240, synchronizacją pionową i poziomą zauważyłem, że możliwy jest wpływ na synchronizację poziomą w liniach wygaszonych (VBLANK) skutkujący przeróżnymi „ugięciami” obrazu, natomiast nie jest możliwy wpływ na synchronizację poziomą w 240 liniach normalnych (o ile nie jest aktywny DGF). W tych liniach obraz jest zawsze w prawidłowym położeniu. Wniosek z tej obserwacji jest taki, że GTIA synchronizuje się z ANTIC-iem w każdej z 240 normalnych linii oraz nie synchronizuje się w liniach wygaszonych. Wiadomo, że synchronizacja następuje, gdy ANTIC podaje na szynę AN2-AN0 sygnał HBLANK czyli wartość binarną 010 (lub 011 jeśli w następnej linii ma być hires). Z podanego wcześniej wniosku wynika, że ANTIC nie podaje sygnału HBLANK w liniach wygaszonych (VBLANK) albo, co bardziej prawdopodobne, ANTIC podaje sygnał HBLANK ciągle przez cały czas trwania VBLANK (z wyjątkiem trzech linii gdzie podaje sygnał VSYNC), a GTIA synchronizuje się z ANTIC-iem tylko przy przejściu z ACTIVE DISPLAY do HBLANK. Za tą drugą opcją przemawia fakt, że puste linie normalne różnią się od linii wygaszonych tym, że w wygaszonych nie mamy wpływu na ich kolor. Musi być więc różnica między sygnałem podawanym przez ANTIC w jednych i drugich liniach. Jedyną możliwością jest, że w pustych liniach normalnych jest to sygnał BACKGROUND (binarnie 000), a w wygaszonych sygnał HBLANK.
Fakt, że w standardowych warunkach GTIA wyświetla obraz poprawny pod względem synchronizacji poziomej we wszystkich liniach ekranu (w tym w liniach wygaszonych) oznacza, że GTIA posiada wewnętrzny licznik, który zlicza cykle koloru i pozwala we właściwym momencie wygenerować impuls synchronizacji poziomej niezależnie od tego, czy ANTIC podaje sygnał HBLANK czy nie. Licznik taki jest z pewnością synchronizowany z sygnałem HBLANK, gdy ten jest podawany przez ANTIC (w 240 liniach normalnych).
Wygląda na to, że przyczyną powstawania efektu DPS jest spóźnione o jeden cykl koloru docieranie sygnału HBLANK z ANTICa do GTIA i synchronizowanie się wewnętrznego licznika cykli koloru GTIA z tak opóźnionym sygnałem. Innym możliwym wytłumaczeniem jest, że GTIA „gubi” przejście od ACTIVE DISPLAY do HBLANK ponieważ jest w trybie GTIAX i być może oczekuje takiego przejścia co drugi cykl koloru i wskutek tego nie synchronizuje się oraz że opóźnienie o jeden cykl koloru związane z DGM powoduje również opóźnienie wewnętrznego licznika cykli koloru, a co za tym idzie opóźnienie impulsu synchronizacji poziomej.
Zauważyłem, że jeżeli DPS jest włączony przed końcem ostatniej 240-stej normalnej linii ekranu i skutkuje przesunięciem PMG i impulsu synchronizacji poziomej w linii następnej to przesunięcie to utrzymuje się przez wszystkie linie wygaszone (VBLANK) aż do pierwszej (z 240 normalnych) linii u góry ekranu. Dopiero tu DPS przestaje być skuteczny o ile nie zostanie włączony tuż przed rozpoczęciem pierwszej linii normalnej i następnych. Ta obserwacja potwierdza, że GTIA nie synchronizuje się z ANTIC-iem w trakcie wyświetlania linii wygaszonych (VBLANK) oraz że ma wewnętrzny licznik cykli koloru.
Efekt DPS włączony tylko w dolnej części
ekranu. Powrót obrazu z przesuniętej do normalnej pozycji następuje
dopiero na początku następnej klatki obrazu, czyli na samej górze
ekranu. Przesunięcie utrzymuje się przez cały czas trwania VBLANK
mimo, że program nie wykonuje przełączeń rejestru PRIOR
włączających efekt DPS w tym czasie
Czy ANTIC wpływa na efekty DGF?
W czasie stabilizowania się efekty DGF pojawiają się i znikają losowo w poszczególnych liniach ekranu. Widoczne jest to jako przesuwanie się zawartości linii o piksel w prawo lub w lewo. Nazwijmy to pulsowaniem. W przypadku efektu DPS dochodzi jeszcze uginanie się obrazu w sąsiedztwie linii z uaktywnionym takim efektem. W pewnych momentach pulsowanie danej linii wygląda na zupełnie niezależne od pozostałych, ale w innych momentach można zauważyć powtarzające się całe grupy linii, które pulsują według takiego samego wzoru. Układ GTIA nie potrafi rozróżniać linii. Nie zawiera licznika linii i nie wie, którą linię ekranu aktualnie przetwarza. Polega tylko na sygnałach podawanych przez ANTIC na szynę AN2-AN0. Wydaje się, że gdyby jedynie układ GTIA był odpowiedzialny za wprowadzanie opóźnień, które skutkują efektami DGF, to te efekty pojawiałyby się i znikały jednocześnie we wszystkich liniach ekranu. Tak jednak nie jest i ten fakt wskazuje na to, że ANTIC jest współodpowiedzialny za powstawanie opóźnień. Udało mi się zaobserwować ciekawy przypadek, który wydaje się tego dowodzić. Zanim go jednak opiszę, muszę dokonać krótkiego wprowadzenia.
Badania przeprowadzałem w taki sposób, że dzieliłem ekran na dwie części, po 100 linii w trybie $0E ANTIC’a każda, przedzielone kilkunastoma liniami. W obu częściach w każdej linii włączony był efekt DPS. W obu częściach włączony był ekran rozszerzony (wide field), który pobiera 48 bajtów na linię w trybie $0E. W Display Liście instrukcja LMS (czyli ustawiająca początkowy adres danych obrazu) występowała tylko w pierwszej ze stu linii każdego bloku. Ilość danych potrzebna dla 100-u linii to 100*48=4800, czyli więcej niż 4kB. Jak wiadomo, wewnętrzny rejestr ANTIC’a wskazujący dane do pobrania jest inkrementowany automatycznie tylko w obrębie 4kB (inkrementacji podlegają tylko bity 11-0) co oznacza, że rejestr wskazujący składa się z 12-bitowego licznika oraz 4-bitowego rejestru zwykłego przechowującego niezmienne najstarsze 4 bity adresu podanego w instrukcji LMS. Licznik 12-bitowy po dojściu do najwyższej wartości $FFF przekręca się, czyli zaczyna liczyć od 0. Tak więc jeżeli 100-u liniowy blok danych obrazu zaczynałby się na granicy 4-kilobajtowego bloku pamięci, np. od adresu $5000 to musiałoby następować jedno przekręcenie się licznika (w linii o numerze (4096 div 48) = 85). A teraz wracam do obserwacji. Udało mi się zaobserwować przypadek, gdzie w opisanych powyżej warunkach (jednakowych w każdej linii 100-liniowego bloku) efekt DPS uaktywniał się dokładnie w jednej linii w obu 100-liniowych blokach.
Po wnikliwym dochodzeniu ustaliłem, że w obu przypadkach jest to linia następująca bezpośrednio po linii, w której dochodzi do przekręcenia się wewnętrznego 12-bitowego licznika ANTICA’a wskazującego dane obrazu (przypomnę jeszcze, że DPS jest widoczny w linii następującej po włączeniu go). Efekt ten występował jako pierwszy zauważalny w całym procesie uaktywniania się DPS/DGF. Później efekt pojawiał się sukcesywnie w coraz większej ilości linii. Podsumowując, jedyny czynnik, jaki mógł spowodować, że DPS wystąpił tylko w jednej ze 100-u linii, to inne opóźnienie (czas propagacji) sygnału podanego przez ANTIC na szynę AN2-AN0 w przypadku przekręcenia się wewnętrznego licznika niż opóźnienie w przypadku, gdy takie przekręcenie nie występuje. Ta obserwacja upewnia mnie w przekonaniu, że ANTIC jest współodpowiedzialny za powstawanie efektów DGF.
Dwa rodzaje HBLANK
Teraz jeszcze obserwacja, która nie ma związku z DGF, ale może być ciekawa dla osób próbujących odtworzyć schemat wewnętrzny układu GTIA. Jak wspomniałem wcześniej, w trakcie wygaszania poziomego ANTIC podaje na szynę AN2-AN0 sygnał HBLANK, czyli wartość binarną 010 jeśli w następnej linii ma być lores lub 011 jeśli w następnej linii ma być hires. Ma to miejsce w cyklach CPU 111-113 (koniec linii) oraz 0-16 (początek następnej linii). ANTIC pobiera instrukcję z DisplayList w cyklu 1 i wtedy dowiaduje się jaki będzie tryb w następnej linii. Odpowiednią wartość sygnału HBLANK wystawia więc na szynę AN2-AN0 dopiero w cyklu 2. Sądzę, że w cyklach 111-113 oraz 0-1 na szynę AN2-AN0 ANTIC podaje wartość sygnału HBLANK taką, jak dla poprzedniej linii, a w cyklach 2-16 wartość właściwą dla bieżącej linii. Obie wartości będą różne, jeżeli następuje zmiana trybu z hires na lores bądź odwrotnie oraz takie same jeżeli zmiana trybu nie następuje. Sądzę, że GTIA wybiera tryb pracy tzn. hires lub lores na podstawie wartości sygnału HBLANK w ostatnim cyklu koloru należącym do okresu HBLANK. Natomiast dla GTIA nie ma znaczenia, który z tych sygnałów jest podawany przez ANTIC, aby wygenerować sygnały (poziomy) wygaszania poziomego i synchronizacji poziomej.
Tryby wykorzystujące DGF
Wykorzystując efekty DGF można uzyskać kilka nowych trybów graficznych na małym Atari. Większość z nich jest trybami interlace’owymi, gdzie jeden z dwóch półobrazów jest poziomo przesunięty o pół piksela w danej rozdzielczości względem drugiego. Dzięki temu uzyskujemy podwojenie rozdzielczości poziomej oraz zwiększenie liczby dostępnych kolorów bądź odcieni w wyniku mieszania się nakładających się połówek pikseli z obu półobrazów.
DGI – Delayed Gtia hires Interlace – tryb, który zademonstrowałem w demie KNIGHT. Charakteryzuje się rozdzielczością poziomą 320 pikseli (hires) przy standardowej szerokości pola. Powstaje przez naprzemienne wyświetlanie dwóch półobrazów w rozdzielczości poziomej 160 (lores), czyli w trybie ANTIC’a $0E lub $04 opcjonalnie podkolorowanych przy pomocy obiektów PMG. W jednym z półobrazów zastosowany jest efekt DPS2 dający przesunięcie o jeden piksel hires w lewo od pozycji normalnej.
DGI – ujęcie pierwsze (to jeszcze z wersji
na WAP-NIAK party z gotyckim fontem)
DGI – ujęcie drugie
Półobraz przesunięty w lewo o piksel
hires
Półobraz nieprzesunięty
DGX – Delayed Gtia cross(X) interlace – tryb będący kombinacją DGI i zwykłego pionowego interlace’u telewizyjnego (opracowanego dla Atari przez Rybagsa). W tym trybie linie półobrazów nie nakładają się, lecz występują naprzemian, a rozdzielczość pionowa jest podwojona. Widzimy piksele lores ułożone jak cegły w murze, czyli w jednej linii nieprzesunięte, w następnej przesunięte o połowę długości, w następnej znów nieprzesunięte itd. Tryb DGX został również zademonstrowany w demie KNIGHT. Wykorzystana grafika nie była jednak tworzona z myślą o takim sposobie wyświetlania więc użycie DGX nie powoduje tu poprawy jakości.
D9I – Delayed gtia9 Interlace – tryb charakteryzujący się rozdzielczością poziomą 160 pikseli przy standardowej szerokości pola. Powstaje przez naprzemienne wyświetlanie dwóch półobrazów w trybie GTIA9 czyli w rozdzielczości poziomej 80. W jednym z półobrazów zastosowany jest efekt DPS dający przesunięcie o jeden piksel lores w lewo od pozycji normalnej.
D10I – Delayed gtia10 Interlace – tryb charakteryzujący się rozdzielczością poziomą 160 pikseli przy standardowej szerokości pola. Powstaje przez naprzemienne wyświetlanie dwóch półobrazów w trybie GTIA10 czyli w rozdzielczości poziomej 80. W jednym z półobrazów zastosowany jest efekt DPS dający przesunięcie o jeden piksel lores w lewo od pozycji normalnej.
D9X – Delayed gtia9 cross(X) mode – tryb nieinterlace’owy polegający na tym, że wszystkie linie są wyświetlane w trybie GTIA9, a co druga jest przesunięta o pół piksela w prawo dzięki zastosowaniu efektu DGM (DG9). Piksele rozdzielczości poziomej 80 są ułożone jak cegły w murze, czyli w jednej linii nieprzesunięte, w następnej przesunięte o połowę długości, w następnej znów nieprzesunięte itd.
D10X – Delayed gtia10 cross(X) mode – tryb nieinterlace’owy polegający na tym, że wszystkie linie są wyświetlane w trybie GTIA10, a co druga jest przesunięta o pół piksela w prawo dzięki zastosowaniu efektu DGM (DG10). Piksele rozdzielczości poziomej 80 są ułożone jak cegły w murze.
D9XI – Delayed gtia9 cross(X) Interlace – tryb charakteryzujący się rozdzielczością poziomą 160 pikseli przy standardowej szerokości pola. Powstaje przez naprzemienne wyświetlanie dwóch półobrazów w trybie D9X, gdzie w jednym półobrazie linie parzyste są nieprzesunięte, a nieparzyste przesunięte o pół piksela w prawo. Natomiast w drugim półobrazie linie parzyste są przesunięte o pół piksela w prawo, a nieparzyste są nieprzesunięte. Tryb ten jest bardzo zbliżony do trybu HIP lecz tu we wszystkich liniach występuje tryb GTIA9. Jest to taki sam tryb jak VZI – VertiZontal Interlacing opracowany w 1994 roku przez Bryana.
D10XI – Delayed gtia10 cross(X) Interlace – tryb charakteryzujący się rozdzielczością poziomą 160 pikseli przy standardowej szerokości pola. Powstaje przez naprzemienne wyświetlanie dwóch półobrazów w trybie D10X na podobnej zasadzie jak tryb D9XI.
Programy
DGF INIT (DGFINIT.XEX) – program, który inicjuje efekty DGF przy rosnącej temperaturze układów GTIA i ANTIC według podanego wyżej opisu. Program mierzy również stabilność (dostępność) efektów DGF i podaje ją w procentach. Efekty DGF włącza przy pomocy zalecanego GTIA10 i wyniki pomiarów dotyczą efektów włączanych tą właśnie metodą. Efekty włączane przy pomocy np. GTIA9 mogą wciąż być niedostępne gdy program pokazuje 100%-ową stabilność. Do wykrywania aktywności DGF w danej linii program używa mechanizmu wykrywania kolizji obiektów PMG z grafiką obrazu. W chwili gdy efekty DGF osiągną 100%-ową stabilność włącza się dźwiękowy sygnał alarmowy oraz wyświetlony zostaje całkowity czas dochodzenia do stabilności. Sygnał trwa około 1 minuty i może być wyłączony wcześniej przez naciśnięcie dowolnego klawisza. Naciśnięcie B powoduje wyświetlenie grafiki tła używanej przez program przy inicjowaniu DGF i pozwala na obserwację zachowania się (pulsowania) poszczególnych linii ekranu w trakcie procesu stabilizacji DGF. Naciśnięcie Esc powoduje wyjście do DOSa.
Program DGF INIT w akcji. Stabilność efektów
DGF (DPS i DGM) osiągnęła 25%
Stabilność 100% osiągnięta po 6-ciu minutach
i 47-miu sekundach
Po naciśnięciu B można oglądać wyginanie się
obrazu w trakcie osiągania stabilizacji efektów DGF
DPS CHECK (DPSCHECK.XEX) – program, który sprawdza, czy efekt DPS (włączany przy pomocy zalecanego GTIA10) jest stabilny (dostępny) w 100%. Program nie posiada bloku RUNAD, a jego przeznaczeniem jest doklejanie na początku plików .xex będących programami wyświetlającymi grafiki w trybach korzystających z DPS. Jeżeli program wykryje, że DPS nie jest stabilny (dostępny) w 100% to wyświetli stosowny komunikat oraz natychmiast wróci do DOSa zapobiegając dalszemu ładowaniu się i uruchomieniu programu głównego.
DGM CHECK (DGMCHECK.XEX) – program, który sprawdza, czy efekt DGM (włączany przy pomocy zalecanego GTIA10) jest stabilny (dostępny) w 100%. Podobnie jak DPS CHECK program nie posiada bloku RUNAD, a jego przeznaczeniem jest doklejanie na początku plików .xex będących programami wyświetlającymi grafiki w trybach korzystających z DGM.
DGM G9 CHECK (DGMG9CHK.XEX) – program, który sprawdza, czy efekt DGM (włączany przy pomocy GTIA9) jest stabilny (dostępny) w 100%. Podobnie jak DPS CHECK program nie posiada bloku RUNAD, a jego przeznaczeniem jest doklejanie na początku plików .xex będących programami wyświetlającymi grafiki w trybach korzystających z DGM.
DGF DEMO – demo efektów DPS i DGM zastosowanych w trybach GTIA9 i GTIA10. Naciśnięcie spacji ujawnia ukryte ugięte części obrazu. Naciśnięcie Esc powoduje wyjście do DOSa. Polecam przejrzenie kodu źródłowego tego programu. W folderze Src\dgfmode znajdują się oddzielne pliki źródłowe dla efektów DPS, DG9 i DG10 oraz ich kombinacji.
DGF DEMO – efekty nieaktywne
DGF DEMO – efekty aktywne
DGF DEMO – widoczne ugięte części
obrazu
KNIGHT – demo trybów DGI i DGX wykorzystujące grafikę „Knight” autorstwa Tomasza „Levi” Lewandowskiego stworzoną dla C64 w trybie Interlaced FLI. Pozwala również wyświetlić samodzielnie oba półobrazy. Program wykrywa brak pełnej stabilności DGF i jeżeli taka sytuacja nastąpi blokuje możliwość wyświetlania trybów DGI i DGX, a także półobrazu z efektem DPS2, który wyświetlałby się nieprawidłowo ze względu na różnice w poziomych pozycjach obiektów PMG w co drugiej linii. Naciśnięcie 1 powoduje wyświetlenie tylko półobrazu przesuniętego o piksel hires w lewo, czyli tego z efektem DPS2, naciśnięcie 2 – tylko półobrazu bez przesunięcia, 3 – pełnego obrazu w trybie DGI, 4 i 5 – dwóch wariantów obrazu w trybie DGX (400i), które różnią się tym, który z półobrazów jest wyświetlany wyżej, a który niżej. Naciśnięcie spacji zatrzymuje płynący napis. Esc powoduje wyjście do DOSa.
CACTUVZI i FARMVZI – programy wyświetlające obrazki w trybie VZI (D9XI) opracowane przez Bryana. W programach tych do włączania efektu DGM używany jest tryb GTIA9, przez co na niektórych maszynach efekt będzie dość krótkotrwały (patrz akapit „Wpływ sposobów włączania efektów DGF na ich stabilność”). Do programów tych można dokleić na początku program DGMG9CHK.XEX w celu dodania mechanizmu wykrywania pełnej stabilności efektu DGM.
Wszystkie wymienione programy mojego autorstwa potrzebują nie więcej niż 48kB pamięci RAM i nie korzystają z pamięci RAM pod OS ROM, dzięki czemu mogą działać również na Atari 800. Programy działają zarówno na maszynach PAL jak i NTSC.
Ciekawe screenshoty
Poniżej zamieszczam kilka spośród licznych screenshotów zrobionych podczas prac nad DGF.
To już koniec
Opisane efekty DGF oraz powstałe z ich użyciem tryby graficzne nie mogą znaleźć poważnych zastosowań ze względu na ograniczoną dostępność (długi czas oczekiwania na samoistne rozgrzanie się układów graficznych, konieczność rozgrzewania tych układów, niewystępowanie efektów DGF w niektórych egzemplarzach Atari). Uważam jednak, że warto było zbadać i opisać zjawisko DGF, po prostu po to, żeby je poznać i wyjaśnić jedną z bardziej skrywanych tajemnic Atari. Ponadto oglądanie trybu DGI – hiresu z mnóstwem kolorów na standardowym Atari przyniosło mi ogromną radość i choćby tylko dla tego trybu warto było takie badania przeprowadzić.
Tym, którzy chcieliby zobaczyć opisane efekty, a obawiają się tak drastycznych metod podgrzewania Atari jak przy użyciu suszarki, polecam włączać komputer w upalne letnie dni. Komputer samoczynnie rozgrzeje się do wymaganej temperatury w około 30 minut. Oczywiście przy włączonym programie DGF INIT. W chłodniejszych porach roku proponuję ustawić Atari w pobliżu kaloryfera, a jeśli ktoś dysponuje własnym CO to również zaaplikować przysłowiowe „więcej węgla”.
Pliki do ściągnięcia: DGF_demo_ATR.zip oraz plik ze źródłami DGF_sources.zip.
Na naszym forum jest też wątek dotyczący zagadnienia DGF.
tdc 2013-02-23 15:55:32
Czapki z głów !
Tezz 2013-02-23 17:17:28
Ditto! Glad to finally read the full details about these findings
xxl 2013-02-23 17:36:24
niesamowite. swietny artykul. brawo Pavros.
fajnie by bylo gdyby na aonline czesciej pojawialy sie tego typu publikacje
adv 2013-02-23 17:52:46
Jeszcze nie czytałem, ale widzę, że jest to profesjonalna publikacja o genialnym - co czytałem wcześniej - zastosowaniu.
eagle 2013-02-23 18:23:22
Teraz czekam na rozszerzenie do atarki - podgrzewacz gtia.
Mój preorder 2szt ;)
Joe Iron 2013-02-23 18:51:46
I can't go above 0% in DGINIT :(
tdc 2013-02-23 19:08:37
Pisałem jakiś czas temu, że uwielbiam czytać i pisać o takich zagadnieniach, dawno nie miałem okazji poczytać czegoś, teraz mam tę frajdę - dzięki Pavros!;)
@xxl, a jak chyba rok temu prosiłem abyś napisał jakiś techniczny tekst na AOL to nie chciałeś - pomyśl jak wszyscy będą myśleć tak jak Ty to nie będzie się pojawiać więcej takich fajnych technicznych artykułów.
To jak napiszesz coś ?
brx 2013-02-23 20:46:02
Szacunek za ogromną pracę włożoną w opisanie i testowanie w sumie zupełnie nieużytecznego trybu :(
xxl 2013-02-23 21:26:03
@tdc: raczej nie, kiepsko pisze to raz a dwa zajmuje sie teraz tutorialami ;-)
tdc 2013-02-24 03:30:31
He he to tak jakbyś napisał że kiepski jestem z pisania spisów treści bo na co dzień pisuję książki a nie spisy :P
Aby nie naciskać na Ciebie, to do wszystkich powiem aby się nie obawiać, jeśli ktokolwiek ma coś ciekawego do zaprezentowania, opisania to proszę się nie przejmować, oferujemy wsparcie techniczne, redaktorskie, jakoś sobie wspólnymi siłami poradzimy;)
tdc 2013-02-24 03:56:37
> zasada jest ta sama co w trybie HIP. Tu jednak możliwe jest mieszanie linii w GTIA9 z przesuniętą o piksel lores linią w GTIA9.
Czyli będzie to tryb HIP+ który będzie miał jeszcze więcej odcieni niż HIP, który i tak ma ich multum jak na komputer 8-bitowy.
jhusak 2013-02-24 09:53:39
Peltier odwrotnie + radiator :) Będzie grzał :)
pin 2013-02-24 11:00:24
... no.. 10 minut grzania i 40% ;)
pin 2013-02-24 11:16:32
Knight ładnie stabilnie mi się wyświetlił ;)
.. ale te dwa obrazki w trybie VZI w żaden sposób poprawnie się nie wyświetlają.
pin 2013-02-24 13:33:04
Testowałem na XEGS (tu siedzi także VBXE), niestety tu już nie jest aż tak "kolorowo" :D. DGF_INIT rozgrzał Antica do czerwoności, lecz program cały czas twierdzi, że to 0% temperatury (około 30 minut już jakoś). Temperatury GTIA nie jestem wstanie stwierdzić, bo poprzez gąszcz dopałek nie mam nawet wizualnego kontaktu z układem :D
adv 2013-02-24 14:51:29
Dobrze powiedziane - znaczy - napisane. To tak ogólnie, bo widać, że xxl kończy gierki, dopracowuje xBiosa, pisze tutoriale - to przecież masa pracy. Pisanie z czasem przyjdzie, cenniejsza jest robota, która przynosi wymierne efekty w postaci programów. Bardzo dobrych z resztą.
pin 2013-02-24 16:02:08
ok - ta grafika z kakatusem :) .. odpaliła jak do pliku DGMG9CHK dołączyłem plik z gfx
Kaz 2013-02-25 00:45:59
Swietnie napisane Pavros! Czyta sie z zapartym tchem, jak kryminal, w ktorym jestesmy ciekawi, czy ten GTIA zabije, czy zabiją jego :). Naprawde, ciezki technicznie tekst, ale przeczytalem calosc z duza uwaga, gratuluje umiejetnosci wyrazania mysli.
Do tego szacunek za ogrom pracy, jaki trzeba bylo wlozyc, zeby TAK to opisac.
andys 2013-02-25 10:21:09
hmmm. czyli jednym slowem mowiac odkrywane efekty atari sa raczej niedostosowaniem sie do norm oraz wszelkich kryteriow jakimi sie okazywali. wliczajac nawet w to gwarancje. uklady nieprzystosowane oraz nieodprowadzano cieplo. nie umiejszam teraz odkrywanych feature, ale mowie o nieudolnosci atari w tamtych latach.
0xF 2013-02-25 11:11:01
Pasjonująca lektura. Widzę w tym temacie jeszcze sporo do zbadania: które chipy są bardziej podatne, jak można szybciej osiągnąć efekt, wytłumaczyć go na podstawie już dostępnych schematów.
pavros 2013-02-25 17:35:22
@pin: Jak pisałem w artykule, te obrazki Bryana w trybie VZI włączają DGM przy pomocy wartośći $40 (GTIA9). Taki sposób wymaga wyższej temperatury niż przy użyciu $80 (GTIA10) co ja zalecam. DGF INIT sprawdza stabilność efektu włączanego przez $80. Czyli DGF INIT pokazuje 100% dla $80 ale dla $40 wciąż jest za mało. Pewnie zanim skleiłeś plik obrazka z DGMG9CHK.XEX to już temperatura doszła do wymaganej.
A w ogóle to super, że udało ci się odpalić rycerza. Kolejna atarka, która może :-).
@0xF: Właśnie uświadomiłem sobie, że nie zbadałem, czy wraz z uaktywnieniem DPS nie zmieniają się granice HBLANK (i czy obie). Jeżeli tak jest, to załuję, że nie wpadłem na to wcześniej, bo to by uprościło wykrywanie aktywności DPSa (teraz wymaga odpowiednich danych grafiki, a tak to by sie dwa PMG ustawiło i sprawdziło czy kolizja się wykrywa, niezależnie od grafiki).
Tak, to jest jak studnia bez dna, jeśli chodzi o możliwe badania.
pavros 2013-02-25 21:09:23
Chociaż ... Tak się chyba nie da wykrywać, bo przecież PMG też się przesuwają.
tdc 2013-02-26 00:24:25
@andys
Może wyjaśnię te zawiłości techniczne. Po pierwsze Tobie odpowiem, że nie efekty w liczbie mnogiej, a dopiero co odkryty DGF. O ile wiem zjawisko opisane przez Pavrosa, jest pierwszym tego typu w całej historii informatyki.
Oczywiście sprzęt elektroniczny, nawet ten cyfrowy był produkowany jak był w latach 70. czy 80. Inne możliwości i inna wiedza, dziś się pod tym względem lepiej konstruuje czy projektuje i chyba nie ma co tego rozwijać.
Różnego rodzaju niedorobienia, błędy konstrukcyjne czy nieprawidłowe działanie było wtedy bardzo powszechne, jeśliby się dobrze przyjrzeć np. ZXom, Commodore'om, Amstradom, Sharpom itp. to też można tam dostrzec wiele nieprawidłowych zachowań różnych układów czy sygnałów na wyjściu (choć inna sprawa, że komputery konkurencji były wyposażone w mniejszą ilość układów, które można badać).
Przykładowo jedna z rodzin komputerów Atari STE miała poważny błąd konstrukcyjny i przetworniki C/A generowały niby dobry sygnał, ale miał on słyszalne zaszumienia i to takie bardzo specyficznie brzmiące, za to już model Mega STE skonstruowany z tych samych podzespołów, a nawet posiadający dodatkowe możliwości, był tej wady pozbawiony.
Fatalnie sytuacja się przedstawiała w latach 80. jeśli chodzi o pierwsze pecetowe karty graficzne. Właściwie żaden model nie był pozbawiony poważnych wad konstrukcyjnych, które uniemożliwiały zastosowanie tych kart w poważniejszych zastosowaniach (choćby dobre GUI, nawet jeśliby starczało wydajności, której nie starczało). Przykładowo karta EGA, miała błąd który bardzo prosto można sprawdzić matematycznie, więc to spora porażka dla projektantów tego modelu. Chciałbym też zwrócić uwagę na to, że wtedy pecetowe karty graficzne produkował IBM, czyli firma przez wielu uznawana za najlepszą (i największą) firmę komputerową świata.
Jeszcze ciekawiej jest w Commodore PET (lata 70.), gdzie znany jest myk z tzw. "Killer poke". Dowcip polega na tym, że rejestr, który przyspieszał wyświetlanie w pierwszych modelach, w następnych uszkadzał monitor czyli faktycznie cały komputer.
Dziś temat jest uznawany za fajną ciekawostkę, ale kiedyś to był fatalny błąd, bo co innego gdyby sprzęt był uszkadzany przez dziwne ustawienia, których nikt nie znał, a co innego gdy uszkodzenia dokonywała spora ilość programów.
Wracając do DGF, sprawa jest bardzo ciekawa, dlatego że tym razem Pavros zaobserwował ciekawe zjawisko (które bezsprzecznie nie jest prawidłowym działaniem układów elektronicznych), które po pierwsze jakimś cudem dochodzi do stanu ustalonego – to bardzo cenne. Po drugie można programowo sprawdzić, czy zjawisko to zachodzi już w 100% czy nie - to jest właściwie bezcenne.
Odnośnie pierwszego, nietrudno sobie wyobrazić jakieś zakłócenia w pracy układów dowolnego komputera, ale aby można je było sensownie wykorzystać, trzeba mieć jakiś stan ustalony, albo 0 albo 1. W przeciwnym wypadku, zabawa będzie utrudniona i nieco skazana na porażkę, choć jestem wstanie sobie wyobrazić zapaleńców, którzy mimo to obwieszczają całemu światu, że odkryli coś nowego/ciekawego.
Tu przypomina mi się np. jak przegrzewające się 286 sąsiada, powodowało zacinanie się gier takich jak Prince of Persia, wtedy ten brał baterię R20 wsadzał na chwilę do zamrażalnika, a potem stawiał ją na procesorze :P
Nie trudno sobie wyobrazić to w drugą stronę, gdy ktoś robi coś, aby jakiś układ zaczął się zachowywać w nietypowy sposób. To oczywiście ze wszech miar możliwe.
Odnośnie drugiego punktu to sytuacja jest już absolutnie unikalna. Jeśli przykładowo na ZX Spectrum odkryto by jakieś odchylenia obrazu po nagrzaniu się jego (a ten to się dopiero grzał, można go używać jako podgrzewacza Atari :P) to tam nie ma możliwości sprzętowych, aby programowo sprawdzić, czy efekt już zaistniał i w jakim stopniu. Oczywiście można próbować jakoś ten problem ominąć, no ale o takim eleganckim rozwiązaniu jak Pavrosa to można wtedy zapomnieć.
Myślę, że taki problem istnieje na wielu innych platformach, że o ile coś zaobserwujemy to możliwości detekcji tego zjawiska będą bliskie zeru. W małym Atari sytuacja jest inna bo jak pisałem wcześniej komputer ten składa się ze sporej ilości oddzielnych specjalizowanych układów elektronicznych (o czym świadczy np. odtwarzanie muzyki przez xxla za pomocą układu graficznego itp.) i potencjał możliwości jest o wiele większy. Prawie z roku na rok, coś jest odkrywane, a przecież komputer ma już kilkadziesiąt lat za sobą !
tdc 2013-02-26 01:43:08
@adv, oczywiście. Jednak ja wychodzę z założenia, że prawie nikt się nie zajmuje tym co xxl, więc jak On nie napisze artykułu to nikt nie napisze. Warto aby napisał coś o tym co robi, jaki techniki koderskie wykorzystuje, jakie problemy są typowe, właściwie niewiele o tym wiemy. Dlatego myślę że jak napisze jeden fajny artykuł na rok, dwa a nawet trzy lata to chyba nic się nie stanie, a dojdzie nam jeszcze jeden ciekawy artykuł.
andys 2013-02-26 08:17:07
Twoj post ciekawszy o wiele niz sam artykul (dla mnie). Dziekuje za wyjasnienia konkretne i rzeczowe. Co do atari to od dziecinstwa pamietam, ze jak byl goracy to artefakty lataly po ekranie wiec stad pomyslalem tym efekcie. chyba tylko jeszcze apple mial takie rzeczy z wyswietlaniem.
adv 2013-02-26 16:22:51
Tdc szkoda, że nie wypuściłeś swojego wpisu jako nowinkę poprzedzającą-zapowiedź do tej nowinki. Mnie też wiele powiedziało.
tdc 2013-03-07 03:22:16
Dzięki chłopaki.
Ja wychodzę z założenia, że nie należy nic dopisywać do artykułów gdyż to autor ma zaspokoić Wasze wymagania ;) Choć oczywiście siłą rzeczy trudno jest autorowi wyczerpać wszystkie zagadnienia, co jest naturalne. Dlatego warto aby artykuły tworzyło kilka osób oraz od strony redakcji aby kilka osób w niej aktywnie uczestniczyło bo każdy od siebie doda coś cennego.
Jednak ja nie lubię w ten sposób wchodzić komuś w paradę i nawet niekoniecznie chodzi o to że to co jeden z nich napisze będzie lepsze czy też gorsze, po prostu myślę że od tego są nasze komentarze.
To że dodałem mały wstęp do tego artykułu podyktowane było jedynie tradycją, którą zapoczątkował kiedyś Kaz. Teraz jedynie ją kultywuję, a to czy dany tekst faktycznie potrzebuje aby coś do niego dodać, to oczywiście różnie z tym bywa, jednak wydaje mi się że dodatkowe opinie wprowadziłyby niepotrzebny zamęt. W mojej ocenie z jednej strony można dodawać komentarze, a z drugiej nic nie stoi na przeszkodzie aby dany temat ktoś (może ja) opisał w odrębnym artykule, wtedy można poznać inne spojrzenie na ten sam temat innego autora i również Wy możecie to komentować.
Zrobiliśmy też kiedyś eksperyment z Urborgiem i trzecią część cyklu o Archonie potraktowaliśmy jako coś w rodzaju zderzenia dwóch autorów, co też niektórzy odebrali jako coś im obcego.
Ogólnie jest to kwestia podejścia, czasami musu.
> jak byl goracy to artefakty lataly po ekranie wiec stad pomyslalem tym efekcie
Potrafię sobie to wyobrazić ;) Choć ja pamiętam że artefakty zwykle zależały od TV/monitora jaki ktoś posiadał. Przykładowo najczystszy obraz był na monitorach czarnobiałych/zielonych, a najwięcej artefaktów na TV i to tych kolorowych. Przykładowo kwestia cieńszych linii parzystych i nieparzystych w 8 trybie bardzo różnie wyglądało u każdego z moich kolegów. Np. u jednego cienkie linie wydawały się być zielone u innego niebieskie. U jeszcze innego niektóre z nich pulsowały, a inne nie. Ciężka sprawa :P
Jednak nie zauważyłem tutaj zależności od nagrzania się któregokolwiek z nich - choć być może coś takiego zachodziło.
Ogólnie im gorszy ktoś miał TV kolorowy tym więcej i to czasami naprawdę dziwacznych rzeczy się działo z obrazem.
> chyba tylko jeszcze apple mial takie rzeczy z wyswietlaniem.
Jak macie jakieś ciekawe linki w tym temacie (z różnych komputerów) to nie krępujcie się ;)
bratek 2013-05-20 22:40:02
Trzeba sprawdzic jak bardzo emulator atari jest kompatybilny z pierwowzorem ;-) .Probowal juz ktos?
Czapki z głów !
Tezz 2013-02-23 17:17:28
Ditto! Glad to finally read the full details about these findings
xxl 2013-02-23 17:36:24
niesamowite. swietny artykul. brawo Pavros.
fajnie by bylo gdyby na aonline czesciej pojawialy sie tego typu publikacje
adv 2013-02-23 17:52:46
Jeszcze nie czytałem, ale widzę, że jest to profesjonalna publikacja o genialnym - co czytałem wcześniej - zastosowaniu.
eagle 2013-02-23 18:23:22
Teraz czekam na rozszerzenie do atarki - podgrzewacz gtia.
Mój preorder 2szt ;)
Joe Iron 2013-02-23 18:51:46
I can't go above 0% in DGINIT :(
tdc 2013-02-23 19:08:37
Pisałem jakiś czas temu, że uwielbiam czytać i pisać o takich zagadnieniach, dawno nie miałem okazji poczytać czegoś, teraz mam tę frajdę - dzięki Pavros!;)
@xxl, a jak chyba rok temu prosiłem abyś napisał jakiś techniczny tekst na AOL to nie chciałeś - pomyśl jak wszyscy będą myśleć tak jak Ty to nie będzie się pojawiać więcej takich fajnych technicznych artykułów.
To jak napiszesz coś ?
brx 2013-02-23 20:46:02
Szacunek za ogromną pracę włożoną w opisanie i testowanie w sumie zupełnie nieużytecznego trybu :(
xxl 2013-02-23 21:26:03
@tdc: raczej nie, kiepsko pisze to raz a dwa zajmuje sie teraz tutorialami ;-)
tdc 2013-02-24 03:30:31
He he to tak jakbyś napisał że kiepski jestem z pisania spisów treści bo na co dzień pisuję książki a nie spisy :P
Aby nie naciskać na Ciebie, to do wszystkich powiem aby się nie obawiać, jeśli ktokolwiek ma coś ciekawego do zaprezentowania, opisania to proszę się nie przejmować, oferujemy wsparcie techniczne, redaktorskie, jakoś sobie wspólnymi siłami poradzimy;)
tdc 2013-02-24 03:56:37
> zasada jest ta sama co w trybie HIP. Tu jednak możliwe jest mieszanie linii w GTIA9 z przesuniętą o piksel lores linią w GTIA9.
Czyli będzie to tryb HIP+ który będzie miał jeszcze więcej odcieni niż HIP, który i tak ma ich multum jak na komputer 8-bitowy.
jhusak 2013-02-24 09:53:39
Peltier odwrotnie + radiator :) Będzie grzał :)
pin 2013-02-24 11:00:24
... no.. 10 minut grzania i 40% ;)
pin 2013-02-24 11:16:32
Knight ładnie stabilnie mi się wyświetlił ;)
.. ale te dwa obrazki w trybie VZI w żaden sposób poprawnie się nie wyświetlają.
pin 2013-02-24 13:33:04
Testowałem na XEGS (tu siedzi także VBXE), niestety tu już nie jest aż tak "kolorowo" :D. DGF_INIT rozgrzał Antica do czerwoności, lecz program cały czas twierdzi, że to 0% temperatury (około 30 minut już jakoś). Temperatury GTIA nie jestem wstanie stwierdzić, bo poprzez gąszcz dopałek nie mam nawet wizualnego kontaktu z układem :D
adv 2013-02-24 14:51:29
quote:Tdc:tak jakbyś napisał kiepski jestem z pisania spisów treści bo na co dzień pisuję książki a nie spisy
Dobrze powiedziane - znaczy - napisane. To tak ogólnie, bo widać, że xxl kończy gierki, dopracowuje xBiosa, pisze tutoriale - to przecież masa pracy. Pisanie z czasem przyjdzie, cenniejsza jest robota, która przynosi wymierne efekty w postaci programów. Bardzo dobrych z resztą.
pin 2013-02-24 16:02:08
ok - ta grafika z kakatusem :) .. odpaliła jak do pliku DGMG9CHK dołączyłem plik z gfx
Kaz 2013-02-25 00:45:59
Swietnie napisane Pavros! Czyta sie z zapartym tchem, jak kryminal, w ktorym jestesmy ciekawi, czy ten GTIA zabije, czy zabiją jego :). Naprawde, ciezki technicznie tekst, ale przeczytalem calosc z duza uwaga, gratuluje umiejetnosci wyrazania mysli.
Do tego szacunek za ogrom pracy, jaki trzeba bylo wlozyc, zeby TAK to opisac.
andys 2013-02-25 10:21:09
hmmm. czyli jednym slowem mowiac odkrywane efekty atari sa raczej niedostosowaniem sie do norm oraz wszelkich kryteriow jakimi sie okazywali. wliczajac nawet w to gwarancje. uklady nieprzystosowane oraz nieodprowadzano cieplo. nie umiejszam teraz odkrywanych feature, ale mowie o nieudolnosci atari w tamtych latach.
0xF 2013-02-25 11:11:01
Pasjonująca lektura. Widzę w tym temacie jeszcze sporo do zbadania: które chipy są bardziej podatne, jak można szybciej osiągnąć efekt, wytłumaczyć go na podstawie już dostępnych schematów.
pavros 2013-02-25 17:35:22
@pin: Jak pisałem w artykule, te obrazki Bryana w trybie VZI włączają DGM przy pomocy wartośći $40 (GTIA9). Taki sposób wymaga wyższej temperatury niż przy użyciu $80 (GTIA10) co ja zalecam. DGF INIT sprawdza stabilność efektu włączanego przez $80. Czyli DGF INIT pokazuje 100% dla $80 ale dla $40 wciąż jest za mało. Pewnie zanim skleiłeś plik obrazka z DGMG9CHK.XEX to już temperatura doszła do wymaganej.
A w ogóle to super, że udało ci się odpalić rycerza. Kolejna atarka, która może :-).
@0xF: Właśnie uświadomiłem sobie, że nie zbadałem, czy wraz z uaktywnieniem DPS nie zmieniają się granice HBLANK (i czy obie). Jeżeli tak jest, to załuję, że nie wpadłem na to wcześniej, bo to by uprościło wykrywanie aktywności DPSa (teraz wymaga odpowiednich danych grafiki, a tak to by sie dwa PMG ustawiło i sprawdziło czy kolizja się wykrywa, niezależnie od grafiki).
Tak, to jest jak studnia bez dna, jeśli chodzi o możliwe badania.
pavros 2013-02-25 21:09:23
Chociaż ... Tak się chyba nie da wykrywać, bo przecież PMG też się przesuwają.
tdc 2013-02-26 00:24:25
@andys
Może wyjaśnię te zawiłości techniczne. Po pierwsze Tobie odpowiem, że nie efekty w liczbie mnogiej, a dopiero co odkryty DGF. O ile wiem zjawisko opisane przez Pavrosa, jest pierwszym tego typu w całej historii informatyki.
Oczywiście sprzęt elektroniczny, nawet ten cyfrowy był produkowany jak był w latach 70. czy 80. Inne możliwości i inna wiedza, dziś się pod tym względem lepiej konstruuje czy projektuje i chyba nie ma co tego rozwijać.
Różnego rodzaju niedorobienia, błędy konstrukcyjne czy nieprawidłowe działanie było wtedy bardzo powszechne, jeśliby się dobrze przyjrzeć np. ZXom, Commodore'om, Amstradom, Sharpom itp. to też można tam dostrzec wiele nieprawidłowych zachowań różnych układów czy sygnałów na wyjściu (choć inna sprawa, że komputery konkurencji były wyposażone w mniejszą ilość układów, które można badać).
Przykładowo jedna z rodzin komputerów Atari STE miała poważny błąd konstrukcyjny i przetworniki C/A generowały niby dobry sygnał, ale miał on słyszalne zaszumienia i to takie bardzo specyficznie brzmiące, za to już model Mega STE skonstruowany z tych samych podzespołów, a nawet posiadający dodatkowe możliwości, był tej wady pozbawiony.
Fatalnie sytuacja się przedstawiała w latach 80. jeśli chodzi o pierwsze pecetowe karty graficzne. Właściwie żaden model nie był pozbawiony poważnych wad konstrukcyjnych, które uniemożliwiały zastosowanie tych kart w poważniejszych zastosowaniach (choćby dobre GUI, nawet jeśliby starczało wydajności, której nie starczało). Przykładowo karta EGA, miała błąd który bardzo prosto można sprawdzić matematycznie, więc to spora porażka dla projektantów tego modelu. Chciałbym też zwrócić uwagę na to, że wtedy pecetowe karty graficzne produkował IBM, czyli firma przez wielu uznawana za najlepszą (i największą) firmę komputerową świata.
Jeszcze ciekawiej jest w Commodore PET (lata 70.), gdzie znany jest myk z tzw. "Killer poke". Dowcip polega na tym, że rejestr, który przyspieszał wyświetlanie w pierwszych modelach, w następnych uszkadzał monitor czyli faktycznie cały komputer.
Dziś temat jest uznawany za fajną ciekawostkę, ale kiedyś to był fatalny błąd, bo co innego gdyby sprzęt był uszkadzany przez dziwne ustawienia, których nikt nie znał, a co innego gdy uszkodzenia dokonywała spora ilość programów.
Wracając do DGF, sprawa jest bardzo ciekawa, dlatego że tym razem Pavros zaobserwował ciekawe zjawisko (które bezsprzecznie nie jest prawidłowym działaniem układów elektronicznych), które po pierwsze jakimś cudem dochodzi do stanu ustalonego – to bardzo cenne. Po drugie można programowo sprawdzić, czy zjawisko to zachodzi już w 100% czy nie - to jest właściwie bezcenne.
Odnośnie pierwszego, nietrudno sobie wyobrazić jakieś zakłócenia w pracy układów dowolnego komputera, ale aby można je było sensownie wykorzystać, trzeba mieć jakiś stan ustalony, albo 0 albo 1. W przeciwnym wypadku, zabawa będzie utrudniona i nieco skazana na porażkę, choć jestem wstanie sobie wyobrazić zapaleńców, którzy mimo to obwieszczają całemu światu, że odkryli coś nowego/ciekawego.
Tu przypomina mi się np. jak przegrzewające się 286 sąsiada, powodowało zacinanie się gier takich jak Prince of Persia, wtedy ten brał baterię R20 wsadzał na chwilę do zamrażalnika, a potem stawiał ją na procesorze :P
Nie trudno sobie wyobrazić to w drugą stronę, gdy ktoś robi coś, aby jakiś układ zaczął się zachowywać w nietypowy sposób. To oczywiście ze wszech miar możliwe.
Odnośnie drugiego punktu to sytuacja jest już absolutnie unikalna. Jeśli przykładowo na ZX Spectrum odkryto by jakieś odchylenia obrazu po nagrzaniu się jego (a ten to się dopiero grzał, można go używać jako podgrzewacza Atari :P) to tam nie ma możliwości sprzętowych, aby programowo sprawdzić, czy efekt już zaistniał i w jakim stopniu. Oczywiście można próbować jakoś ten problem ominąć, no ale o takim eleganckim rozwiązaniu jak Pavrosa to można wtedy zapomnieć.
Myślę, że taki problem istnieje na wielu innych platformach, że o ile coś zaobserwujemy to możliwości detekcji tego zjawiska będą bliskie zeru. W małym Atari sytuacja jest inna bo jak pisałem wcześniej komputer ten składa się ze sporej ilości oddzielnych specjalizowanych układów elektronicznych (o czym świadczy np. odtwarzanie muzyki przez xxla za pomocą układu graficznego itp.) i potencjał możliwości jest o wiele większy. Prawie z roku na rok, coś jest odkrywane, a przecież komputer ma już kilkadziesiąt lat za sobą !
tdc 2013-02-26 01:43:08
@adv, oczywiście. Jednak ja wychodzę z założenia, że prawie nikt się nie zajmuje tym co xxl, więc jak On nie napisze artykułu to nikt nie napisze. Warto aby napisał coś o tym co robi, jaki techniki koderskie wykorzystuje, jakie problemy są typowe, właściwie niewiele o tym wiemy. Dlatego myślę że jak napisze jeden fajny artykuł na rok, dwa a nawet trzy lata to chyba nic się nie stanie, a dojdzie nam jeszcze jeden ciekawy artykuł.
andys 2013-02-26 08:17:07
Twoj post ciekawszy o wiele niz sam artykul (dla mnie). Dziekuje za wyjasnienia konkretne i rzeczowe. Co do atari to od dziecinstwa pamietam, ze jak byl goracy to artefakty lataly po ekranie wiec stad pomyslalem tym efekcie. chyba tylko jeszcze apple mial takie rzeczy z wyswietlaniem.
adv 2013-02-26 16:22:51
Tdc szkoda, że nie wypuściłeś swojego wpisu jako nowinkę poprzedzającą-zapowiedź do tej nowinki. Mnie też wiele powiedziało.
tdc 2013-03-07 03:22:16
Dzięki chłopaki.
Ja wychodzę z założenia, że nie należy nic dopisywać do artykułów gdyż to autor ma zaspokoić Wasze wymagania ;) Choć oczywiście siłą rzeczy trudno jest autorowi wyczerpać wszystkie zagadnienia, co jest naturalne. Dlatego warto aby artykuły tworzyło kilka osób oraz od strony redakcji aby kilka osób w niej aktywnie uczestniczyło bo każdy od siebie doda coś cennego.
Jednak ja nie lubię w ten sposób wchodzić komuś w paradę i nawet niekoniecznie chodzi o to że to co jeden z nich napisze będzie lepsze czy też gorsze, po prostu myślę że od tego są nasze komentarze.
To że dodałem mały wstęp do tego artykułu podyktowane było jedynie tradycją, którą zapoczątkował kiedyś Kaz. Teraz jedynie ją kultywuję, a to czy dany tekst faktycznie potrzebuje aby coś do niego dodać, to oczywiście różnie z tym bywa, jednak wydaje mi się że dodatkowe opinie wprowadziłyby niepotrzebny zamęt. W mojej ocenie z jednej strony można dodawać komentarze, a z drugiej nic nie stoi na przeszkodzie aby dany temat ktoś (może ja) opisał w odrębnym artykule, wtedy można poznać inne spojrzenie na ten sam temat innego autora i również Wy możecie to komentować.
Zrobiliśmy też kiedyś eksperyment z Urborgiem i trzecią część cyklu o Archonie potraktowaliśmy jako coś w rodzaju zderzenia dwóch autorów, co też niektórzy odebrali jako coś im obcego.
Ogólnie jest to kwestia podejścia, czasami musu.
> jak byl goracy to artefakty lataly po ekranie wiec stad pomyslalem tym efekcie
Potrafię sobie to wyobrazić ;) Choć ja pamiętam że artefakty zwykle zależały od TV/monitora jaki ktoś posiadał. Przykładowo najczystszy obraz był na monitorach czarnobiałych/zielonych, a najwięcej artefaktów na TV i to tych kolorowych. Przykładowo kwestia cieńszych linii parzystych i nieparzystych w 8 trybie bardzo różnie wyglądało u każdego z moich kolegów. Np. u jednego cienkie linie wydawały się być zielone u innego niebieskie. U jeszcze innego niektóre z nich pulsowały, a inne nie. Ciężka sprawa :P
Jednak nie zauważyłem tutaj zależności od nagrzania się któregokolwiek z nich - choć być może coś takiego zachodziło.
Ogólnie im gorszy ktoś miał TV kolorowy tym więcej i to czasami naprawdę dziwacznych rzeczy się działo z obrazem.
> chyba tylko jeszcze apple mial takie rzeczy z wyswietlaniem.
Jak macie jakieś ciekawe linki w tym temacie (z różnych komputerów) to nie krępujcie się ;)
bratek 2013-05-20 22:40:02
Trzeba sprawdzic jak bardzo emulator atari jest kompatybilny z pierwowzorem ;-) .Probowal juz ktos?