Co do loadera zgodziłbym się, bo uwzględnianie wszystkich możliwości prowadzi do paranoicznej polityki pisania programów. Chciałem wskazać potencjalne zagrożenia, bo piszecie o pewności zapisu do PORTB i to z poziomu loadera (czyli blokiem pliku wykonywalnego), a programista nie może zakładać że jego program zawsze będzie ładowany z Chaos Loadera po SIO z jednostronnej dyskietki o gęstości SD.
Nawet stawiając się w pozycji programisty sprzed 20 lat który nie mógł znać niuansów VBXE czy innych rozszerzeń, których wtedy zwyczajnie nie było (należy więc założyć że cokolwiek będzie z nowych rozszerzeń korzystać zrobi to tak, żeby stary program mógł poprawnie pracować), warto by moim zdaniem spojrzeć na rzeczy, które nawet 20 lat temu były. Mapping of the Atari zdaje się wskazuje że można założyć obszar $2000 wzwyż jako bezpieczny (nie pamiętam co mówi o włączonym BASIC-u). Ja rozumiem, że wielu programistów używało wskazywanych przez Was technik ładowania danych do banków extramu, ale te techniki niekoniecznie są dobrymi praktykami.

Akurat zapis do PORTB SDX-a nie wyłoży, bo  i tak SIO ładuje dane do bufora SIO po czym przerzuca dane do pamięci (nawet jeśli używany jest ramdysk, to po powrocie z SIO odtwarzany jest PORTB). Ale w PORTB są nie tylko bity od konfiguracji extramu - są też od OS-a, BASIC-a, cartridge-a i SELF-TEST-u. Skoro zamierza się używać extramu, to może należałoby pozostawić resztę bitów w spokoju, bo nie wiadomo jaki loader ładuje program?  Może akurat jest pod OS ROM-em, w MAPRAM-ie albo w ROM-ie carta XEGS (tak, wiem że to karkołomna sztuczka i że _do_tej_pory_nikt_takiego_nie_zrobił_)? Spróbujcie łaskawie spojrzeć może nieco bardziej perspektywicznie.

Edit: Warto też pamiętać o priorytetach okien MEMAC w VBXE/FX i extram. Zapis do PORTB może okazać się bardzo nieskuteczny.

Atariki http://atariki.krap.pl/index.php/Binarny_plik_DOSu mówi, że to cecha DOS XL i SpartaDOS (X siłą rzeczy też).

Edit: Czyli może to pomysł ICD?

@pin: Dodatek zawsze możesz wyrwać :)
@xxl: Czy będzie tam omówienie idei stojących za xBIOSem czy analogicznie jak w przypadku opisu nielegali - opis funkcji z przykładami użycia? Może dodałbyś tam coś więcej niż jest na stronie?

Już wiesz, ale dla potomności:

  blk dos $2000
  ...

  run $480
  ini $2000

  blk sparta $480
  jmp entry

  blk reloc main
entry:
  ...

I taka sztuczka załatwia sprawę, bo SDX faktycznie jeśli nie ma bloku RUN próbuje odpalić program od pierwszego załadowanego bloku (to pewnie jakaś zgodność z innymi DOS-ami).

Taki kod:

  blk reloc main
table:
?first .word 0
?last .word 0

table2:
  .byte [table.?last-table.?first]/4

generuje mi: "address relocation overload" !
Oficjalna dokumentacja (w historii) mówi: "błąd 'Addres relocation overload' wystąpi teraz tylko gdy wyrażenie będzie dotyczyć więcej niż jednej etykiety relokowalnej, poprzednio każde wyrażenie z udziałem etykiety relokowalnej powodowało wyświetlenie tego komunikatu błędu".
Ale jaki jest właściwie problem z etykietami relokowalnymi _w_jednym_bloku_? Bo ja rozumiem, gdybyśmy mieli etykietki w róznych blokach - wtedy nie wiadomo jaki będzie między nimi dystans, ale w przypadku jednego bloku wszystko przecież wiadomo...
Dałoby się to naprawić?

Edit: A druga choć związana z poprzednim przypadkiem rzecz jest taka - podobny kod;

  blk reloc main
table:
?first .word 0
?last .word 0
?len = [?last-?first]/4

table2:
  .byte table.?len

się kompiluje poprawnie, ale markuje table2 jako _adres_ do relokacji. A to już jest bardzo nieładne, bo:
1. w table2 mam bajt, a loader SDX zmodyfikuje mi tam 2 bajty,
2. table.?len jest jednak interwałem, który da się określić na etapie kompilacji i on się nie zmieni - nie powinien być relokowalny.
Kod wynikowy wygląda tak:

fe ff 01 00 00 00 05 00 
00 00 00 00 00 

fd ff 01 00 00 
fe 01
04 
fc

Edit2: Co myślałbyś o:
1. generowaniu "Addres relocation overload" tylko przy obliczeniach używających etykiet leżących w różnych blokach relokowalnych,
2. rzucaniu warninga kiedy do obliczeń używane są etykiety relokowalne - user ma być świadom tego co robi, a jak user sobie chce zaszkodzić, to niech sobie szkodzi :)

Orzeł wylądował! Książka super! Dzięki Duddie.

Ja poproszę sztukę.

Nazewnictwo, nazewnictwem ale bity adresujące banki są inne. Masz więc niby RAMBO (wg Twojej nomenklatury), które używa innych bitów (jak CompyShop). Wniosek stąd, że standardy standardami a rzeczywistość i tak bywa zaskakująca.
@koala: Zrób tę detekcję do cholery i będziesz miał problem z głowy :)

Pin chyba rzadko używa rdzeni R, bo ma w kompie gigamega ramu z U1MB.

W VBXE masz 2 banki - stały MEMACB leżący dokładnie w miejscu banku PORTB i MEMACA, którego położenie i wielkość możesz konfigurować.

Dzięki.