Dane modułu .SID ładowane są w obszar MEMLO+zrelokowany kod programu..$CFFF i $D800..$FFBF. W konfiguracji OSRAM obszar ten pomniejsza się o rozmiar kodu sterownika SDFS i bufory SDX (nie pamiętam teraz ile dokładnie tego jest i gdzie leżą).
Następnie zależnie od obszaru docelowego w którym powinien się znaleźć moduł określane są obszary pamięci do zachowania na później tak, aby zwolnić pamięć z której korzysta moduł .SID.
Są dwie strategie - domyślna i awaryjna.
Domyślna stara się zachować obszary z systemem i odtworzyć je po wyjściu z playera.
Awaryjna stosowana jest wtedy gdy nie da się zachować elementów systemu tak, aby je potem odtworzyć i wrócić bezawaryjnie do DOS-a. Wtedy wyjście z playera kończy się powrotem do SELF-TEST-u.
Tryb awaryjny stosowany jest tylko gdy użytkownik na to pozwoli przez włączenie przełącznika w linii poleceń lub zmiennej środowiskowej.
Kiedy dysponuję odpowiednią ilością XRAM programy systemu zachowywane są w XRAM i tryb awaryjny nie ma zastosowania.
Trudno mi podać konkretne wartości, bo zależą od załadowanych sterowników, ilości XRAM i konfiguracji systemu.

Edit: Ale robi się chyba niepotrzebny offtop. Ciekawiło mnie po prostu gdzie leży problem z wymaganiami SDX odnośnie uruchomienia playera SID, no bo starałem się żeby player potrafił poprawnie zadziałać na standardowym Atari XL/XE.

Zawsze mi się wydawało, że projektowałem swój player tak, żeby działał na 62KB. Ale może się jednak mylę.

Tak. Państwo było właścicielem :)

No tak. Nie zdziw się, że za swój pomysł dostaniesz potem 5% co najwyżej. Resztę weźmie kapitał, który przecież nie ma narodowości. No bo przecież to on dysponuje kapitałem, a ty "tylko" pomysłem, nie masz doświadczenia, nie znasz się na "finansowości" - uzasadnień jest mnóstwo. Tylko, że ten sam kapitał bez narodowości trąbi na okrągło o pomysłach i kreatywności, bo jednak o ironio - sam kapitał jakoś nie bardzo chce się pomnażać :/

Ale czy możesz legalnie taką nazwę utworzyć?

Nie. GITS nie można oglądać z dubbingiem. Ścieżka dźwiękowa i dialogi mają być oryginalne - melodia tego języka to połowa przyjemności z oglądania.
No zobaczymy co to będzie jesienią.

Do prawie każdego narzędzia w SDX masz instrukcję użytkowania dostępną za pomocą MAN (tzw. manual) w języku angielskim (czasem trzeba sobie go przy instalacji rozpakować z ARC-a i skopiować do katalogu z manualami). Są to zwykłe pliki tekstowe, więc można sobie je przetłumaczyć i wrzucić gdzieś do katalogu, po czym dodać do zmiennej środowiskowej MANPATH tę ścieżkę - wtedy polecenie MAN będzie szukać manuala w ścieżkach zdefiniowanych właśnie tam.
Manuale do poleceń systemowych znajdują się na CAR: (w większych kartridżach).
Poza tym, jak skrzyp napisał, dostępny jest aktualny podręcznik na stronie projektu, w którym masz np. informacje jak używać funkcji systemu z BASIC-a. No i podręcznik programisty (głównie ASM), ponieważ SDX udostępnia szereg mechanizmów nie znanych w innych DOS-ach na Atari (i nie - nie jest to tylko SpartaFS jak by się na pierwszy rzut oka mogło wydawać, przez co często nie da się przenieść programu napisanego dla SDX pod Sparta3.2, BW-DOS, RealDOS czy inne używające SpartaFS). SDX to nie jest tylko inny system plików.
W Atariki jest też kilka stron dotyczących programowania różnych rzeczy pod SDX.

O. Wielkie dzięki. Włączone były wyniki prywatne. Co za świat.

Można się o tym coś więcej dowiedzieć?

No, a Ty już ich zdążyłeś odsądzić od czci i wiary :)

Co tam 300 - 1000%. Ostatnio widziałem ZX128 za 2kPLN.

PMCNTL/GRACTL ($D01D) jest o tyle niefajny, że steruje włączeniem sprajtów a on nie ma cienia.
Z CONSOL'em faktycznie jest problem wskazany przez XXLa.
HITCLR ($D10E) służy do kasowania kolizji sprajtów.
Może GTIACTL/GPRIOR ($D01B)? Ten ma z kolei cień przepisywany na VBLK więc można by zapisać cień w dowolnej chwili, a i tak uaktualniony byłby na VBLK.
A może wykorzystać jakiś rejestr na $D0xx ale poza standardowym obszarem GTIA (jak to robi np. VBXE)?