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
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Lost Party 2025 startuje już jutro W Licheniu Starym rusza zlot fanów 8-bitowych komputerów
zeST 20250627 - Atari ST w FPGA z turbo! Nowa wersja zeST z trybem turbo 50 MHz i poprawkami Shiftera i MFP
UltraSatan - firmware 1.30 Nowa wersja firmware dla UltraSatana wspiera nowoczesne karty SDHC i SDXC
53 lata marki Atari 53 lata od założenia Atari - firmy, która odmieniła świat gier i komputerów.
Odtwarzanie układów z Atari Falcon Trwa zbiórka na odtworzenie chipów Videl, Combel i SDMA z Atari Falcon
atari.area forum » Posty przez xxl
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
> 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)
> 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
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...
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.
> 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.
pamietam z automatow ale nigdy na atari mi sie nie udalo ubic smoka (oczywiscie jest to mozliwe).
nie wnikalem ale raczej nie ma zakonczenia a jesli o "smoki" chodzi to sprobuj takiego zabic bez patcha :-)
wyglada zajefajnie. takich gier wlasnie caly czas brakuje na atari... patrzac jak szybko gra powstaje wydaje sie ze to takie proste :-)
> 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 :-)
> 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.
> 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.
> 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.
> 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
@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.
> 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 :-)
> 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 :-)
nie, to jest plajer dla karta SlightSID.
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?
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.
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)
> Długość jest znana - tzn. kto ją zna?
zapis jest przerywany jesli dotrzemy do konca pliku
> 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
Duuuuzo zmian, najwazniejsza: plajer nie relokuje danych - wczytuje bezposrednio pod prawidlowe adresy. powinien przez to czytac znacznie wiecej sidow niz poprzednio.
atari.area forum » Posty przez xxl
Wygenerowano w 0.208 sekund, wykonano 11 zapytań