atarionline.pl Rzeczywista wysokość ekranu - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1: CommentAuthorpavros
    • CommentTime8 Nov 2009
     
    Mam ogromną prośbę. Chodzi o pomiar ilości linii ekranu, jaka jest widoczna powyżej i poniżej standardowego obszaru 240 linii na ekranie telewizora/monitora. Ma to na celu ustalenie jaka ilość linii poza standardowym polem jest widoczna przez wszystkich (lub przynajmniej większość) i na której jest sens cokolwiek wyświetlać. Dla ułatwienia pomiarów przygotowałem specjalny programik (nazwałem go Screen Height Meter), który wyświetla coś na wzór linijki. Podziałka ustawia się początkowo zgodnie z numeracją linii ANTICa ale za pomocą strzałek można ją przesuwać tak, by punkt zerowy ustawić dogodnie do pomiaru. Jeżeli ktoś będzie w stanie pomóc, to proszę podawać wyniki jako X=? dla ilości linii powyżej standardowego obszaru oraz Y=? odpowiednio dla linii poniżej. W grę wchodzą również konwertery (S)VIDEO->VGA.
    Udało mi się potwierdzić, że GTIA może wyświetlać treść obrazu w każdej z 312 linii, czyli nawet w liniach, w których odbywa się synchronizacja pionowa. Tak więc kwestią jest tylko ile telewizory/monitory są w stanie pokazać. Poniżej rysunek klatki obrazu Atari z podziałem na poszczególne obszary.



    Krótka instrukcja do programu:
    Strzałki - poruszają linijkę w pionie i w poziomie; jest też autorepetycja dla szybkiego przesuwania (50 pikseli na sekundę)
    A - ustawia linijkę, tak by wyświetlane numery linii pokrywały się z faktycznymi numerami ANTICa; oczywiście ANTIC podaje numer linii podzielony przez 2
    B - przełącza wyświetlanie w czasie 12 linii wygaszania pionowego - to pokazuje, że Atari może wyświetlać obraz w każdej z 312 linii, ale trudno to zobaczyć; czasem udaje się przy braku synchronizacji pionowej
    C - zmienia schemat kolorów - początkowo miał być tylko cały czarny ekran, ale dodałem podświetlanie poszczególnych obszarów, aby było jakieś odniesienie; kolory są po to, żeby sprawdzić, czy przypadkiem monitor nie przekłamuje ich, gdy jest włączony tryb pełnoekranowy
    S - przełącza sygnał synchronizacji pionowej; przy jej braku na niektórych monitorach możliwe jest nawet zobaczenie obszaru wygaszania pionowego (vertical blank), ponieważ obraz "pływa" z góry na dół
    ESC - wyjście do DOSa

    Jako ciekawostkę dodam, że program wykrywa uruchomienie na emulatorze i informuje wtedy o swej użyteczności jedynie z prawdziwym sprzętem.
    • 2: CommentAuthorxxl
    • CommentTime8 Nov 2009
     
    nie zorumiem jak mam ustawic linijke wiec napisze co robilem:
    ustawilem "0" na samej gorze ile sie tylko dalo, 11 linii jest do pierwszego pola (rozumiem ze na pierwszym polu zaczyna sie rysowanie programem antica), na samym dole antic konczy rysowanie i widze jeszcze 17 linii.
    atari 130xe
    monitor lcd szajsung
    • 3: CommentAuthorpavros
    • CommentTime8 Nov 2009
     
    Dzięki xxl.
    Właśnie o to chodzi. Czyli jak rozumiem w twoim przypadku jest X=11, Y=17
    • 4: CommentAuthorScalak
    • CommentTime8 Nov 2009
     
    X=Y=12 TV Belstar
    • 5:
       
      CommentAuthorlarek
    • CommentTime9 Nov 2009 zmieniony
     
    x=15 y=17 14" TV LCD (UNITED) na S-Video:

    • 6: CommentAuthorstc
    • CommentTime12 Nov 2009
     
    x=17 Y=24 PHILIPS CM8833-II
    • 7: CommentAuthorirwin
    • CommentTime4 Feb 2010
     
    @Pavros, no i coś z tych twoich testów wynika?

    Nie wiem czy dobrze rozumiem ale czy owe wyniki testów nie oznaczają że jeśli średnio każdy widzi około 25-30 dodatkowych linii to czy nie można by je dodać np do Graph2Fonta?
    • 8: CommentAuthorurborg
    • CommentTime4 Feb 2010
     
    A u mnie jest X=13 Y=9, Telewizor CRT Samsung 29"
    • 9:
       
      CommentAuthorjhusak
    • CommentTime5 Feb 2010 zmieniony
     
    eeee, nieważne. usunąć.
    • 10: CommentAuthorpavros
    • CommentTime15 Feb 2010
     
    Podsumowanie ankiety.
    Pomiary dotyczą tylko i wyłacznie komputerów w systemie PAL.
    Podobny wątek założyłem również na forach AtariArea oraz AtariAge.
    Oto tabela wyników pomiarów zamieszczonych na forach oraz moich własnych:
    X Y
    11 17
    12 12
    15 17
    17 24
    13 9
    14 17
    11 15
    8 8
    23 24
    10 18
    16 17
    20 20
    29 28
    12 8
    15 18
    15 18

    Pomiarów niestety nie ma zbyt wiele co powoduje, że wyciągnięte wnioski mogą być nie do końca prawdziwe.
    Niemniej są one następującce:
    1. 8 linii powyżej oraz 8 linii poniżej standardowych 240 widzą wszyscy (łącznie 256).
    2. 15 linii powyzej standardowych 240 widzi się najczęściej.
    3. 17 linii poniżej standardowych 240 widzi się najczęściej.
    4. Dla uproszczenia możnaby przyjąć, że najczęściej widzimy 16 linii powyżej i poniżej standardowych 240 (łącznie 272).
    5. 24 linie powyżej oraz 24 linii poniżej standardowych 240 to maksymalna ilość linii, w których możemy cokolwiek
    wyświetlać zachowując zgodność z przyjętą normą dla systemu PAL (łącznie 288). Tyle widzą głównie posiadacze
    monitorów Commodore 1084 i Philips CM8833 (zależy to od ustawień). To ograniczenie właściwie dotyczy tylko dolnej
    części ekranu a ograniczenie górnej jest tylko dla zachowania symetrii.

    Przypomnę, że w dodatkowych liniach można wyświetlać tylko sprite'y (PMG) i nie działa dla nich DMA. Po szczegóły odsyłam do artykułu na temat ramki.

    A oto link do przykładu wykorzystania dodatkowych linii na C64. Tam też używane są tylko sprite'y. Link podrzucił Irwin.
    • 11:
       
      CommentAuthorKaz
    • CommentTime15 Feb 2010
     
    Brawo!

    A wiec udalo sie ustalic, ze mamy do wykorzystania jeszcze 24 linie na dole i na gorze maksymalnego ekranu (240 linii). Mozna tam rysowac duszkami oraz... no wlasnie - co tam jeszcze mozna wykorzytac?

    z artka Pavrosa:

    Okazuje się, że GTIA może wyświetlać obiekty PMG (sprite’y) na wysokiej ramce. Oczywiście poza standardowymi 240-stu liniami DMA sprite’ów nie działa podobnie jak DMA obrazu. Można jednak wpływać na kształt sprite’ów poprzez rejestry $D00D-$D011. To daje możliwość wyświetlania nieskomplikowanej grafiki na wysokiej ramce. Należy pamiętać, że wysoka ramka to tryb hires z samymi jedynkami. To oznacza, że wszystkie piksele ramki mają zawsze priorytet nad sprite’ami jeżeli chodzi o jasność, natomiast przejmują barwę sprite’ów. Aby uzyskać pełną niezależność kolorów sprite’ów od koloru ramki oraz ich wyższy priorytet należy użyć jednego z trybów GTIA lub opisanego wcześniej E+. W trybach GR.9 i GR.11 nie można uzyskać dowolnego koloru ramki, co wynika ze specyfiki tych trybów oraz z faktu, że treść obrazu ramki stanowią same jedynki. W trybie GR.10 oraz w E+ możemy ustawić dowolny kolor ramki. W trybie E+ kolor wysokiej ramki ustawiamy w rejestrze colpf3 ($D019). W trybie GR.10 również w rejestrze colpf3 dla większości powierzchni ramki oraz dodatkowo w colbak($D01A) dla pierwszego piksela (kolumny) od lewej. Powiązanie pierwszego piksela z rejestrem colbak ma związek z faktem przesunięcia o jeden piksel właśnie całego obrazu w trybie GR.10 względem obrazu w trybach GR.9 i GR.11. W trybie GR.9 jasność wysokiej ramki jest maksymalna (15) a o barwie decyduje rejestr colbak. W trybie GR.11 barwa wysokiej ramki jest pomarańczowo-brązowa (15) a o jasności decyduje rejestr colbak. W załączonych przykładach używany jest tryb GR.10.




    • 12:
       
      CommentAuthorKaz
    • CommentTime15 Feb 2010 zmieniony
     
    Co to jest hires "z samymi jedynkami"? Czy to tak jakby piksele byly narysowane?
    • 13: CommentAuthorpavros
    • CommentTime15 Feb 2010
     
    Wszystkie piksele są zapalone (COLPF1). To oznacza, że nie ma niezapalonych (COLPF2). W praktyce to nie ma żadnego znaczenia. Grafiki i tak wyświetlać nie można. Najlepiej też jest włączyć tryb GTIA 10 - wtedy uzyskujemy dowolny kolor tła i niezależne od niego kolory sprite'ów. Oczywiście kolor tła jest wtedy, tak jak pisałem w artykule, w COLPF3 (oraz w COLBAK dla pierwszego piksela od lewej).
    • 14:
       
      CommentAuthorKaz
    • CommentTime15 Feb 2010
     
    Czy mozna to tak rozumiec, ze jest tylko "stan" zapalonych pikseli, a nie sa one faktycznie zapalone", bo po prostu nie ma grafiki, tak?
    • 15: CommentAuthorirwin
    • CommentTime15 Feb 2010
     
    @Pavros, dzięki za drążenie tematu grafiki na małe Atari. Szkoda że nie da rady malować tam grafiką bo same atarowskie duszki jako tako się sprawdzają gdy ich powiększone pixle 4x1 czy nawet 8x1 są tuszowane przez nakładanie na nich zwykłej grafiki. Za to gdy ich brak to naprawdę ciężko coś zrobić w takim wypadku, szkoda że nie mamy więcej duszków. Ale mimo to za jakiś czas spróbuje coś stworzyć sensownego w tym trybie, tj obrazek w g2f plus linie Pavrosa ;) osobno, może ktoś to połączy bo póki co nie ma jak, jest tylko teoria.
    • 16:
       
      CommentAuthorKaz
    • CommentTime15 Feb 2010 zmieniony
     
    Czy dobrze rozumiem, ze mamy takie warianty "wysokiej ramki":

    1) tryb GR8 - nie trzeba nic ustawiac, jest to jakby domyslny tryb; nie widac na tych obszarach zadnej grafiki bitmapy, ale wplywa ona na duszki, ktore mozna tam umiescic, w ten sposob, ze wszystkie piksele ramki mają zawsze priorytet nad duszkami (w zakresie jasnosci), a przejmuja barwe duszkow.

    2) tryb GR9 - nie mozna uzyskac dowolnego koloru ramki - jej jasnosc jest maksymalna (15), ale mozna ustawic barwe (rejestrem COLBAK). Mamy pelna niezalezosc kolorow i priorytetow duszkow.

    3) tryb GR10 - mozna ustawic dowolny kolor ramki (pierwszy piksel z lewej na calej wysokosci ramki rejestrem COLBAK, $D01A, a pozostala czesc ramki rejestrem COLPF3, $D019). Mamy pelna niezalezosc kolorow i priorytetow duszkow.

    4) tryb GR11 - nie mozna uzyskac dowolnego koloru ramki - jest pomaranczowo-brazowa (15), ale mozna ustawic jasnosc (rejestrem COLBAK). Mamy pelna niezalezosc kolorow i priorytetow duszkow.

    5) tryb E+ - mozna ustawic dowolny kolor ramki (rejestrem COLPF3, $D019). Mamy pelna niezalezosc kolorow i priorytetow duszkow.

    1. Interesuje mnie tu odpowiedz na pytanie, czy na pewno nie jest mozliwe uzyskanie jakiejkolwiek grafiki na wysokiej ramce w punktach 2- 5 (bo w 1 juz wiem, ze nie mozna)?

    2. Drugie pytanie dotyczy szerokosci - ten obszar ma, jak widac na zdjeciach, ograniczona szerokosc - jaka ona jest?

    3. Trzecie pytanie: czy obszarowi po bokach wysokiej ramki mozna tez nadac jakis kolor poza czarnym?

    4. Czwarte pytanie: czy duszki na wysokie ramce moga byc uzywane na calej szerokosci takiej jak ma obraz w glownej czesci ekranu (32, 40, 48 bajtow) czy w takiej jak ma wysoka ramka?

    5. Piate pytanie: jak to zaimplementowac w G2F? ;)
    • 17: CommentAuthorirwin
    • CommentTime15 Feb 2010 zmieniony
     
    @Kaz, z tego co wiem od Tebe to on raczej nie jest zainteresowany takim rozszrzeniem z uwagi na małe praktyczne zastosowanie. I poniekąd ma rację, wątpię aby bez możliwości użycia grafiki do maskowania duszków, powstało więcej niż 2-3 grafiki na rok, a raz już coś podobnego robił (narobił się przy AIS, a nie ma ludzi chętnych do malowania)
    Tak więc mam taki pomysł: zapis normalnego obrazka w Graph2Font do asm, zapis 16 górnych linii namalowanych duszkami do pliku pmg (w g2foncie) zapis 16 dolnych linii namalowanych duszkami do pliku pmg (w g2foncie), napisanie przez Pavrosa nagłówku w asm który trzeba dokleić w stosowne miejsce do pliku asm wygenerowanego z Graph2Fonta. Użycie Madsa: i obrazek gotowy. Chyba że tak się nie da, lub coś pokręciłem - nie znam się tym.
    • 18: CommentAuthorpavros
    • CommentTime15 Feb 2010
     
    @Kaz: Twój opis wariantów 1)-5) dokładnie odpowiada rzeczywistości. Świetne podsumowanie!
    Ad 1. Na pewno nie jest możliwe uzyskanie grafiki w jakimkolwiek trybie.
    Ad 2. Szerokość wysokiej ramki jest dokładnie taka, jak szerokość szerokiego pola wyświetlania. Jest więc 4 piksele po lewej stronie pola standardowego + 160 pikseli pola standardowego + 16 pikseli po prawej stronie. Łącznie 180 pikseli.
    Ad 3. Obszarowi po bokach wysokiej ramki (czyli poza 180 pikselami tej ramki) nie można zmienić koloru. Zawsze jest czarny.
    Ad 4. Duszki widoczne są tylko na szerokości wysokiej ramki czyli na 180 pikselach. Odpowiada to 45 bajtom obrazu (1 po lewej + 40 standard + 4 po prawej).
    Ad 5. Byłoby to szalenie trudne. Ponadto prawdopodobnie nie istnieje jedno najlepsze rozwiązanie uaktywniające dodatkowe linie. Kod musiałby być zależny od treści obrazka. Według mnie gra nie warta świeczki. Dla być może kilku obrazków, jakie dzięki temu powstaną, szybciej będzie zakodować to ręcznie.

    @irwin: Niewykluczone, że to się uda.
    • 19:
       
      CommentAuthorKaz
    • CommentTime15 Feb 2010 zmieniony
     

    pavros:

    Szerokość wysokiej ramki jest dokładnie taka, jak szerokość szerokiego pola wyświetlania. Jest więc 4 piksele po lewej stronie pola standardowego + 160 pikseli pola standardowego + 16 pikseli po prawej stronie. Łącznie 180 pikseli.


    Dobrze rozumiem, ze podajesz piksele rozmiarow 2x1, a nie (odpowiednio) GR8,9,10,11?
    • 20: CommentAuthorpavros
    • CommentTime16 Feb 2010
     
    Tak, piksele rozmiarów 2x1.
    • 21:
       
      CommentAuthorKaz
    • CommentTime13 Jul 2015
     
    Widze, ze ostatnio ludzie interesuja sie obrazem Atari, to odkopuje temat, bo programik Pavrosa przydatny.