Jak to w zasadzie ATARI produkuje obraz, normalnie linie parzyste o potem to samo na liniach nieparzystych? Czy zawsze tylko linie parzyste? Jeżeli parzyste i nieparzyste to wiadomo, które aktualnie lecą?
To nie samo w sobie Atari a standard TV. Jeżeli masz klasyczny CRT z i "interlaced czyli przeplot" to najpierw masz linie nieparszyte a potem parzyste. Tak więc 50Hz to 25fps bo obraz złożony jest co drugi cykl. A w NTSC to 60Hz czuli 30fps stąd te lepsze poczucie płynności obrazu :)
Sygnał TV z przeplotem polega na wyświetlaniu dwóch półobrazów na "ramkę" 25 Hz, z czego jeden jest przesunięty o pół linii w czasie, więc renderowanie tej linii odbywa się pół linii niżej.
Ale - jak nie zrobi się tego opóźnienia pół linii (Atari w standardzie tego nie robi, ani C64, ani Spectrum, tylko Amiga ma tę możliwość) - to wyświetlamy 2 "pół"obrazy w tym samym miejscu, de facto jak zwał tak zwał, ale po prostu mamy 50 obrazów na sekundę w 50Hz.
Tak naprawdę monitor/TV nie wyświetla "dwóch półobrazów w 25Hz (bo to tylko prosta elektronika przekształcająca liniowy w czasie sygnał video na prostokątny w wyglądzie obraz zawijając linie), tylko to, co mu tam wrzucimy w 50Hz. To tylko to opóźnienie pół linii co drugą ramkę powoduje interlace i zwiększenie rozdzielczości w pionie.
Tak więc nie ma czegoś takiego, jak linie parzyste czy nieparzyste w sygnale video z Atari. Atari po prostu renderuje kolejne linie z pamięci.
Stąd częste artefakty w przypadku filmów 25Hz wyświetlanych z przeplotem. Powinno być tak, że ramka składa się z lini nieparzystych danego kadru, następnie parzystych tego samego kadru. Niestety, w wyniku ww właściwości, że TV to 50 Hz, a film to 25 Hz zdarza się (raz na 2 razy), że te ramki się przesuną o 1 i mamy przy sczytywaniu 25Hz grabberem w jednym kadrze linie z dwóch kolejnych kadrów, co się nie nadaje za bardzo do oglądania.
Hm. Atari produkuje linie. Możesz je nazwać jak chcesz. One są w miejscu nieparzystych linii (1,3,5,itd) na ekranie, ale generowane są fizycznie 1,2,3,4, itd.
Przecież piszę, że dla nieparzystych. Tzn. bez opóźnienia 0.5 linii.
Ale - jak piszę - te parzyste i nieparzyste to umowa. Jest Vsync, jest czas do pierwszego hsync i to ten się zmienia o pół linii. Reszta jest identyczna (w sensie przebiegów i zależności czasowych), aż do następnego Vsync.
Mają prawo, aczkolwiek _chyba_ one (grabbery) dobrze zbierają sygnał interlaced (większość z nich). Wiedzą, która ramka jest nieparzysta, a która parzysta. Przy montażu na pulpicie video nie ma to znaczenia, jeśli sygnał jest 50Hz z przeplotem. Gorzej, jak jest 25Hz i 2 półobrazy są takie same - wtedy w wyniku grabberowania mogą trafić 2 różne półobrazy do jednej ramki 25Hz. Dlatego ja zgrywam video z kaset w DV, 50 Hz z przeplotem i konwertuję na taki mp4 - 50 Hz z przeplotem (o ile dobrze pamiętam, to tak).
Czterej pancerni wydani na DVD tak mają - niektóre sceny są dobrze, a niektóre przesunięte o tę jedną ramkę i zakodowane znowu. Przy zgrywaniu mamy właśnie kadr złożony z dwóch sąsiednich.
Ale dalej mi coś tu nie gra. Avery Lee w "Altirra Hardware Reference Manual" podaje na stronie 135 tabelę PAL GTIA dla "Even lines" i "Odd lines". To by oznaczało, że ATARI produkuje dwa półobrazy?
Edit: A dobra już wiem. Z punktu widzenia całego pola obrazu to ATARI produkuje pola z liniami nieparzystymi. W ramach tych pól linie oczywiście maja negowaną fazę koloru jak to w PAL. ATARI robi to tak jak umie i jak opisuje Lee.
Czyli dedykowany konwerter dla ATARI SVIDEO->DVI w zasadzie powinien wystawić 576p. Jeżeli tylko monitor/TV łyknie 576p to można mu zrobić obraz wręcz idealny.
Sygnał koloru w ATARI to jest w zasadzie sygnał cyfrowy. Poszli na łatwiznę i wystarczy porównać go z licznikiem 4 bitowym. Sygnał luminacji jest analogowy i może być zakłócony, ale łatwo go naprawić, bo wiemy, że atari ma tylko 16 poziomów jasności. Więc jak coś odstaje od tego to jest to zakłócenie. Sumarycznie po zapamiętaniu dwóch atarowskich linii obrazu można wyliczyć trik z powiększaniem liczby kolorów wykorzystując właściwości PAL.
Teoretycznie więc można zrobić niemalże idealny konwerter SVIDEO->DVI z emulacją PAL jak na CRT. Oczywiście będzie działał tylko z ATARI.
Sygnał koloru w ATARI to jest w zasadzie sygnał cyfrowy. Poszli na łatwiznę i wystarczy porównać go z licznikiem 4 bitowym. Sygnał luminacji jest analogowy i może być zakłócony, ale łatwo go naprawić, bo wiemy, że atari ma tylko 16 poziomów jasności.
Nie wiem, skąd te tezy. Jak spojrzysz na pinout GTIA, to luminancja jest ewidentnie cyfrowa (piny LUM0-3), a chrominancja jednym pinem COLOR.
Chrominancja czyli dla mnie kolor, w zasadzie można podać od razu na układ cyfrowy. A luma jak @pancio pisze... Sortując swoje stare projekty znalazłem IPCora dla FPGA do obsługi DVI. I tak mnie pikło, że w sumie to możnaby z sygnału ze złącza DIN wyprodukować DVI dla monitorka LCD ale tak, żeby udawać te niuanse co się dzieją na CRT z PAL (czyli te tryby graficzne z ATARI co to w liniach się zmienia kolory). Jeżeli ATARI produkuje pole 50Hz, to zrobić z tego 576p nie jest już takie trudne.
Obecnie to te LCDeki to robią deinterlace potem podbijają fps i w sumie na koniec zwykły atarowski scroll jest jakiś szarpany.
Kodowanie barwy w standardzie PAL jest związane z podnośną chrominancji o częstotliwości ok. 4,3MHz. O ile wyciągnięcie luminancji nie stanowi problemu (cyfrowa informacja jest dostępna bezpośrednio na wyprowadzeniach GTIA), o tyle dekodowanie barwy będzie już nieco bardziej złożone (informacja o składowych jest przenoszona przez zmianę amplitudy i fazy sygnału). To akurat "małe Miki", ponieważ standardy obrazu, związane z kodowaniem TMDS (DVI/HDMI) nie przewidują obsługi strumieni generowanych przy pixelclocku, który mógłby być właściwy dla Ataryny. Najniższa, gwarantowana przez standard i swobodnie obsługiwana rozdzielczość, jest związana z "industrial VGA", ergo 640x480@60Hz (pixelclock = 25MHz). Z częstotliwości synchronizacji słów kodowych, podziału strumienia na linie i ramki, wynika z kolei częstotliwość synchronizacji pionowej/poziomej (HSYNC/VSYNC). Niestety nie znam monitora, który "chapnąłby" strumień TMDS wyprowadzający HSYNC_freq na poziomie właściwym dla PAL. Te problemy zresztą leżą u podstaw koncepcji scandoublerów i podobnych.
@thewasp (...)zmianę amplitudy i fazy sygnału(...)
W ATARI chyba tylko fazy? ATARI nie umie zmieniać nasycenia. Nasycenie to "gałka" na TV, więc się uprości.
Podłączyłem kiedyś dekoder DVBT w 576p do starego monitora LCD (4:3) i zaskoczył (HDMI->DVI). Wydaje mi się, że sporo LCDeków ma tolerancje dużo niżej niż pixelclock dla VGA. Tak samo te małe zabawkowe wyświetlacze do rPi itp. Więc może nie będzie tak źle. :)
Jeżeli po dwóch liniach zebranych z ATARI zacznę produkować strumień DVI to w zasadzie emulacja PAL będzie naturalna, a opóźnienie niewielkie. Do produkcji sygnału użyłbym TFP410PAP żeby nie było problemu z licencjami HDMI jak to mają układy od Analog Devices.
Najniższa częstotliwość transmisji strumienia zakodowanego TMDS (wariant 8b10b) to ok. 250MHz, czyli pikselclock @ 25MHz. Podział obrazu na linie/ramki jest zwykle ściśle określony i wynika z danych EDID, przekazywanych przez urządzenie wyświetlające. Zwykle jest to mocno "pilnowane" i przy odstępstwach najczęściej pojawi się komunikat OSD o zerwaniu synchronizacji (albo obraz będzie nieczytelny)
Próba buforowania linii jest dobrym (choć dość podstawowym) pomysłem. Konsorcjum HDMI wyznacza słone opłaty licencyjne, ale jeśli utrzymasz wyłączną zgodność z DVI (tj. bez rozszerzeń, właściwych dla HDMI w niewidocznych obszarach obrazu), to w zasadzie nie ma specjalnych podstaw do roszczeń. Akceptowanie strumienia w formacie DVI przez wyświetlacze z HDMI, jest jednym z zasadniczych założeń. Nie spotkałem jeszcze monitora HDMI, który nie zaakceptowałby strumienia DVI generującego obraz "industrial VGA" (nie trzymam się kurczowo tej rozdzielczości :) - podaję jako przykład, który mimo najbardziej podstawowego charakteru jak dla wyświetlaczy o kosmicznych rozdzielczościach, nadal daje radę).
@thewasp Zgadzam się w 100%. Ciekawe, czy te wszystkie "chińskie" konwertery DVItoHDMI są poprawne licencyjnie. Bo coś czuję, że od miejsca HDMI to tak średnio... No ale to problem producentów konwerterów.
@mrroman Jakim cudem? :) Czyli można GTIA tak ogłupić, żeby na ramkę parzystą opóźniło się i poszło "od środka" linii. Hmm, to takie coś ogarnąć to całą ramkę w bufor trzeba wpakować :/
