@Marok: sprawa wyglada nastepujaco:
identyfikator $ffff jest niezbedny jesli adresem ladowania bedzie $ffff - nie wazne w ktorym bloku (nie musi byc na poczatku). MADS generuje takie binarki prawidlowo. taka funkcjonalnosc zabrala 7 bajtow ;-) i polega na tym, ze pierwsza kombinacja $FFFF w bloku ZAWSZE jest pomijana, kolejne (nawet $FFFF) traktowany jest jak adres ladowania - skuteczne.
dlaczego? boot zajumuje 384 bajty i bylo sporo niezagospodarowanego miejsca wiec dodalem (wersja uniwersalna):
- obsluge formatu katalogu top dos, bibodos (128 plikow)
- dynamiczny zmiana mapowania pliku dla mydos/ataridos,
- sprawdzanie formatu SD/DD itp.
- funkcja load file
- przejscie z DSKINV na SIOINI
- jesli brak adresu uruchomienia program wystartuje od poczatku pierwszego bloku (*)
- jak ktos chce moze obsluzyc tez katalogi, zmiany gestosci i zapis
- obsluga adresu ladowania $ffff
(*) - obsluga adresu ladowania w pierwszym bloku przy systemowych prockach nie ma wiekszego sensu ;-)
wiec jest wybor - dedykowany boot lub uniwersalny. dedykowany jest pod flopka a uniwersalny niekoniecznie.
> Ale to załaduje tylko jeden bajt, czy następne, w np. 130 XE też?
nastepne tez, w 130 tez, to definiuje juz naglowek... moze byc tez jeden bajt.
> Czy to może tylko ewentualne przystosowanie do np. Rapidusa i jego liniowej pamięci?
format plikow binarnych na atari nie przewiduje pamieci powyzej maksymalnej dostepnej dla procesora 8bitowego. krotko mowiac w pliku binarnym nie mozna podac adresu wiekszego niz $ffff.
