@Gzynio, boxa sobie mozesz zostawic :)

pisz na forum 8bit a nie tu. http://ixkuczek.republika.pl/ixkuczek_pol.html

> ale żaden nie załaduje bloku którego adresem startowym jest $ffff

xBios moze zaladowac 1 bajt gdy adresem startowym jest $FFFF

NOTE/POINT dodane, POINT moze sie przydac NOTE jak ktos lubi (nie kosztowalo miejsca w pamieci wiec dodalem)

POINT ustawia wskaznik czytania z pliku na bajt ktorego adres jest w rejestrze A,X,Y
NOTE czyta wskaznik, oddaje adres w A,X,Y

przyklad uzycia:

                ldy <file_name
                ldx >file_name                
                jsr xBIOS_OPEN_FILE

                ldy #$80
                ldx #$03
                lda #0
                jsr xBIOS_POINT

                jsr xBIOS_GET_BYTE

w akumulatorze znajdzie sie bajt o indeksie $000380 od poczatku pliku.

umknielo mi wczesniej a to moze miec dla niektorych znaczenie:

xBIOS_OPEN_FILE - otwiera plik do odczytu/zapisu (wymiany) mozna jednoczesnie czytac i pisac do/z pliku.

xBIOS_SET_LENGTH - jesli uzywamy to wystarczy raz ustawic, nie trzeba inicjowac po kazdym READ/WRITE

> sprawdzilem MADS nie generuje sygnaturki przed blokiem ladowanym pod $ffff

odszczekuje. MADS generuje sygnature $ffff przed blokiem ladowanym pod $ffff czyli wszystko gra

---
no jak to? :-) po kilku kilobajtach tekstu doszlismy do wniosku (mam nadzieje - hi Pecus) ze prawidlowo zbudowany plik binarny moze zawierac w naglowku adres ladowania pod rom :D

lekki offtop byc moze da odpowiedz skad wiadomo ze kolejne bloki w pliku binarnym nie musza miec sygnaturki w naglowku.

czy dos jest w stanie stworzyc taki plik? chyba nie, dos stworzy/polaczyc pliki binarne tak ze zawsze bedzie sygnaturka wiec skad pomysl ze nie musi byc sygnaturki? moze ktos podejrzal loadera w dosie i zauwazyl ze wynika to z jego uproszczonej budowy i mozliwy jest taki myk. ciekawe tez czy ktorys ze starszych kompilatorow gdy atari jeszcze zylo nie generuje sygnaturki w naglowku np Assembler Editor, MAC/65 lub Kyan Pascal ... ?

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

jesli sygnaturka pliku binarnego nie bylaby opcjonalna to mozna ladowac dane pod $ffff bez problemu. trzebaby sie dowiedziec skad wiadomo ze sygnaturka jest opcjonalna (moze Krotki by to wiedzial)

sygnaturka $FFFF jest opcjonalna przy kolejnym ORG (mads tak chyba robi) wiec kompilujac madsem po drugim ORG wystapi $org $ffff to bedzie lipa

> SDX w trybie BANKED ... co za OGROMNY zysk

litosci... czyli wszyscy maja miec minimum dodatkowe 128 ramu, moje atari nie ma 128 kb ramu. no i nie ma rozszerzenia w postaci sdx.

> strzal w stope? sektory maja 512 bajtow

nie bede Cie uczyl JTZ, madra glowa ta implementacje dla przykladu dla ide+ zrobilaby na 1 stronie pamieci...

> w związku z tym jeśli chcę ten kawałek pamięci użyć muszę mieć KOLEJNĄ WERSJE bibliotek, skompilowaną pod inny adres.

nie

> Czyli poza wersjami dla różnego sprzętu, powstawać będą wersję dla różnych programów

nie. poczytaj pierwszy post

> Czy nie lepiej jednak trzymać się zasad przy pisaniu programów??

od poczatku nie wymieniles ani jednaj zasady, wymieniasz OGRANICZENIA dosa.

nie wnikalem ale raczej nie ma zakonczenia a jesli o "smoki" chodzi to sprobuj takiego zabic bez patcha :-)

> Ostatnimi laty dużo się zmieniło w "pamięciach masowych" dla atari

kazda stacja SIO, ktora dziala standardowo bedzie takze dzialac z ta biblioteka bez zadnych zmian. chocby nie wiem ile sie w niej zmienilo. porazka? musialbym przestac pisac gry :-)

> Czyli - po prostu - zrobileś całodysk sektorowy.

oczywiscie, ze nie. dlaczego tak uwazasz?

> Wówczas dla danego urządzenia powinien istnieć loader (ale nie Twój !) który to uruchomi

oczywiscie ze nie moj, ja zrobilem tylko dla urzadzen SIO i ataridos fs :-)

> Warto by spisać zasady tworzenia prawidłowych plików binarnych,

jedyne ograniczenie pliku binarnego pokazal Marek Konopka.