1

Koledzy Atarowcy,

    jakiś czas temu, w tym wątku, pisałem o próbach z pewnym konwerterem S-video/Composite na HDMI. Kolega @Montezuma zainspirował mnie do sprawdzenia, jakie opóźnienie w wyświetlaniu obrazu wprowadza konwerter i telewizor. Może się bowiem okazać, że czas jaki mija od momentu ruchu joystickiem do pojawienia się na ekranie telewizora obrazu będącego odpowiedzią na ruch joysticka jest tak duży, że nie będzie dało się grać w gry zręcznościowe.



Schemat układu pomiarowego

Schemat



Stanowiska pomiarowe

Fotorezystor umieszczony był w odległości kilkunastu centymetrów od ekranu telewizora, na wysokości ok. 10 centymetrów powyżej dolnej krawędzi ekranu. Oko fotorezystora było skierowane w stronę ekranu.


Fotorezystor, przejściówka do podłączenia joysticka
Fotorezystor oraz przejściówka do podłączenia joysticka umożliwiająca podłączenie się oscyloskopem


Fotorezystor na statywie skierowany w stronę ekranu telewizora LCD
Fotorezystor na statywie skierowany w stronę ekranu telewizora LCD


Fotorezystor skierowany w stronę ekranu telewizora CRT
Fotorezystor skierowany w stronę ekranu telewizora CRT


Komputer, oscyloskop



Błędy pomiarowe

Zdaję sobie sprawę, że opóźnienia zaobserwowane w wyniku pomiaru mogą być obarczone błędem. W szczególności:
1. Nie wiem, czy użyty fotorezystor ma jakieś istotne opóźnienie w zmianie rezystancji w stosunku do momentu, gdy zaczyna na niego padać światło. Może w przyszłości to sprawdzę przy użyciu oscyloskopu, fotorezystora i diody elektroluminescencyjnej.
2. Nie wiadomo, w którym miejscu była wiązka elektronów wykreślająca obraz na ekranie telewizora CRT w momencie wykonania ruchu joystickiem -- ten błąd starałem się zmniejszyć poprzez wykonanie wielokrotnych pomiarów, co umożliwia uśrednienie otrzymanych wyników.
3. Fotorezystor nie był umieszczony w dokładnie takiej samej pozycji w stosunku do ekranu telewizora CRT i LCD.
4. Nie starałem się dokładnie odczytywać wyników pomiarów z ekranu oscyloskopu. Zadowoliłem się dokładnością ok. 5-10 ms.
O ile bezwzględnym czasom opóźnienia uzyskanym w wyniku pomiarów nie można do końca ufać, to mam nadzieję, że przeprowadzone testy pozwolą poznać relacje opóźnień między telewizorem kineskopowym, telewizorem LCD (wprowadzony sygnał Composite), telewizorem LCD (z wykorzystaniem konwertera Composite->HDMI). Być może nowocześniejsze niż mój telewizory LCD wprowadzają mniejsze opóźnienie; tego nie wiem.



Testowane urządzenia

1. Telewizor kineskopowy Philips typu 14PT2666/58; do telewizora wprowadzany jest sygnał Composite z komputera Atari 65XE.
2. Telewizor LCD Samsung UE32ES6100; do telewizora wprowadzany jest sygnał Composite z komputera Atari 65XE.
3. Telewizor LCD Samsung UE32ES6100 + konwerter; sygnał Composite z komputera Atari 65XE wprowadzany jest na wejście konwertera; z konwertera wyjściem HDMI wyprowadzany jest sygnał na wejście HDMI telewizora.
4. Komputer Atari 65XE, beż żadnych modyfikacji.



Program testowy

Na komputerze Atari 65XE działa program, który:
1. Wyświetla czarne tło.
2. Czeka na ruch wykonany joystickiem.
3. Po ruchu wykonanym joystickiem, wyświetla białe tło.


Zmiana jasności tła, po ruchu wykonanym joystickiem (niebieski kanał oscyloskopu), jest wykrywana za pomocą fotorezystora (żółty kanał oscyloskopu).


        org $600

color2  equ $02C6
ptrig0  equ $027C
black   equ $00
white   equ $0f

main    lda #black
        sta color2
        ldx #white
loop    lda ptrig0
        bne loop
        stx color2
end     jmp end

       run main


Wyniki pomiarów

Należy zwrócić uwagę, że przebiegi dla poszczególnych układów były zdejmowane przy różnych podstawach czasu.


Telewizor CRT, do którego został wprowadzony sygnał Composite z komputera Atari
Atari 65XE -> [Composite] -> Telewizor CRT
Telewizor CRT


Telewizor LCD, do którego został wprowadzony sygnał Composite z komputera Atari
Atari 65XE -> [Composite] -> Telewizor LCD
Telewizor LCD


Telewizor LCD z konwerterem
Atari 65XE -> [Composite] -> Konwerter -> [HDMI] -> Telewizor LCD
Telewizor LCD + konwerter



Wnioski

Czas po jakim, od momentu ruchu joystickiem, pojawiał się obraz na ekranie testowanego telewizora CRT wynosił od 35 ms do 55 ms.
Czas po jakim, od momentu ruchu joystickiem, pojawiał się obraz na ekranie testowanego telewizora LCD wynosił od 170 ms do 210 ms.
Obraz na ekranie testowanego telewizora CRT pojawiał się nawet ok. 5 razy szybciej niż obraz na ekranie testowanego telewizora LCD.
Czy opóźnienie telewizora LCD rzędu 200 ms dyskwalifikuje go do szybkich gier zręcznościowych?

Czas po jakim, od momentu ruchu joystickiem, pojawiał się obraz na ekranie testowanego telewizora LCD z podłączonym konwerterem Composite->HDMI wynosił od 210 ms do 240 ms.
Testowany konwerter wprowadza dodatkowe opóźnienie rzędu 35 ms. Zatem chyba konwerter nie dokłada się znacznie generowanym opóźnieniem do dużego opóźnienia, które generuje telewizor LCD (w stosunku do opóźnienia generowanego przez telewizor CRT).

tr1x

Atari 800XL, 2 x Atari 65XE, Atari 65XE ECI, Atari 520STE, Atari Video Music (C240), Atari Portfolio, Atari 1200XL

2 Ostatnio edytowany przez mono (2018-12-21 03:02:10)

Testujesz i sterujesz rejestry cienie, które są aktualizowane na przerwaniu VBLK. To powoduje, że od fizycznej zmiany stanu joysticka do aktualizacji rejestru PTRIG może minąć prawie cała ramka czyli 312 linii skanningowych (PAL). Następnie na podstawie cienia ustawiasz stan rejestru cienia dla koloru COLOR2 - zostanie on zaktualizowany dopiero przy następnym VBLK - czyli po kolejnych prawie 312 liniach skanningowych. Co więcej sterujesz COLPF2 a więc obszar tła w trybie GR.0 a więc kolor zieniany jest w ograniczonym obszarze. Więc przy Twojej metodzie pomiaru miną min 1 a max 2 ramki ekranu w reakcji na wychylenie joystickiem.
Ile to może zabrać czasu? 114 cykli na linię * 312 linii skanningowych / 1773447 Hz = 20 ms. To jest czas trwania ramki w PAL.
Proponuję użyć rejestrów hardwareowych, wtedy na natychmiastową zmianę stanu joysticka będzie można natychmiast zmienić kolor tła ekranu. Proponuję też wyświetlać ekran pusty i zmieniać kolor ramki ekranu w reakcji nie na wychylenie joysticka, ale na stan przycisku.

RTCLOK = $12
TRIG0 = $D010
COLBAK = $D01A
DMACTL = $D400
NMIEN = $D40E
NMIRES = $D40F

  lda RTCLOK+2
sync:
  cmp RTCLOK+2
  beq sync
  lda #$00
  sta DMACTL
  sta NMIEN
  sta NMIRES
loop:
  ldx #$00
  lda TRIG0
  bne skip
  ldx #$0F
skip:
  stx COLBAK
  jmp loop

Monitor CRT powinien dać opóźnienie od 0 do 20 ms, ponieważ fotorezystor bada punkt na ekranie, przez który przebiegnie plamka (pewnie jakiś obszar) a przecież wciśnięcie przycisku mogło się zdarzyć w pierwszej linii skanningowej, a badanie plamki w ostatniej. Reakcja na zmianę stanu przycisku odbywa się w ciągu 12 cykli CPU więc w ok. 7us i to właściwie powinien być najkrótszy obserwowalny czas reakcji CRT.
Wydaje mi się, że w ten sposób dałoby się precyzyjniej określić opóźnienie LCD, ale cudów nie oczekiwałbym - podejrzewam, że czas reakcji skróci się o 20..50 ms.
Przerwania NMI wyłączam ze względu na odświeżanie rejestrów hardwareowych na podstawie rejestrów cieni na VBLK.

Edit: Może nie prościej, ale czy nie lepiej byłoby zamiast testować stan joysticka badać skok sygnału luminancji a element światłoczuły ustawić na górze ekranu? I mrugać wtedy ekranem co np. 1s?

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

3 Ostatnio edytowany przez pablozp (2018-12-21 07:53:05)

Ale to wystarczy włączyć pierwsze lepsze demko gdzie jest płynny scroll. I próbować go przeczytać na LCD. Wtedy życze powodzenia

.

4

Sporo pracy w to włożyłeś, chociaż zupełnie niepotrzebnie, bo jest to rzecz jak najbardziej wiadoma od zawsze.
Mimo wszystko dzięki.

5

pablozp napisał/a:

Ale to wystarczy włączyć pierwsze lepsze demko gdzie jest płynny scroll. I próbować go przeczytać na LCD. Wtedy życze powodzenia

Ale opóźnienie wyświetlania a bezwładność obrazu na LCD to dwie różne rzeczy.

Pamięć studenta ma charakter kwantowy - student wie wszystko, ale jednocześnie nic nie pamięta.
- Kilka(naście?) pudełek z klawiszami i światełkami. I jeden Vectrex, żeby nimi wszystkimi rządzić.

6

mono napisał/a:

Testujesz i sterujesz rejestry cienie, które są aktualizowane na przerwaniu VBLK. To powoduje, że od fizycznej zmiany stanu joysticka do aktualizacji rejestru PTRIG może minąć prawie cała ramka czyli 312 linii skanningowych (PAL). Następnie na podstawie cienia ustawiasz stan rejestru cienia dla koloru COLOR2 - zostanie on zaktualizowany dopiero przy następnym VBLK - czyli po kolejnych prawie 312 liniach skanningowych. Co więcej sterujesz COLPF2 a więc obszar tła w trybie GR.0 a więc kolor zieniany jest w ograniczonym obszarze. Więc przy Twojej metodzie pomiaru miną min 1 a max 2 ramki ekranu w reakcji na wychylenie joystickiem.

Dzięki za cenne uwagi.

mono napisał/a:

Edit: Może nie prościej, ale czy nie lepiej byłoby zamiast testować stan joysticka badać skok sygnału luminancji a element światłoczuły ustawić na górze ekranu? I mrugać wtedy ekranem co np. 1s?

To jest dobry pomysł. Zrealizuję to, a o wynikach powiadomię w tym wątku na forum.

Jedną sondą oscyloskopu podepnę się pod sygnał Composite bądź S-Video wychodzący z Atari 65XE. Na telewizory i konwerter będę wprowadzał zawsze sygnał Composite, a nie S-video, gdyż telewizor CRT, którym dysponuję ma tylko wejście Composite.
Drugą sondą oscyloskopu podepnę się pod fotorezystor, który to umieszczę przy górnej krawędzi ekranu telewizora. Na fotorezystor założę jakąś rurkę dotykającą do ekranu, aby ograniczyć mu pole widzenia do niewielkiego obszaru.
Będę sprawdzać, jakie jest opóźnienie skoku sygnału z fotorezystora w stosunku do skoku sygnału luminancji na wyjściu monitorowym w odpowiedzi na zmianę koloru tła z czarnego na białe.

I teraz pytanie o program, który posłuży do przeprowadzenia tego eksperymentu. Wstępnie wydaje mi się, że program, którego kod wstawiłem w pierwszym wpisie w tym wątku (korzystający z joysticka i operujący na rejestrach cieniach) będzie odpowiedni. Można go zmodyfikować, aby zmieniał także (albo wyłącznie -- fotorezystor będzie umieszczony przy górnej krawędzi ekranu) kolor ramki. Joystick nie będzie tu elementem, w stosunku do którego cokolwiek mierzymy, a jedynie wyzwalaczem zmiany koloru tła (można też co sekundę zmieniać kolor tła, o czym pisałeś). Jeśli dobrze rozumiem, to ponieważ w tym programie operujemy na rejestrach cieniach, to synchronizujemy się z powrotem pionowym i dzięki temu pozbywamy się problemu związanego z niepewnością, gdzie była plamka w momencie zmiany koloru tła.

Liczę na uwagi dotyczące właściwego przygotowania do powtórnego eksperymentu, za które z góry dziękuję.

Atari 800XL, 2 x Atari 65XE, Atari 65XE ECI, Atari 520STE, Atari Video Music (C240), Atari Portfolio, Atari 1200XL

7

tr1x napisał/a:

I teraz pytanie o program, który posłuży do przeprowadzenia tego eksperymentu. Wstępnie wydaje mi się, że program, którego kod wstawiłem w pierwszym wpisie w tym wątku (korzystający z joysticka i operujący na rejestrach cieniach) będzie odpowiedni. Można go zmodyfikować, aby zmieniał także (albo wyłącznie -- fotorezystor będzie umieszczony przy górnej krawędzi ekranu) kolor ramki. Joystick nie będzie tu elementem, w stosunku do którego cokolwiek mierzymy, a jedynie wyzwalaczem zmiany koloru tła (można też co sekundę zmieniać kolor tła, o czym pisałeś). Jeśli dobrze rozumiem, to ponieważ w tym programie operujemy na rejestrach cieniach, to synchronizujemy się z powrotem pionowym i dzięki temu pozbywamy się problemu związanego z niepewnością, gdzie była plamka w momencie zmiany koloru tła.

Tak jest. W tym przypadku cienie będą doskonałe.
Przykładowy program zmieniający kolor co 1s z czarnego na biały:

RTCLOK = $12
COLBAKS = $2C8

  ldx #$00
  ldy RTCLOK+2
blink:
  tya
  clc
  adc #50
  tay
sync:
  cpy RTCLOK+2
  bne sync
  stx COLBAKS
  txa
  eor #$0F
  tax
  jmp blink
hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

8

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

9 Ostatnio edytowany przez seban (2018-12-21 13:13:08)

Jedna uwaga co do elektroniki... zastosowanie fotorezystora jest w tym wypadku wydaje się niewłaściwe, średni czas reakcji fotorezystora jest za wolny do tego testu... noty katalogowe podają czas reakcji na poziomie aż 30ms... radziłbym zastosować fotodiodę lub fototranzystor, wtedy nie będziesz miał dodatkowego opóźnienia wnoszonego przez czas reakcji fotorezystora.

EDIT: jeszcze jedno jeżeli chodzi o pomiar czasu opóźnienia scalerów/graberów/scan-converterów względem CRT to stosuje się zazwyczaj metodologię polegającą na wyświetlaniu tego samego dynamicznego obrazu na dwóch monitorach równocześnie, tzn. CRT robi jako źródło referencyjne, LCD + konweter, up-scaler, etc. jest traktowany jako obiekt mierzony. Uruchamiasz soft testowy, np:

240p test suite <--- a dokładniej chodzi o lag-test z tego pakietu.

i robisz zdjęcie/kręcisz film obu monitorów jednocześnie,test wygląda np. tak: LCD input lag test with and without Framemeister

Myślę że nie jest jakimś dużym wyzwaniem napisanie takiego testu natywnie dla 8-bit Atari.

10

Napisałem program podobny do tego "lag-test" z pakietu "240p test suite" i pozwoliłem go sobie zaprezentować w tym wątku: Video Latency Test. Może się przyda do dalszych pomiarów.