2,401

(108 odpowiedzi, napisanych Programowanie - 8 bit)

Marek Konopka napisał/a:
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.

Marek Konopka napisał/a:

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.

2,402

(108 odpowiedzi, napisanych Programowanie - 8 bit)

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

2,403

(108 odpowiedzi, napisanych Programowanie - 8 bit)

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.

2,404

(108 odpowiedzi, napisanych Programowanie - 8 bit)

Foxie ale pionowe paski w Heliosie to chyba bardziej ten "Aperture Grille" niż jednolite paski przez całą długość jak w przypadku Trinitron-a :) Ja miałem Philipsa 17" CRT i on faktycznie miał kineskop wykonany jak Trynitron, bardzo mi to odpowiadało (pozytywnie wpływało na jakość obrazu). Jednak niektórzy nie trawili Trynitron-ów bo widać było na nich dwie ciemniejsze poziomie linie mniej więcej w 1/4 i 3/4 wysokości obrazu (taka uroda konstrukcyjna tych kineskopów).

Ale co ja pierniczę... niezły offtopic zrobiłem ;P

2,405

(4 odpowiedzi, napisanych Sprzęt - 16/32bit)

Jak najbardziej to możliwe DRAM to w rzeczywistości kondensator który przetrzymuje ładunek, tak więc odcięcie zasilania nawet na jakiś czas nie powoduje usunięcia zawartości pamięci ;)

proponuje obejrzeć sobie np. film z tego linku... http://citp.princeton.edu/memory/ bardzo obrazowo pokazuje jak zachowuje się DRAM :)

2,406

(108 odpowiedzi, napisanych Programowanie - 8 bit)

Candle masz rację że w rubinach była DELTA :) Nie wiem co nazywasz Vertical Stripe ale Triniotron-owych kineskopów to jakoś dużo nie widziałem.... za to tych z przesuniętymi paskami całą masę :)

Tak przy okazji dyskusji o kineskopach:

http://en.wikipedia.org/wiki/Aperture_grille - to paski RGB
http://en.wikipedia.org/wiki/Shadow_mask - a to rubinowy układ Delta ;)

2,407

(108 odpowiedzi, napisanych Programowanie - 8 bit)

pionowe paski luminoforu to tylko w Sony Trinitron (http://pl.wikipedia.org/wiki/Trinitron) ;) Inne technologie kineskopów to tzw. układy "DELTA"

R
GB

lub paski RGB które są przesunięte trochę względem siebie.

RGB RGB RGB
  RGB RGB RGB
RGB RGB RGB
  RGB RGB RGB

2,408

(108 odpowiedzi, napisanych Programowanie - 8 bit)

Fox: sprawdzę na oscyloskopie oglądając imp. synchronizacji i dam znać ale to muszę z domu się ruszyć do lepszego oscyloskopu.

Krótki: Fox mnie uświadomił (parę postów wyżej) że mój pomysł to porażka z innego względu ;)

2,409

(108 odpowiedzi, napisanych Programowanie - 8 bit)

eru: no 50fps masz tylko gdy rysujesz jeden z półobrazów, automatycznie gdy chcesz rysować dwa to pełna klatka ma 25FPS bo potrzeba dwóch pół-obrazów do jej stworzenia. Czyli VBL masz nadal 50Hz tyle że cała klatka powstaje ze złożenia dwóch ramek... jedna zawiera linie parzyste druga linie nieparzyste obrazu (tak jak w zwykłym programowym interlace). Patent Rybags-a daje ci to magiczne przesunięcie o pół linii w dół, tak że faktycznie linie nieparzyste są rysowane tam gdzie powinny być a nie w tym samym miejscu jak w przypadku dotychczasowych rozwiązań.

Fox napisał/a:

Dekoder PAL skleja kolory w sąsiednich liniach, ale raczej nie między półobrazami.

Aaaaa.. Foxie masz rację... zupełnie o tym zapomniałem :( Mój pomysł mieszania 9,11 przy pomocy półobrazów upadł. No cóż... jak się pisze szybciej niż myśli to wychodzi się na durnia ;) I właśnie to zrobiłem ;)

2,410

(108 odpowiedzi, napisanych Programowanie - 8 bit)

pavros: Ale scroll jest wykonany na VBL co jedną ramkę... (zajrzałem w kod) co VBL rejestr HSCROLL jest de facto zwiększany o 1 lub o 2 jeżeli wciśniesz OPTION. Adres procedury scroll-a jest od $41E6.

jellonek napisał/a:

seban: obraz na tv tez sie sklada z 50ciu polobrazow, wyswietlajac 25 klatek na sekunde, czy widzisz jak to na tv mruga? chyba nie...

To zależy od treści i czasu reakcji kineskopu. I poza tym jak robisz softwarowy interlace to myślisz że jaki frame rate uzyskujesz? dokładnie 25FPS więc miganie jest dokładnie takie samo :)

A tak poza tym to nie ma co się spierać tylko sprawdzić trzeba fakty w rzeczywistości :) To nowy pomysł i teraz trzeba po prostu sprawdzić go w praktyce :D Oczywiście nie zakładam iż nie mylę się... sam nie sprawdzałem jeszcze nic dokładniej więc jak najbardziej mogę się mylić. W domu nie mam nic z CRT więc zanim będę mógł powiedzieć jak to wygląda na CRT minie chwilka.

2,411

(108 odpowiedzi, napisanych Programowanie - 8 bit)

Fox napisał/a:

1. Dlaczego 30 lat temu nie zrobili w GTIA bitu, który pozwoliłby się przełączyć między półobrazem parzystym a nieparzystym?

Wydaje mi się iż spowodowane było to tym iż bardziej komfortowe przy statycznych obrazach typu tekst, grafika było wyświetlanie ich 50 razy na sekundę w niższej rozdzielczości niż robić migające 25 obrazów co pewnie przy edycji tekstu i pisaniu programów byłoby bardzo denerwujące dla użytkownika. Poza tym chyba ciężkie byłoby uzyskanie takiego trybu pracy w przypadku trybów tekstowych. Nikt chyba nie myślał wtedy aby robić układ graficzny który mógłby generować na wyjściu obraz w trybie interlace... pierwszym przykładem użycia tego typu trybów była dopiero Amiga ze swoimi trybami x512.

Fox napisał/a:

Co do nowych trybów: nie spodziewałbym się rewolucyjnej poprawy trybów, które już wykorzystują stary (migający) interlace. Wygodne byłoby przełączanie trybów 9/10 co ramkę, a nie co skanlinię (byłoby łatwiej robić efekty w HIP/TIP), ale podejrzewam, że to jednak będzie migać (chyba, że telewizor 100Hz - ma ktoś taki?). Najwięcej zyskają tryby bez interlace - G2F, GR8 itp.

No a co do trybów interlace to chyba wszystkie mieszanki trybów 9,10,11 będą oczywiste :) Żadnego DLI co jedną linię ekranową ;) W jednej klatce wyświetlasz tryb 9, potem przełączasz się na linie nieparzyste i wyświetlasz np. tryb 11 ;) mamy 256 kolorów i dużo czasu aby coś jeszcze w tym trybie rysować :D

A migać to będzie w/g o wiele mniej bo linie np. trybu 9 będą zawsze w tym samym miejscu a linie trybu 11 w swoim, bezwładność CRT pozwoli zachować o wiele mniejsze migotanie obrazu niż w przypadky wyświetlania w tym samym miejscu dwóch różnych trybów na przemian. Ale to tylko moje domysły trzeba sprawdzić w praktyce.

2,412

(108 odpowiedzi, napisanych Programowanie - 8 bit)

chodziło mi o to że jak wykonamy screen-shoota używając karty TV w pełnej rozdzielczości PAL (720x576) to karta złapie dwa pół-obrazy. Pełna klatka będzie się składała z dwóch pół-obrazów... Jeden będzie zawierał linie parzyste a drugi nieparzyste. Scroll w każdym z pół-obrazów będzie miał inną pozycję (zakładam że scrollujemy co 1 ramkę, a więc 50 razy w ciągu sekundy) co powinno wyglądać tak jak na obrazku załączonym przez Rybags-a...

jeżeli jakiś dekoder PAL nie zrozumiałby nowych imp. synchronizacji pionowej wygenerowanych przez procedurę Rybags-a to nie widziałbyś tego charakterystycznego poszarpanego efektu, no chyba że karta ma włączone sprzętowe usuwanie przeplotu i na swoim wyjściu generuje już obraz z usuniętym przeplotem (25FPS progressive).

2,413

(14 odpowiedzi, napisanych Software, Gry - 16/32bit)

Co do teorii Jacques-a...

ależ to przecież wiadome od dawna iż pomysłodawca układów wchodzących w skład 8-bit Atari (Jay Miner, http://en.wikipedia.org/wiki/Jay_Miner), potem założył własną firmę po czym kupiło ją Commodore :) Także naprawdę Amiga ma więcej wspólnego z Atari 8-bit niż Atari ST, analogie są po prostu oczywiste:

ANTIC ze swoim Display List -> Copper wraz z jego cooper-listą oczywiście mocno rozbudowaną ze swoimi możliwościami w porównaniu do ANTIC-a :) btw. psychol miał fajny pomysł na upgrade GTIA tak aby miało ono coś w stylu copper listy :) (http://madteam.atari8.info/index.php?prod=gtia2), druga sprawa to np. budowa sprite-ów :) Dokładnie taka sama jak w przypadku A8 czyli obiekty długie na cały ekran, a więc kolejna analogia. Pewnie jakby przysiąść dłużej znalazło by się coś więcej, to w/g mnie dwa podstawowe podobieństwa które wskazują iż pomysłodawcą obu serii układów był ten sam człowiek (Jay Miner)

Kiedyś słyszałem jeszcze iż człowiek projektujący układy dla ST (np. Shifter) to człowiek pracujący wcześniej dla Commodore, ale w tej chwili nie pamiętam nazwiska więc nie jestem w stanie podać linku weryfikującego tą teorię.

2,414

(108 odpowiedzi, napisanych Programowanie - 8 bit)

tebe napisał/a:

czyli jest to sprzętowy interlace, mając tylko jedna klatkę obrazu włączając ten tryb uzyskamy interlace ?

Wtedy niestety uzyskasz w liniach parzystych nieparzystych dokładnie ten sam obraz... aby była dwa razy większa rozdzielczość musisz mieć dwie klatki obrazu... zawierające linie parzyste i nieparzyste.
Czyli obrazek 480linii i 2 DL-ki w których w pierwszej masz linie: 0,2,4,6,8  w drugiej 1,3,5,7,9... tak jak w przypadku softwarowego interlace... cały myk polega na tym że w tej dodatkowej klatce którą dokładasz te linie rysują się naprawdę pomiędzy tymi z normalnej klatki... masz dwa razy większą rozdzielczość tyle że narysowanie tego trwa dwie klatki ;)

Przy obrazach dynamicznych (np. jakimkolwiek ruchu w poziomie) pojawiają się oczywiście wszystkie problemy związane ze zjawiskiem przeplotu.

pavros napisał/a:

Scroll jest poprawny tzn. nie rozjezdza sie, jak to jest pokazane na zdjeciu wyzej. Niesamowity widok :-)

Znaczy że twój VGA converter dokonuje deinterlaceingu, albo jednak nie rozumie informacji że nadawana jest klatka nieparzysta.

pozdrawiam
Seban

2,415

(14 odpowiedzi, napisanych Software, Gry - 16/32bit)

[offtopic mode: ON]

dla mnie Wings of Death była jedną z fajniejszych gier na Atari ST :) I po tylu latach przez przypadek się dowiaduje że jest jej druga część :)

Sound Track z tej gry jest również wyśmienity :D Chociaż przyznam że z muzyką z Wings of Death jakoś bardziej się osłuchałem grając w nią godzinami :)

2,416

(108 odpowiedzi, napisanych Programowanie - 8 bit)

Rybags this is the greatest discovery of last years! Your idea is brilliant! Big respect for you and your great work! This is another milestone that will achieve even greater graphics capabilities!

THANK YOU VERY MUCH FOR THAT! And also many thanks for your willingness to share knowledge and experience!

with big greetings
Seban / SLIGHT

2,417

(108 odpowiedzi, napisanych Programowanie - 8 bit)

Nie przyglądałem się temu na oscyloskopie co generuje procedura Rybags-a, trzeba by jednak to zrobić i zobaczyć na ile zgodne jest to z tym co standard PAL przewiduje. Ale jeżeli jego karta TV w PC i jakiś monitor CRT złapały co trzeba i dokonały detekcji ramek parzystych i nieparzystych to jest spora szansa że będzie to działać globalnie na większości monitorów i TV. Dekodery PAL są mocno głupoto-odporne z racji że musiały sobie kiedyś radzić z kiepskim sygnałem złapanym z powietrza :) (analogowa telewizja naziemna) Tolerują więc większość rozbieżności w sygnale PAL.

Co do testów to jak się pozrastam i wstanę z łóżka to sprawdzę dokładnie ;) A tymczasem tutaj obrazek pokazany przez Rybags-a na Atari Age:

http://seban.slight.pl/aa/rybags_480i.jpg

zwróćcie uwagę na wygląd scroll-a :) To sugeruje że to istotnie działa ;)

2,418

(108 odpowiedzi, napisanych Programowanie - 8 bit)

dlatego podałem linka to strony zawierającej pokazane właśnie rysunki, podając również sekcję w której one się znajdowały :D Tyle że te rysunki nie pokazują tak dokładnie co się dzieje ;) Najprostszym wytłumaczeniem jest po prostu cytat fragmentu z omawianej strony:

Vertical sync is obtained from the last few and first lines of each field. These lines contain a series of special sync pulses which differ on alternate fields: -

The format for field 1 (starting at line 623.. ends at line 5 inclusive):

    * 6 Pre-equalizing pulses.. 5 long sync pulses... 5 Post-equalizing pulses.

The format for field 2 (starting at line 311.. ends at line 317 inclusive):

    * 5 Pre-equalizing pulses.. 5 long sync pulses... 4 Post-equalizing pulses.

2,419

(108 odpowiedzi, napisanych Programowanie - 8 bit)

kolejny BUG GTIA który daje fantastyczne możliwości :) Wykorzystanie tego iż GTIA przestaje generować poprawne imp. synchronizacji i aby syntezować je ręcznie był fenomenalny :)

2,420

(108 odpowiedzi, napisanych Programowanie - 8 bit)

Co do VBXE to sync pulses jest brany z GTIA myślę że można to bez większych problemów wykorzystać ten manewr z VBXE :) przełączając tylko parę rejestrów VBXE podczas VBL tak jak pisał Candle udałoby się pewnie zrobić 640x480 :)

2,421

(108 odpowiedzi, napisanych Programowanie - 8 bit)

różnica jest taka że gościowi udało się tak namieszać GTIA że dekoder synchronizacji w monitorze/TV faktycznie (tak jak jest to w prawdziwym obrazie PAL) w nieparzystych klatkach przesuwa cały obraz o 0,5 linii trybu ANTIC $0F w dół. czyli faktycznie można uzyskać prawdziwy przeplot (nie szybkie rysowanie w tym samym miejscu dwa razy) ale masz linie parzyste i nieparzyste (są dwa razy cieńsze). Na emu nic nie widać potrzebny real hardware.

No jestem pod wrażeniem i uporem gościa. Gość prawdopodobnie wykorzystał fakt iż GTIA gdy ma w ostatniej linii $0F normalnie zrywała synchronizację  i efektem był taki biały pasek. Prawdopodobnie GTIA w tym momencie na wyjściu generuje napięcie odpowiadające "blanking level" (DMACT=$03) a gdy DMACTL=$00 to robi się na wyjściu napięcie odpowiadające SYNC_LEVEL. Rybags ręcznie generuje serię impulsów synchronizacji odpowiadającej przełączeniu się monitora/TV na ramki nieparzyste (normalnie GTIA generuje tylko klatki jednego typu, chyba parzyste).

Czyli upraszczając dzięki Garry-emu macie do dyspozycji tryby real-interlace takie jak np. Amiga (w trybach x512) z prawdziwymi nieparzystymi i parzystymi liniami :) no chylę czoła przed gostkiem! SZACUN!

o PAL i Sync Pulses trochę jest tu: http://martin.hinner.info/vga/pal.html (sekcja PAL B/G/D/K/I, Timing)


A tutaj dokładna różnica pomiędzy impulsami synchronizacji pomiędzy klatkami parzystymi a nieparzystymi:

http://www.kolumbus.fi/pami1/video/pal.gif

RYBAGS! GREAT WORK! :D

2,422

(14 odpowiedzi, napisanych Emulacja - 8bit)

A w opcjach emulatora: ATARI->OPTIONS masz zaznaczone "H: patch"?

i weź popraw powyższego swojego posta :) Zaraz przyjdzie admin i się zdenerwuje ;) (chodzi o punkt nr 8 regulaminu forum, regulamin jest tu: http://atariarea.krap.pl/forum/viewtopic.php?id=817)

2,423

(14 odpowiedzi, napisanych Emulacja - 8bit)

eee... słuchaj.... jeżeli piszesz "ENTER "E:TEST2.LST"  to w przypadku ATARI nie oznacza dysku "E" tylko urządzenie "E:" które w systemie atari jest edytorem ekranowym, czyli próbujesz wczytać plik nie z dyskietki ale jakby to powiedzieć po "pecetowemu" z urządzenia STDIN :) tak jakbyś na PC napisał:

copy con:  c:\test.txt

OS Atari domyślnie instaluje urządzenia:

"C:" magnetofon
"P:" drukarka
"E:" edytor ekranowy
"S:" ekran graficzny
"K:" klawiatura

inne urządzenia pojawiają się po wczytaniu odpowiednich programów od ich obsługi, np. urządzenie "D:" pojawia sie po wczytaniu DOS-a.

rozwiązania masz dwa, albo wrzucisz sobie ten swój plik do jakiegoś pliku ATR wraz z dosem, albo tak jak pisano wcześniej użyjesz udawanego przez emulator wirtualnego dysku "H1:". Scieżki odpowiadające wirtualnym twardym dyskom ustawiasz w ATARI 800WIN po naciśnięciu ALT+H lub z menu Atari->Hard disks.

2,424

(14 odpowiedzi, napisanych Emulacja - 8bit)

a bez tego "\" działa?

2,425

(14 odpowiedzi, napisanych Emulacja - 8bit)

a tak się głupio zapytam, go co napisałeś w notatniku ma numery lini?

np.

10 REM *** TEST ***
20 GRAPHICS 0
30 ? "BUM!"

ENTER "D:\TEST2.LST"

no i ten back-slash "\" jest zupełnie niepotrzebny, pisz po prostu:

ENTER "D:TEST2.LST"