magnetofon na którym nagrywałeś jest mono czy stereo? Pytam dlatego iż atari czyta dane z kanału prawego a plik mp3 jest mono więc jeżeli się nagrało na lewym tylko to będzie tak iż magnetofon Atari nic nie odczyta. Dane muszą być nagrane na prawym.  Na lewym kanale może być nagrane cokolwiek... nawet muzyka którą będzie słychać podczas wczytywania ;)

Ok, no więc tak:

MP3 do nagrania na kasetę masz tutaj. Trochę to będzie powolne i traumatyczne, ponieważ wczytanie każdej gry będziesz musiał poprzedzić wczytaniem tego pliku w standardzie (trwało będzie to około 3 minut). To najprostsze rozwiązanie. Wczytujesz to z kastety włączając ATARI z przyciśniętymi klawiszami OPTION i START.

Szybszym rozwiązaniem byłoby nagranie samych loaderów, a nie całej zawartości cartridge. Ja niestety samych loaderów do AST nie posiadam, a czasu na wygrzebywanie ich z obrazu cartridge nie miałem za bardzo. Drugim rozwiązaniem stosowanym w starych czasach było nagranie mini-loadera (1-2 rekordy) w standardzie i reszty danych (np. pełnego systemu już w turbo). Jeżeli ktoś ma ochotę i czas na przygotowanie takiego wynalazku to proszę:

"zdumpowany" cart AST w formacie DOS ast_cart.xex (można uruchomić z dowolnego DOS-a)
"zdumpowany" cart AST w formacie BOOT ast_cart.bot (można uruchomić po nagraniu na kasetę jako tzw. boot, wciskamy OPTION+START, włączamy ATARI i wczytujemy)

A może ktoś ma jakieś narzędzia i loadery do AST? Jeden z mikro-loaderów kiedyś dostarczył Pecuś, jednak nie mam nic co by nagrywało coś w AST (np. z pod DOS-a, dodając odpowiedni loader).

I jak się komuś jeszcze przyda to proszę, tutaj wersja CAS z której stworzony został plik audio: ast_cart.cas

A i jeszcze jedno, tutaj link do wątku w którym Pecuś udostępnił swój loader: http://atariarea.krap.pl/forum/viewtopi … 162#p76162

Ponieważ loaderów do AST było kilka rodzajów nie wiem jakiego rodzaju format wczytuje ten udostępniony przez Pecusia (nigdy nie miałem AST, dopiero niedawno zacząłem nadrabiać zaległości ;] )

pozdrawiam
Seban

http://www.faqs.org/faqs/atari-8-bit/fa … on-89.html

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.

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.

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.

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