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 :)

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

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ń.

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 ;)

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.

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.

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ę.

[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 :)

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:

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

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 :)

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:

RYBAGS! GREAT WORK! :D

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.

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

np.

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

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

ENTER "D:TEST2.LST"

ale ja myślałem że 83833-II ma tylko RGB input :D a się okazuje że ma Composite Video ;)