5,376

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

no wlasnie jesli chcemy ladowac od $ffff to musi byc poprzedzony sygnaturka i nie ma problemu ale skad wiadomo ze sygnaturka jest opcjonalna?

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

5,377

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

> 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)

5,378

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

> Czy wszyscy, jak Ty muszą zatrzymać się na etapie prehistorycznym?

moje standardowe atari ma 64kb ramu noi nie ma rozszerzenia sdx :). no niestety atari to juz prechistoria :D

5,379

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

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...

5,380

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

nie zaladujesz bezposrednio, takie jest OGRANICZENIE xBiosa, no to ja zacytuje pierwszy post:

$0000-$00ff
$0100-$01ff
$0200-$03ff
$0400-$06ff
$0700-$07ff    ; bufor uzywany podczas IO
$0800-$0bff   ; xBios
$0c00-$cfff
$d000-$d7ff   ; Atari HW
$d800-$ffff

do obszaru bufora i xBiosa bezposrednio niczego nie zaladujesz.

5,381

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

> 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.

5,382

(36 odpowiedzi, napisanych Software, Gry - 8bit)

pamietam z automatow ale nigdy na atari mi sie nie udalo ubic smoka (oczywiscie jest to mozliwe).

5,383

(36 odpowiedzi, napisanych Software, Gry - 8bit)

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

5,384

(89 odpowiedzi, napisanych Fabryka - 8bit)

wyglada zajefajnie. takich gier wlasnie caly czas brakuje na atari... patrzac jak szybko gra powstaje wydaje sie ze to takie proste :-)

5,385

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

> 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 :-)

5,386

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

> nawet robienie własnego SIO może skutkować tym, że z jakąś tam stacją już nie będzie działać - bo to jest jednak INNE SIO. A co z "turbami", które są w OSach i stacjach ? Najmniejszy wspólny mianownik ?

pojdzie, pojdzie :-) z turbo sie wypowiem bo to bylo jedno z zalozen:
turbo dla stacji jest jej rozszerzeniem, biblioteka dla stacji turbo rozni sie 1 bajtem ale nie bedzie przelaczana automatycznie, user ma wybor. uzywaj biblioteki pod twoja konfiguracje sprzetowa.

5,387

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

> 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.

5,388

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

> XXL zastanów się - przez 30 lat napisano OS i X DOSów, które obsługują Y filesystemów w różnych wariantach a na dodatek jest ileś tam urządzeń w różny sposób sprzętowo dostępnych,

powielano ten sam blad... pozwole zacytowac sobie pierwszy post:

obecnie dziala dla AtariDos i urzadzen podlaczonych przez SIO czyli stacje dyskow, SIO2SD, SIO2PC itp ale jesli ktos zrobi wersje na inny filesystem i/lub urzadzenie to tylko z pozytkiem dla userow tych urzadzen/filesystemow.

dla oryginalnego sprzetu atari biblioteka juz dziala i to sie nie zmieni, jesli ktos bedzie pisal wesje biblioteki pod konkretny sprzet/filesystem - zapraszam.

5,389

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

> O.K. Nie doczytałem o ładowaniu, czyli, trzeba będzie mieć DOSa,

jednak nie doczytales. nie trzeba miec tylko mozna miec. biblioteke mozna nagrac do boot sektorow i wtedy dos jest niepotrzebny, jednak wydaje mi sie lepszym rozwiazaniem, zeby gra byla uruchamiana (poprzez biblioteke) z dosa ewentualnie tez bez dosa z dowolnego bootstrapa

@Marek Konopka: prawda


> nie dopasowujmy systemu do gry, ale grę do systemu.

gra ma dzialac na sprzecie a nie wpasowywac sie w ograniczenia DOSa

5,390

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

@Krotki, poprawione...

> No nie ładnie  wykropkowałeś listę komend, NOTE/POINT na niej nie było...

zadnej listy nie wykropkowalem, zrobiles to Ty, nie mozna mowic ze wszystko pod dos jest wymienne bo nie jest i kropka :-) note point nie ma bo jest dla mnie zbedne.

> Pytanie podchwytliwe.... jak taka gra załaduje sobie bibliotekę ?? - no chyba że będzie ona wkompilowana w grę - czyli: gra będzie miała różne wersje pod różne filesystemy/urządzenia. Cudowny pomysł.... "ops gra nie działa, czy to wersja Pod SIO i AtariDOS, czy może pod SIDE i SDX a może pod SIO i SDX .... muszę ściągnąć inna."

gra nie laduje biblioteki, jest tylko jedna wersja gry, biblioteka jest dla filesytstemu/urzadzenia. widze ze nie czytales o czym mowimy... przeczytaj prosze pierwszy post.


> MEMLO naciągałem, ale dwie pozostałe to zasady

te "zasady" DOSa sa tak samo naciagnane. plik binarny nie ma tych ograniczen.

5,391

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

> DOSy są różne, .... to MUSI działać pod KAŻDYM DOSem

nieprawda, NOTE/POINT nie dziala tak samo w roznych dosach.

> Bo de facto gra z włączoną tą biblioteką będzie grą całodyskową zapisaną pod konkretnym filesystemem i działającą z konkretnym rozwiązaniem sprzętowym (w zależności od biblioteki oczywiście).

nie, gre mozesz sobie przeniesc na inne urzadzenie z innym filesystemem dla ktorego masz biblioteke i bedzie dzialac tak samo.

> To nie łatwiej pisać po sektorach?

nie, organizacja plikowa jest wygodna.

> Z zasady nie ładujemy pliku w miejsce

chcesz powiedziec ze zasady sa takie ze z zasady nie ...
gdyby to byly zasady chociazby z tym memlo to 90% gier by sie dzialalo

przykro mi ;-) obchodze te OGRANICZENIA


> A jak jako programista tej gry chciałbym otworzyć dwa pliki jednocześnie?

niestety, tylko jeden plik otwarty na raz. dlamnie wystarczy, musisz skorzystac z innego rozwiazania niz ta biblioteka.


> Może zakup w końcu 130XE i wtedy SDX załatwi Twoje problemy w większości...

te wszystkie rozszerzenia nadal nie pozwola mi na to na co pozwala ta biblioteka.


> Aaaa.... i zostaw $FFFA-$FFFF w spokoju

niestety, najlepsi tego nie robia. ucze sie od najlepszych :-)

5,392

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

> Tę bolączkę usuwa dowolny DOS, wystarczy trzymać się zasad, nie trzymasz się tych zasad widocznie.

DOS ma wygorowane wymagania dotyczace pamieci i zasobow (przy ograniczonych zasobach atari to jest nie do przyjecia), niestety co moze umyka Twojej uwadze jest zwiazany z filesystemem zbyt mocno. czyli gra napisana pod "dosa" moze nie dzialac prawidlowo pod innym dosem :-)
w przypadku tej biblioteki nie ma takiego zagrozenia.


> Mylisz ZASADY poprawnego tworzenia plików binarnych z ograniczeniami.

nieprawda, nie lamie zasad tworzenia pliku binarnego, jesli sie niezgadzasz podaj ktora zasad jest tu zlamana.
Wydaje mi sie ze to wlasnie Ty mylisz tu zasady z OGRANICZENIAMI w dodatku z kazdym DOSem innymi.
rozszerzam mozliwosci uzycia plikow binarnych i to znaczenie pozbywajac sie garba OGRANICZEN DOSa i niego samego.


> Jaki to "pozytek" że program będzie musiał mieć wersje pod:

nieprawda, gra/program ma tylko jedna wersje, API jest stale. to biblioteka odpowiada za komunikacje i to biblioteka jest w wersjach na filesystem/urzadzenie tak jak w calym bozym swiecie, zmieniasz sprzet to zmien biblioteke lub wybierz biblioteke pod konkretny sprzet, gry beda dzialaly nadal.


> "Wymyślasz"

nie wymyslam nic nowego, skorzytalem z mozliwosci atari. pamietaj, przyzwyczajenia zabijaja, zwlaszcza te zle :-)

5,393

(105 odpowiedzi, napisanych Fabryka - 8bit)

nie, to jest plajer dla karta SlightSID.

5,394

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

dodane:

xBIOS_SET_LENGTH        equ xBIOS+$1e

przyklad uzycia:

                ldy <file_name
                ldx >file_name                
                jsr xBIOS_OPEN_FILE

                ldy #$80             ; len = $380
                ldx #$03
                jsr xBIOS_SET_LENGTH

                ldy <load_dest
                ldx >load_dest                
                jsr xBIOS_LOAD_FILE

czyli $380 bajtow zostanie zaladowanych z pliku. jesli plik jest krotszy niz (w tym przypadku $380) lub nie podamy dlugosci zostanie zaladowany caly plik.

pierwszy post wyedytowany

> XBIOS jest już w 16/32bitowych Atarkach, więc proponuję zmianę, tak żeby się komuś nie pomyliło

ta nazwa funkcjonuje nie tylko na st ale na malym atari chyba nie?

5,395

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

wiem, ze tak mozna ale to nie jest wygodne. zaoszczedze kilka bajtow w bibliotece ale strace ergonomie.

zobacz jak przekazac parametr np do funkcja WRITE FILE a jak do PUT

zeby zapisac jeden bajt bedziesz musial w rejestrach trzmac adres danej przy PUT wystarczy do akumulatora zaladowac dana

lda dana
jsr

vs

ldy <adr_dana
ldx >adr_dana
jsr

ale oczywiscie przemysle to jeszcze bo moze sie myle.

5,396

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

mozesz miec racje. jedno co piszesz jest sluszne tzn. trzeba bedzie chyba dodac:

ldy <file_len
ldx >file_len
jsr xBIOS_FILE_LENGTH

jesli tego nie zdefiniujesz zapisujesz/czytasz zawsze do konca pliku jesli jednak wykonasz FILE_LENGTH to po tej operacji LOAD/WRITE FILE bedzie dzialalo tylko do dlugosci zdefiniowanej LUB do konca pliku - co wystapi wczesniej.
po tej modyfikacji faktycznie CLOSE bedzie wymagane - 2 pieczenie na jednym ogniu

jednak PUT I GET musi zostac (musze miec mozliwosc czytania zapisywania wiekszej ilosci danych niz pojemnosc pamieci)

---
no popatrz popatrz... myslimy podobnie ;-)

tak, wolnego miejsca jest jeszcze bardzo duzo (z 4 stron pamieci na biblioteke zajete jest niecale 3)

5,397

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

> Długość jest znana - tzn. kto ją zna?

zapis jest przerywany jesli dotrzemy do konca pliku

5,398

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

> Komenda xBIOS_WRITE_FILE nie przyjmuje parametru określającego długości pliku do zapisu.

ilosc danych do przeslania/odebrania ustalasz xBIOS_SET_LENGTH, jesli jej nie uzyjesz to komenda  xBIOS_WRITE_FILE zapisze caly plik.

> Bardziej intuicyjne byłoby założenie, że CLOSE jest wymagany za każdym razem,

CLOSE jest wymagane po operacjach zapisu WRITE i PUT. byc moze trzeba CLOSE nazwac inaczej.

mysle ze temat skierowany jest do programistow gier.

rozwiazanie to usunelo jedna z moich najwiekszych bolaczek czyli brak mozliwosci czytania/zapisywania danych pogrupowanych w pliki na dysku przy minimalnych wymaganiach - cala pamiec zajeta przez gre. co oferuje xBios - przedewszystkim wykonuje operacje na plikach i katalogach bez obecnosci DOSa, bez urzadzenia D:, bez systemu operacyjnego i bez przerwan. zajmuje 4 strony ramu, jest relokowalny i pozwala ladowac dane bezposrednio do calej pamieci (bez ograniczen stawianych przez dos) - rowniez do pamieci pod ROM. moze tez sluzyc jako inicjalizer/loader do gier.

wersje do pobrania oraz opis aktualizowany tu: http://xxl.atari.pl/?p=1076

--- edycja zrodla i opisu

5,400

(105 odpowiedzi, napisanych Fabryka - 8bit)

Duuuuzo zmian, najwazniejsza: plajer nie relokuje danych - wczytuje bezposrednio pod prawidlowe adresy. powinien przez to czytac znacznie wiecej sidow niz poprzednio.