Jak rozumiem Mazezam binary load wykonuje co chwila...
Jakoś nie spotkałem aplikacji na Atari, która potrzebowałaby binary load, poza DOSem. Chyba że programista lubi tracić kontrolę nad działaniem programu. Dane ładuje się przy pomocy open, bget, get, close, lylko to daje pełną kontrolę nad miejscem w pamięci do którego dane się ładują ich ilością i jeśli trzeba poprawnością.

Powtórzę moje pytanie z lekką poprawką po znowu czepniesz się czegoś innego "jaki sens ma stosowanie xbiosa w aplikacjach, które doskonale zmieszczą się w RAMie z DOWOLNYM DOSem i potrzebują funkcji dostępnych przez CIO"

P.-S.A tak na marginesie jeśli Mazezam byłby napisany zgodnie z zasadami działałby doskonale nawet z magnetofonem w T2000 bez żadnych zmian w kodzie gry zachowując pełną funkcjonalność.

Tyle, że w tym przypadku starzy wyjadacze ;) od dawna powtarzaja, DA SIĘ, bo to co jest w Mazezam, da się bez wysiłku zrobić zgodnie zasadami, bo xxl szuka niskiego MEMLO nawet w sytuacji gdy może ono być tak wysokie, że zmieści się pod nim ze 2 duże DOSy.

xxl piszesz teoretycznie. Ja nie neguję że coś takiego może się przydać ale... Czy Mazezam zajmuje całą dostępną pamięć i czy przypadkiem nie zmieściłby się bez kombinowania w pamięci  od $2000 do $C000 i jeszcze sporo by nie zostało?
Wystarczyłoby przed kompilacją ustawić adres startowy na $2000, nie bawić się w utrudniacze typu "a załadujmy coś bezpośrednio do wektorów pod ROM bo to pokaże siłę xbiosa" i zamiast 3 rozkazów JSR do xBiosa dać 3 wywołania CIO.

No po prostu narobić się przy tym trzeba strasznie i nie da się zrobić tego bez ogromnego wysiłku programistycznego - gratuluję.
Dzięki temu otrzymałeś "produkt", który do każdej kombinacji sprzęt-filesystem potrzebuje innej wersji pliku z biblioteką (sam pisałeś że musiałeś podsyłać komuś z ABBUC inną wersję biblioteki, bo nie odpalało się). I zwykły użytkownik, nie może go sobie ot tak za pomocą prostego COPY przekopiować np. na partycje SDX obsługiwaną przez SIDE, czy na dyskietkę z jakimś DOSem jeśli chce odpalać tę grę np. w trybie US (traktuj to jako przykłady różnych konfiguracji sprzętowych, zamiast udowadniać, że w tej konkretnej zadziała), bo do każdej takiej kombinacji potrzebuje inny plik biblioteki.
A jak sobie wymyśli jeszcze inne rozszerzenie, to nawet jeśli będzie ono w 100% zgodne z systemem operacyjnym Atarynki i tak będzie sobie musiał do tej gierki napisać bibliotekę, choć wszystkie inne programy będą działały bez kłopotu.

I to że ABBUC nie miał uwag... swietnie, tyle że oni potraktowali tę grę jako całodyskową i tak ją będą traktować w większości jej użytkownicy.... cała zaleta robienia jej w pliku bierze niestety w łeb.

Ale co za problem pisząc program, który potrzebuje załadować lub zapisać jakiś plik, używać standardowego OPEN (z podaniem nazwy pliku), BGET, BPUT i CLOSE ???
Oprogramowanie tego z poziomu assemblera jest trywialne. Na dyskietce systemowej MAC65 jest nawet zestaw makrodefinicji implementujących wywołanie tych funkcji w sposób identyczny jak w BASICu (jak się komuś uczyć nie chce).
Tak napisany program będzie działał pod każdym atarowskim DOSem, nawet takim, którego jeszcze nie napisano, z każdym dopalaczem, każdym interfejsem (pod warunkiem, że są zgodne z systemem). I będzie działał BEZ DADAWANIA BIBLIOTEK, po prostu po skopiowaniu i uruchomieniu.
Oczywiście jeśli naprawdę brakuje RAMu, a wyłączenie ROMu w czasie ładowania jest konieczne to przyda się inne rozwiązanie, ale w większości przypadków (taki Mazezam np.) nie jest to konieczne, bo program spokojnie odpaliłby się pod dowolnym DOSem, ale autor postanowił że ma być inaczej...

Pablo.... ale po co suwać. Dwie tablice po 256b i gra najrówniej bez suwania i nopów.

Oj z tym Command jako in/out to nie wiem czy się da.
Ale jeśli już czytanie stanu linii Command by działało, to dla mnie rozwiązanie jest oczywiste, korzystamy ze standardowego protokołu SIO, zakładając jakiś konkretny numer urządzenia przydzielony komputerowi. Reszta to kwestia oprogramowania (czekanie na zmianę stanu linii Command i jeśli tak to odbiór komendy, rozpoznanie, sprawdzenie czy jest ona "do mnie" i realizacja polecenia). Tak działałby komputer realizujący polecenia, a nadawca stosowałby standardową komunikację SIO.

Ale znając XXLa wymyśli coś tak pokrętnego, na około i niestandardowego, że moje sugestie na nic są tutaj ;P

Pytanie podstawowe. Do jakiego celu ma to służyć?
Bo może zamiast kombinować jak tu się dostać do pamięci Atari, należy zmusić Atari by samo wysyłało odpowiednie informacje do PCta. Czyli niewielka modyfikacja handlera "E:".
Wystarczy by działały wszystkie normalnie napisane programy (czyli z góry należy założyć, że żaden program napisany przez XXLa nie zadziała w takich warunkach ;) ) pracujące w trybie tekstowym.

Eeeee tam ze Streetem przesadzacie. Do emulacji WiFi jest zbędne, a cała reszta w Streecie jest.
No i z dwiema dobrymi grami w sklepie nówka 449zł.
Wiem bo kupiłem i potrzeby posiadania WiFi nie zauważam.

Devil inside....
A imię jego czterdzieści i cztery :)

E tam zaraz atak. Po prostu uściślić chciałem ;).

Bo w przypadku Jet Boot Jack Twój problem rozwiązuje sama gra, uruchamia się resetem, a potem zmienia wektory. A Final Legacy "cytowałem z pamięci" i nie wiem w czym dokładnie był tam problem.

Nie pamiętam teraz tytułu (poza tym, że nakombinowałem się z loaderem, żeby ta gra się łądowała), ale nic Ci to nie pomoże, prześledź sobie w ROM procedurę resetu i tyle.
Jeśli program ustawi komórki:

$033D, $033E, $033F (zwane magicznymi ;) )
$0244 - znacznik zimnego startu
i wektory
$02,$03 lub $0C,$0D  w połączeniu z odpowiednim stanem $09

NIC nie zrobisz i koniec. Ale powinieneś to wiedzieć i mieć tego świadomość (a wygląda na to że wiesz ale nie masz świadomości :) - bo w to, że nie wiesz ja nie uwierzę).