"dla wygody" uuuuua :)
Po prostu bez tego skopiowania "dla wygody" i dołożenia przynajmniej jednego pliku zależnego od tego na co kopujesz i na czym chcesz uruchamiać, gra się z tego XEXa nie odpali. Nazywasz to wygodą???

Normalny użytkownik chce skopiować XEXa i odpalić grę ze swojego ulubionego DOSa czy loadera, albo skopiować ATRa i odpalić, dlatego będzie milion wersji tej gry, mimo że nie nazywasz ich wersjami.

O to jest już biblioteka z obsługą DD ?? no no.... cuuuudo? Jak rozumiem u Kaza w katalogu gier będziemy mieli najdłuższą listę wersji jednej gry. Jeżeli to o to chodzi - nie mam pytań - "Kawa i WZ-tka jest u nas obowiązkowa, bijemy się o złotą patelnię"?? :)

No, gratulacje, będą kolejne wersje na kolejne komputery, stacje dysków, HDD, SIO2SD, SIO2IDE, joy w drugim porcie, telewizor podłączony przez przejściówke SCART, monitor bursztynowy... i jeszcze dla Atarynek w różnych odcieniach obudów... Do roboty XXXL ;)

A nie prościej było (bez wysiłku) zrobić jedną wersję w pliku, bez nielegali, z komunikacją przez CIO ???

Tyle że przy klasycznym SIO (bez xBiosa) też taki player powinien działać (warunkiem jest niezajmowanie zbyt wiele czasu procesora przy NMI (klasyczne SIO stosuje przerwania maskowalne do obsługi transmisji i dobrze byłoby ich nie zablokować na zbyt długi czas) i działanie na dwóch generatorach - konkretnie tych, przez które nie chodzi SIO).

Gdzieś na starej dyskietce powinienem mieć napisany wiele lat temu malenki program rezydentny (bawiłem się pod DOSem II+, ale będzie działał pod dowolnym), który gra jakąś prostą muzyczkę w tle, a DOS dalej działa tak jak działał.

Nie wiem, co chciałeś udowodnić... rozumiem, że kolejną wyższość xBiosa, tylko jakoś nie wiadomo nad czym.

To że w grach i programach plikowych nie ma muzyczek w tle nie wynika wcale z tego, że się wcześniej nie dawało. Wynika to z tego, że stwarza to problemy użytkownikom (dowolne turbo dyskietkowe będzie zawieszało wczytywanie)... chyba że zmuszasz wszystkich do dłuższego czekania i wysłuchiwania za każdym razem muzyki....

... <pusty smiech> Mazezam </pusty smiech>.

I stosuje ją także w programach, które wolnej pamięci mają "wiadro" w związku z tym programów tych (mimo że są plikami i na plikach operują) nie da się skopiować i używać pod Spartą (napisz se bibliotekę), pod SIDE (napisz se bibliotekę), nie korzystają z dopalaczy (napisz se bibliotekę).... a wszystkie te utrudnienia tylko dlatego ze xxl chce na siłę i bez potrzeby udowodnić wyższość xBiosa, stosując go nawet wtedy gdy 3 wywołania CIO załatwiłyby sprawę i zapewniły zgodność ze wszystkim co na Atari powstało i powstanie.

No a jak już napisałbym sobie (czego robić nie zamierzam) bibliotekę do SDX z obsługą US i wpadłby do mnie kolega bez SDX prosząc o skopiowanie któregoś z tych programów na dyskietkę musiałbym zapewnić mu bibliotekę zgodną z filesystemem tej dyskietki i pamiętać dodatkowo że np. ma on Karin Maxi (napisz se bibliotekę).

Gdyby program stosował CIO (a wiemy, że spokojnie mógłby) skopiowałbym plik i voila.

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