Dziękuję za kolejny update.

I przy okazji kolejny fajny kawałek demonstrujący możliwości brzmienia SID-ów grających stereo, tym razem zapraszam do posłuchania:

Melanoma Mood by Randall (format FLAC, 16bit, 96KHz)

To jest jeden z tych kawałków który zupełnie inaczej brzmi po zgraniu go nawet w 96KHz, zabawa muzyka filtrami w tym kawałku jest tak ciekawa że mimo iż SID teoretycznie nie może wygenerować tak wysokich częstotliwości to tym razem muzyk w porywie geniuszu (lub przez przypadek :P) zmusił filtry SID-a do wygenerowania tak wysokich harmonicznych że nawet przy 96KHz próbkowania muza brzmi wyraźnie inaczej niż oryginał lecący z SID-a...

Długo siedziałem i słuchałem, wnikałem co jest nie tak z tym kawałkiem, że po zgraniu w 48KHz kawałek brzmiał zupełnie inaczej - powiem wręcz że fatalnie, zresztą w 96KHz też nie brzmi doskonale ;) Ciekawy fenomen jak dla mnie, bo zdawałem sobie sprawę że takie efekty będą występować, i w tej wersji Slight-SID starałem się nie ograniczać SID-owi pasma  ani od dołu ani od góry... i uznałem że to co wypluwa z siebie SID będzie przeniesione 1:1 na wyjście, przyznaję że nie spodziewałem się aż takich różnic pomiędzy brzmieniem oryginalnego SID-a a wersją samplowaną nawet z wysoką częstotliwością, dla niedowiarków analiza widmowa fragmentu w którym szaleje filtr:

ps) Ta muzyka nie ma żadnych sampli, tak gra SID z player-em który wywoływany jest klika razy na ramkę.

Autor pewnie chętnie sam się wypowie, a ja co prawda się na tym nie znam, ale mam na ten temat własne zdanie i się nim podzielę ;)

Player napisany przez mono działa świetnie, zarówno na SlightSIDzie, jak i na Evie. Ma możliwość odgrywania subsongów, włączania/wyłączania filtrów, i, że się tak konkretnie wyrażę, w ogóle. Po zakończeniu działania wraca gładko do DOS-u. Działa ładnie zarówno na gołym Atari, jak i na takim ulepszonym (np. z Rapidusem).

Statystyka wygląda tak, że póki co na 145 przetestowanych sidów, nie zadziałało 11, w tym niektóre z przyczyn zupełnie obiektywnych, typu brak w Atari pamięci RAM w obszarze $d000-$d7ff.

Jak zwykle kawał znakomitej koderskiej roboty.

PS. Dwa nagrania z Evie:

Flimbo's Quest

For Avantgarde (to z kolei mój ulubiony)

Dziękuję drac030 za wyczerpującą odpowiedź.

Będę obserwować rozwój tematu.

Pozdrawiam

:)

Cos z tymi linkami nie poszło... :)

@wieczór: linki fixed :)

@pasiu: doskonale rozumiem co masz na myśli. Co do wysokości dźwięku to chyba jestem w takim razie głuchy ale słuchałem plików WMA które podrzucił Draco oraz tych które zgrałem ja i wyszło mi że te WMA grają niżej. Ja taktuje SID-a w przypadku PAL ~985KHz. Więc skoro taktujesz SID-a w Evie 992kHz powinno faktycznie grać wyżej.

prosiłbym bym w takim razie  jakiegoś muzyka o porównanie tego na jego słuch :) chodzi o kawałki Avantgarde oraz Flimbo's Quest.

porównałem również nie "na ucho", ale czysto matematycznie... no i Evie jednak gra niżej...

kolor niebieski Evie, Kolor czerwony SID8580R5, próbka z kawałka Flimbo's Quest.

@wieczór: ja mam to samo, wolę brzmienie 8580... i to nawet w kawałkach które były pisane dla 6581. Przesłuchałem ich wiele w obu wersjach i zdecydowana większość wypadała na korzyść 8580. Pisałem o 6581 bowiem autor muzyki pisał ją używając 6581 więc uznałem że takie brzmienie oryginalnie słyszał i no i Evie oczywiście grało używając charakterystyki filtra z 6581.

No teraz mozna porownywac. Na moje ucho wysokosc dzwieku jest ta sama. Evie ma troche bardziej ostry, spiczasty bas, natomiast wyrazna roznice słychac w poczatkowych uderzeniach perkusji - o ile brzmienie jest w zasadzie to samo, to ze SlightSIDa perca jest "gładka", z Evie taka bardziej pozakłocana, poszarpana. Tym niemniej oceniam, ze emulacja jest dosc wierna - byc moze kwestia w rozdzielczosci cyfrowego dzwieku (tylko nie wiem czy pionowej, czy poziomej ;) )

To bym musiał posłuchac chyba rownoczesnie :) Wiesz to jest 0.8% raptem, na pierwszy rzut ucha roznica jest niesłyszalna. Natomiast jesli Ci chodzi ze powinno byc odwrotnie, to moze własnie niekoniecznie - moze czestotliwosc generowanego dzwieku jest odwrotnie proporcjonalna do zegara? Zalezy jak fizycznie ten dzwiek jest generowany. Zeby sie o tym przekonac, musiałbys sciagnac taktowanie jakos tak dwukrotnie :) Poza tym porownujesz nagrany plik - sa jeszcze filtry na wyjsciach itp - tor audio nie jest ten sam.

A czy dwie wersje (6581 i 8580) SIDów mogą wylądować na tym karcie?
To czy ew. można zamieniać, który ma być podstawowym, żeby porównać jak grają - to o czym piszecie?

Zrobiłem taki analizator kodu, który wchodził w procedury init i play przelatywał wszystkie rozgałęzienia i wyłapywał odwołania do sprzętu (no i podmieniał je na moje). Okazało się, że taka statyczna metoda analizy jest mniej sensowna niż zwykłe search/replace. A czemu? A temu, że np. init $800 (cały .sid ładuje się do powiedzmy $4000) potrafi mieć w kodzie pętlę przepisującą dane playera i muzyki z $1000 na $B000. Za pętlą oczywiście jest skok do $B000, ale podczas analizy w tamtym miejscu nie ma oczywiście nic. Trzeba by symulować taki kod i w ten sposób określać gdzie jest program. To byłaby zresztą najlepsza metoda podmiany odwołań do rejestrów sprzętowych, bo bez ryzyka przypadkowej zmiany danych muzyki.
Póki co search/replace działa wg prostego algorytmu analizując dane pliku bajt po bajcie:
- sprawdzamy czy opkod chce 2 bajty argumentu
- sprawdzamy do jakiego rejestru się odwołuje argument
- sprawdzamy czy następny opkod wygląda na coś sensownego.
Te 3 kroki w połączeniu z testowaniem tylko opkodów do odczytu (kiedy rejestr może być tylko odczytywany) lub tylko do zapisu (kiedy rejestr może być tylko zapisywany) zawężają dość dobrze szanse na przypadkową zmianę danych. Ograniczana jest też lista rozkazów, którymi operuje się na danym rejestrze bo np ASL na rejestrze SIDa nie ma sensu więc raczej nie będzie zastosowany, ale już na rejestrach VICa może i jest nagminnie stosowany. 100% pewności nie ma i ciągle zdarzają się .sid'y które grają źle.

Jeszcze nie jestem zadowolony z playera, bo naprawdę programiści stosują przeróżne dzikie sztuczki. Zazwyczaj schemat wygląda tak:
1. init przygotowuje dane dla procedury odgrywającej.
2. Play wywoływany okresowo gra muzykę.
Ale również występuje inny:
1. Init przygotowuje dane + inicjalizuje liczniki taktujące.
2. Play gra muzykę synchronizując interwał z licznikiem.
Ale również inny:
1. Init przygotowuje dane + inicjalizuje liczniki i przerwania.
2. Playa nie ma.
Przy czym init wraca do playera i mogę sobie skonfigurować co tam chcę i odpalić.
Ostatni schemat jest najbardziej hardkorowy, ale też stosowany bo i czemu nie:
1. Init inicjalizuje dane + liczniki + przerwania (również IRQVEC oraz NMIVEC) i po czym włazi w pętlę bez końca ewentualnie czekając na jakąś flagę w sprzęcie (od licznika) i samodzielnie wywołuje procedurę odgrywającą (ponieważ w .sid nie ma o tym żadnej informacji, no to nie wiadomo która to procedura.
2. Playa nie ma.
Akurat nad ostatnim wariantem jeszcze rozmyślam, ale u siebie zorganizowałem sobie całą infrastrukturę analizującą które liczniki są wykorzystane i przydzielającą im przerwania POKEYa i jak do tej pory metoda się sprawdzała. Możliwe, że trzeba będzie zastosować jednak inne rozwiązanie. Przechwytywane są też wektory przerwań CINV i NMINV.
Problemów jest mnóstwo od adresowania pośredniego, po samomodyfikujący się kod.
Dlatego niechętnie podchodzę do takich formatów bo to nie jest żaden format muzyczny, tylko wyzwanie polegające na przechytrzeniu programisty. Powinni tego zabronić :P

Edit: Liczniki są potraktowanie umownie - równie dobrze może to być przerwanie rastra.

Wow, rozumiem, ze to odpadło rowniez :) Fajnie by było cos takiego miec tez na POKEYach :)

A ja mam pytanie co do stosowania filtrow SIDa na dzwieku wejsciowym z POKEYa - to sie włacza niezaleznie od tego co gra SID czy jest jakos powiazane? Pytam bo nie do konca wiem jak to działa - mam na mysli to, czy filtry uzywane przy graniu na kanałach SIDa maja automatyczny wpływ na wejscie, czy mamy nad tym pełna kontrole.