Można i tak:
Wykrywanie trywialne i tylko częściowo pokrywa się z tym co robi prawdziwe atari, ale póki nie poznam jak dokładnie działa ten bug w ANTICu, to lepiej nie napiszę.
Download tu.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
atari.area forum » Programowanie - 8 bit » 480 linii
Strony Poprzednia 1 2 3 4 5 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Można i tak:
Wykrywanie trywialne i tylko częściowo pokrywa się z tym co robi prawdziwe atari, ale póki nie poznam jak dokładnie działa ten bug w ANTICu, to lepiej nie napiszę.
Download tu.
Ej, rozbudowywujemy atari800, nie jakieś atari++!
EDIT: no dobra, i tak super, że jakiś emulgator to wspiera :)
To kiedy będzie w atari800? ;)
Istotna uwaga do dyskusji w tym wątku...
Zajrzałem do książki "Telewizja - Poradnik" autorstwa Otto Limanna oraz Horsta Pelki.
Otóż, klatki nieparzyste (chwilowo określając je jako (i mod 2) == 0) są wyświetlane od początku lini (od lewej krawędzi), ale klatki parzyste ((i mod 2) == 1) za to od centrum poziomej linii. Biorąc pod uwagę fakt, że cewki odchylania pionowego nie przytrzymują napięcia na okres kreślenia poziomej linii tylko stale przesuwają wiązkę elektronów w doł, to początkowa pozycja w pionie wcale nie jest taka sama jak w klatce nieparzystej, tylko leży dokładnie w połowie trasy promienia pokonującego linię poziomą. Linia "pozioma" de facto nie jest linią poziomą na ekranie, a lekko pochylającą się w dół, patrząc od lewej strony.
eru nie miał racji pisząc, że Atari wyświetla obraz o linię niżej w klatkach parzystych, ale także nie miał racji Fox pisząc, że Atari wyświetla dwie klatki kolejne w tym samym miejscu. Ja również nie miałem świadomości tego faktu.
To przesunięcie o 1/2 lini skaningowej jest naturalną konsekwencją procesu wyświetlania obrazu w TV.
Tryby typu HIP działają zapewne dlatego, że odpowiadające sobie linie w dwóch kolejnych klatkach obrazu posiadają część wspólną (~0,5 lini skaningowej, a może i więcej). W takim wariancie mamy pustą przestrzeń (połowa lini skaningowej), jeżeli założymy że wysokość promienia rozciąga się na grubość jednej lini skaninowej, co wcale tak być nie musi.
Powstaje zatem pytanie - co uzyskał Rybags tak na prawdę?
jeżeli układ generujący imp. synchronizacji generuje tylko klatki parzyste lub nieparzyste to tak wyświetla obraz montor czy TV. Układ separacji impulsów identyfikuje o którą klatkę chodzi i wyświetla ją jako parzystą lub nieparzystą... a że GTIA generuje tylko jeden rodzaj klatek to cały czas są wyświetlane w tym samym miejscu (nie zachodzi przesunięcie).
Z tego co zrozumiałem to chciałeś powiedzieć iż zawsze lecą klatki naprzemiennie jedne niżej, drugie wyżej... a tak nie jest w przypadku standardowego obrazu generowanego przez ATARI czy nawet C64.
Jeżelibyśmy "szturchnęli" w schemacie opisanym przeze mnie w powyższym wpisie obraz w klatce parzystej o połowę wysokości lini skaningowej, to uzyskalibyśmy właśnie rozdzielczość "rozłącznych" 480 lini w pionie. Oczywiście, w pojedynczym półobrazie nadal rysowalibyśmy połowę liń (240), co drugą linię, ale w kolejnym półobrazie te luki zostałyby wypełnione. Być może właśnie to robi Rybags. Tylko tutaj powstałoby pytanie. Dlaczego standardowy obraz w TV nie jest tak wyświetlany?
Z tego co zrozumiałem to chciałeś powiedzieć iż zawsze lecą klatki naprzemiennie jedne niżej, drugie wyżej... a tak nie jest w przypadku standardowego obrazu generowanego przez ATARI czy nawet C64.
Czyli Atari/C64 standardowo generuje na sekundę 50 półobrazów o różnej zawartości, ale każdą "stempluje" jako nieparzystą (bądź parzystą), skutkiem czego są one WSZYSTKIE (50) wyświetlane zawsze w tym samym miejscu (w pionie)?
zawartość również jest taka sama chyba że robisz softwarowy interlace, czyli co ramkę zmieniasz zawartość wyświetlaną na ekranie. Jednak zawsze jest ona wyświetlana w tych samych liniach skaningowych monitora. Rybags dokłada dodatkowe imp. synchronizujące tak że układ ich detekcji w monitorze czy karcie TV interpretuje to jako klatki np. nieparzyste (zakładam iż domyślnie GTIA oznacza klatki jako parzyste).
W przyszłym tygodniu postaram się moje domysły potwierdzić screen-shotami oraz oscylogramami.
to o czym piszę jest troszkę opisane w linku który podawałem już wcześniej, czyli: http://martin.hinner.info/vga/pal.html
You can stop the display being interlaced if you want - the solution appears to be to just use the same sync pulse train each field, ie: the 6-5-5 one from 'field one' (which lasts 8 whole lines). I've seen it done like this in chip data sheets and tested it with my Z80 project (also confirmed with a oscilloscope connected to a Playstation2 running a non-interlaced game). The only 'problem' is that you're now dealing with 2 fields of 312 lines instead of 312.5 - which means you get a frame rate of 50.0801Hz instead of 50Hz - but TVs don't seem to have a problem with it. Presumably its possible to alternate between two different sized frames (312 and 313 lines) to maintain the 50Hz average but I've not tried it.
pozdrawiam
Seban
zawartość również jest taka sama chyba że robisz softwarowy interlace, czyli co ramkę zmieniasz zawartość wyświetlaną na ekranie.
Mieszanie znaczy się, nie interlace? Interlace to formalnie wybieranie międzyliniowe...
Jednak zawsze jest ona wyświetlana w tych samych liniach skaningowych monitora. Rybags dokłada dodatkowe imp. synchronizujące tak że układ ich detekcji w monitorze czy karcie TV interpretuje to jako klatki np. nieparzyste (zakładam iż domyślnie GTIA oznacza klatki jako parzyste).
Fragmenty książki, które zacytowałem zasugerowały mi, że typu kolejnego półobrazu nie można zmieniać swobodnie. Być może jestem w błędzie.
Pogrzebę jeszcze głębiej w literaturze...
w funkcji czasu:
tv rysuje sobie linie - jak juz wspomniales nieco na ukos, bo przez caly czas zmienia sie prad w cewkach odchylania pionowego, mniej wiecej w polowie linii, Garry wymusza impuls synchronizacji poziomej - tv odbiera sygnal i interpretuje, ze trzeba przerwac rysowanie aktualnej linii i confac wiazke na pozycje poczatku nowej linii - w tym czasie prad w cewkach odchylania pionowego nie osiagna jeszcze wartosci takiej, jaka by mial podczas normalnego zakonczenia rysowania linii poziomej, ale z grubsza jej polowe
wiec kolejne linie beda rysowane na nieco nizszych pozycjach niz normalnie
dosc jasne?
gdzies na aage sa oscylogramy, ale nie bardzo moge je znalesc :(
seban napisał/a:zawartość również jest taka sama chyba że robisz softwarowy interlace, czyli co ramkę zmieniasz zawartość wyświetlaną na ekranie.
Mieszanie znaczy się, nie interlace? Interlace to formalnie wybieranie międzyliniowe...
no źle sie wyraziłem trochę... pisząc software-owy interlace miałem na myśli typowe wyświetlanie na przemian linii parzystych i nieparzystych obrazka, czyli wszystkie TIP-y, HIP-y, RIP-y, XLP-MAX. To co dawało nam normalnie zwiększenie liczby kolorów/odcieni. Czyli dwie DL przełączane co ramkę, i linie parzyste i nieparzyste obrazka wyświetlane na przemian w tym samym miejscu.
Fragmenty książki, które zacytowałem zasugerowały mi, że typu kolejnego półobrazu nie można zmieniać swobodnie. Być może jestem w błędzie.
Pogrzebę jeszcze głębiej w literaturze...
No właśnie cała zabawa w tym iż możesz poinformować monitor/TV który aktualnie półobraz leci. Typ półobrazu (parzysty lub nieparzysty) monitor czy TV określa sobie na podstawie imp. synchronizacji pionowej w którym znajdują się informacje o typie aktualnie nadawanego półorazu.
Wydaje mi się iż czasach projektowania TIA,CTIA,GTIA czy nawet VIC-a... nikt nie myślał o wyświetlaniu obrazu z przeplotem, ba nawet Shifter z ATARI ST fabrycznie nie potrafi wyświetlać obrazu z przeplotem... pierwsze fabryczne prawdziwe tryby interlace miała chyba dopiero AMIGA.
Przy wyświetlaniu obrazu z przeplotem obrazów statycznych nie uzyskujemy żadnych efektów ubocznych, jednak gdy zaczyna się ruch (w szczególności w poziomie)... no to zaczynają się problemy.
No właśnie cała zabawa w tym iż możesz poinformować monitor/TV który aktualnie półobraz leci. Typ półobrazu (parzysty lub nieparzysty) monitor czy TV określa sobie na podstawie imp. synchronizacji pionowej w którym znajdują się informacje o typie aktualnie nadawanego półorazu.
Ok, to w takim razie trochę zamieszałem. Przepraszam za to.
Jeżeli jest tak, jak piszesz, to ten nowy tryb interlace będzie nieprzydatny w uzyskiwaniu nowych trybów programowych z udziałem GR9, GR10. Możnaby za to uzyskać płynniejszy scrolling obrazu w pionie.
Przy wyświetlaniu obrazu z przeplotem obrazów statycznych nie uzyskujemy żadnych efektów ubocznych ...
Obraz bardziej migocze. Dana linia obrazu jest rzadziej pobudzana.
Zastanawia mnie jednak to, czy czasem Atari nie zmienia częstotliwości wyświetlania obrazów, stosując taki myk i jak to ma się to do stabilnego wyświetlania obrazu na różnych odbiornikach telewizycjnych.
zrodelko od Garrego
zrodelko od Garrego
Not Found.
hehe... Bo w linku powinno być Rybags a nie Rygabs :D
Czy mógłby ktoś napisać jak to się sprawuje na realnym sprzęcie? Czy miganie jest widoczne?
miga, jak to interlace
u mnie nic nie miga.
mam bardzo stabilny - czarny ekran (konwerter svideo -> vga nie trawi tego sygnalu)
Stellar Shuttle 480i - game revamped.
Doubled vertical resolution and 16 step rotation of the asteroids and rocks.
Seems to be working on emu :)
Final (hopefully) release of Stellar Shuttle 480i
http://users.tpg.com.au/rybags/Atari/Stelr480i.xex
Reworked load sequence so now should load with any DOS.
Title screen changed, 8x16 Font incorporated into game.
Annoying bug in original game where UFO sometimes flashed onscreen and killed player fixed.
Strony Poprzednia 1 2 3 4 5 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Programowanie - 8 bit » 480 linii
Wygenerowano w 0.026 sekund, wykonano 63 zapytań