1 Ostatnio edytowany przez seban (2018-12-25 11:49:53)

Zainspirowany ostatnimi postami dotyczącymi różnego rodzaju maści video-konwerterów, scalerów, a także wątkiem forumowicza tr1x (Test opóźnienia telewizora CRT, LCD i konwertera wideo).

Postanowiłem napisać taki prosty "Video Latency Test", inspirując się "lag testem" z pakietu 240p test suite.

Ten mini program nie wygląda zbyt imponująco:

http://seban.pigwa.net/atari/latency_test/latency_test.png

Po uruchomieniu "Video Latency Test" użytkownik zobaczy liczniki zliczające, kolejne ramki telewizyjne generowane przez Atari, sekundy, minuty i godziny. Dodatkowo każda nowa ramka powoduje podświetlenie kolejnej z dużych cyfr widocznych na ekranie. Nic w tym ciekawego dla ludzkiego oka, jednak pojawiają się ciekawe możliwości jeżeli uzbroimy się w aparat fotograficzny, ew. kamerę/telefon które może kręcić filmy z prędkością 50/60 klatek na sekundę.

Aby poprawnie dokonać pomiaru opóźnienia wprowadzanego przez dany monitor, konwerter, scaler potrzebne jest źródło obrazu referencyjnego... takie o znanym opóźnieniu lub takie o zerowym opóźnieniu, takim źródłem będzie klasyczny monitor CRT który nie buforuje i nie dokonuje obróbki sygnału wejściowego tylko od razu go wyświetla.

Aby przeprowadzić poprawny pomiar należy ustawić takie monitor referencyjny obok monitora na którym będzie wyświetlany sygnał którego opóźnienie chcemy zmierzyć (może to być pomiar np. opóźnienia przetwarzania samego monitora LCD lub pomiar opóźnienia wprowadzanego przez konwerter).

Przykładowy zestaw testowy zestawiony z monitora CRT CM11342/00G oraz monitora LCD LG M228WA, wygląda tak:

http://seban.pigwa.net/atari/latency_test/latency_test.jpg

Zdjęcie powyższego zestawu zostało wykonane aparatem cyfrowym z ustawionym na sztywno czasem naświetlania na 1/50 sek. (gdyby Atari pracowało w systemie NTSC, należało by ustawić czas naświetlania na 1/60 sek.)

Ze zrobionego zdjęcia wynika że monitor LCD wprowadza dwie klatki opóźnienia w stosunku do obrazu generowanego przez Atari (CRT wyświetla już ramkę nr 4, natomiast LCD próbuje wyświetlić ramkę nr 2). Nie jest to jeszcze złym wynikiem, jednak bardziej niepokojący jest czas reakcji matrycy... można zaobserwować że matryca LCD ma bardzo długi czas reakcji, tak właściwie widać że jeszcze widać poświatę na cyfrze "0", ogromną poświatę na cyfrze "1" oraz to że ramka z podświetloną cyfrą "2" nie została jeszcze w pełni wyświetlona (o ile udało się zareagować matrycy na zamianę ciemnego w jasne, to zamiana jasnego obszaru cyfry "2" w ciemny nie udała się jeszcze w pełni).

Pokazuje to tylko jak wolne czasy reakcji prezentuje matryca zastosowana w tym wiekowym modelu monitora. O innych efektach ubocznych które powstają na LG M228WA za chwilę.

Oczywiście monitor CRT reaguje pięknie i dynamicznie, obraz uchwycony na zdjęciu za każdym razem jest ostry, kineskop nadąża za dynamicznymi zmianami znakomicie. Opóźnienie jest zerowe. Jeżeli chcieć by się przyczepić to widać (ale tylko na zdjęciu) minimalną poświatę na cyfrze z poprzedniej klatki.

Ten test testuje jedynie "opóźnienie" wprowadzane przez dany monitor, konwerter, etc. Na chwilę obecną nie testuje jakości przetwarzania sygnału 240p (taki generuje domyślnie Atari) przez wszelakiego rodzaju monitory LCD, konwertery, etc. Jeżeli będzie potrzeba lub zainteresowanie tematem opracują odpowiedni zestaw testów umożliwiający przetestowanie przetwarzania różnych formatów obrazu generowanych przez Atari.

Wyprzedzając nieco wydarzenia mogę powiedzieć że żaden z tanich konwerterów/scalerów oprócz wprowadzania opóźnień rzędu od kilku do kilkunastu ramek, robi z takiego sygnału prawdziwą masakrę.

Nie sięgając daleko, nawet sam monitor LG M228WA znośnie wyświetla jedynie statyczny obraz z Atari, natomiast gdy tylko jakiś obiekt na ekranie się porusza, wbudowany w TV software próbuje "na siłę" poprawiać obraz i wydaje mu się ze wie lepiej co powinien wyświetlić zamiast oryginalnego obrazu... a zatem dodaje od siebie filtrowanie, de-interlace, wygładzanie, wyostrzanie, etc. Oprogramowanie w monitorze jest fabryczne i nie da się w żaden sposób tychże polepszaczy wyłączyć (mówię o sytuacji gdy sygnał podłączony jest do gniazda EURO/SCART, S-Video lub Composite Video w monitorze).

Kończąc już ten nieco przydługi wątek (bo jak zwykle się rozpisałem)... jeżeli kogoś to interesuje to oprogramowanie można pobrać tutaj: Video Latency Test v.1.1

Na chwilę obecną żadna instrukcja nie jest potrzebna. Program należy po prostu uruchomić z dowolnego medium/nośnika (ma postać standardowej binarki Atari DOS [XEX] więc nie powinno być żadnego problemu). Jeżeli komuś przeszkadza niebieskie tło, można go zmienić na czarne wciskając klawisz SHIFT w dowolnym momencie). Soft rozpoznaje system TV (PAL/NTSC) w którym pracuje Atari i odpowiednio dostosowuje swoje ustawienia.

Program oczywiście można uruchomić na emulatorze, ale chyba tylko po to aby pokazać jak trudno dobrze wyświetlić dynamiczny obraz generowany przez Atari w systemie nadrzędnym, często również w przypadku niezgodności prędkości odświeżania monitora oraz obrazów generowanych przez emulator).

Z czasem wrzucę również na forum Atari Area (zapewne gdzieś w dziale sprzęt) testy konwerterów które posiadam aby pokazać czego należy za wszelką cenę unikać i nie wyrzucać pieniędzy w błoto.

EDIT@2018.12.25: aktualizacja wersji do 1.1, zmiana .7z na .zip

2

Seban, jestem pod wrażeniem Twojej płodności programistycznej :-) Bardzo ciekawy tool. Napisz jeszcze jak podłączyłeś oba monitory na raz do Atari.

Pozdrawiam,
pancio

https://systemembedded.eu/ ... https://www.youtube.com/watch?v=GwS7Es1x6mw
""Ja bardzo przepraszam, ale podejrzenia panów są całkowicie bezpodstawne. Ja niczym nie handluję. Ta pani przyszła do mnie w tym Pancake-u i w nim wychodzi.""
ABBUC Member #319. Preferowana forma kontaktu: email

3

Nie mam CRT ale zrobiłem sobie pokrętny test samego konwertera - sygnał S-video podany równocześnie z Atari bezpośrednio do monitora i do konwertera HDMI a z niego do monitora po DVI. Na monitorze odpalony PIP, z lewej DVI, z prawej S-video.

Konwerter spóźni się o 1 ramkę. Teoretycznie bo praktycznie nie wiem jak realizowany jest PIP.

Post's attachments

latency.jpg 117.57 kb, nikt jeszcze nie pobierał tego pliku. 

Tylko zalogowani mogą pobierać załączniki.

4 Ostatnio edytowany przez seban (2018-12-23 23:46:23)

pancio.net napisał/a:

Seban, jestem pod wrażeniem Twojej płodności programistycznej :-) Bardzo ciekawy tool.

nie przesadzajmy z tą "płodnością"... to naprawdę nie zajęło dużo czasu i napisanie tego nie wymagało zbytniego wysiłku. Na tym forum są ludzie którzy kodują takie rzeczy że jestem przy nich totalnym cieniasem :)

pancio.net napisał/a:

Napisz jeszcze jak podłączyłeś oba monitory na raz do Atari.

W przypadku zdjęcia które zamieściłem, podłączenie było proste i oczywiste, a to tylko dlatego że komputer testowy miał na pokładzie VBXE... LG dostawał sygnał RGB z VBXE na swoje wejście EURO/SCART... natomiast CRT dostawał tylko sygnał luma (taki kabel miałem pod ręką).

A następne testy robiłem zupełnie niezgodnie ze sztuką ... powinienem był "na prędce" skleić chociaż jakiś wtórnik/bufor do sygnału wideo ale poszedłem na totalną łatwiznę... i zastanawiając się czy ryzykuję obciążyłem wyjście atari dwoma monitorami jednocześnie więc 75ohm impedancji zmieniło się w straszliwe 37ohm... ja się zastawiałem co na to powie Atari i jak długo wytrzyma :) ale radziło sobie dzielnie i efektem ubocznym był spadek amplitudy sygnału video co przełożyło się na delikatne zmniejszenie poziomu jasności...

... wiem, wiem... wypisuje herezje i postępuje krocząc ścieżką zmierzającą ku zagładzie ;P jednak nie zależało mi na jakości ani ostrości obrazu... wszystko miałem podłączone do jednej listwy zasilającej i nie miałem żadnych "ground loops" i prawdę mówiąc nie sądziłem że to zadziała dobrze, a jeżeli zadziała to spodziewałem się o wiele większej degradacji sygnału jednak zdziwiłem się tym co ujrzałem przy innych testach więc szybko przestałem się przejmować ;) naprawdę zwyciężyło lenistwo i nie chciało mi się nic lutować... więc zrobiłem kablową maskarę typu:

[monitor#1]-------\
                  |---------[CVBS signal]-----[Atari]
[monitor#2]-------/

potem się trochę ogarnąłem, i zrobiłem dwa wtórniki na szybkim op-ampie przeznaczonym do tego celu... jednak sądzę że można to wykonać również z dwóch tranzystorów. Teraz przyszedł mi do głowy jeszcze jeden pomysł, ale nie wiem czy zadziała... sprawdzę go i dam znać niebawem :)

I nikomu nie polecam takiego postępowania jakie zaprezentowałem wyżej, ja ryzykowałem na własną odpowiedzialność... ale to nie było mądre... tak naprawdę wystarczy że jakiś TV będzie miał jakiś nietypowy układ wejściowy czy jakąś składową stałą na wejściu video i mogą zacząć się problemy. nie powinno się tak postępować jak to uczyniłem, konsekwencje mogą być różne. Jak napisałem niebawem dam znać jak podłączyć dwa monitory jednocześnie bez większego ryzyka.

atarixegs napisał/a:

Nie mam CRT ale zrobiłem sobie pokrętny test samego konwertera - sygnał S-video podany równocześnie z Atari bezpośrednio do monitora i do konwertera HDMI a z niego do monitora po DVI. Na monitorze odpalony PIP, z lewej DVI, z prawej S-video.

Konwerter spóźni się o 1 ramkę. Teoretycznie bo praktycznie nie wiem jak realizowany jest PIP

no właśnie taki rodzaj pomiaru daje wiele niewiadomych, dlaczego? postaram się pokazać to na przykładzie...

tutaj fota gdzie atari podłączono to taniego monitora LCD przez HDMI z użyciem konwertera który ma minimalne latency (właściwie kilka linii skaningowych)...

http://seban.pigwa.net/atari/latency_test/zero_latency_hdmi_conv.jpg

jak widać sam monitor przy przetwarzaniu sygnału z zewnątrz wnosi opóźnienie rzędu 2 klatek... ale ten model to taki low-cost all in one... tzn. ma również wejścia EURO/SCART, S-Video, Component, Composite Video. I co się stanie jak podłączymy Atari do tych wejść bezpośrednio?

http://seban.pigwa.net/atari/latency_test/mistral_cvbs_latency.jpg

wyszło na to że konwersja sygnału cvbs zajęła bebechom monitora kolejne dwie klatki, co byłoby dość logiczne, ponieważ konwerter zapewne czeka aż przyjdą do niego dwa kolejne pół-obrazy systemu PAL... po czym składa sobie jedną klatkę obrazu przy okazji robiąc masakrę z sygnału 240p który otrzymał od atari...

i dlatego pisałem wyżej że Twoja metoda pomiaru może (ale nie musi) dawać nieadekwatne testy...

ale dzięki Twojemu wspomnieniu o braku CRT... Kurdę chyba wpadłem na pewnie pomysł jak to zrobić bez CRT :D to ma szansę zadziałać, ale muszę to sprawdzić :)

Wracając na chwilę do tego nieszczęsnego mistrala jak pisałem ten monitor również (tak jak LG) robi istną kaszanę z sygnału 240p... tak będzie robić również większość TV, konwerterów, etc. (u Ciebie też chyba widać na zdjęciu że obraz z prawej strony jest nieprawidłowy i drży o jedną linię co ramkę (no chyba że czas "otwarcia migawki" za długi jest))

Muszę jednak dorobić jakiś test pokazujący/testujący nieprawidłowe przetwarzanie sygnałów 240p przez większość sprzętu obecnego na rynku.

Dlaczego wygłaszam tak pesymistyczną opinię... tylko dlatego że 240p nie jest żadnym standardem, a w stanach FCC zabroniło nadawania w tym formacie, żaden sprzęt studyjny nie wspiera tego formatu. 240p to właściwie "hack" który działał na analogowych TV/Monitorach (stąd też słynne scan-lines jako efekt uboczny).

5

U mnie obraz po prawej jest lipny tylko dlatego, że to PIP w układzie 1/2 ekranu - wtedy nawet obraz statyczny się tak rozwala. Jak dam mniejsze okienko to jest stabilny (ale wtedy fota nieczytelna). W trybie fullscren czy to DVI czy S-vieo - obraz jest zawsze stabilny.

6

dzięki za info! czyli sam "konwerter" który posiadasz wydaje się być całkiem OK? Rozumiem że dobrze on sobie radzi z interlace? (zarówno tym pseudo, nazwijmy go 240i /via software/ jak i tym sprzętowym 480i by Rybags). Bo rozumiem że mówisz o konwerterze z np. tego wątku: http://www.atari.org.pl/forum/viewtopic.php?id=15674

7 Ostatnio edytowany przez Pin (2018-12-24 13:59:17)

ehhh, szkoda że zipem spakowane. 7z potrzebny do spakowania 703 bajtów :) Teraz muszę odpalić piec, rozpakować to, przepakować do zipa, wrzucić na ftp i zassać telefonem przerzucając to przez sio2bt. Jak by nie to, to wystarczy telefonem zipa wprost do atarki zrzucić, gdzie zipa rozpakujesz bez łaski ;)

Uprzejmie donoszę też, że zabawnie wraca do dosa, zimny reset jest konieczny, no i rozwala Spartę.

Kontakt: pin@usdk.pl

8

seban napisał/a:

dzięki za info! czyli sam "konwerter" który posiadasz wydaje się być całkiem OK? Rozumiem że dobrze on sobie radzi z interlace? (zarówno tym pseudo, nazwijmy go 240i /via software/ jak i tym sprzętowym 480i by Rybags). Bo rozumiem że mówisz o konwerterze z np. tego wątku: http://www.atari.org.pl/forum/viewtopic.php?id=15674


Tak, to ten konwerter, przy czym u mnie odwzorowuje świetnie a u kolegi tr1x wygląda to fatalnie bo nie ma modu supervideo w atarce.

Radzi sobie całkiem nieźle z interlace (na C64też)

http://atariage.com/forums/uploads/monthly_05_2009/post-7804-1243347276.jpg

Np przy grafika robionych bugbiterem we znaki daje się brak frame blendingu, niewidoczny pal artefacting

I tak na Altirra z odpalony frame blendingiem mamy taki efekt:

https://i.imgur.com/LBlzHs4.png


Na LCD via konwerter po HDMI jest już tak:

https://i.imgur.com/Ued7Qgm.jpg

dla oryginału:

https://i.imgur.com/vzc5mAI.png

9 Ostatnio edytowany przez seban (2018-12-24 19:48:23)

Pin napisał/a:

ehhh, szkoda że zipem spakowane. 7z potrzebny do spakowania 703 bajtów :) Teraz muszę odpalić piec, rozpakować to, przepakować do zipa, wrzucić na ftp i zassać telefonem przerzucając to przez sio2bt. Jak by nie to, to wystarczy telefonem zipa wprost do atarki zrzucić, gdzie zipa rozpakujesz bez łaski ;)

Uprzejmie donoszę też, że zabawnie wraca do dosa, zimny reset jest konieczny, no i rozwala Spartę.

Pin, spakowane 7z nie z powodu chęci zaoszczędzenia miejsca, ale tylko i wyłącznie z tego powodu aby mieć pewność że sciągnięty plik jest poprawny (7z zapewnia integralność danych, a przynajmniej wiesz jeżeli coś się z archiwum spierniczyło po drodze). Ale ok wrzucę Ci na pigwę wersję .XEX.

Co do sparty... wytłumacz mi proszę jakie ty masz memlo? ;) program się ładuje od $2000, jakim cudem Ci to Spartę rozwala? Mogę go skompilować wyżej... ale też trzeba uważać bo przecież zaraz będziesz narzekał że jak bedzie ponad $a000 to trzeba będzie ładować przez /X czy coś bo tam też sparta... :) powiedz gdzie ma się ładować aby nie robiło "kuku" sprawcie.

i  Ty mówisz na poważnie, że takiego programu:

    $22C0 - $2572 : $02B3
RUN $2473

nie da się normalne załadować spod sparty? serio? ;)

Czy do tak prostej "popierduły" mam dołączyć relokator i relokować dynamicznie w zależności od memlo? czy może jednak
wystarczy ładować nieco wyżej aby Sparta mogła żyć spokojnie?

Jak mi napiszesz co mam zrobić aby zadowolić spartę, chętnie poprawie te $2b3 bajtów kodu ;P

EDIT: Pin, specjalnie dla Ciebie wersja 1.1, ładowana od $8000, i to w formie XEX: Video Latency Test v.1.1.xex

Dodatkowo po wciśnięciu ESC robi WARM START/RESET powinno wrócić do Sparty bez problemu? nie?

atarixegs napisał/a:

Tak, to ten konwerter, przy czym u mnie odwzorowuje świetnie a u kolegi tr1x wygląda to fatalnie bo nie ma modu supervideo w atarce.

Jeszcze raz dzięki za tak rozbudowane informacje na temat konwertera i jego zachowania w różnych trybach pracy. A możesz podpowiedzieć którą dokładnie wersję do super video w swoim Atari posiadasz?

10

W 130XE oraz 65XE mam mod wg http://www.retrocomputing.net/parts/ata … 130-1.html

W XEGS mam mod wg http://www.tehkella.net/retro/wp-conten … XEGM-1.pdf

BTW w 1 szt z 3 jakie posiadam, od nowości uwalone było kilka elektrolitów (wywalone gumowe korki), dlatego we wszystkich zrobiłem recapping, dodałem radiatory i aktywne chłodzenie (wentylator 12v zasilany z 5v na niskich obrotach przez co bezgłośny).

https://i.imgur.com/1cYlrXe.jpg

Overkill ale co sobie człowiek podłubie to jego ;)

Przy okazji sprawdziłem, czy na płytach są jakieś numery rewizji - niestety nic.

11

ZIP też ma sumę kontrolną, a można rozpakować na maluchu.

https://www.youtube.com/watch?v=jofNR_WkoCE

12 Ostatnio edytowany przez seban (2018-12-25 12:03:14)

@atarixegs: dzięki za info! niezły mod... :) z ciekawości jeszcze zapytam... pamiętasz co napisane było na scalakach? tzn. na jakich scalakach bazuje konwerter?

@fox: jasne rozumiem, zmieniłem na .zip. Prawdę mówiąc zakładałem że i tak ludzie używają PC aby ściągnąć pliki z internetu. Ale PIN jak widać używa telefonu... ja nawet nie zakładałem takiej opcji bo ja nie używam telefonu/tabletu to takich celów ;) następnym razem wrzucę  Pinowi archiwum w formacie .bz2 albo .xz ... ;P

13

Pin do ściągnięcia zasobów z internetu używa Atari :] Serio.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

14

Układ obrabiający sygnał analogowy jest zeszlifowany.

Układ od HDMI to CAT6612

Post's attachments

CAT6612_ChipAdvancedTechnology.pdf 1.01 mb, liczba pobrań: 9 (od 2018-12-25) 

Tylko zalogowani mogą pobierać załączniki.