@epi: Bo dobrze gra w ST07? Co do rozszerzeń to nie obstaję przy swoim - chodzi, analogicznie jak w przypadku przeróbek procedury odgrywającej CMC (bo tam też nie zmienił się w żaden sposób format zapisu muzyki), żeby jakoś można było automatycznie rozróżnić muzyczki dla odpowiedniej procedury grającej.
@miker: Pomysł z .ST ok, ale czemu ST9?

Musi to jakiś żołnierz...

Mnie linux raportuje 24MHz. Dzielniki działające (na brzegach względnie stabilnie) są w zakresie:

divider baud(PC)            dev(pal)            dev(ntsc)
190     126315,789473684    0,0028339991939     0,01192969909216
191     125654,45026178     0,00805476359602    0,01710284202885
192     125000              0,01322114503563    0,02222209805995
193     124352,331606218    0,01833398884373    0,02728830480575
194     123711,340206186    0,02339412292186    0,03230228261603
195     123076,923076923    0,02840235818893    0,03726483501287
196     122448,979591837    0,03335948901449    0,04217674911995
197     121827,411167513    0,03826629363878    0,04703879607873
198     121212,121212121    0,04312353458       0,05185173145207
199     120603,015075377    0,04793195902935    0,05661629561563

Odchylenia liczyłem dla baud=126674,785714286 PAL i 127840,892857143 NTSC wyliczone ze wzoru Atari.
No to teraz jeśli przyjąć że tolerancja POKEYa jest symetryczna, to prawdziwa prędkość transmisji to 123.35kbaud? Skoro tak, to może współczynnik jednak powinien wynosić 7,18610754177378?

Edit: divider w tabelce a nie hsidx; hsidx to oczywiście 0

Po analizie playerków w wersji 07 i 08 widzę, że:
1. Wersja 07 obsługuje:
- łączenie kanałów (autctl w patternie),
- zegar bazowy 1.77MHz dla #1 i #3 (ustawiany za pomocą yx w edytorze obwiedni częstotliwościowej, gdzie y jest dowolną nieparzystą wartością).
2. Wersja 08 obsługuje:
- filtr w #2 sterowany #4 włączony na stałe i używany do dudnień - wartość z #2 jest zmniejszana o 1 i wstawiana do #4,
- zniekształcenie instrumentu $Cx włącza pierwszą tabelę basów,
- zniekształcenie instrumentu $6x włącza drugą tabelę basów,
- nie ma brzmień 2-kanałowych (aczkolwiek kanały można łączyć w AUDCTL),
- zegar bazowy 1.77MHz dla #1 i #3 (ustawiany za pomocą yx w edytorze obwiedni częstotliwościowej, gdzie y jest dowolną nieparzystą wartością).
Jakby ktoś odkopał pliki dla ST w wersji 08, to mógłbym dodać support do playera.

Wersja 0.5 z poprawnym basem Rzóga (do tej pory go wcale nie było).
Załączyłem kawałek Cedynia p.t. HLEJNIA.CMR. Normalny bas można włączyć za pomocą /N żeby zobaczyć różnicę :)
Kierownik może ściągać player stąd.

Z klawiatury można sterować strzałką za pomocą Shift+kursory i Shift+Return. Shift+P odtwarza muzykę.
Edit: A = Shift+L ładuje song.

Tam mają być 4 zera. Kanał 1 i 2 jest w zybexie łączony więc warto by go ustawić po jednej stronie :)
Np.

[s]MUZ=A:>BIN>STPLAY.COM,% -1,-1,0,1 /X[/s]

Edit: Nie mogę sprawdzić na Atari bo zwaliło mi się SIO... hehe. Biednemu to wiatr w oczy itd.

Edit 2: No tak - późno już. Myślałem, że piszesz o STplay. Sprawdzę to zaraz.

Edit 3: Na emulu gra na obydwu kanałach równo. Ja żywym Atari nie mam chwilowo stereo jak wiesz...:/

E tam. Napisałbyś Mikey jakiś fajny programik.

Edit: Na ATARI!

Jeśli w ciągu głównym liczysz współrzędne punktów, a za pomocą cli, sei pozwalasz na wykonanie procedury IRQ, która w międzyczasie nadeszła, to może prościej (i szybciej) byłoby wywołać zwykły jsr bez uruchamienia przerwań. Przyjęcie procedury przerwania wymaga:
- zakończenia bieżącego cyklu rozkazowego (czyli cli) - rozkaz sei pobrany prefetchem podczas wykonania cli zostaje zignorowany,
- przyjęcia przerwania przez cpu - 7 cykli (odłożenie powrotu i rejestru znaczników cpu na stos, wstawienie adresu procedury obsługi przerwania z $fffe do pc),
- przy powrocie z przerwania rti wykona się drugie 7 cykli.
A jsr zajmie 6 cykli + 6 cykli rts, nie komplikuje algorytmu, jest przejrzystsze.

Edit: A jeśli już koniecznie chcesz użyć przerwań, to zrób zamiast cli, sei po prostu brk!

Tak.

Procesor zajmuje się wykonywaniem Twojego programu. W momencie kiedy pojawi się sygnał przerwania ustawiana jest odpowiednia flaga żądania obsługi w IRQST. Jeśli znacznik I procesora jest zgaszony (a gasi go rozkaz CLI), wtedy wykonywanie programu jest zawieszane, a CPU zajmuje się wykonaniem procedury obsługi przerwania. Po wykonaniu obsługi wraca z powrotem do wykonywania programu od miejsca w którym mu przerwano.
Jeśli znacznik I jest ustawiony, to CPU nie wykonuje przerwania. Do chwili kiedy nie skasujesz flagi I po prostu przerwania nie będą obsługiwane, ale odpowiednie znaczniki ciągle będą się palić w IRQST. Jak odblokujesz przerwania (CLI), wtedy procesor będzie ciągle przerywał Twój program i będzie obsługiwał przerwania do chwili kiedy w IRQST nie zniknie ostatnie żądanie. Żądanie obsługi przerwania znika kiedy następuje potwierdzenie jego obsługi - odbywa się to przez Twoją procedurę obsługi przerwania w sposób, jaki opisano wyżej - przez zablokowanie danego przerwania w IRQEN i ponowne jego włączenie w tym samym rejestrze.

Edit: Jeśli źródło przerwań zgłasza je często (TIMER1 może to robić BARDZO często - szczególnie z ustawionym zegarem 1.77MHz), może się zdarzyć, że podczas obsługi przerwania nadejdzie nowe żądanie. Wtedy po zakończeniu obsługi bieżącego przerwania CPU od razu wejdzie z powrotem do procedury obsługi przerwania.

Z tego co piszesz nie ustawiasz rejestru zezwolenia na przerwanie IRQEN ($D20E) wartością zezwalającą na przerwanie TIMER1 (#1).
SEI powoduje zablokowanie obsługi przerwań przez CPU, a CLI odblokowanie obsługi ale tylko tych, które są dozwolone w IRQEN. W żadnym wypadku NIE WYGENERUJE żadnego przerwania.
IRQST ($D20E) zawiera flagi informujące, że dane źródło przerwania IRQ jest aktywne. Poprawna obsługa przerwania polega na zablokowaniu i ponownym odblokowaniu przerwania w IRQEN dzięki czemu zniknie flaga zgłoszenia w IRQST.