A tam wielkie słowa.
.PSG to jest zwykły dump rejestrów AY (stąd wielki rozmiar pliku). Format prościutki (PSGFormat.rar): http://bulba.untergrund.net/progr_e.htm
Dokumentacja jest trochę nieścisła, ponieważ nagłówek naprawdę zajmuje 16 bajtów, lecz 4 pierwsze to identyfikator formatu i wersja, a reszta ztcw jest niewykorzystana.

A program odtwarza pliki w formacie PSG1 z prędkością 1 na ramkę (50 fps).
Plik jest ładowany do RAM, potem do XRAM. Evie testowane jest pod adresem bazowym $D2C0 - można podać inny adres przełącznikiem /A addr (jeśli kiedykolwiek w przyszłości zajdzie taka potrzeba).
/Q 1.77 lub /Q 2.00 włącza odpowiedni zegar bazowy, /2 dzieli go jeszcze na pół.
Testowo zrobiona jest jeszcze panorama /P pan podawana w tradycyjny spektrumowski sposób (ABC, CAB, itd.) pozwalająca na przyporządkowanie kanałów AY do kanałów stereo.
Muzyka nie jest zapętlana - odtwarzanie kończy się po odegraniu kompletnego pliku lub po osiągnięciu końca dostępnej pamięci (jeśli cały plik nie zmieścił się w pamięci dostajemy odpowiednią informację i player przystępuje do odtwarzania).
Warto zauważyć, że sterownik RAMDISK.SYS zabiera XRAM więc można udostępnić więcej pamięci rekonfigurując go w CONFIG.SYS. Informacja o ilości wolnej pamięci dla programów dostępna jest zleceniem MEM /X.

Plik .PSG można otrzymać odpalając dowolną muzykę np. pod emulatorem fuse http://fuse-emulator.sourceforge.net/. Za pomocą File>AY Logging>Record startujemy nagrywanie .PSG, poprzez File>AY Logging>Stop zatrzymujemy. Taki plik należy potem sobie przenieść dowolnym sposobem na Atari i odtwarzać.

Format .YM również jest dumpem, ale bywa inaczej zorganizowany (co w sumie nie przeszkadza, bo i tak wszystko jest naraz załadowane do pamięci) - .PSG jest strumieniem i można by go było odtwarzać strumieniowo bez wykorzystania pamięci. .YM ma też parę ficzerów typu SIDSound, odtwarzanie n x na ramkę i sample.

Na mojej stronie dostępne są pliki .ARC, .ATR i .ZIP. psgplaye.ext to ostatnia wersja, dostępna jest też wersja wcześniejsza psgplaye-0.1.ext - trzeba sobie zmodyfikować link.

Ile poziomów głośności ma obwiednia w implementacji? Jeśli 16, to mamy AY, jeśli 32 to YM (tam są tylko dodatkowe poziomy "między") :D
Od strony programisty zarówno AY, jak i YM się niczym nie różni (głośność kanału bez obwiedni jest zawsze 16 stopniowa).

Ależ przejdzie. Wystarczy, że na początku pliku znajdą się rozkazy:

isb $??FF,x ;$FFFF
inc $??FF,x ;$FFFE
dcp $??FF,x ;$FFFD
dcp $??FF ;$FFFC
lax $??FF,y ;$FFFB
lax $??FF ;$FFFA
aso $??FF ;$FFF0
isb $??DD,x ;$DDFF
lax $??FB,y ;$FBFB

Choć to prawie same niepubliczne, to zawsze chętny do oszukania DOSa wyprowadzi go w maliny.
Sam mógłbyś (podejrzewam, że z przewrotną przyjemnością :D) tak zacząć pierwszy blok programu, żeby DOS poszedł się kochać - choćby tym INCem. Stąd właśnie moja propozycja o zdefiniowanie nagłówka. Mniej mi chodzi o to żeby DOS zadziałał poprawnie, ale żeby użytkownik nie musiał restartować komputera przy próbie uruchomienia programu, którego w danym środowisku nie będzie mógł poprawnie odpalić. Mając identyfikator nawet głupi DOS może załadować Twojego xBIOSa i zrobić to, czego żąda od niego user.
Jeśli się nie da, to trudno - zawsze pozostanie rozszerzenie pliku.

Niewiele się różni, zresztą jak słychać komponenty te same! :D XE to był zawsze porządny sprzęt!
F16? Pin! - ukradłeś armii silnik od samolotu? A pomyślałeś o offsecie?

A może w ogóle zrobiłbyś dla plików xBIOSowych osobny nagłówek identyfikujący. Dzięki temu można by łatwo je identyfikować i ładować, albo i nie.
O ile wiem obecnie zajęte są:
$FFFF (ATARI)
$FFFE (Sparta)
$FFFD (Sparta)
$FFFC (Sparta)
$FFFB (Sparta)
$FFFA (Sparta)
$FFF0 (ACX)
$DDFF (BasicXE)
$FBFB (AlfAssembler)
Może coś w rodzaju $4278 :)?

Edit: Czy DOSy (i user) identyfikują sobie tylko po rozszerzeniu (powiedzmy .XB)?

Fajne, fajne.
1. Jak zorganizowane są pliki na dyskietce? Czy żeby poprawnie działało xBIOS_GET_FILE_OFFSET/xBIOS_SET_FILE_OFFSET plik powinien być zapisany w kolejnych sektorach czy też może być rozsiany po całym dysku (korzystasz z linków na końcu sektorów czy nie)?
2. Co robi zmiana katalogu bieżącego xBIOS_CHANGE_DIR? I pochodne - jak otwierasz plik? Czy przeszukujesz kolejne wpisy (64 lub 128 pozycji katalogu (jak wiadomo katalog w ATARIDOS zajmuje zawsze 8 kolejnych sektorów) i czytasz kolejne sektory katalogu)?
3. Na czym polega indeksowanie plików? Czy po prostu wyszukujesz odpowiedni plik w katalogu i ja (jako programista) mogę sobie wtedy zachować jego pozycję dzięki czemu mogę w dowolnej chwili czytać dowolny sektor i resztę pliku (i korzystać z xBIOS_SET_FILE_OFFSET)?
4. Jak wygląda zmiana xBIOS_SET_FILE_OFFSET np. z $1000 na $0 - czy potrzebujesz odczytać z katalogu gdzie jest początek pliku i przeliczyć pozycję (lub przelecieć się po sektorach i przeczytać wszystkie linki aż do chwili kiedy znajdziesz odpowiedni sektor pliku)?
Fajny pomysł z tym indeksowaniem - zaciekawiło mnie jak to działa i jakie założenia przy budowie dyskietki z .atr poczyniłeś.

Edit: A uchwyty! Przepraszam - uciekło mi trochę postów w wątku i przypadkiem zobaczyłem. Ale nadal ciekawi mnie zmiana offsetów i zakładana organizacja pliku na dysku.

A gdzie duchowieństwo? Szlachta służy do szlachtowania ;> Atarowska społeczność stanowa.

00:05:54:Jest pan na pustyni, idzie po piasku...
00:05:57:To początek testu?
00:05:58:Tak.|Jest pan na pustyni, wszędzie piasek...
00:06:01:nagle spogląda pan w dół...
00:06:02:Na jakiej?
00:06:03:Która to pustynia?
00:06:04:To nie ma żadnego znaczenia.|To tylko hipoteza.
00:06:07:-Ale co ja tam robię?|-Może ma pan wszystkiego dość, może...
00:06:09:chce być pan sam. Kto wie?
00:06:13:Patrzy pan pod nogi i widzi żółwia.
00:06:15:-Zbliża się w pańskim kierunku...|-Żółwia?
00:06:21:-Wie pan co to jest żółw?|-No jasne.
00:06:23:No, widzisz.
00:06:25:Nigdy nie widziałem żółwia.
00:06:29:Ale rozumiem co ma pan na myli.
00:06:30:Schyla się pan i obraca go na grzbiet.
00:06:34:To pan wymylił te pytania,|panie Holden?
00:06:36:Czy może kto je dla pana ułożył?
00:06:38:Żółw leży na grzbiecie,|smaży się na słońcu...
00:06:41:Przebiera nożkami, próbuje obrócić się,|ale nie daje rady.
00:06:44:To niemożliwe bez pańskiej pomocy.|Ale pan mu nie pomaga.
00:06:47:Jak to, nie pomagam mu?
00:06:48:Nie pomaga pan mu.
00:06:50:Dlaczego, Leon?
00:06:59:To są tylko pytania.

bSDM.

Jeśli jest miejsce, to byłoby bardzo fajnie, żeby można było zidentyfikować rozszerzenie. Umożliwiłoby to programom, które robią coś procesorem autokonfigurację (np. odgrywarkom sampli).

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 :)

Świetnie! Czy te POKEYe implementują feature z transmisją dwutonową z SKCTL? Czy implementują przerwania od liczników i czy da się je wykrywać metodą #2 Draka? Czy SID-a można wykryć metodą jak SlightSID-a? a może jest sposób na wykrycie Evie (wtedy wiemy co mamy na pokładzie)?
Pisałbym się również na egzemplarz. Playerów nie obiecam natentychmiast, bo Draco i Candle mi łeb ukręcą.

Edit: Transmisja dwutonowa interesuje mnie jedynie pod kątem brzmienia dźwięków w POKEY-u - sama transmisja mi niepotrzebna.