nie narzekaj Jury, spójrz na to z szerszej perspektywy, Pasiu martwi się o miejsce w FPGA, umieszcza tam misz masz, mając MP3 masz jeden konkret który możesz wykorzystywać na różne sposoby, tracker dla MP3, będziesz miał instrumenty jako próbki MP3, ścieżki jak w Pro Trackerze etc., chcesz odtworzyć jeden długi moduł, proszę bardzo jest taka możliwość

jeden mógłby rządzić wszystkimi jak mawiał Tolkien

pasiu, mozesz zrobic film z grania tego:
http://asma.atari.org/asmadb/search.php?play=2319
oraz tego, co zostalo udostepnione w tym watku:
http://atariage.com/forums/topic/189077 … try2390478

Pajero nie mam takiego planu. RAMu brak - to jest jedna z różnic w stosunku do sound board-a.
Jeśli chodzi o PS/2, to planowane jest coś w rodzaju AKI. HW wspiera wszytko co potrzebne, więc trzeba tylko napisać parę rzeczy.

Kod w vhdl-u znalazłem. Pominien wejść zamiast 2 pokeyów.
Pytanie jak można zorganizować dostęp do jego rejestrów, bo zdaje się w YM jest trochę inaczej jak zwykle. Osobny rejestr dla adresu i osobny dla danych to chyba właściwa droga. Druga rzecz to częstotliwość taktowania YM-a. Jaka jest ta właściwa?
W sumie to i tak nie ma softu, który mógłby takiego YM-a sprawdzić, więc na razie nic z tym nie robię. No chyba że się coś zmieni :).

Teraz nie. Czy może to być do czegoś potrzebne?

Przerwania nie są obsługiwane. Drugiego pokeya daje się wykryć metodą Draco, ale gdy mam załączoną kartę turbo, to nie zawsze to się udaje i często pokazuje, że brak stereo.
Co do wykrywania SID-a, to odczytywana wartość z każdego jego rejestru daje $33. Tak jak podaje atariki.
Nie dodałem jeszcze czegoś co może powiedzieć, że jest evie na pokładzie, ale mam to w planie. 

Myślałem o tym, ale tego nie zrobiłem. Z dwóch powodów. Jedną z gorszych rzeczy, które trzeba robić to miksować kanały a mając tyle źródeł dźwięku mam problemy z uzyskaniem odpowiedniej głośności bez konieczności przełączania się na konkretne źródło (pokey czy sid). Dodanie opcji filtru dla pokeya czy covoxa zwiększy ilość miksowanych kanałów, co może negatywnie odbić się na poziomie dźwięku. Pewnie można lepiej to robić niż ja to zrobiłem. Jak ktoś wie, to niech powie.
Drugi powód to brak softu, który miałby to obsługiwać. Jeżeli jednak ktoś ma chęć tym się zając niech podniesie rękę.

Czy ktoś podpowie jak otworzyć sap-a na normalnej Atarce? Bezeceński format normalnie, ale chętnie bym to sprawdził.

Jeśli chodzi o te dźwięki z drugiego linku, to nie, PWM nie działa dobrze. Takiej odpowiedzi się spodziewałeś, czyż nie? :)

Pewnie, czemu nie. Czy ktoś zaznajomiony oszczędziłby mi szukania i powie jak to jest na innych platformach? Chyba ZX i ST jako pierwsze tutaj wchodzą w grę.

Wracając jeszcze do tego niechodzącego PWM-a. Jeżeli player wykorzystuje STIMER (a mniemam po źródłach, że raczej tak), to nie ma prawa to działać. Trzeba będzie jakoś to dodać.

/Edit/

Candle, ten sap nie chce ładować się pod Sapemu v0.2 Epiego. Masz to może w bardziej zjadliwym formacie?

> Pytanie jak można zorganizować dostęp do jego rejestrów, bo zdaje się w YM jest trochę inaczej jak zwykle. Osobny rejestr dla adresu i osobny dla danych to chyba właściwa droga.

tak

> Druga rzecz to częstotliwość taktowania YM-a. Jaka jest ta właściwa?

wydaje mi sie 3.5 MHz (na zx spectrum)

> W sumie to i tak nie ma softu, który mógłby takiego YM-a sprawdzić, więc na razie nic z tym nie robię. No chyba że się coś zmieni

na PC jest Vortax Tracker II (eksportujacy muzyke dla Atari ST i ZX Spectrum). moglbym napisac plajera ktory bedzie odtwarzal muzyke napisana w VortaxTrackerzeII.

Czyli de facto każdą muzykę 50hz z ZX Spectrum, bo wystarczy sobie wgrać cokolwiek na VT II i zapisać/exportować jego file (czyli z resztą skompilowany PT3, w każdym przypadku).

ewentualny plajer dla tej karty podobnie jak SlightSID Player bedzie uzywal xBIOS.

nie musze sie tym przejmowac, moje programy dla atari sa wyzszej uzytecznosci, nie emusze isc na kompromis zeby zapewnic sobie sukces komercyjny :-)

Mi po głowie chodzi jeszcze co innego - oczywiście playery odtwarzające natywne formaty dla określonych chipów jak najbardziej. Ale dodatkowy format wraz z trackerem do grania na wszystkim naraz, bo wtedy dopiero ujawni się moc tej karty :) Kupa roboty, ale skórka warta wyprawki. Wstępnie można zmiksować kilka playerów grających jednocześnie - mało optymalne rozwiązanie i pewnie pochłonie zbyt dużo CPU do użycia gdziekolwiek ale dobry wstęp jako proof of concept.

Co do taktowania AY, to dokumentacja określa 1MHz jako minimum, 2MHz jako maksimum. Ja bym się trzymał standardu Spectrum, to ma chyba najwięcej sensu.

1. Obsługę STIMER (sterowanie PWM przez kontrolowanie startu dzielników) i SKCTL (bit 3 - transmisja dwutonowa czyli filtrowanie licznika 2 zawartością licznika 1) polecałbym. To są ficzery, które rzadko (albo i nigdy) są obecnie stosowane, lecz IMHO dają pewne możliwości jeśli idzie o dźwięk i na pewno powstanie kiedyś narzędzie które będzie z tego korzystać.
2. Widzę że obsługa AY/YM przez jeden rejestr adres:dane to standard, ale zalecałbym rozwagę, ponieważ adresowanie 16 rejestrów w taki sposób niestety wydłuży czas działania playera (w podobnym stylu adresuje się kanały w SoundBoard). Umieszczenie wszystkich rejestrów w przestrzeni adresowej (może np. od D2F0?) uprościło by i przyspieszyło dostęp. CPU jest jednak wąskim gardłem - owszem, dźwięk może nie jest specjalnie wymagający, ale jeśli trzeba złożyć wszystko do kupy, to zaczyna brakować cykli w ramce (vide pojawiające się co jakiś czas wątki z pytaniami o najszybszy znany player). Wystarczy zresztą zobaczyć ile zajmuje odtwarzanie RMT, czy TMC 4x na ramkę :/
3. Przerwania - miła rzecz i cieszy :)

Wbrew pozorom to sie moze dac, o ile player gra na wszystkich chipach w sposob zintegrowany, tzn. uruchomienie jednego RMT na dwoch POKEYach, drugiego na pozostałych, SIDa na SIDzie :) i czegos jeszcze na AY zarznie procesor koncertowo - w najlepszym przypadku zagra ale to wszystko co zrobi. ALE(!) jesli player jest jeden grajacy na wielu chipach to robi sie tego znacznie mniej, dolozenie dodatkowego kanalu do istniejacego cyklu nie dociaza juz tak bardzo. Po drugie - granie na Pokeyu jest dosc czasochlonne z natury, gdyz nie posiada on mechanizmu obwiedni ani nic wbudowanego poza generowaniem w danej chwili czasu okreslonego przebiegu na generatorze z okreslonym poziomem zaklocen. Oznacza to, ze aby slyszec instrument trzeba do tego pokeya co ramke jakies tam wartosci pchac, a jeszcze wczesniej je wyliczyc tzn. jaka ma byc glosnosc w danej chwili czasu, czestotliwosc wynikajaca z vibrato itp. To troche pochlania a dwa razy na ramke to juz w ogole. Z innymi chipami - w ich programowanie jeszce nie wnikalem - moze byc troche prosciej? Covox sprawa oczywista, od grania sampli na pokeyu rozni sie w zasadzie jedynie jakoscia (8 bitow zamiast 4) i chyba jednym rozkazem na probke mniej, ale to nadal reczne granie.

Edit: dodatkowo jeszcze chyba SID nie jest formatem muzyki a kontenerem, czyms w rodzaju naszego SAPa, czyli zawiera cały player, albo STkowego SNDH. Zdecydowanie to nie jest najoptymalniejsza metoda grania :) Dobre do zagrania czegokolwiek niezaleznie od formatu, ale tu sie prosi az aby to odseparowac.

I emulator C-64 na Rapidusie, VBXE i Evie stanie się realny ;)