Zaletą pomysłu xxla jest mały rdzeń realizujący proste operacje na fsie. Nie ma tam np. tworzenia plików o dowolnym rozmiarze, a tylko zapis slotów o z góry ustalonym rozmiarze (zawartość slota może mieć max tyle ile na niego przewidział projektant gry). Nie potrzeba też mieć ciągle włączonego OSu, żeby realizować operacje IO. Samo wywołanie funkcji jest znacznie krótsze niż jakiekolwiek wywołanie CIO (wyjątkowo wywołania funkcji SDX są krótkie). Ma swoje ograniczenia, ale ma też i ogromne IMHO zalety. Że każdy bajt pamięci podstawowej się liczy, to wie każdy komu jej zabrakło. Argumentacja ze 130xe też jest słaba, bo proszę sobie pomyśleć ile zachodu wymaga wykorzystanie pamięci bankowanej (jeśli nie, to dlaczego każdy kto myśli o wsadzeniu 816 do Atari od razu chce mieć pamięć liniową). A że projekt ma swoje ograniczenia - każdy ma :)

@electron: Jeśli masz na myśli BIOS np twardego dysku to przecież nie jest powiedziane, że xxl do niego nie skacze (tak, jak to robi OS Atari). Przecież SIO też zaimplementował tak, jak to robi Atari, ale bez użycia przerwań - czy to że nie skacze do ROMu Atari oznacza zaraz że urządzenia podłączone do magistrali nie będą działać? Czy jak ktoś zmieni ROM stacji dysków, to zaraz rozwiązanie xxl przestanie działać? Nie. Po to są interfejsy i standardy, żeby umożliwić pisanie softwareu niewrażliwego na zmiany po drugiej stronie/zmiany bebechów.
Każda gra napisana pod xBIOSa pisana jest standardowo, ale dla innego zbioru interfejsów. Interfejsów xBIOSa. Po prostu żeby gra zadziałała musi być załadowana biblioteka xBIOS. Czy będzie ona w sektorach boot, czy załadowana inaczej to kwestia drugorzędna.

Jednym z ograniczeń standardowego formatu pliku binarnego jest to, że bloki ładują się pod STAŁY adres. A w OS istnieje przecież coś takiego, jak MEMLO które jest olewane przez DOS podczas ładowania pliku binarnego (no AtariDOS chyba sprawdza czy nie próbuje się go nadpisać). Dopiero Sparta potrafi sobie blok załadować na MEMLO, ale ma już zupełnie inny format pliku niekompatybilny z resztą DOSów.
xBIOS xxla ma tę zaletę,  że zajmuje pamięć między $700..$BFF i wiadomo gdzie na 100% się nie ładować. I ta granica jest STAŁA (póki co ;>).
Założenie, że "porządny" DOS zajmuje pamięć poniżej $2000 jest sztuczne i jest konsekwencją stosowania formatu binarnego - gdyby chcieć na serio traktować MEMLO (a DOS nie ma do tego żadnego supportu) to trzeba by pisać programy relokowalne i własnoręcznie sobie je relokować. Inną opcją jest wykorzystanie ACX i wykrywanie czy mamy do czynienia z XL/XE oraz użycie relokatora, który jest UKRYTY w systemie i używany jedynie do ściągania driverów z urządzeń SIO. Dlaczego DOS z tego nie korzysta? Do w serii 400/800 nie ma? Zawsze można było rozpoznać rodzaj OSu i go sobie doładować.

@MarekKonopka: Przecież można załadować blok pod $FFFF - taki blok wygląda np. tak:

$FF $FF $FF $FF $FF $FF dana

Wiele loaderów pozwoli na adres końca mniejszy niż początkowy, co pozwoli od razu załadować dane na zpg, ale załóżmy że jest to niepolityczne bo a nuż w przyszłości Atari będzie mieć liniową pamięć poza 64k - kończmy więc na $FFFF.

Edit: Innym ograniczceniem podczas korzystania z extramu zgodnego z rambo jest nie umieszczenie pamięci ekranu/dlisty w $4000..$7FFF. Kolejnym jest cartridge z DOSem $A000..$BFFF. Obszar od $C000..$FFFF jest niedostępny, no bo to ROM a DOS nie potrafi tam niczego załadować. Więc aby ładować program w zgodzie ze sztuką należałoby używać w pliku binarnym dwóch obszarów:
- $2000..$3FFF,
- $8000..$9FFF (odpada kiedy mam karta 16K).
16K (8K przy bardziej wymagającym karcie) - hmmmm ciekawe, który z projektantów gier się tym przejmował?