Green Beret ma:

jerzyk@ox:~/atari/sidplay$ ./show.sh sid/greenb.sid 
File:  sid/greenb.sid
Signature: PSID2
Load/Init/Play: $9f90..$cff9*/$9fce/$cff0
Song: 1/21
Speed: 00000000000000000000000000000000
Title: Green Beret
Author: Martin Galway
Copyright: 1986 Imagine/Konami
Flags: 0000000000010100
 Built-in player
 C64 compatible
 PAL clock
 6581
Reloc: free $4000..$9eff ($5f pages)
Content:
0000000: 48 20 9e 9f 20 a8 9f 68 20 18 cf 4c b4 9f a5 01  H .. ..h ..L....
0000010: 8d c0 9f a9 35 85 01 60 a2 05 bd fa ff 9d c4 9f  ....5..`........

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.

Nie znam się, więc się wypowiem :)
Playery SID są bardzo różne:
- taktowanie ze stałą częstotliwością (PAL, NTSC lub "prawie 60 Hz"),
- taktowane z dowolną częstotliwością liczników CIA1 lub CIA2 zliczającymi takty CPU,
- synchronizowane z dowolną linią rastra (spotkałem się zazwyczaj z jednym konkretnym rastrem, ale nie jest wykluczona synchronizacja z różnymi liniami),
Sample zwykle odpalane są na osobnym liczniku CIA2 (NMI) poza playerem (IRQ rastra albo CIA1).
Playery są zazwyczaj bardzo krótkie, bo SID robi sam wiele ficzerów typu ADSR, modulacje, kształty fal, filtrowanie. Zauważyłem, że zazwyczaj jest to kilka, kilkanaście linii rastra (raczej nie przekraczają 20) - imho znacznie mniej niż w przypadku playerów POKEYowych. Jakkolwiek wszystkie dane trzeba mu wsadzić ręcznie - nie ma programu jak ANTIC. Rejestrów jest więcej bo 25 (+2 do odczytu - dokumentacja mówi że mogą być wykorzystane do modulacji programowych, ale trzeba by popytać Komodorowców czy ktoś z tego korzysta).
Trochę im zazdroszczę łatwości generowania bogatego brzmieniowo dźwięku :)

To samo dotyczy

Y=X/(2^N+1)

więc

Y=round(X-X/2^N)/2^N

Czyli dzielenie X/65 też będzie działać ładnie (i pewnie da się to uogólnić tylko ja nieuk jestem).

Problem nie polega na czyszczeniu ekranu (kanał #0), tylko na otwarciu kanału #6 do operacji graficznych, którego to kanału używa LOCATE. Jeśli chcesz zachować zawartość ekranu trzeba go jednak przepisać (wydaje mi się, że GRAPHICS 0+32 mimo, że powinno działać, to jednak nie działa :/).

Posługujesz się specjalnymi komendami SIO2SD w tym celu?

64 pliki w katalogu max.

@pin: Nie uzależniaj zakupu dobrego hardwaru od tego czy JEST na niego soft. Soft to sobie można nawet samemu napisać w (do)wolnej chwili :) A produkcja hardwaru to jest sprawa znacznie poważniejsza i nie każdy może to samodzielnie zrobić.

Edit: Korzystaj póki jest.

Dope... Doskonały soundtrack! Dzięki, bo kiedyś tego szukałem :)

Marudzicie. Kawałek ładnego programu - brawo Epi!

Właśnie tak to działa. Jeśli idziesz do sklepu bez pieniędzy kupić produkt A, to tak naprawdę idziesz po produkt A i kredyt - a więc po dwie rzeczy. Jeśli produkt A kosztuje N zł, to produkt A + kredyt kosztuje WIĘCEJ (nie ma darmowych obiadów). Jeśli więc przychodzisz z pieniędzmi i płacisz za produkt A a nie potrzebujesz kredytu, to płacąc tę samą kwotę płacisz również za coś czego nie potrzebujesz. Proste? Proste. Czyli jesteś (jestem) jeleniem.