@FUJI: Ja oczywiście jestem po twojej stronie :-). Zapomniałeś tylko dodać, że gdy przy korzystaniu z CAS2SD na ekranie zobaczysz komunikat "Please rewind to scene 0" to przeklikanie się przyciskiem tegoż urządzenia do pliku "scene 0" (po liscie plikow) będzie znacznie łatwiejsze niż podanie docelowego numeru bloku. Po pierwsze, bo się go nie zna. A druga sprawa, że kłopotliwe byłoby ustawianie numeru bloku przy pomocy może dwóch przycisków lub wymagałoby to rozbudowy CAS2SD o klawiaturę numeryczną.

maly pisze o nozkach ukladu MC1377 co jest dosc oczywiste w kontekscie tego co pisal wczesniej. Uklady, do ktorych linki podal, choc zastosowane do konwersji RGB->Composite oraz RGB->S-Video dla Atari ST, rownie dobrze moga byc uzyte do konwersji sygnalow RGB z VBXE.
Prosze przed zarzuceniem komukolwiek niezrozumienia tematu dwukrotnie upewnic sie, ze samemu zrozumialo sie o czym ta osoba pisze. Gdyby nawet osoba nie rozumiala tematu (co w tym wypadku nie ma miejsca) to mozna jej zwrocic uwage w sposob kulturalny.

Racja, więc się nie upieram. Faktycznie trzeba poprawić emulatory. W przypadku jednak przyspieszonego wczytywania CASa przez emulator może być z tym pewien problem - emulator musi z góry wiedzieć ile OS przeznacza czasu na sygnał "pilota".

Bardzo proszę o podejście do tej kwestii ze zrozumieniem.
Piszę o plikach, jakie widzi Atari np. w programie kopiującym. Przykładem jest właśnie para plików binarnych: "wykrzyknik" i xex, które wchodzą w skład CASa. Przykładem są również gry składające się z kilku plików, takie jak "The Goonies", "Spy vs Spy 2", "Crumbles Crisis", "Winter Olympics". Te gry widziane z punktu widzenia kopiera na Atari są zestawem kilku plików. Chodzi mi o to, żeby była możliwość manipulacji zawartością CASa właśnie na poziomie takich plików składowych. W emulatorach natomiast przydałaby się jeszcze możliwość "przewijania kasety" na początek wybranego pliku (np. scene 0 w The Goonies gdy gramy od nowa). Teraz można przewijać tylko do konkretnego rekordu. Oczywiście manipulacja zawartością CASa na poziomie rekordów, o której wspominasz, też jest potrzebna.
Aha, ważna uwaga. Niemożliwość manipulacji CASem na poziomie plików składowych w emulatorze skutkuje np. tym, że gra wielo-plikowa jak "The Goonies", jest zgrywana do CASa na różne sposoby, czyli całość w jednym CASie oraz podzielona na blok główny i poszczególne sceny, gdzie dodatkowo scene 0 istnieje zarówno jako pojedynczy plik oraz znajduje się również w bloku głównym. Ten drugi sposób zgrania z podziałem na sceny jest robiony dla wygody grania pod emulatorem. Oczywiście taki podział nie jest konieczny, gdy wiemy konkretnie, od którego rekordu zaczyna sie poszczególna scena. Ale skąd mamy to wiedzieć? Potrzebny jest dodatkowy plik z informacją o tym! To oznacza w CASie nie mamy pełnej informacji o grze. Mi zależy żeby całą grę wielo-plikową wraz z pełną informacją można było zapisać w jednym pliku CAS.

Nie, nie chodziło mi o przechowywanie "katalogu" programów czyli jak rozumiem np. całej kasety w jednym CASie, niemniej to też w konsekwencji byłoby możliwe. Chodzi o gry wielo-plikowe (czytaj powyżej).
Nie wiedziałem, że CAS może zawierać więcej niż jeden blok FUJI. To by było w sumie wystarczające, choć niezgodne ze sposobem, w jaki gry wielo-plikowe są zgrywane obecnie. Czy którykolwiek emulator to wspiera?

Muzyka zajmuje wszystkie kanały pokeya. Z tymi efektami to raczej ciężko by było.

Wszystkim forumowiczom wesołych świąt oraz masy wolnego czasu, ktory można przeznaczyć na atarowskie produkcje w nadchodzącym roku.

@Candle: Tak, wiem, że nie działa na NTSC. Postaram się to poprawić w następnym releasie. Niestety zabrakło czasu w ramce, która w NTSC jest sporo krótsza, ale coś się wymyśli.
@miker: Masz rację, że tempo nie jest zbyt równe. Jest to zasługa Roba Hubbarda, który nie wiedzieć czemu, wprowadził do playera taki kod, który co 112 ramek VBL wprowadza jedną dodatkową "bezczynną" ramkę. Obliczyłem, że w skali całego utworu czyli 460 sekund zyskał 4 sekundy długości. Jedyne sensowne wytłumaczenie, to że zawarł kontrakt na utwór o długości 460 sekund :-) a tu mu trochę zabrakło. Jak widać, moje dążenie do maksymalnej zgodności z oryginałem w tym wypadku okazało się przesadą. Właśnie słucham muzyczki w wersji bez tego dziwnego wydłużania i teraz tempo jest już ok. W następnym release wrzucę tą poprawiona wersję.
Co do samej konwersji, to początkowo myślałem o czymś takim jak SID2POKEY Świętego, ale po głębszej analizie stwierdziłem, że w ten sposób nie uzyskam ani dobrej jakości dźwięku ani dobrej wydajności playera. Ostatecznie zdisasemblowałem player Hubbarda i przeprogramowałem go do współpracy z POKEYem. Zmiany dotyczyły przede wszystkim generacji różnych efektów jak vibrato, portamento, obsługi tablicy częstotliwości czy wreszcie definicji instrumentów i obsługi rejestrów POKEYa. Nie obyło sie również bez zmian w samym zapisie nutowym, ale były one bardzo niewielkie.
@mariuszbox: Dzięki.

Czy brzmi lepiej niż na C64 to nie jestem pewien. Na pewno brakuje tu efektów fali trójkątnej, zmiany współczynika wypełnienia fali prostokątnej oraz filtrów. Ale w sumie też jestem bardzo zadowolony z wyniku konwersji. :-)

Jesli chodzi o odtwarzanie muzyki stworzonej dla PAL na NTSC, to na przyklad w IK+ dla C64 zastosowano prosta sztuczke polegajaca na tym, ze w co 6-stej ramce VBL nie jest wykonywane wywolanie procedury playera.

Jak znajdę czas to zrobię. Oczywiście bez gwarancji poprawnego działania. A nie 262 linie?

Candle, zgadzam się z tobą. Mi jednak chodzi o policzenie tych linii, ktore widać. VBLANKu nie wyświetli raczej żaden telewizor/monitor. Napisałem że GTIA może wyświetlać treść w liniach VBLANK bo to jest fakt. Inna rzecz, czy należy z tego korzystać czy nie.

Oczywiście ja mówię teraz o tym prawdziwym VBLANKu zdefinowanym dla PAL czyli tych 12 liniach na samym dole obrazka, a nie o atarowskim VBLANKu (72 linie).